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

[Keith Packard]

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.

>> +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.

>> +   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.

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.

>> +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?

>> +      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.

> 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.

> 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.

-- 
-keith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20180619/115f46b0/attachment.sig>