Let me preface my comment with "I don't know a lot about OGL" so some further clarification may be needed.
I am assuming that pbuffers are basically buffers that can be used as textures by OGL. I would then assume that the OGL driver would have some mapping of pbuffer id to the texture memory it represents, maybe this memory is in video memory maybe it has been "swapped out" so-to-speak by some texture manager etc. So basically this copies data from an XvMC offscreen surface to an OGL offscreen surface to be used by OGL for normal rendering purposes. Seems easy enough... I expect anyone doing XvMC would use the drm for the direct access (or their own drm equivalent) which would also be the same drm used for OGL and therefore whatever texture management needs to be done should be possible without much of a problem. My main problem with the concept is that it seems that a copy is not always required, and is costly at 24fps. For YUV packed surfaces at least, an XvMC surface could be directly used as a texture. Some way to associate an XvMC surface with a pbuffer without a copy seems like something that would have a large performance gain. Also, what is the goal exactly? Are you trying to allow video to be used as textures within a 3d rendered scene, or are your trying to make it possible to do something like Xv, but using direct rendering and 3d hardware? If you are trying to do the latter, it seems far easier to just plug your XvMC extension into the 3d engine rather than into the overlay. I think you've done the equivalent with Xv already. -Matt -----Original Message----- From: Mark Vojkovich [mailto:[EMAIL PROTECTED] Sent: Friday, May 30, 2003 4:30 PM To: [EMAIL PROTECTED] Subject: RFC: OpenGL + XvMC I'd like to propose adding a XvMCCopySurfaceToGLXPbuffer function to XvMC. I have implemented this in NVIDIA's binary drivers and am able to do full framerate HDTV video textures on the higher end GeForce4 MX cards by using glCopyTexSubImage2D to copy the Pbuffer contents into a texture. Status XvMCCopySurfaceToGLXPbuffer ( Display *display, XvMCSurface *surface, XID pbuffer_id, short src_x, short src_y, unsigned short width, unsigned short height, short dst_x, short dst_y, int flags ); This function copies the rectangle specified by src_x, src_y, width, and height from the XvMCSurface denoted by "surface" to offset dst_x, dst_y within the pbuffer identified by its GLXPbuffer XID "pbuffer_id". Note that while the src_x, src_y are in XvMC's standard left-handed coordinate system and specify the upper left hand corner of the rectangle, dst_x and dst_y are in OpenGL's right-handed coordinate system and denote the lower left hand corner of the destination rectangle in the pbuffer. "Flags" may be XVMC_TOP_FIELD, XVMC_BOTTOM_FIELD or XVMC_FRAME_PICTURE. If flags is not XVMC_FRAME_PICTURE, the src_y and height are in field coordinates, not frame. That is, the total copyable height is half the height of the XvMCSurface. XvMCCopySurfaceToGLXPbuffer does not return until the copy to the pbuffer has completed. XvMCCopySurfaceToGLXPbuffer is pipelined with XvMCRenderSurface so no explicit synchronization between XvMCRenderSurface and XvMCCopySurfaceToGLXPbuffer is needed. The pbuffer must be of type GLX_RGBA, and the destination of the copy is the left front buffer of the pbuffer. Success is returned if no error occured, the error code is returned otherwise. Possible Errors: XvMCBadSurface - The surface is invalid. BadDrawable - The pbuffer_id is not a valid pbuffer. BadMatch - The pbuffer is not of type GLX_RGBA or the pbuffer does not have a front left buffer. XvMCCopySurfaceToGLXPbuffer is supported if the following flag: #define XVMC_COPY_TO_PBUFFER 0x00000010 is set in the XvMCSurfaceInfo's flags field. I'd like to bump the API version up to 1.1 and add this. Comments? Mark. _______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel _______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
