Sounds fine to me. I just wanted to confirm that they are unrecoverable. Reviewed-by: Jason Ekstrand <ja...@jlekstrand.net>
On Wed, Jun 27, 2018 at 9:13 AM, Keith Packard <kei...@keithp.com> wrote: > Jason Ekstrand <ja...@jlekstrand.net> writes: > > > Is this the same thing that happens on VT switch? If so, we may want to > > return SURFACE_LOST for leases and OUT_OF_DATE for things running > directly > > on the display. > > No, on VT switch, my code currently sits in the driver and waits for the > VT to return. The errors here are unexpected and the driver doesn't > currently have any way to recover from them. This patch came from > reviewing the valid error returns from these functions with my broader > understanding of Vulkan and evaluating which error message most > accurately described the situation. SURFACE_LOST is more accurate than > OUT_OF_DATE as a DRM lease termination (the only "normal" cause of these > errors) definitely requires the application create a new surface. > > If there were errors we knew how to handle, and the way to handle them > was to re-query the surface and re-create the swap chain, then we should > return OUT_OF_DATE. > > On another note, I re-read the spec for vkAcquireXlibDisplayEXT when > looking at this and found that it explicitly calls out VT switch as a > case where the driver is supposed to return 'an appropriate error', but > I can't see an error which would be appropriate in this case -- > DEVICE_LOST and SURFACE_LOST are both effectively fatal errors to the > application while OUT_OF_DATE requires the application to re-query the > surface and re-construct the swap chain. I guess we could have the > surface query block until the VT returns? Is that better than just > having the presentation block? > > -- > -keith >
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
