Re: Open letter to NetBSD about Mesa 13+

[Tobias Nygren <tnn%NetBSD.org@localhost>]

Hi!

On Thu, 2 Feb 2017 12:52:12 -0800
David Shao <davshao%gmail.com@localhost> wrote:

> NetBSD developers need to make a couple of decisions about
> implementing support for Mesa 13+.
> 
> As documented in PR kern/51786
> (mesa 13.0.2 libdrm 2.4.74 Radeon needs kernel support, new ioctl or sysctl)
> Mesa 13+ switched hardware detection to libdrm.  In libdrm
> the work is now done by passing the file descriptor of the
> equivalent of /dev/dri/card0 or whatever the device is and
> then asking libdrm to fill in the pci video card information.
> 
> 1) First decision: Provide either through sysctl or ioctls
> this pci card information.  In the above PR, I ported
> OpenBSD's use of an ioctl, but I changed it from re-using
> an old ioctl to using a so-far unused ioctl number.
> But FreeBSD and DragonFly already have the kernel provide
> this information through sysctls.

Even after adding some kernel API to look up this, in pksgsrc we still
have to deal with support for stable NetBSD releases. The way I solved
this issue was to patch libdrm to use code similar to
pci_drvnameonbus(3) and assume vga0 is dri0. This is only guaranteed to
work for single adapter setups but I think that is good enough for now.
(We don't support multi card arbitration anyway, or do we?)

> After making this decision, patch libdrm somewhat similar
> to what has been documented in PR pkg/51795
> (x11/libdrm update xf86drm.c for mesa 13.0.2 needs negotiation)
> 
> NetBSD currently has a problem with dlopen, init-exec, and
> non-trivial initializers.
> 
> See the discussion in the thread
> (Workaround for NetBSD initial-exec and dlopen is not supported?)
> 
> https://mail-index.netbsd.org/pkgsrc-users/2015/08/25/msg022089.html
> 
> https://mail-index.netbsd.org/pkgsrc-users/2015/09/11/msg022183.html
> 
> Therefore there was a pkgsrc MesaLib 11 patch to initialize with 0 and
> later in assembly generated code initialize
> with a default array.

I'm aware of this. I've backed out TLS dispatch in wip/MesaLib while I
am figuring out what to do about this.
 
> As further documented in PR pkg/51796
> (graphics/MesaLib Update to 13.0.2 with glamor / egl somewhat working)
> some change between Mesa 11 and Mesa 13 caused NetBSD's
> patch to no longer compile.
> 
> 2) Second decision:  Patch NetBSD so it can handle non-trivial
> initializers to dlopen-ed init-exec, or try and figure out the
> one change between Mesa 11 and Mesa 13 that broke the
> patch, or brute force provide an initializing array.

I agree it would be nice to fix this issue on RTLD, but again we have
to deal with stable NetBSD releases so the workaround has to remain.

> I tried to revert various changes between Mesa 11 and 13
> but never found a reversion that fixed compilation.  In the
> above PR I submitted a brute force initializing array that
> does not handle the case of debugging enabled.
> 
> Of course this is open source and doing nothing is an option.
> It may be even easier to accept since apparently Intel
> integrated graphics does not use the libdrm code path.
> But if Mesa is ever upgraded to 13+, Radeon and perhaps
> other pci graphics cards will lose even 2D exa acceleration.
> 
> This matter needs to be dealt with now.

I will try to merge your work to wip/MesaLib.
Please feel free to work directly on that package rather than forking it :)

Kind regards,
-Tobias