Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751506AbdHGDCs (ORCPT ); Sun, 6 Aug 2017 23:02:48 -0400 Received: from mail.netline.ch ([148.251.143.178]:41662 "EHLO netline-mail3.netline.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751364AbdHGDCr (ORCPT ); Sun, 6 Aug 2017 23:02:47 -0400 Subject: Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls [v2] To: Keith Packard , Daniel Vetter Cc: Dave Airlie , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org References: <20170705221013.27940-1-keithp@keithp.com> <20170801050306.24423-1-keithp@keithp.com> <20170801050306.24423-4-keithp@keithp.com> <20170802092505.ynlpy6dxf3lxziim@phenom.ffwll.local> <87r2wpfk14.fsf@keithp.com> From: =?UTF-8?Q?Michel_D=c3=a4nzer?= Message-ID: <2cc66cb5-f808-734f-123a-f745eed40a3e@daenzer.net> Date: Mon, 7 Aug 2017 12:02:35 +0900 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <87r2wpfk14.fsf@keithp.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1iPdTjlJHp6Q0Xr494eN9nbd0A36FAqXe" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4215 Lines: 109 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --1iPdTjlJHp6Q0Xr494eN9nbd0A36FAqXe Content-Type: multipart/mixed; boundary="CvoF2rQEmXlHH3Tw0eXwJotVSX7qLvmaJ"; protected-headers="v1" From: =?UTF-8?Q?Michel_D=c3=a4nzer?= To: Keith Packard , Daniel Vetter Cc: Dave Airlie , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Message-ID: <2cc66cb5-f808-734f-123a-f745eed40a3e@daenzer.net> Subject: Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls [v2] References: <20170705221013.27940-1-keithp@keithp.com> <20170801050306.24423-1-keithp@keithp.com> <20170801050306.24423-4-keithp@keithp.com> <20170802092505.ynlpy6dxf3lxziim@phenom.ffwll.local> <87r2wpfk14.fsf@keithp.com> In-Reply-To: <87r2wpfk14.fsf@keithp.com> --CvoF2rQEmXlHH3Tw0eXwJotVSX7qLvmaJ Content-Type: text/plain; charset=utf-8 Content-Language: en-CA Content-Transfer-Encoding: quoted-printable On 06/08/17 12:32 PM, Keith Packard wrote: > Daniel Vetter writes: >=20 >>> +#define DRM_CRTC_SEQUENCE_FIRST_PIXEL_OUT 0x00000004 /* Signal when = first pixel is displayed */ >> >> Note that right now vblank events are defined as: >> - The even will be delivered "somewhen" around vblank (right before up= to >> first pixel are all things current drivers implement). >> - An atomic update or pageflip ioctl call right after a vblank event w= ill >> hit (assuming no stalls) sequence + 1. radeon/amdgpu have some sw ha= cks >> to handle this because their vblank event gets delivered before the = last >> possible time to update the next frame. >> - The timestamp is corrected to be top-of-frame. >> >> Would be a good time to document this a bit better, and might not exac= tly >> match what vk expects ... >=20 > [...] >=20 > FIRST_PIXEL_OUT is an attempt to signal to the kernel that the > application really wants to see the event when the first pixel hits the= > display. I assume the important thing here is the timestamp in the > event and not the actual delivery, but I don't actually know that. >=20 > If the timestamp is the only important thing, it sounds like the kernel= > already satisfies that, which is cool. >=20 > If Vulkan really wants the event to be delivered when the first pixel i= s > displayed, then having this bit in the ioctl means we can let drivers > continue to do whatever they are now when the bit isn't set, but try > harder to deliver the event at first-pixel when requested. I don't see the point of giving this choice to userspace. The event timestamp specifies when first-pixel occurs; if it's in the future, userspace can use other functionality to wait until then if needed (though it's hard to imagine why it would be). > So, I think what I want to do is leave the bit in the request so that > drivers can at least see what user space is asking for, and if we learn= > that it's important to deliver the event at the requested time, we can > go fix drivers later. This seems like a very bad idea: Having a flag which doesn't have any effect at first will result in userspace randomly setting the flag or not. If we were to then change the behaviour with the flag (not) set, some userspace will almost certainly break. So effectively we can never make the flag have any effect. The way to go here is to drop the flag for now and document the behaviour explicitly. If unexpectedly a real need for different behaviour comes up in the future, we can add a flag for it at that time. --=20 Earthling Michel D=C3=A4nzer | http://www.amd= =2Ecom Libre software enthusiast | Mesa and X developer --CvoF2rQEmXlHH3Tw0eXwJotVSX7qLvmaJ-- --1iPdTjlJHp6Q0Xr494eN9nbd0A36FAqXe Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iHEEARECADEWIQSwn681vpFFIZgJURRaga+OatuyAAUCWYfYTxMcbWljaGVsQGRh ZW56ZXIubmV0AAoJEFqBr45q27IASKcAn1iaGoKDJ+CLLZWwOYptznGxGimAAKCh cEWeDNpUOoxB9peXdtvTRZIe8A== =nbny -----END PGP SIGNATURE----- --1iPdTjlJHp6Q0Xr494eN9nbd0A36FAqXe--