Re: [Dri-devel] Streaming video through glTexSubImage2D

[Ian Romanick]

Arkadi Shishlov wrote:

On Fri, Jan 31, 2003 at 10:26:13AM -0800, Ian Romanick wrote:

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

You are talking about extensions here, but my P3 600MHz Radeon8500 box
with ATI binary drivers is able to push normal frame rates in MPlayer
with 720x480 movies with OpenGL output driver at 80% CPU load.
30% with XVideo.
It use regular glTexSubImage2D, so it is either R100 or DRI beign slow
in this case (if CPU is powerful enough).

I'm 99% sure that the ATI driver multi-buffers textures. This was the second technique that I mentioned in my post to improve texture upload performance. There are probably other ways to pipeline texture uploads, but the DRI doesn't use any of them. My guess is that if you profiled it you would see that most of the wall clock time is spent waiting for the rendering pipe to flush.

I believe that this problem is the reason the guys at Tungsten implemented NV_vertex_array_range and the simplified version of APPLE_client_storage. The "real" fix is going to be a LOT of work. The current sollution is a good stop-gap method, though. I would suggest modifying MPlayer to use the var+client_storage work-around, and then help us implement the long-term fix. :)

I don't know much about extensions you mentioned, but how much you'll
save with MPlayer? One memcpy() (assuming it doesn't wait for texture
upload)?

It depends. Using a "real" implementation of APPLE_client_storage, your main loop would like something like the following, and it there would be little or no waiting and no copies. This loop would actually require APPLE_fence, but that would be fairly trivial.

The trick is that when you use a texture the driver uses pages from your memory space as pages for the AGP aperture. I don't know exactly what they've done, but I know that Apple has gone to some great lengths to optimize this path.

struct {
GLuint texture_id;
GLuint fence_id;
void * buffer;
} texture_ring[ MAX_TEXTURES ];

foo( ... )
{
/* Allocate memory, texture IDs, and fence IDs for the ring. */
....

i = 0;
while ( ! done ) {
glFinishObjectAPPLE( texture_ring[i].fence );
decode_video_frame( texture_ring[i].buffer );

glBindTexture( GL_TEXTURE_2D, texture_ring[i].texture_id );

/* Render with the texture. */
....

i = (i + 1) % MAX_TEXTURES;
}

/* Destroy textures, free memory, etc. */
....
}



-------------------------------------------------------
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