[igt-dev] [PATCH i-g-t] lib: Introduce the igt_nouveau library

[Lyude Paul]

On Thu, 2021-03-18 at 11:17 +0200, Petri Latvala wrote:
> On Wed, Mar 17, 2021 at 06:38:27PM -0400, Lyude wrote:
> > From: Lyude Paul <lyude at redhat.com>
> > 
> > This introduces the igt_nouveau library, which enables support for tiling
> > formats on nouveau, along with accelerated clears for allocated bos in VRAM
> > using the dma-copy engine present on Nvidia hardware since Tesla. Typically
> > the latter would be handled by the kernel automatically, which is the
> > long-term plan for nouveau, but since the kernel doesn't yet support that
> > we implement this in igt in order to fulfill the expectation that most of
> > igt has in which newly allocated fbs are expected to be zero-filled by
> > default.
> > 
> > The dma-copy engine is capable of fast blitting, and is also able to
> > perform tiling/untiling at the same time. This is worth mentioning because
> > unlike many of the other drivers supported in igt, we go out of our way to
> > avoid using mmap() in order to perform CPU rendering wherever possible.
> > Instead of mmap()ing an fb that we want to draw to on the CPU (whether it
> > be for converting formats, or just normal rendering), we instead use
> > dma-copy to blit linear/tiled fbs over to linear system memory which we
> > mmap() instead. This is primarily because while mmap() is typically
> > painfully slow for vram, it's even slower on nouveau due to the current
> > lack of dynamic reclocking in our driver. Furthermore, using the dma-copy
> > engine for copying things over to system ram is also dramatically faster
> > than using igt's memcpy wc helpers even when no tiling is involved. Such
> > speed improvements are both quite nice, but also very necessary for certain
> > tests like kms_plane that are rather sensitive when it comes to slow
> > rendering with drivers.
> > 
> > This doesn't mean we won't want to provide a way of using mmap() for
> > rendering in the future however, as at least basic testing of mmap() is
> > certainly something we eventually want for nouveau. However, I think the
> > best way for us to do this in the future will be to adapt the igt_draw API
> > to work with nouveau so we can explicitly request using mmap() in tests
> > which need it.
> > 
> > Finally, this code also adds a hard dependency on libdrm support for
> > nouveau tests. The main reason for this is currently there are no real
> > applications that use nouveau's ioctls directly (mesa for instance, uses
> > libdrm as well) and also that nouveau's ioctls are currently a bit
> > complicated to use by hand. This will likely be temporary however, as Ben
> > Skeggs is planning on revamping a lot of nouveau's APIs to simplify them
> > and make libdrm support for nouveau obsolete in the future. Note that we
> > take care to make sure that users can still disable libdrm support for
> > nouveau if needed, with the only caveat being that any tests using
> > igt_nouveau will be disabled, along with any tiling support for
> > nvidia-specific tiling formats.
> > 
> > This should enable igt tests which test tiling formats to run on nouveau,
> > and fix some seemingly random test failures as a result of not having
> > zero-filled buffers in a few other tests like kms_cursor_crc.
> > 
> > Signed-off-by: Lyude Paul <lyude at redhat.com>
> > Cc: Martin Peres <martin.peres at free.fr>
> > Cc: Ben Skeggs <bskeggs at redhat.com>
> > Cc: Jeremy Cline <jcline at redhat.com>
> > ---
> >  .gitlab-ci.yml                  |   7 +
> >  include/drm-uapi/drm_fourcc.h   |   2 +-
> >  lib/drmtest.c                   |   5 +
> >  lib/igt_fb.c                    |  98 +++++++--
> >  lib/igt_fb.h                    |   2 +
> >  lib/igt_nouveau.c               | 281 ++++++++++++++++++++++++++
> >  lib/igt_nouveau.h               |  65 ++++++
> >  lib/meson.build                 |   8 +
> >  lib/nouveau/cea0b5.c            | 252 +++++++++++++++++++++++
> >  lib/nouveau/nvhw/class/cl906f.h | 103 ++++++++++
> >  lib/nouveau/nvhw/class/cla0b5.h | 250 +++++++++++++++++++++++
> >  lib/nouveau/nvhw/drf.h          | 209 +++++++++++++++++++
> >  lib/nouveau/nvif/push.h         | 345 ++++++++++++++++++++++++++++++++
> >  lib/nouveau/nvif/push906f.h     |  70 +++++++
> >  lib/nouveau/priv.h              |  57 ++++++
> >  meson.build                     |   3 +
> >  tests/meson.build               |   2 +-
> >  17 files changed, 1745 insertions(+), 14 deletions(-)
> >  create mode 100644 lib/igt_nouveau.c
> >  create mode 100644 lib/igt_nouveau.h
> >  create mode 100644 lib/nouveau/cea0b5.c
> >  create mode 100644 lib/nouveau/nvhw/class/cl906f.h
> >  create mode 100644 lib/nouveau/nvhw/class/cla0b5.h
> >  create mode 100644 lib/nouveau/nvhw/drf.h
> >  create mode 100644 lib/nouveau/nvif/push.h
> >  create mode 100644 lib/nouveau/nvif/push906f.h
> >  create mode 100644 lib/nouveau/priv.h
> 
> Do you want to support autotools?

nope :P. I can if it's needed, but otherwise I'm totally fine with this being a
meson-only feature

> 

-- 
Sincerely,
   Lyude Paul (she/her)
   Software Engineer at Red Hat
   
Note: I deal with a lot of emails and have a lot of bugs on my plate. If you've
asked me a question, are waiting for a review/merge on a patch, etc. and I
haven't responded in a while, please feel free to send me another email to check
on my status. I don't bite!