If texture is locked in DRI while rendering, the straghforward solution is to allocate new texture for every frame or reuse old one from the ring. The new texture will be free, one application thread can be dedicated to push texture to AGP and than into the card, while another threads can decode the video, eliminating stall. The method you described is just async io, the only advantage is that there is no copy app mem -> AGP mem. So multu-buffer is not an advantage over multithreaded approach (besides of sheduling overhead) but use of DMA'able memory directly is. Did I understood it correctly? Probably you can advice MPlayer HQ to use multiple textures in a ring to speedup mplayer on DRI (in case original problem poster system is not CPU bound)?
arkadi. ------------------------------------------------------- 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
