MMU Notifiers and the quest for graphics feature parity

[K. Macy]

On Thursday, May 12, 2016, René Ladan <r.c.ladan at gmail.com> wrote:

> 2016-05-12 5:37 GMT+02:00 K. Macy <kmacy at freebsd.org <javascript:;>>:
> > My motivation for writing this email stems from my recent work extending
> the
> > linuxkpi to facilitate updating graphics support for FreeBSD. I've made
> > reasonable progress limiting my changes to the linuxkpi so far. I have
> 3D HW
> > acceleration working on an essentially unmodified 4.6-rc5 drm and i915
> driver.
> > The 4.6 i915 driver supports all of Haswell (3.8 doesn't), Broadwall,
> Skylake,
> > and the, as of yet, unreleased Kaby Lake processors. Additionally, I am
> > expecting a Thinkpad e565 (AMD based) to arrive on Friday which will
> allow me
> > to bring up amdgpu (the Radeon driver for post 2013 AMD GPU hardware)
> this
> > weekend. I find this exciting as it means that FreeBSD will be able to
> run on
> > _all_ x86 graphics hardware. Unfortunately, most if not all ARM GPU
> drivers
> > are closed source.
> >
> > This isn't quite everything though. There is a new "userptr" ioctl in
> > graphics drivers that allows applications to safely register user memory
> with
> > the driver. This works because  if pages are evicted or the process goes
> away,
> > the driver will be notified first. This notification takes place through
> the
> > "mmu notifier" facility.
> >
> > MMU Notifiers are essentially just VM callbacks (or in FreeBSD parlance
> > eventhandlers). They were first added to Linux to enable KVM to better
> > interoperate with the native VM's resident set management:
> >
> > https://lwn.net/Articles/266320/
> >
> > They're now also used by IB, IOMMUs, MPSS (Xeon Phi), and graphics
> drivers.
> > The API is well enough documented in the header file:
> >
> > http://lxr.free-electrons.com/source/include/linux/mmu_notifier.h
> >
> >
> > I don't have strong feelings for what these are called or their precise
> > location. I do, however, need to be able to support roughly equivalent
> > semantics when I register these eventhandlers from the notifer calls in
> the
> > linuxkpi.
> >
> > I haven't worked on the VM in a year or two so don't know quite how to
> proceed.
> > I'm happy to produce patches for review, but fear that they might be
> rejected
> > out of hand for one reason or another. I'd like feedback on the approach
> > itself and what I might do to make any proposed patches more palatable.
> >
> I have a laptop with both an nVidia GeForce 940M and a built-in
> graphics card on the Intel i7 6500U CPU:
> vgapci0 at pci0:0:2:0:     class=0x030000 card=0x09851025 chip=0x19168086
> rev=0x07 hdr=0x00
>     vendor     = 'Intel Corporation'
>     device     = 'HD Graphics 520'
>     class      = display
>     subclass   = VGA
>
> So if I understand correctly this 520 chip might work with your patch?
> Stock FreeBSD 11.0 r298793 with xf86-video-intel 2.21.15_9 does not
> see the driver.
> For now it does run with scfb.


Yes. I don't have a Skylake based laptop (I will shortly), so I haven't
actually tested it yet. That's part of what I'm waiting on for a CFT. I
haven't tested prime support yet at all so switching between the discrete
and integrated based on C state or other power management policy is a week
or two off - at least. I appreciate your enthusiasm but please let's move
all device support and other X11 discussion to the X11 list.

Thanks.

-M


>
> Thanks for your work,
> René
> --
> https://rene-ladan.nl/
>