From: "Michel Dänzer" <michel@daenzer.net> To: Keith Packard <keithp@keithp.com>, Daniel Vetter <daniel@ffwll.ch> Cc: Dave Airlie <airlied@redhat.com>, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls [v2] Date: Mon, 7 Aug 2017 12:02:35 +0900 [thread overview] Message-ID: <2cc66cb5-f808-734f-123a-f745eed40a3e@daenzer.net> (raw) In-Reply-To: <87r2wpfk14.fsf@keithp.com> [-- Attachment #1.1: Type: text/plain, Size: 2735 bytes --] On 06/08/17 12:32 PM, Keith Packard wrote: > Daniel Vetter <daniel@ffwll.ch> writes: > >>> +#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 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 ... > > [...] > > 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. 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. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 224 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: "Michel Dänzer" <michel@daenzer.net> To: Keith Packard <keithp@keithp.com>, Daniel Vetter <daniel@ffwll.ch> Cc: Dave Airlie <airlied@redhat.com>, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org Subject: Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls [v2] Date: Mon, 7 Aug 2017 12:02:35 +0900 [thread overview] Message-ID: <2cc66cb5-f808-734f-123a-f745eed40a3e@daenzer.net> (raw) In-Reply-To: <87r2wpfk14.fsf@keithp.com> [-- Attachment #1.1.1: Type: text/plain, Size: 2735 bytes --] On 06/08/17 12:32 PM, Keith Packard wrote: > Daniel Vetter <daniel@ffwll.ch> writes: > >>> +#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 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 ... > > [...] > > 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. 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. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer [-- Attachment #1.2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 224 bytes --] [-- Attachment #2: Type: text/plain, Size: 160 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2017-08-07 3:02 UTC|newest] Thread overview: 82+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-07-05 22:10 [PATCH 0/3] drm: Add CRTC-id based ioctls for vblank query/event Keith Packard 2017-07-05 22:10 ` Keith Packard 2017-07-05 22:10 ` [PATCH 1/3] drm: Widen vblank count to 64 bits. Change vblank time precision to ns Keith Packard 2017-07-05 22:10 ` Keith Packard 2017-07-06 7:19 ` Daniel Vetter 2017-07-06 7:19 ` Daniel Vetter 2017-07-06 14:59 ` Keith Packard 2017-07-06 14:59 ` Keith Packard 2017-07-07 12:16 ` Daniel Vetter 2017-07-07 12:16 ` Daniel Vetter 2017-07-25 20:54 ` Keith Packard 2017-07-25 20:54 ` Keith Packard 2017-07-06 7:45 ` Michel Dänzer 2017-07-06 7:45 ` Michel Dänzer 2017-07-06 8:05 ` Michel Dänzer 2017-07-06 8:05 ` Michel Dänzer 2017-07-06 15:11 ` Keith Packard 2017-07-06 15:04 ` Keith Packard 2017-07-06 15:04 ` Keith Packard 2017-07-07 1:34 ` Michel Dänzer 2017-07-07 1:34 ` Michel Dänzer 2017-07-07 2:05 ` Michel Dänzer 2017-07-07 2:05 ` Michel Dänzer 2017-07-05 22:10 ` [PATCH 2/3] drm: Reorganize drm_pending_event to support future event types Keith Packard 2017-07-05 22:10 ` Keith Packard 2017-07-06 7:30 ` Daniel Vetter 2017-07-06 15:36 ` Keith Packard 2017-07-06 15:36 ` Keith Packard 2017-07-07 12:05 ` Daniel Vetter 2017-07-07 12:05 ` Daniel Vetter 2017-07-05 22:10 ` [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls Keith Packard 2017-07-05 22:10 ` Keith Packard 2017-07-06 7:53 ` Daniel Vetter 2017-07-06 10:16 ` Ville Syrjälä 2017-07-06 10:16 ` Ville Syrjälä 2017-07-06 11:04 ` Daniel Vetter 2017-07-06 14:08 ` Ville Syrjälä 2017-07-06 16:28 ` Keith Packard 2017-07-06 16:28 ` Keith Packard 2017-07-06 17:59 ` Ville Syrjälä 2017-07-06 17:59 ` Ville Syrjälä 2017-07-06 18:22 ` Keith Packard 2017-07-06 18:22 ` Keith Packard 2017-07-06 18:59 ` Ville Syrjälä 2017-07-06 18:59 ` Ville Syrjälä 2017-07-06 19:46 ` Keith Packard 2017-07-06 19:46 ` Keith Packard 2017-07-06 16:27 ` Keith Packard 2017-07-06 16:27 ` Keith Packard 2017-07-06 21:49 ` Daniel Vetter 2017-07-06 21:49 ` Daniel Vetter 2017-08-01 5:03 ` [PATCH 0/3] drm: Add CRTC-id based ioctls for vblank query/event Keith Packard 2017-08-01 5:03 ` Keith Packard 2017-08-01 5:03 ` [PATCH 1/3] drm: Widen vblank UAPI to 64 bits. Change vblank time to ktime_t [v2] Keith Packard 2017-08-01 5:03 ` Keith Packard 2017-08-02 8:53 ` Daniel Vetter 2017-08-02 8:53 ` Daniel Vetter 2017-08-02 9:41 ` Michel Dänzer 2017-08-02 9:41 ` Michel Dänzer 2017-08-06 17:35 ` Keith Packard 2017-08-06 17:35 ` Keith Packard 2017-08-01 5:03 ` [PATCH 2/3] drm: Reorganize drm_pending_event to support future event types [v2] Keith Packard 2017-08-02 9:05 ` Daniel Vetter 2017-08-01 5:03 ` [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls [v2] Keith Packard 2017-08-01 5:03 ` Keith Packard 2017-08-02 9:25 ` Daniel Vetter 2017-08-02 9:25 ` Daniel Vetter 2017-08-06 3:32 ` Keith Packard 2017-08-06 3:32 ` Keith Packard 2017-08-07 3:02 ` Michel Dänzer [this message] 2017-08-07 3:02 ` Michel Dänzer 2017-08-07 8:34 ` Daniel Vetter 2017-08-07 8:34 ` Daniel Vetter 2017-10-09 17:18 ` Keith Packard 2017-10-09 17:18 ` Keith Packard 2017-10-10 8:55 ` Daniel Vetter 2017-10-10 8:55 ` Daniel Vetter 2017-08-02 9:45 ` Michel Dänzer 2017-08-06 3:42 ` Keith Packard 2017-08-06 3:42 ` Keith Packard 2017-08-07 3:03 ` Michel Dänzer 2017-08-07 3:03 ` Michel Dänzer
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=2cc66cb5-f808-734f-123a-f745eed40a3e@daenzer.net \ --to=michel@daenzer.net \ --cc=airlied@redhat.com \ --cc=daniel@ffwll.ch \ --cc=dri-devel@lists.freedesktop.org \ --cc=keithp@keithp.com \ --cc=linux-kernel@vger.kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.