Re: [PATCH 2/2] drm/etnaviv: Add GPU reset counters

[Lucas Stach <l.stach@pengutronix.de>]

Am Donnerstag, dem 09.07.2026 um 21:41 +0200 schrieb Christian Gmeiner:
> Hi Lucas,
> 
> > > The OpenGL and Vulkan robustness extensions let an application detect a
> > > GPU reset and check if its own context caused it, so the application can
> > > drop the broken context and build a new one. The kernel knows both
> > > facts, but etnaviv has no way to report them to userspace.
> > > 
> > > Add two counters and expose them through GET_PARAM: a per-GPU counter
> > > that counts every reset of that GPU, and a per-context counter that only
> > > counts the resets this context was guilty of. Userspace compares the
> > > counters with saved values: if the context counter moved the context was
> > > guilty, if only the GPU counter moved the context was an innocent
> > > victim.
> > 
> > I don't really agree with the design of exposing this through
> > GET_PARAM.
> > 
> > 
> > First it assumes that each etnaviv_file_private can only have a single
> > context, something that is true today but which I would very much like
> > to change to rid of false dependencies when the application uses
> > multiple GL contexts through the same screen. I have a rework to do
> > this in the pipe, which I didn't get around to finish, yet. While I
> > don't want to block any of your work on this rework, I also wouldn't
> > like to see UAPI land which bakes in the single context per file
> > private assumption.
> > 
> 
> Makes sense. I only picked it because msm and v3d expose their fault
> counters that way.
> 
> For v2 I have replaced the two params with a dedicated ioctl:
> 
> struct drm_etnaviv_reset_query {
>     __u32 pipe;            /* in */
>     __u32 flags;            /* in, must be 0 */
>     __u64 global_reset_counter;    /* out */
>     __u64 context_reset_counter;    /* out */
> };
> 
> flags must be zero for now and is rejected with EINVAL otherwise, so
> your multi context rework can later add a flag plus a context field to
> query a specific context.
> 
Looks good to me.

> > 
> > Second, with this design each userspace query incurs two roundtrips
> > into the kernel, as userspace needs to know both counter values to tell
> > innocent vs guilty resets apart.
> > 
> > My vote would be on adding a new ioctl to query both reset counters at
> > the same time, with a flags argument baked in, so it can be extended
> > once I manage to finish the multi context rework.
> > 
> 
> One thing to note: the global counter is per GPU core, so a context
> that uses more than one pipe still needs one query per pipe. I think
> that is fine for the robustness use case, but tell me if you would
> rather have a variant that returns all pipes at once.

I think the current design is fine. While there might be some
configurations where a context uses multiple pipes (2D GPU texture
upload or one of those chips with multiple 3D GPUs), I think that those
are sufficiently rare that we might want to deal with the additional
kernel transitions for those rather than complicating the ioctl for the
common case of a context using a single pipe.

Regards,
Lucas