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.
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
Server does 2D rendering to both buffers
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)
-- /\
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
