PDA

View Full Version : glDrawPixels and DMA



pascalbamford
06-10-2005, 10:09 AM
Hopefully an easy one: if I glDrawPixels(), should I expect the GPU to perform DMA? Is this graphics-card dependent? I've run a simple loop to render an image stored in RAM, but the CPU (i.e. not GPU) runs at 100%. I've done this on high-end and low-end cards. Is there an openGL function to determine the capabilities of the graphics card (i.e. DMA Y/N)?

I want to be able to pan around a large offscreen image, stored in RAM, at high frame rates. The large offscreen image needs to be updated (read from disk) every now and then, so I need the CPU to be available to read data from disk and decompress for extended periods (i.e. several hundred frames worth of processing). I can run this in a separate thread, but the CPU is too busy rendering by the looks of it.

Any pointers? I've researched a fair bit (redbook etc.) without any answers yet... All docs seem to jump right into drawing triangles and things! Maybe I've got the wrong API?

THANKS

dvm
06-10-2005, 01:02 PM
Well, I had a case similar with yours, only I didn't have to change the images. I don't know, maybe you should try textures. Furthermore you could check texture compression (as in S3TC). If you could get your images compressed on the disk, maybe you could see some improvement. Good luck!

06-10-2005, 11:03 PM
Originally posted by pascalbamford:
Hopefully an easy one: if I glDrawPixels(), should I expect the GPU to perform DMA? Is this graphics-card dependent? I've run a simple loop to render an image stored in RAM, but the CPU (i.e. not GPU) runs at 100%. I've done this on high-end and low-end cards. Is there an openGL function to determine the capabilities of the graphics card (i.e. DMA Y/N)?

I want to be able to pan around a large offscreen image, stored in RAM, at high frame rates. The large offscreen image needs to be updated (read from disk) every now and then, so I need the CPU to be available to read data from disk and decompress for extended periods (i.e. several hundred frames worth of processing). I can run this in a separate thread, but the CPU is too busy rendering by the looks of it.

Any pointers? I've researched a fair bit (redbook etc.) without any answers yet... All docs seem to jump right into drawing triangles and things! Maybe I've got the wrong API?

THANKSglDrawPixels() does a lot more than just a simple memcopy since it depends on the setting of glPixelZoom(), glPixelStore(), glPixelMap() and glPixelTransfer().

So in general you cant expect a OpenGL implementation do utilize a DMA transfer during a glDrawPixel call and the high CPU load is probably caused by pixelscaling, color component swizzeling etc.).

zeckensack
06-11-2005, 11:33 PM
glDrawPixels will block the calling thread until all the data is pulled, to maintain coherency. Most of the time this means 100 per cent load. Perhaps if enough people complain to implementors, we'll see some drivers that yield instead ...

You should definitely look into using texture tiles, say 128x128. For some obscure reasons this is much more efficient on all hardware that matters today. IMO the only company that really cares about the pixel path is 3DLabs, but their market penetration is too low to rely on that.

pascalbamford
06-13-2005, 10:23 AM
Thanks for the tips. I'll look into textures but it sounds like I need dedicated h/w. Thanks again.

ZbuffeR
06-13-2005, 12:33 PM
Originally posted by pascalbamford:
I'll look into textures but it sounds like I need dedicated h/w.What do you mean ? :eek: any card post 1997 is able to deal with textures efficiently.