lkml.org 
[lkml]   [2023]   [Jun]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH v5 1/1] drm/doc: Document DRM device reset expectations
From
Hi Marek,

Em 27/06/2023 15:57, Marek Olšák escreveu:
> On Tue, Jun 27, 2023, 09:23 André Almeida <andrealmeid@igalia.com
> <mailto:andrealmeid@igalia.com>> wrote:
>
> +User Mode Driver
> +----------------
> +
> +The UMD should check before submitting new commands to the KMD if
> the device has
> +been reset, and this can be checked more often if the UMD requires
> it. After
> +detecting a reset, UMD will then proceed to report it to the
> application using
> +the appropriate API error code, as explained in the section below about
> +robustness.
>
>
> The UMD won't check the device status before every command submission
> due to ioctl overhead. Instead, the KMD should skip command submission
> and return an error that it was skipped.

I wrote like this because when reading the source code for
vk::check_status()[0] and Gallium's si_flush_gfx_cs()[1], I was under
the impression that UMD checks the reset status before every
submission/flush.

Is your comment about of how things are currently implemented, or how
they would ideally work? Either way I can apply your suggestion, I just
want to make it clear.

[0]
https://elixir.bootlin.com/mesa/mesa-23.1.3/source/src/vulkan/runtime/vk_device.h#L142
[1]
https://elixir.bootlin.com/mesa/mesa-23.1.3/source/src/gallium/drivers/radeonsi/si_gfx_cs.c#L83

>
> The only case where that won't be applicable is user queues where
> drivers don't call into the kernel to submit work, but they do call into
> the kernel to create a dma_fence. In that case, the call to create a
> dma_fence can fail with an error.
>
> Marek

\
 
 \ /
  Last update: 2023-06-27 23:32    [W:0.062 / U:0.704 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site