From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Anholt Subject: Re: [PATCH] dri3: Support GLX_INTEL_swap_event Date: Mon, 25 Nov 2013 13:48:51 -0800 Message-ID: <87hab0cfuk.fsf@eliezer.anholt.net> References: <1385103489-24727-1-git-send-email-keithp@keithp.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0444360054==" Return-path: In-Reply-To: <1385103489-24727-1-git-send-email-keithp@keithp.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mesa-dev-bounces@lists.freedesktop.org Errors-To: mesa-dev-bounces@lists.freedesktop.org To: Keith Packard , mesa-dev@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org --===============0444360054== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" --=-=-= Content-Type: text/plain Keith Packard 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 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) --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) iQIcBAEBCAAGBQJSk8XDAAoJELXWKTbR/J7oRscP/RcLfcKB/JZwiIgNLwI5W4rA d5/oO0jrZg2v06Lz+qwIpMv6cAoKyGuMJB+lo20Z1ITCbcH6dfrkKVAYHn8ihu2u Jahx2g9ibGG69DiDiq+LxXwpLjfEQTj2+2CPqMbDyEnlmPjQwefLI+u4sA4ofuH+ tDiCqo0UaDn6rBxWheM2AkvvyXYMV+0k6me9KIuysaAPgicEjiw5kXmF2K5vPuSx KFLBm2Aec9DwIT4qiP6lIjsXuxNPCGqIQW3zSRGcXjJz9IvlCubS8hOmGeVsTktX A0FOpIWDFjX50SfAgg7VCq6GV7+eD20IOCwhlCF+4FPbleNaQsIY9EGfsgku5lhm ZT0LGq84sHu+6vKvt23IoUHR0qarSkbm5QNJ8kI5K9fJNzcCL5iNvqdSKhSLm0w8 eKuht/9IEES6ZtLxsXEec1tuIQ1YgI+1w3zdn7539CmvHw1u1vpzi6suBuwZ2lBL XusVm7Sy6U8foby8Opd5fCSZQ2EqIHrRYdfUCBpge2Oq9QDga8QGP53EIELM3FPH Gyuz314BiPWvc1jhPAvdd7sw2SNjuiryfsaa+m45T9hg7cVs3b78w4h7VVz/cpb+ kG5u6THHIq1y62jkWPMYb5Z+9Ey+hR5nIAz3mnsksEQ+N3s45kYeSzp3vVF+hr8n lY//1oAMxYjLr9zkWjV2 =Mws9 -----END PGP SIGNATURE----- --=-=-=-- --===============0444360054== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev --===============0444360054==--