Keith Whitwell wrote:
> 
> 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...

Great.  What thrue me off was your statements:

KW> The good news is there's no real cost to switching between
KW> mechanisms,

Isn't there an overhead when going into page flipping mode in that the
server has to duplicate the contents of the front buffer into the both
buffers?

KW> but we do have to decide at the start of the frame which one to
KW> use, and that frame has to be in the "non-flipped" state - ie.
KW> we have that opportunity to fallback every second frame, I think..."

If the server can start rendering to buffer B as it's current front (as
described in scenario above), then couldn't you switch modes on *any*
frame?  I don't understand why you are limited to every second frame.

--                             /\
         Jens Owen            /  \/\ _    
  [EMAIL PROTECTED]  /    \ \ \   Steamboat Springs, Colorado

_______________________________________________________________

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

Reply via email to