(In reply to comment #0)
> There's a second issue, which may not be related, when a 3d app is started and
> then another one, there's a 50% chance pfCurrentPage will be 1. In that case, if
> a third 3d app is started and one of the 3 closed, pfCurrentPage will go back to
> 0 for some reason and the two remaining apps will flicker (this can be corrected
> by for instance moving the windows of the 3d apps around).

Can you verify that the correct RADEONDRITransition*() functions are called
under the right circumstances? Also, it looks to me like we should try flipping
to page 0 in RADEONDisablePageFlip() before actually disabling page flipping,
but I'm not sure that's related to the issues you're seeing.

(In reply to comment #1)
> Can you verify that the correct RADEONDRITransition*() functions are called
> under the right circumstances?
Yes, all calls to TransitionTo2D/3D and SingleToMulti/MultiToSingle3d happen as
expected when multiple 3d apps are started. When switching to/from another
terminal, none of them are called (I think that's expected too?).

> Also, it looks to me like we should try flipping
> to page 0 in RADEONDisablePageFlip() before actually disabling page flipping,
> but I'm not sure that's related to the issues you're seeing.
I've wondered about that, but the code as-is seems to be specifically designed
so it can handle the case when pfCurrentPage stays at 1 and buffer swapping
happens. I think changing this might be problematic, as I suppose if you'd start
a second 3d app the first one might still dispatch a flip even when the xserver
just had set the page to 0 and disabled page flipping.

(In reply to comment #0)
> If a 3d app is running and the user switches to another terminal, when switching
> back the 3d app will flicker [...]

I just realized this is probably because page 1 isn't synchronized with page 0
in EnterVT?

(In reply to comment #2)
> 
> [...] but the code as-is seems to be specifically designed so it can handle
> the case when pfCurrentPage stays at 1 and buffer swapping happens. 

Sure, it can handle it, but it's far from ideal nonetheless.

> I think changing this might be problematic, as I suppose if you'd start
> a second 3d app the first one might still dispatch a flip even when the xserver
> just had set the page to 0 and disabled page flipping.

Doesn't the server hold the HW lock when it disables page flipping?

> (In reply to comment #0)
> > If a 3d app is running and the user switches to another terminal, when switching
> > back the 3d app will flicker [...]
> 
> I just realized this is probably because page 1 isn't synchronized with page 0
> in EnterVT?
What needs to be synchronized?

> > [...] but the code as-is seems to be specifically designed so it can handle
> > the case when pfCurrentPage stays at 1 and buffer swapping happens. 
> 
> Sure, it can handle it, but it's far from ideal nonetheless.
Well I just guessed there's a reason things are handled that way :-)

> > I think changing this might be problematic, as I suppose if you'd start
> > a second 3d app the first one might still dispatch a flip even when the xserver
> > just had set the page to 0 and disabled page flipping.
> 
> Doesn't the server hold the HW lock when it disables page flipping?
It should. However, the clients don't when they decide if they should dispatch a
flip or a swap. Thus, they could easily dispatch a flip even after the xserver
has disabled page flipping, and drm doesn't care at all if page flipping is
enabled or not when it dispatches a flip (and btw I think it's not really a good
idea that the sarea page flip variable has a different name in drm/dri (pfState)
and xorg (pfAllowPageFlip) - moreover the comment in drm what this variable is
good for isn't quite how it's used).

(In reply to comment #4)

> > > [...] but the code as-is seems to be specifically designed so it can handle
> > > the case when pfCurrentPage stays at 1 and buffer swapping happens. 
> > 
> > Sure, it can handle it, but it's far from ideal nonetheless.
> Well I just guessed there's a reason things are handled that way :-)

If you think about what would happen if the X server decided to do a pageflip
(rather than the application doing one), it should be clear - you'd end up on
page 0, sure, but there would be a half-rendered scene in what the application
thought was the backbuffer.  

You could jump through all sorts of hoops trying to get things to work out -
perhaps tell the app to abandon that frame, generate expose events to make sure
that it really is rendering a new frame.  Or backcopy the old frontbuffer over
the top of what was the backbuffer, etc.  In short it would be a mess.

The only real choice is to leave pageflipping to the application and have the X
server and everybody else deal with the possibility that you might end up on
page 1 after a session of flipping.

(In reply to comment #4)
> > (In reply to comment #0)
> > > If a 3d app is running and the user switches to another terminal, when
switching
> > > back the 3d app will flicker [...]
> > 
> > I just realized this is probably because page 1 isn't synchronized with page 0
> > in EnterVT?
> What needs to be synchronized?

The page contents. :) See RADEONEnablePageFlip(). BTW, that blit should probably
really set the destination offset instead of using coordinates...

Actually, turns out this is a simple problem (the vt switch one). The FLIP_CNTL
bit will not get set. This has to do with that while X sets up the
CRTC_OFFSET_CNTL register we're relying on drm to set the flip cntl bit, which
it will only do when a new client dispatches a flip.
Not sure how exactly a good solution would look like, since we don't save any
regs when LeaveVT is called (only when using fbdev, which indeed saves that reg
just for page flipping). Probably just saving those offset cntl regs when
leaving vt might do the trick (though I think a solution which would also get
rid of the FLIP_CNTL bit when page flipping is not enabled would be better).

Mass version move, cvs -> git

Pageflip should be working fine with KMS.  Closing.