Re: [PATCH] dri3: Support GLX_INTEL_swap_event

[Eric Anholt <eric@anholt.net>]

[-- Attachment #1.1: Type: text/plain, Size: 1543 bytes --]

Keith Packard <keithp@keithp.com> writes:

> The easy part is turning on the extension, now that the X server has a patch
> to send the events.
>
> The only trick was making sure the Present extension reliably provided the
> right 'sbc' count back in the event, and that's done by making sure the sbc
> count is always the same as the sequence number that we send in the
> PresentPixmap requests, and that's done by using the same variable for both
> roles.

I'd prefer to see sbc stay with its current name, since that's its name
in the specs we're trying to implement (GLX_OML_sync_control,
GLX_INTEL_swap_event).  If you drop the rename from the patch,

Reviewed-by: Eric Anholt <eric@anholt.net>

I think our handling of SBC for glXWaitForSbcOML() is wrong.  From the
OML_sync_control spec:

    The SBC value is incremented by the graphics driver at the completion
    of each buffer swap (e.g., the pixel copy has been completed or the
    hardware register that swaps memory banks has been written). For pixel
    formats that do not contain a back buffer, the SBC will always be
    returned as 0.

I read that as "SBC is incremented when the PresentComplete comes in"
not "SBC is incremented when we generate the Present request".
Otherwise glXWaitForSbcOML doesn't make much sense. (in the "e.g." I'm
assuming they're talking a hardware register for pageflipping that
immediately starts scanning out the new stuff, not our fancy new
automatically double buffered ones that you have to push hard on to get
an immediate pageflip mode)

[-- Attachment #1.2: Type: application/pgp-signature, Size: 835 bytes --]

[-- Attachment #2: Type: text/plain, Size: 156 bytes --]

_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev