Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1705068

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls [v2]

From Michel Dänzer <michel@daenzer.net>
Newsgroups linux.kernel
Subject Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls [v2]
Date 2017-08-07 05:10 +0200
Message-ID <ubGAy-2IM-23@gated-at.bofh.it> (permalink)
References <u00Ol-3Tl-5@gated-at.bofh.it> <u9xBn-7sU-1@gated-at.bofh.it> <u9xBn-7sU-5@gated-at.bofh.it> <u9Y8x-83f-15@gated-at.bofh.it> <ubmBQ-6Fy-3@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


[Multipart message — attachments visible in raw view] - view raw

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

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCH 0/3] drm: Add CRTC-id based ioctls for vblank query/event Keith Packard <keithp@keithp.com> - 2017-08-01 07:10 +0200
  [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls [v2] Keith Packard <keithp@keithp.com> - 2017-08-01 07:10 +0200
    Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE  ioctls [v2] Daniel Vetter <daniel@ffwll.ch> - 2017-08-02 11:30 +0200
      Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls [v2] "Keith Packard" <keithp@keithp.com> - 2017-08-06 07:50 +0200
        Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE  ioctls [v2] Michel Dänzer <michel@daenzer.net> - 2017-08-07 05:10 +0200
        Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE  ioctls [v2] Daniel Vetter <daniel@ffwll.ch> - 2017-08-07 10:40 +0200
    Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE  ioctls [v2] Michel Dänzer <michel@daenzer.net> - 2017-08-02 11:50 +0200
      Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls [v2] "Keith Packard" <keithp@keithp.com> - 2017-08-06 07:50 +0200
        Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE  ioctls [v2] Michel Dänzer <michel@daenzer.net> - 2017-08-07 05:10 +0200
  [PATCH 1/3] drm: Widen vblank UAPI to 64 bits. Change vblank time to ktime_t [v2] Keith Packard <keithp@keithp.com> - 2017-08-01 07:10 +0200
    Re: [PATCH 1/3] drm: Widen vblank UAPI to 64 bits. Change vblank  time to ktime_t [v2] Daniel Vetter <daniel@ffwll.ch> - 2017-08-02 11:00 +0200
      Re: [PATCH 1/3] drm: Widen vblank UAPI to 64 bits. Change vblank time  to ktime_t [v2] Michel Dänzer <michel@daenzer.net> - 2017-08-02 11:50 +0200
      Re: [PATCH 1/3] drm: Widen vblank UAPI to 64 bits. Change vblank time to ktime_t [v2] "Keith Packard" <keithp@keithp.com> - 2017-08-06 19:40 +0200
  [PATCH 2/3] drm: Reorganize drm_pending_event to support future event types [v2] Keith Packard <keithp@keithp.com> - 2017-08-01 07:10 +0200
    Re: [PATCH 2/3] drm: Reorganize drm_pending_event to support future  event types [v2] Daniel Vetter <daniel@ffwll.ch> - 2017-08-02 11:10 +0200

csiph-web