[GEM-dev] Re: [PD] GEM Linux and video codecs

[Etienne Desautels]

Hi Chris,

On 05-06-10, at 12:33, chris clepper wrote:

>
> On Jun 10, 2005, at 8:54 AM, Etienne Desautels wrote:
>>> So I guess you are proposing that the part that opens files be 
>>> threaded
>>> so that loading the file off disk does not stall rendering?
>
> This would have to be pretty carefully done in GEM because a lot of 
> the APIs used are not entirely thread safe.  Quicktime is pretty hit 
> or miss with threading as is OpenGL.  Just opening the file is not 
> really causing the stall, but rather all of the other setup code and 
> buffer management.
>
> With Quicktime on OSX and Windows there might be a way to get around 
> this which involves using a reference movie.  The movie would contain 
> a reference to a set of .mov files and once loaded all of the setup 
> would be done once.  This might make switching between clips smoother.

Yes, that's true.

>>> This is impossible for your project because there is not enough RAM 
>>> to
>>> hold all the textures needed?
>>
>> Yes it's impossible. The minimum acceptable size and number of images 
>> I have to have is around 70 images of 2048x1024 plus others smaller 
>> images. 12MB each (decompression is to slow for large image, slower 
>> then reading from disk in my test and least color conversion, JPEG 
>> are YUV) x 70 =  840MB. And that's for the real minimum I need.
>
> How many of those images are loaded at once?

1 or 2 but with a few smaller ones ( around 120x40). Maybe in the 
future, the double, because I would like to drive to video output from 
one computer, one GPU.

>  If you load every single one using pix_image you will be far beyond 
> VRAM and performance will suffer.

Yes, I know. That's why I need to be able to load it only when I need 
it but without disrupting the display.

> Uploading images of that size to the GPU takes some time, which might 
> be the cause of the problem.

Maybe a part of the problem but I'm not quite sure. If I'm not wrong, 
AGP 8X have a bandwidth of 2.1GB/s. That's a lot ! I know that's the 
theoretical speed but at this speed it would take less then 6 ms to 
load a 2048x1024 (12MB) image from the memory to the GPU. I could not 
believe that's the main bottleneck. As a proof of this, I did some test 
in Python with pyOpenGL. At the beginning I had the same problem that I 
have in PD, the display was stalling when I loaded a 2048x1024 image. 
Then after, I did some changes and at every change the stall was 
smaller and smaller. Now I don't have any stall. My first change was 
reading the image in BMP instead of JPG. More time reading on the disk 
but no time for decompression and color conversion. My second change 
was putting the reading of the image in a thread. And my last change 
was putting the call to load the image just after the redraw of the 
scene. So, to me, the uploading of the images to the GPU seems to be 
only a small part of the problem.

Etienne

> cgc
>