[PATCH 0/5] A couple more present fixes

Alex Deucher alexdeucher at gmail.com
Wed Nov 20 13:52:40 PST 2013


On Wed, Nov 20, 2013 at 1:51 AM, Keith Packard <keithp at keithp.com> wrote:
> I've gotten a couple more bugs in Present resolved, and I'd love to
> have some review of the current set of five tiny patches before I
> merge them to master. Three of these are a repost, the last two are
> new
>
> Again, I'm soliciting any kind of comments as I'd like to get these
> into the server before I release another RC on Friday.
>
> -keith
>
>  [PATCH 1/5] present: Round fake MSC computations intead of truncating
>
> I don't know if anyone has noticed, but Present doesn't suffer the
> DRI2 problem of running apps at infinite speed when DPMS fires, or
> when the windows go off-screen. Instead, it has a 'fake' MSC timer
> that keeps them going at a sensible speed.
>
> For drivers with a real MSC interrupt available, the fake MSC runs at
> 1Hz. This means that when your screen blanks, all of your applications
> slow down to one update per second, saving a tonne of power.
>
> For drivers without a real MSC, the fake MSC runs at 60Hz. This means
> that there is no driver support required for a usable Present
> extension; you get updates at a reasonable rate on all cards, although
> you won't avoid tearing unless you have hardware support.
>
> In any case, this patch cleans up the computation of the fake MSC
> value (it's computed from GetTimeInMicros, after all), to round rather
> than truncate, which avoids having the MSC go backwards.

For anyone interested in fixing this for pre-present xserver, Ilija
fixed it similarly in the ddx for radeon:
http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=6981a5c087165b126c15ba0025cffdba218ab652

Alex

>
>  [PATCH 2/5] present: Ignore event_id 0 from driver vblank notify
>
> This is a trivial patch to work around potential driver bugs; if a
> driver delivers a vblank event_id of zero, it "can't" be valid, and
> may accidentally match sentinal values in various structures.
>
>  [PATCH 3/5] present: Signal destroyed flip window with vblank->window
>
> This changes some internal workings of the Present code to use a NULL
> window value rather than a separate boolean for tracking when the flip
> window has been destroyed (and hence the flip pixmap needs to be
> 'unflipped' asap). This eliminates some bugs where the code was
> dereferencing through the flip window pointer after it had been freed.
>
>  [PATCH 4/5] present: Block for wait_fence in present_execute
>
> This adds a bit of missing functionality -- the server wasn't waiting
> for the provided 'wait_fence' to be signaled before presenting the
> pixmap.
>
>  [PATCH 5/5] present: When unflipping, copy to flip window rather than
>
> This avoids spamming old window contents on top of other windows on
> the screen. I discovered this could occasionally happen when starting
> a window manager with a full-screen GL application running along with
> other apps. One of the intermediate stages while the window manager
> was starting had the GL window full-screen and uncovered, causing a
> page flip, and then immediately covering that with a decorated client
> window; the window background paint would happen and then the whole
> screen would get painted with the old GL window contents. This was
> easily fixed by painting the old back buffer contents into the client
> window itself, which respected the new clip list.
> _______________________________________________
> xorg-devel at lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: http://lists.x.org/mailman/listinfo/xorg-devel


More information about the xorg-devel mailing list