Re: OpenGL + XvMC
It *may* not always be required. There have been GLX extensions in the past (see my first message in this thread) that worked that way. However, as we discussed earlier, this doesn't seem to work so well with MPEG video files. The main problem being that you don't get the frames exactly in order. You're stuck doing a copy either way. Why ? You have usually enough video/AGP/whatever texture memory to store multiple frames. I haven't looked at XvMc, but there is a difference between rendering frames and scheduling them for display, you render them to multiple buffers and schedule display when your next expected display frame is ready. I completely agree that it's a big waste to still have a copy in cases where the HW let you avoid it Ben. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: OpenGL + XvMC
Can you use those non-power-of-two mpeg surfaces as normal textures without limitations? I don't think most hardware can do that, some possibly can't at all. Well for one thing my XvMC surfaces ARE power of two, but that is not the point. The HWMC engine used the very same texture engine as is used for 3d. So while the planar surfaces are not _great_ for use as textures it can be done. It is probably just as much bandwidth due to an internal conversion but the YUV planar to YUV packed conversion could happen render time into a temporary buffer. In the end, I think this is more of a neat trick than anything else so I don't think it matters a whole lot if there is an extra copy. I keep thinking that some sort of Direct Rendered Video extension would be very useful for X. You could then alloc a direct video surface that was mappable. Populate it from the final write in the decode process (From ANY codec) then either do a Put() a Blend() or a CopytoPBuffer(). The CopytoPBuffer() may be unnecessary if you could do a CreatePBufferFromXvD() to share the surface. In such a scenario I think the ability to save the copy is quite important. I am interested in getting mpeg into textures for the purpose of incorporating into 3D scenes and video editing/post production. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: OpenGL + XvMC
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 0x0010 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
Re: OpenGL + XvMC
Sottek, Matthew J wrote: 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. A pbuffer is (basically) just an off-screen window. You can do the same things to a pbuffer that you can do to a normal window. This includes copying its contents to a texture. There was a proposal to bring WGL_render_texture to GLX, but, in light of other developments, there wasn't much interest. It *may* be resurrected at some point for completeness sake, but I wouldn't hold my breath. 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. Well, except that, at least in the open-source DRI based drivers, the texture memory manager doesn't live in the DRM (anymore than malloc and free live in the kernel). 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. It *may* not always be required. There have been GLX extensions in the past (see my first message in this thread) that worked that way. However, as we discussed earlier, this doesn't seem to work so well with MPEG video files. The main problem being that you don't get the frames exactly in order. You're stuck doing a copy either way. 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. I think the goal is to be able to do both. Although, the idea of using MPEG video files as animated textures in a game is pretty cool. :) ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: OpenGL + XvMC
On Mon, 2 Jun 2003, Sottek, Matthew J wrote: 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. A pbuffer is a GLXDrawable like a window is. You can make current on it and draw to it. The intention of pbuffers is that they're always in hardware. 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. Can you use those non-power-of-two mpeg surfaces as normal textures without limitations? I don't think most hardware can do that, some possibly can't at all. I expect binding an XvMC surface as a texture isn't implementable without limitations on most hardware. It also requires that OpenGL do all the work for this since XvMC doesn't have access to OpenGL's texture namespace. It would also require cooperation between OpenGL and XvMC that makes me nervous. OpenGL would have to make sure that XvMC's Surface didn't go away while it was using it as a texture. An explict copy from the XvMCSurface to a pbuffer solves these problems with the cost of the extra copy, which at least for my hardware, isn't a big issue. Also, what is the goal exactly? I am interested in getting mpeg into textures for the purpose of incorporating into 3D scenes and video editing/post production. Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
