In case you've been wondering what the i915tex_privbuffers is good for, here's a short description. As the name implies, it uses private buffers... It gets rid of all rendering to shared buffers (you don't need a new ddx, it just won't use the buffers allocated there). The reason for this is that shared buffers are quite problematic, as you have to handle cliprect changes at any time and everywhere throughout your driver - and there's hardware which simply can't deal at all with such changes in the middle of a frame. So, all rendering is done to private buffers - even rendering to a front buffer isn't any different. Resizing the buffers is only done when a buffer is blitted to the real frontbuffer (and at makecurrent time, there are still outstanding issues there which need to be investigated) - if rendering to the backbuffer, this is at swapbuffer time, otherwise it's each glFinish (yes this is not performance-optimal, could use at least a timer-based solution to avoid excessive blitting, but who cares about performance of front-buffer rendering). Also, the fake frontbuffer will currently not copy in any content of the real frontbuffer, so you can't mix rendering with other apps (this could be added, basically would need to copy in/out on XWaitGL/XWaitGL probably to be conformant). The DRIdrawables cliprects are only used for blitting to the real frontbuffer. While the driver seems to look quite a bit nicer (and it handles things like xdemos/wincopy with ease now), just moving windows around looks much nicer now, there are some issues worth pointing out: First, no pageflip. This is not an easy to solve problem, non-fullscreen pageflip is completely out of the question, and fullscreen pageflip would require interaction with the X server. Triple buffering OTOH wouldn't be too hard to add back. Also, I've ripped out all the rotation code (instead of adapting it), since newer ddx do that on their own (though fail spectacularly here but that's a different matter...), so you won't have much luck with that. I couldn't test if changes in the virtualsize of the screen are handled correctly (because the current driver never seems to change it at all), but in theory this should be trivial - the dri driver basically has nothing to do at all if such a change happens. This is only tested to work on i915/i945 btw, you may have luck with i830/i855, at least I didn't intentionally break them...
Roland ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Mesa3d-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
