[Mesa-maintainers] Downstream Mesa patches and quirks

[Jonathan Gray]

On Wed, Feb 21, 2018 at 02:51:43AM +1100, Jonathan Gray wrote:
> On Tue, Feb 20, 2018 at 03:22:31PM +0000, Emil Velikov wrote:
> > On 16 February 2018 at 03:45, Jonathan Gray <jsg at jsg.id.au> wrote:
> > > On Mon, Feb 12, 2018 at 05:59:21PM +0000, Emil Velikov wrote:
> > >> Hi all,
> > >>
> > >> A humble reminder to forward any outstanding patches or hacks needed
> > >> to get your Mesa packages building.
> > >> I would kindly urge you to do so, even if your previous attempt did
> > >> not fare well or you the patch seems not applicable upstream.
> > >>
> > >> Quick random look shows the following:
> > >> Fedora:
> > >>   - multiple patches, static libstdc++ workaround (Vivek had an
> > >> alternative here [1]
> > >>
> > >> FreeBSD/DragonFly
> > >>  - multiple patches (GregV up-streamed a few things already), shebang
> > >> (no longer needed), glx-tls, sed/other hacks
> > >
> > > The way build-id is now entangled in the dri drivers in 18.x while not
> > > being supported by the last GPLv2 bfd ld (2.17) will need to be
> > > addressed.  It is used by the shader cache but disabling the
> > > shader cache and patching out the flag in configure.ac still results in
> > > fatal asserts at runtime on i965.
> > >
> > Hacking away the LD flag won't work. I'd suggest filing a feature req.
> > to the compiler team.
> > Until then you'll need to hack away the entry-points + disable
> > GL_ARB_get_program_binary.
> 
> It seems lld supports it so for platforms that include llvm but still
> have a bfd linker as ld -fuse-ld=lld could work.  That includes
> amd64/i386 the only platforms i965 is built on.
> 
> > 
> > 
> > Skimming through the log in your github repo lists, amongst others:
> >   - Disable the code that allocates W|X memory on OpenBSD
> > Let the function in your C runtime fail - mesa will act accordingly.
> 
> I believe the kernel will kill W^X violating processes in this case.
> 
> > 
> >  - ralloc: don't use ralloc_set_destructor() for linear allocations
> > What happened with this?
> 
> Still required for older gcc versions as I understand it.
> https://bugs.freedesktop.org/show_bug.cgi?id=98595
> 
> > 
> >  - sync OpenBSD changes to i915_drm.h
> > I though you were OK with adding stubs for the unused functionality?
> 
> The changes there are for different ioctl numbering that Owain did
> back when he did the first intel drm port.  I would like to drop that
> but it involves finding a convient time to break ioctl abi.

ioctl break committed

https://marc.info/?l=openbsd-cvs&m=151977867729288&w=2
https://marc.info/?l=openbsd-cvs&m=151977871229306&w=2