glDrawPixels use in real-time?
Author
I would like to use the command glDrawPixels (with GL_DEPTH_COMPONENT or GL_STENCIL_INDEX) in real-time under windows, I mean I have to call it at each image. But it seems that it needs 30ms to transfer the pixels from the processor memory to the video memory, which is too long for a real-time application. Is it possible to accelerate this transfer, or to use another list of commands that will do the same thing? Indeed the problem is that the transfer locks the buffer and it stops the pipeline, and slows the application.
yannick Le Goc
I use glDrawPixels to copy the virtual framebuffer of my software renderer to the OpenGL Framebuffer. It also works in realtime, but I suppose its not the best way to do so. My Software renderer is able to do perspective correct texture mapping. With glDrawPixels I''m able to reach some 30fps, rendering a few cubes and a sphere. But maybe there is a faster way to blit images to the gl framebuffer.
glDrawPixels has a reputation of being slow (of course it all depends on the implementation). Make sure you turn off all the things you don''t need, such as texture mapping, lighting, etc. since OpenGL will apply such things to blits as well as rendered 3d primitives.
Unfortunately, glDrawPixels kills performance. It will stall the command stream FIFO and give a big burden to the AGP bus. Reading from video memory is even worse.
For what exactly do you need to write depth and stencil values ? You should check your algorithms, if there is any other way to achieve the results you want, without manually writing to the depth buffer. PBuffers or CopyPixels might help, but that depends on the 3D card. You could also look at depth textures.
If there is really no way around manually writing, and you have an nVidia card, then you should look into the NV_packed_depth_stencil extension, it considerably speeds up the access.
/ Yann
[edited by - Yann L on April 3, 2002 10:44:03 AM]
For what exactly do you need to write depth and stencil values ? You should check your algorithms, if there is any other way to achieve the results you want, without manually writing to the depth buffer. PBuffers or CopyPixels might help, but that depends on the 3D card. You could also look at depth textures.
If there is really no way around manually writing, and you have an nVidia card, then you should look into the NV_packed_depth_stencil extension, it considerably speeds up the access.
/ Yann
[edited by - Yann L on April 3, 2002 10:44:03 AM]
unfortuntly like the GDI SetPixel() glDrawPixels() performs format conversions for you on request. this requires the driver during copies to do some math which is ussually fast, but will slow things down some. furthermore due to bandwidth limitations, you can only get so much data across the bus in a reasonable amount of time. how much are you actually tranfering from system memory? 30ms for a decent sized buffer (ie 640x480x32 or higher) is acceptable. i am assuming you are actually drawing some geometry as well, and not doing just pixel operations. cause if you are just doing poxel operations, use directdraw or the gdi (via dibs). opengl does NOT handle perpixel stuff very well.
you may look into how animated textures are done (ie like the playing an avi tutorial on nehes site). since this seems like what you are doing.
please provde system specs, video buffer size you are transfering, and what you are trying to do.
*DONT read below unless you are open minded and believe opengl and d3d both have their strngths and weakness due to video card drivers, hardware, OS, portablity, and for the most part are EQUAL in performence and features if you try hard enough (and use proper coding for the api you use).
also if worse comes to worse, consider direct3d, older cards tend to have better support for d3d and hence you might get better performence for what you are trying to do (though i think you have a flaw in just how you are doing things). also d3d drivers ussually support accelerated agp transfers of sys to vid mem when using blit(). even old ati rage pros, since this was useful for directdraw apps as well. also because d3d''s blit() (or you can use lock()/unlock()) does not try to convert formats (ie its a blind copy) it will always be faster then functions that converts the color format. btw this is NOT meant to push d3d in favor of opengl, just to point some things out that may help explain why using functions like gldrawpixels is bad, an dthat since opengl is portable, somce of the functions tend to err on the side of portabliity then speed (since opengl cant assume things like d3d which is for the most part integrated with the os at some levels).
you may look into how animated textures are done (ie like the playing an avi tutorial on nehes site). since this seems like what you are doing.
please provde system specs, video buffer size you are transfering, and what you are trying to do.
*DONT read below unless you are open minded and believe opengl and d3d both have their strngths and weakness due to video card drivers, hardware, OS, portablity, and for the most part are EQUAL in performence and features if you try hard enough (and use proper coding for the api you use).
also if worse comes to worse, consider direct3d, older cards tend to have better support for d3d and hence you might get better performence for what you are trying to do (though i think you have a flaw in just how you are doing things). also d3d drivers ussually support accelerated agp transfers of sys to vid mem when using blit(). even old ati rage pros, since this was useful for directdraw apps as well. also because d3d''s blit() (or you can use lock()/unlock()) does not try to convert formats (ie its a blind copy) it will always be faster then functions that converts the color format. btw this is NOT meant to push d3d in favor of opengl, just to point some things out that may help explain why using functions like gldrawpixels is bad, an dthat since opengl is portable, somce of the functions tend to err on the side of portabliity then speed (since opengl cant assume things like d3d which is for the most part integrated with the os at some levels).
glDrawPixels does *not* do format conversion, if you don't ask for it. If your source data matches the destination buffer format, then glDrawPixels will do a straight copy transfer.
As for d3d: it won't change very much, at least on modern cards (with good OpenGL drivers, -> nVidia). Current 3D hardware can not DMA framebuffer data (only texture and vertex data), so the CPU is stalled while the bus transfer is active. So is the command stream FIFO. That's API independend, it's a hardware limitation. Current 3D hardware is highly optimized for texture and vertex uploads, but framebuffer transfers have been neglected. This might change on future cards, but until then I highly encourage you to stay away from any pixel transfer operations going over the AGP bus (and this is true for both OGL and d3d). Try to use textures instead.
BTW: make sure that AGP fastwrites and sideband addressing is active, this will generally speed bus transfers to vidmem up (a lot). And install AGP x4 drivers, if you haven't already done this.
/ Yann
[edited by - Yann L on April 3, 2002 6:47:36 PM]
As for d3d: it won't change very much, at least on modern cards (with good OpenGL drivers, -> nVidia). Current 3D hardware can not DMA framebuffer data (only texture and vertex data), so the CPU is stalled while the bus transfer is active. So is the command stream FIFO. That's API independend, it's a hardware limitation. Current 3D hardware is highly optimized for texture and vertex uploads, but framebuffer transfers have been neglected. This might change on future cards, but until then I highly encourage you to stay away from any pixel transfer operations going over the AGP bus (and this is true for both OGL and d3d). Try to use textures instead.
BTW: make sure that AGP fastwrites and sideband addressing is active, this will generally speed bus transfers to vidmem up (a lot). And install AGP x4 drivers, if you haven't already done this.
/ Yann
[edited by - Yann L on April 3, 2002 6:47:36 PM]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
