On Tue, Jun 19, 2018 at 9:44 PM, Keith Packard <keithp@xxxxxxxxxx> wrote:
Jason Ekstrand <jason@xxxxxxxxxxxxxx> 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) Sure. I was under the impression that application bugs weren't supposed
>> +{
>> + 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.
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); 0.1s -- a value which is longer than any display time, but short enough
>> + ret = wsi_display_wait_for_event(wsi, wsi_rel_to_abs_time(
>> 100000000ull));
>>
>
> What's with the magic number?
to catch things like DPMS off or VT switch without unduly delaying the
application.
>> +VkResult
>> +wsi_register_device_event(VkDevice device, It's not a big deal to implement, I just didn't need it. I suppose the
>> + 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
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 Sure; that's easy enough and reduces us to a single forward function
> 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.
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
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
