Jens Owen wrote: > > Keith Whitwell wrote: > > > > Jens Owen wrote: > > > > > > Keith Whitwell wrote: > > > > > > > > Michael wrote: > > > > > > > > > > On Tue, May 21, 2002 at 12:14:45AM +0100, Keith Whitwell wrote: > > > > > > I have a .XF86config-radeon that sets ModulesPath to that directory, and >maybe > > > > > > I need to set an env var or two... I guess the magic is adding up. > > > > > > > > > > Yeah, I should have rtfm'd, ModulesPath into .../exports/lib/modules > > > > > fixes it, thanks. > > > > > > > > > > glxgears > > > > > 5229 frames in 5.0 seconds = 1045.800 FPS > > > > > 5210 frames in 5.0 seconds = 1042.000 FPS > > > > > > > > > > 200fps+ at least there > > > > > > > > I've done some more work & will probably commit shortly. > > > > This is good stuff, I think. > > > > > > It is! > > > > > > > Changes since last time: > > > > - Deprecate the Open/Close Fullscreen foo. > > > > - Automatically turn pageflipping on when there > > > > is exactly one 3d client > > > > -- There may be situations where this > > > > isn't a good idea, perhaps many many > > > > cliprects? > > > > > > Oh yeah, we won't have a private full size back buffer for single 3D > > > client anymore. The performance tradeoff will be relative to the > > > compexity of the model and the number of passes the 3D driver will have > > > to make to render into multiple clip regions. I think two passes by the > > > 3D driver will washout any gains made by flipping. Perhaps we could use > > > hardware stencil support to render a complex clip list in a single pass. > > > > > > > The good news is there's no real cost to switching between mechanisms, but we > > do have to decide at the start of the frame which one to use, and that frame > > has to be in the "non-flipped" state - ie. we have that opportunity to > > fallback every second frame, I think... > > Hmmm, aren't we going to need to fall back at any arbitrary time? For > example, let say the first app started (with page flipping) and rendered > and odd number of frames. Then if a second application starts, we will > need to fall back at that point regardless of which buffer is front and > which is back at the time.
Yes, this is what we already do. > Perhaps we stop page flipping, but we don't stop the mechanism of > dynamically assigning front and back buffers. > > Here's the scenario I'm thinking of: > > Buffer A assigned to be "front" buffer at server init > Buffer B assigned to be "back" buffer at server init > > Server does 2D rendering to Buffer A (current front) > > 3D application 1 starts > 3D driver 1 enables page flipping mode > 3D driver 1 copies Buffer A to Buffer B for entire screen Yep, but the Server does the copy. > > Server does 2D rendering to both buffers Yep, using the shadow module to track dirty regions & blit them clean. > > 3D driver 1 does 3D rendering to Buffer B (current back) > > Server continues to render to both buffers > > 3D application 1 issues a swap buffers command > 3D driver 1 performs page flip: front is B, back is A > > 3D driver 1 does 3D rendering to Buffer A (current back) > > Server continues to render to both buffers > > 3D appication 2 starts > 3D driver 2 disables page flipping mode: front stays B > > Server does 2D rendering to Buffer B (current front) > > 3D driver 2 does 3D rendering to Buffer A (current back) > 3D driver 1 does 3D rendering to Buffer A (current back) This is all eactly as implemented, I think... See -- it wasn't so hard... Keith _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
