From: "Keith Packard" <keithp@keithp.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: linux-kernel@vger.kernel.org, Dave Airlie <airlied@redhat.com>,
        Daniel Vetter <daniel@ffwll.ch>, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls [v2]
In-Reply-To: <20170802092505.ynlpy6dxf3lxziim@phenom.ffwll.local>
References: <20170705221013.27940-1-keithp@keithp.com> <20170801050306.24423-1-keithp@keithp.com> <20170801050306.24423-4-keithp@keithp.com> <20170802092505.ynlpy6dxf3lxziim@phenom.ffwll.local>
Date: Sat, 05 Aug 2017 23:32:39 -0400
Message-ID: <87r2wpfk14.fsf@keithp.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
        micalg=pgp-sha256; protocol="application/pgp-signature"
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 4905
Lines: 113

--=-=-=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Daniel Vetter <daniel@ffwll.ch> writes:

> Since I missed all the details Michel spotted, so I'll defer to his r-b.
> Also, before merging we need the userspace user. Do we have e.g.
> -modesetting patch for this, fully reviewed&ready for merging, just as
> demonstration?

Well, given that we'll have to keep the old API around for older
kernels, at least for a decade or so, I'm not sure why we'd actually
want that anytime soon, if ever? I guess it does provide 64-bit sequence
numbers, which Present wants?

> This way we could land this before the lease stuff for the
> vk extension is all solid&ready.

Do you think there's a pile more work to be done for the lease changes
in the kernel? Or are you just trying to separate the work flows?

I can go re-write the modesetting present support to use this new API
and use that for testing the kernel, if you think that would help move
the kernel bits along.

>> +	drm_modeset_lock(&crtc->mutex, NULL);
>> +	if (crtc->state)
>> +		get_seq->active =3D crtc->state->enable;
>> +	else
>> +		get_seq->active =3D crtc->enabled;
>> +	drm_modeset_unlock(&crtc->mutex);
>
> This is really heavywheight, given the lockless dance we attempt above.
> Also, when the crtc is off the vblank_get will fail, so you never get
> here. I guess my idea wasn't all that useful and well-thought out, or we
> need to be a bit more clever about this. To fix this we need to continue
> even when vblank_get fails (but only call vblank_put if ret =3D=3D 0 ofc)=
. And
> to avoid the locking you can use READ_ONCE(vblank->enabled) instead.

So, in reality, the client can more-or-less tell that the crtc is
disabled because the call fails? Sounds like I can just remove the
little dance to get the CRTC enabled state entirely. I don't understand
your comment about READ_ONCE(vblank->enabled); that doesn't relate to
the crtc enabled state, I don't think?

>> +
>> +/* Queue event to be delivered at specified sequence */
>> +
>> +#define DRM_CRTC_SEQUENCE_RELATIVE		0x00000001	/* sequence is relative =
to current */
>> +#define DRM_CRTC_SEQUENCE_NEXT_ON_MISS		0x00000002	/* Use next sequence=
 if we've missed */
>> +#define DRM_CRTC_SEQUENCE_FIRST_PIXEL_OUT	0x00000004	/* Signal when fir=
st 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 will
>   hit (assuming no stalls) sequence + 1. radeon/amdgpu have some sw hacks
>   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 exactly
> match what vk expects ...

(NEXT_ON_MISS is not used by the new Vulkan code; I added it only to keep
compatibility with the old API, in case we want to switch someday).

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.

If the timestamp is the only important thing, it sounds like the kernel
already satisfies that, which is cool.

If Vulkan really wants the event to be delivered when the first pixel is
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.

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.

=2D-=20
=2Dkeith

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEw4O3eCVWE9/bQJ2R2yIaaQAAABEFAlmGjdcACgkQ2yIaaQAA
ABFEUhAAhNiAkMDvaBdm/hb+8O3T7TdTklbTf4L66eN+9E9VKGV2YIM1mSf06BDC
TCPWljjvTo1fFhCf+BLFCmJLj186RCeqVLvauvXkdbuKYaVCPDhXvNCOAHu8I+Rc
PbjysERg6DVPM+dWBMgi6TrZZ4vMNs3/RlooYLjfMRVLKy6s9JhGAz9J53MnOdeP
jGIc7Hhl0jYLII9sVrneSHf10GWCtNVsBaHXcfz5GY9FgsRbkXeh7HtkGHetb4zD
ZkQD+V7Ss5PQwA+hwaL3cfe6GochV1Ym2KuIVtVQ8K8Qg2ozfhJb3BpEes3BYA+i
rToQ4q8ngOjUPdToRFa0ZSyreHwgfPsq7cn/IWyyOsPzhoxzh5Kc02YLQF3TL17v
aCp4eKyxr43V7h3/68EpSm/cKPmFSLNqwWsAGE24XKW0lPMekt1/Ucx6Ttp5gRa5
DLyPAP84Pd2zLk5p3Po2xLD/ZoS3JWZamynodTUa0c2TCy5mkAMr5rruvP/qGcCe
2ASN4N2by6QNYUrp9NcikHxqxSXHgXRxvcp0H3CjyFrPXhFw3iTQVlguhwjqnsHq
q9UfjLnIweEx6XaJCp7j4usHabePHnob0C3NzvSYhLI01aDiTOZV15LizNUGtDu6
QDLUtRMBk9fot3sG36/j1LQWETjmBlLsvz2StRYj7IdZ2bZ79mo=
=p0Ng
-----END PGP SIGNATURE-----
--=-=-=--