[PATCH 0/7] libdrm tests for hot-unplug feature

Alex Deucher alexdeucher at gmail.com
Thu Jun 3 21:20:03 UTC 2021


On Thu, Jun 3, 2021 at 5:11 PM Daniel Vetter <daniel at ffwll.ch> wrote:
>
> On Thu, Jun 03, 2021 at 10:22:37AM -0400, Andrey Grodzovsky wrote:
> > Ping
> >
> > Andrey
> >
> > On 2021-06-02 10:20 a.m., Andrey Grodzovsky wrote:
> > >
> > > On 2021-06-02 3:59 a.m., Daniel Vetter wrote:
> > > > On Tue, Jun 1, 2021 at 10:17 PM Andrey Grodzovsky
> > > > <andrey.grodzovsky at amd.com> wrote:
> > > > > Adding some tests to acompany the recently added hot-unplug
> > > > > feature. For now the test suite is disabled until the feature
> > > > > propagates from drm-misc-next to drm-next.
> > > > >
> > > > > Andrey Grodzovsky (7):
> > > > >    tests/amdgpu: Fix valgrind warning
> > > > >    xf86drm: Add function to retrieve char device path
> > > > >    test/amdgpu: Add helper functions for hot unplug
> > > > >    test/amdgpu/hotunplug: Add test suite for GPU unplug
> > > > >    test/amdgpu/hotunplug: Add basic test
> > > > >    tests/amdgpu/hotunplug: Add unplug with cs test.
> > > > >    tests/amdgpu/hotunplug: Add hotunplug with exported bo test
> > > > Given how nasty hotunplug is I really think collaborating on igt tests
> > > > on this would be best for everyone ... do we have to keep doing
> > > > parallel tests here for amdgpu?
> > > > -Daniel
> > >
> > > AFAIK as far as AMD goes a lot of developers use libdrm for regression
> > > testing
> > > while developing their features and also QA as i can see from some
> > > internal ticket
> > > specifically opened for failing to pass libdrm tests. From my bitter
> > > experience with
> > > GPU reset - features which are not part of a common use case such as
> > > device loading,
> > > mode setting or commands submissions tend to very quickly break as
> > > people develop
> > > features but never test them in those uncommon use cases - this is why I
> > > feel it will be
> > > very helpful to include those tests in libdrm.
> > >
> > > Also given that this is libdrm amdgpu code it fits naturally into libdrm.
> > >
> > > Regarding IGT - as you may remember I have them there too -
> > > https://gitlab.freedesktop.org/agrodzov/igt-gpu-tools/-/commits/master
> > > I hit some compile breakage on debian platform there which i need to
> > > resolve before i will submit for review there too.
>
> Why can't amd run the igt tests? Afaiui on the display side this is
> happening already, at least sometimes.
>
> And yes regression tests matter, it just feels silly that we need to have
> them 2x for amdgpu. For old stuff the old repo is all fine, but for new
> feature it looks a bit silly.

Different teams, different CI infrastructures...  It ends up being
easier to port tests between frameworks than to switch frameworks in
some cases.

Alex


> -Daniel
>
> > >
> > > Andrey
> > >
> > >
> > > >
> > > > >   tests/amdgpu/amdgpu_test.c     |  42 +++-
> > > > >   tests/amdgpu/amdgpu_test.h     |  26 +++
> > > > >   tests/amdgpu/basic_tests.c     |   5 +-
> > > > >   tests/amdgpu/hotunplug_tests.c | 357
> > > > > +++++++++++++++++++++++++++++++++
> > > > >   tests/amdgpu/meson.build       |   1 +
> > > > >   xf86drm.c                      |  23 +++
> > > > >   xf86drm.h                      |   1 +
> > > > >   7 files changed, 450 insertions(+), 5 deletions(-)
> > > > >   create mode 100644 tests/amdgpu/hotunplug_tests.c
> > > > >
> > > > > --
> > > > > 2.25.1
> > > > >
> > > >
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch


More information about the amd-gfx mailing list