I've been thinking of trying to implement an XV adapter using OpenGL
and MESA_ycbcr_texture for YUV or regular RGB textures for RGB video. This would not only provide a default Xv adapter (in the event that the
hw didn't have one) or it would provide hw accelerated video playback
on hw that supports the appropriate OGL extensions. You would also not
be limited to a single window like most hardware that only provides a
single overlay. I mentioned this a while back, but I hadn't had much
time to think about it. I'm new to openGL so I'm still trying to
figure out what all would be involved. From what I've read traditional
openGL textures have to be a power of 2 and be RGB. MESA_ycbcr_texture
seems to handle the YUV colorspace, and it perhaps NV_texture_rectangle
allows you to get around the power of 2 issue. Am I even on the right
track here?
As a side note, it's interesting that this comes up now in dri-devel while a similar discussion is happening in [EMAIL PROTECTED] (the subject is "RFC: OpenGL + XvMC").
You're totally on the right track. However, there's one GL extension you've forgotten about that makes your job almost a no-op: APPLE_client_storage. It isn't very well supported right now, but with some improvements to Mesa and a few of the DRI drivers, we could make it 1st class.
The idea is the app captures a frame to memory "somewhere." The app then specifies a pixel packing of GL_UNPACK_CLIENT_STORAGE_APPLE. The Mesa part of the driver then keeps to pointer specified to glTexImage, glDrawPixels, etc. When the device specific part of the driver gets the pointer it does one of several things depending on where the data is.
1. If the data is in video memory (like on a VIVO card), it does a blit to copy the buffer.
2. If the data is in AGP memory, it does a normal texture upload to video memory or uses AGP texturing.
3. If the data isn't any video or AGP memory, it uploads it just like any other texture / pixel data.
There are two problems. As near as I can tell, the support for APPLE_client_storage isn't complete enough to handle all this. The other problem is there isn't a synchronization mechanism available so that apps know when they can touch their memory (i.e., NV_fence or APPLE_fence).
Technically speaking, there is no reason why any driver shouldn't expose this extension. Why force Mesa to have a copy of the image when the application already has one? There is some trickery involved. The application would have to supply the image data in *exactly* the right format that the driver could use, and there are probably one or two other corner cases.
Somewhere around line 848 in texstore.c (current Mesa CVS, in _mesa_store_teximage2d), there should be a check to determine if <format> and <type> match the internal format set ChooseTextureFormat *exactly*. If it's a perfect match, it should keep the pointer and set texImage->IsClientData. Then most of r200ValidateClientStorage would go away (it would actually be moved to _mesa_store_teximage2d & co.), and the rest of it wouldn't happen until uploadSubImage time. There may also be some endianness issues, but I'd have to think about it more.
Anyway, that's just my thought on the matter. :)
http://oss.sgi.com/projects/ogl-sample/registry/APPLE/client_storage.txt http://oss.sgi.com/projects/ogl-sample/registry/APPLE/fence.txt http://oss.sgi.com/projects/ogl-sample/registry/NV/fence.txt
------------------------------------------------------- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
