Re: [PATCH v4 4/7] drm: nova: Add a GPU info ioctl

[Alistair Popple]

On 2026-08-25 at 06:04 +1000, John Hubbard <jhubbard@xxxxxxxxxx> wrote...
> On 8/24/26 12:34 PM, Danilo Krummrich wrote:
> > On Tue Aug 11, 2026 at 7:06 AM CEST, Alistair Popple wrote:
> >>  include/uapi/drm/nova_drm.h    | 27 +++++++++++++++++++++++++++
> > 
> > Btw. I think it would be nice to have project to play around with and write
> > tests directly on top of the uAPI before we can run the big test suites.
> 
> Yes, I think it's reasonable to do something like that. Seeing a new API
> from both sides, caller and callee, is always illuminating during review,
> for one thing.

Yes, I had meant to do this so thanks for the reminder.
You can of course see the other side of the API here:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/43352

But that's a user of the UAPI rather than a tester of it which makes it hard to
exercise everything or specific parts of the API. I did actually end up writing
my own standalone test case for these, similar to [1] but never got around to
tidying it up and posting it. Looking at [1] it seems reasonable as a simple
stand-alone test so I will do that ahead of the next revision for this series.

> > 
> > When I implemented the VM_BIND uAPI for nouveau I used IGT for this (but didn't
> > enjoy it too much). It turned out to be very useful to test and benchmark the
> > implementation before being able to complete VK CTS.
> > 
> > When I sent the first nova-drm skeleton, I also submitted [1]; maybe we can
> > extend this further accordingly?
> > 
> > I'm also open for other ideas, but I'd really like to have something like this
> > as we develop nova-drm.
> > 
> > [1] https://gitlab.freedesktop.org/dakr/drm-test
> 
> I was thinking about where this sort of thing should go, and this
> location seems as good, or slightly better than the main alternatives,
> to get started anyway.
> 
> Alternatives include:
> 
> 1) The kernel's kselftests (tools/testings/selftests). These are
> helpful in many cases, but some minor issues include:

Yeah, I don't think these style of tests belong in kselftests if only because
they're never going to be self-contained as at a minimum they will require
specific HW. It might make sense for unit-test style things, but I (think)
Rust-for-Linux already has that covered.

>     a) Oddly tight coupling to kernel code, even though the whole
>        point of these is to exercise the kernel from user space.
>        (Otherwise, these days one would use KUnit.) I've personally
>        working on mitigating the coupling-induced problems and 
>        ran into other, bigger problems along the way, such as:
> 
>    b) Confused build system and an arguably wrong way of invoking
>       the tests (from Make(1) !).
> 
> 2) Some other github-like location to host user space tests for
>    nova. The idea is, do we want to set up a well-known location
>    that people should keep updated? Or let a thousand github
>    small test sites bloom? 

We obviously can't stop a thousand small test sites blooming if people create
them, but I think it would be good to establish a well-known location for core
Nova developers to contribute to at least.

> thanks,
> -- 
> John Hubbard
>