Morten Hustveit wrote:
Currently, the performance when streaming video through glTexSubImage2D is very low. In my test program and with mplayer, I get approximately 8 fps in 720x576 on my Radeon 7500 with texmem-branch from a couple of weeks ago. glDrawPixels is equally slow. I assume glTexSubImage2D is supposed to be able to process realtime video, since it handles extensions like EXT_422_pixels (for 4:2:2 Y'CbCr) and EXT_interlace.There are two typical ways to go about imporving texture upload performance in OpenGL applications. One is through the use of OpenGL extensions. There are several extensions available (or available any day now) to help this process. NV_pixel_data_range and APPLE_client_storage are the two most directly applicable. Neither of these two is /generally/ available in DRI. There is a version of NV_vertex_array_range in the R200 (and R100?) driver that can be used with APPLE_client_storage for texture data.
Using OpenGL for streaming video is useful for creating nonlinear video editing applications (I think Apple's Shake use OpenGL), because you will be able to preview many of the most common effects in realtime.
Is there any work in progress to make texture sub-image uploading faster? Which changes need to be done?
http://oss.sgi.com/projects/ogl-sample/registry/NV/pixel_data_range.txt
http://oss.sgi.com/projects/ogl-sample/registry/APPLE/client_storage.txt
Jeff Hartmann and I are in the process of designing a COMPLETE replacement of the memory management system for DRI. This re-work should allow for a full, proper implementation of APPLE_client_storage. It's going to take a lot of work, though. The way that APPLE_client_storage is implemented in MacOS X is the application mallocs memory for textures and the system dynamically maps those pages into the AGP aperture. This would be very difficult on x86, but I think Jeff has thought of a different way to get the same effect.
There is another extension from the ARB that should be available, literally, any day now to accelerate the process of uploading vertex data (it's a replacement for NV_vertex_array_range & ATI_vertex_array_object). John Carmack made brief mention of it in his recent plan update. As a follow on, there will likely be a version for texture data very soon.
I plan to have both these extensions implemented in DRI as part of the memory managment re-write. My personal opinion is that NV_*_range will universally go away after ARB_vertex_buffer_object gains ground. There are too many pitfalls with them for general use, especially WRT software fallbacks. The slow software path becomes even slower if the application "optimizes" by putting data in AGP or on-card memory. :P
The other way to speed-up texture upload performance is to double-buffer the textures in side the driver. The straight forward way to implement texture updates is to wait for rendering that may be using the texture to finish, then modify the texture data in place. If I'm not mistaken, this is how DRI works. The optimization is to allocate a new texture buffer if the texture has in-flight rendering.
This should be doable in the current implementation, but the implementation would be non-trivial. Basically, you'd have to add a way to track if a texture has in-flight rendering. In the TexSubImage functions for each driver you'd need to add code to detect this case. In this case the "old" driTextureObject would need to be added to a list of "dead" texture object (to be released when their rendering is done), and a new driTextureObject would need to be allocated. Periodically objects in the dead list would need to be checked and, if their rendering is complete, freed.
That's the 10,000 mile over-view. There's probably some other cases I'm missing. It might also be possible to implement most of this in a device independent way, but I would do it in a single driver first. I think the tough part will be getting the fencing right. If you (or anyone else!!!) would be interested in working on this, we can talk about it more in next Monday's #dri-devel meeting.
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
