[PATCH 5/7] vulkan: add VK_EXT_display_control [v5]

[Jason Ekstrand]

On Tue, Jun 19, 2018 at 9:44 PM, Keith Packard <keithp at keithp.com> wrote:

> Jason Ekstrand <jason at jlekstrand.net> writes:
>
>
> >> +      if (!prop)
> >> +         continue;
> >> +      if (prop->flags & DRM_MODE_PROP_ENUM) {
> >> +         if (!strcmp(prop->name, "DPMS"))
> >> +            connector->dpms_property = drm_connector->props[p];
> >>
> >
> > break?
>
> Not break; I need to free the property. However, an early exit from the
> loop seems reasonable. How about:
>
>    for (int p = 0; connector->dpms_property == 0 && p <
> drm_connector->count_props; p++) {
>
> This skips the whole sequence if the property has already been found, or
> stops as soon as it has.
>

That seems good to me.  Unless, of course, DPMS is something we expect to
change over time somehow.  Then again, we don't handle that at all right
now so meh.  Let's go with what you wrote above for now.


> >> +static bool
> >> +wsi_display_fence_wait(struct wsi_fence *fence_wsi,
> >> +                       bool absolute,
> >> +                       uint64_t timeout)
> >>
> >
> > Would it make more sense for this function to return a VkResult?  Then
> you
> > could tell the difference between success, timeout, and some other
> > failure.  I guess the only other thing to return would be
> > VK_ERROR_DEVICE_LOST which seems pretty harsh but, then again,
> > pthread_timed_wait just failed so that's also really bad.
>
> That's a good idea. The boolean return is pretty ambiguous. I copied
> that from the radv internal fence API, which could also benefit from
> this change. I've changed the API and adjusted the anv and radv code to
> match. It reads a lot better now.
>

Cool.


> >> +   if (!absolute)
> >> +      timeout = wsi_rel_to_abs_time(timeout);
> >>
> >
> > Are relative times really useful?  I suspect it doesn't save you more
> than
> > a couple of lines and it makes the interface weird.
>
> No. Relative timeouts aren't actually used anywhere either. I've removed
> them.
>

Sounds good.


> I did catch a mistake in the anv driver looking at this -- the !waitAll
> code wasn't bothering to check the fences if the time had already
> passed, so an application polling would never catch the fences being
> ready. I've changed the while (current_time < timeout) {} to a do {}
> while (current_time < timeout) loop.
>

Yeah, that was going to be a problem for someone if they ever decided to
busy-loop in the app. :-)


> >> +static void
> >> +wsi_display_fence_destroy(struct wsi_fence *fence_wsi)
> >> +{
> >> +   struct wsi_display_fence *fence = (struct wsi_display_fence *)
> >> fence_wsi;
> >> +
> >>
> >
> > An assert(!fence->destroyed) in here might be useful to guard against
> > double-frees.
>
> Sure. I was under the impression that application bugs weren't supposed
> to be rigorously checked in the implementation though? When should I be
> checking API usage issues?
>

They shouldn't be and that's why I'm a fan of making them asserts which get
compiled out instead of actual checks.  Also, I find this pseudo reference
counting to be somewhat confusing and adding asserts informs the reader of
the assumptions made.


> >> +      if (!ret)
> >> +         return VK_SUCCESS;
> >> +
> >> +      if (errno != ENOMEM) {
> >> +         wsi_display_debug("queue vblank event %lu failed\n",
> >> fence->sequence);
> >> +         struct timespec delay = {
> >> +            .tv_sec = 0,
> >> +            .tv_nsec = 100000000ull,
> >> +         };
> >> +         nanosleep(&delay, NULL);
> >> +         return VK_ERROR_OUT_OF_HOST_MEMORY;
> >>
> >
> > Why are we sleeping for 0.1s before we return?  That seems fishy.
>
> Yeah, the kernel API is not great. There's a finite queue which can be
> consumed with both flip events and vblank wait events. If that fills,
> we'll get an error back. The only way to empty it is to have some events
> get delivered, and those will only get delivered after a vblank happens.
>
> It's an application bug that triggers this -- requesting too many vblank
> events. Throttling the application so it doesn't just spin makes it
> possible to stop it.
>
> >> +      pthread_mutex_lock(&wsi->wait_mutex);
> >> +      ret = wsi_display_wait_for_event(wsi, wsi_rel_to_abs_time(
> >> 100000000ull));
> >>
> >
> > What's with the magic number?
>
> 0.1s -- a value which is longer than any display time, but short enough
> to catch things like DPMS off or VT switch without unduly delaying the
> application.
>
> >> +VkResult
> >> +wsi_register_device_event(VkDevice device,
> >> +                          struct wsi_device *wsi_device,
> >> +                          const VkDeviceEventInfoEXT
> *device_event_info,
> >> +                          const VkAllocationCallbacks *allocator,
> >> +                          struct wsi_fence **fence_p)
> >> +{
> >> +   return VK_ERROR_FEATURE_NOT_PRESENT;
> >>
> >
> > I don't think we're allowed to just not implemnet this.  At the very
> least,
> > we should accept the event and never trigger it.  Better would be to
> > actually wire up hotplug detection.  I have no idea how insane that would
> > be to do. :-P
>
> It's not a big deal to implement, I just didn't need it. I suppose the
> test suite will be unhappy with this? Let me know if you want to insist
> on having it implemented.
>

What test suite?  Honestly, I know of no code anywhere that actually uses
this API for anything other than VR headsets.

I guess it's kind-of a question of how much effort we want to put into
this.  One option would be to add VK_KHR_display support to vkcube and make
it automatically show up on all your displays using hotplug events.

If we're going to not care, returning VK_ERROR_FEATURE_NOT_PRESENT is
probably the best thing to do since at least the app has feedback.


> > Both RegisterDeviceEvent and RegisterDisplayEvent say they can only
> return
> > VK_SUCCESS.  We should submit a MR against the extensions to also allow
> > OUT_OF_HOST_MEMORY at the very least.
>
> There's already weasel words in the section on memory allocation that
> says the command must generate VK_ERROR_OUT_OF_HOST_MEMORY when
> allocation fails. But, it would be nice for these APIs to be documented
> as possibly returning that value.
>

Yeah.  It's probably a 2-line change.


> > Any particular reason to put these all the way down here?  I think my
> > preference would be to move wsi_display_fence_event_handler to right
> after
> > wsi_display_fence_check_free and give it a predeclaration (instead of
> these
> > two) and then move the sequence and vblank handlers to right above
> > event_context since they're just little wrappers around
> > wsi_display_fence_check_free.  Sorry if that's a bit petty but it was
> hard
> > to find wsi_display_fence_check_free all the way down here and it's
> really
> > needed in order to understand the pseudo reference counting you're doing
> > with fences.
>
> Sure; that's easy enough and reduces us to a single forward function
> declaration instead of two.
>
> I've implemented all of the indicated changes above; I'll send out a
> replacement patch series shortly.
>

Awesome.  I think we're really close on this one.

--Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20180620/1115c96c/attachment.html>