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.
>
> 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.
Will send v2 shortly.
--
greets
--
Christian Gmeiner, MSc
https://christian-gmeiner.info/privacypolicy
