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