>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).
The texture manager itself may not but the drm is the arbitrator. As I understand it the app takes the lock and then manages the texture memory itself. The "good neighbor" approach, where the supervisor process just controls the locks and the apps are expected to play nice. An XvMC app can "play nice" by the same rules as the OGL app. The point was that there are no real technical roadblocks to making an direct rendered XvMC application use the same texture manager. >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. That is only a problem if you want to connect a "stream" of data to a texture. I.e. just bind an XvMC stream to a texture and have it auto-update. That is nearly impossible... XvMC has individual surfaces for each frame. The surfaces "live" for the life of the decode, they are not freed when the frame is done being displayed. So you have maybe 6 XvMC surfaces that you use again and again. That surface may, on some hardware, be directly usable with the 3d engine without a needed copy. >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. :) Mpeg in textures is a cool idea, and something of this nature would be needed for that. Using 3d hardware to display the video doesn't need this concept and due to the surface copy is probably drastically slower than using XvMC without OGL and just hooking it's final on-screen render up to the XvMCPutSurface. _______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel _______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
