On Tue, Jun 27, 2023 at 5:31 PM André Almeida <andrealm...@igalia.com> wrote:
> Hi Marek, > > Em 27/06/2023 15:57, Marek Olšák escreveu: > > On Tue, Jun 27, 2023, 09:23 André Almeida <andrealm...@igalia.com > > <mailto:andrealm...@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. > It only does that before every command submission when the context is robust. When it's not robust, radeonsi doesn't do anything. > > 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. > Yes. Ideally, we would get the reply whether the context is lost from the CS ioctl. This is not currently implemented. Marek > > [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 > >