[PATCH 2/2] DRI2: Add error message when working around driver bug

[Alex Deucher]

On Thu, Oct 28, 2010 at 2:20 PM, Mario Kleiner
<mario.kleiner at tuebingen.mpg.de> wrote:
> On Oct 28, 2010, at 6:02 PM, Jesse Barnes wrote:
>
>> On Thu, 28 Oct 2010 18:47:09 +0300
>> Pauli Nieminen <ext-pauli.nieminen at nokia.com> wrote:
>>>>
>>>> Most of what you have in (b) is pretty straightfoward; even the shared
>>>> drawable case shouldn't be too bad, since each X connection could have
>>>> bits indicating whether the counter has been picked up after a CRTC
>>>> move.
>>>
>>> One option would be adding crct id parameter to calls.
>>>
>>> glXGetMscBaseRateOML would return rate, base msc and pipe id where this
>>> msc
>>> value is valid. Now all MSC calls would take the returned pipe id as
>>> parameter. If pipe id doesn't match current crtc any more then call would
>>> fail.
>>>
>>> This would allow complex applications to pass same pipe id to different
>>> context.
>>>
>>> Negative side is that API would have to be changed to include extra
>>> parameter.
>>
>> Yeah that would be a good extension though; we may as well expose the
>> fact that different display pipes exist on the system, and have
>> corresponding MSCs.  Old applications using SGI_video_sync or existing
>> OML behavior would work like they do today (with an MSC value that may
>> jump, which we could fix with the virtualize count), and new ones would
>> be pipe aware.
>>
>
> I also like option b) the most, define new spec and api instead of working
> around the old specs limitations.
>
> Another way of doing it, in the same spirit, would be some generation
> counter. Starts with 1, increments each time that something changes in the
> configuration which could influence the display timing and mess with the
> schedule the app had in mind. If the drawable changes crtc's. If the crtc
> changes its video mode (esp. refresh rate) or configuration
> (mirrored/extended desktop, synchronized to other crtc's etc.), dpms change
> etc.
>
> A get call could return the current count, other calls could return the
> count that was valid at time of their processing. E.g., intel_swap_events
> could code more info like generation count, crtcid.
>
> Apps could pass in the count to the msc related functions and those would
> fail on mismatch to the current count. One could also have one special
> "don't care" value (e.g., 0) that says "I don't care about an isolated
> glitch, because i'm not prepared to handle this anyway. Just do something to
> make sure i don't hang, e.g., fall through a blocking glXWaitMscOml() call
> or swap the buffers immediately on glXSwapBuffersMscOML()".
>
> I'm also for exposing rather more than less information, like pipe
> configuration, or the ability for the app to decide what it wants, e.g.,
>
> * If the drawable covers multiple crtc's, or is in mirror display mode,
> should one of them define when to swap and the other should show tearing, or
> should each of them sync its swap separately, which looks nice, but can
> throttle redraw rates or possibly exhaust resources if the crtc's run and
> largely different rates.
>
> Windows has the concept of a "primary display" which defines the swap timing
> on extended desktops. The non-primary display just shows tearing. Mac OS
> behaves similar, except that you don't have control over which is the
> primary display, and some (sometimes buggy) heuristic decides for you and
> gives you the fun of working around it by replugging monitors and other fun
> things. I like control.
>
> The current intel and radeon ddx in page flipped mode will swap each crtc
> separately. Tear free, but with throttled framerate, as swap completion ==
> swap completion of the last involved crtc. This btw. is a problem for the
> returned timestamps and timing if the crtc's run at different refresh rates,
> as the app doesn't know to which crtc the swap completion timestamp belongs.
> And it changes over time. For blitted copy-swaps you get tearfree on the
> assigned crtc for a drawable and tearing on the other one.
>
> Another approach would be to define swap times in system (gettimeofday()
> time). Specify a swap deadline tWhen and the system tries to swap at the
> earliest vblank with a time tNow >= tWhen. Then one doesn't have to care too
> much about changes in msc rates. The NV_present_video
> <http://www.opengl.org/registry/specs/NV/present_video.txt> extension does
> something similar for presentatio of video buffers. My own toolkit does this
> as well and for user code it's a natural way to specify presentation times,
> especially if it has to synchronize presentation with other modalities like
> sound, digital i/o, eye tracking etc. My code just uses the
> glXGetSyncValuesOML() call to translate a user-provided system time tWhen
> into a corresponding target_msc for glXSwapBuffersMscOML().
>
> When we're at defining new api (christmas time is coming, i got lots of
> wishes), a new swapbuffers call could also define what to do if a
> presentation deadline can't be met. E.g., instead of a delayed swap it could
> drop the swap and completely skip a bufferswap request to get presentation
> timing back on schedule, so skipped frame errors can't accumulate. Something
> like that could be interesting for video players in combination with
> n-buffering. A player could queue up multiple frames and tell the
> implementation what to do on frame skips. Occassional skipped frames may be
> mildly annoying, but losing audio-video lip-sync is much worse.
>
> Some of this may need new interfaces to the kernel drm, but long term we
> need them anyway. E.g., ioctl()'s for true 64-bit vblank counts and targets.
> Or in the case of amd's evergreen gpu's for crtc selection. They have up to
> 6 crtc's, but the vblank ioctl() only allows to select between 2 crtc's.

While we are wishing for new things, it would also be nice to have
support for pageflipping as fast as possible rather than only at the
vblanks.  Sure it will tear, but it will also give the you maximum
possible fps.

Alex