[Mesa-maintainers] Downstream Mesa patches and quirks

Emil Velikov emil.l.velikov at gmail.com
Tue Feb 20 16:54:07 UTC 2018


On 20 February 2018 at 15:51, Jonathan Gray <jsg at jsg.id.au> 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.
>
Might want to bring it with the kernel team - changing that to a mmap
failure, will remove hacks like the one here.
Any broken apps that do not check the mmap return value, will still
crash so one will be in the same state.

>>
>>  - 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
>
Quick grep shows that the patch causes UB, as pointed by Curro.
You'd want to look at a more comprehensive solution the bug... or
simply hack away the assert ;-)

https://lists.freedesktop.org/archives/mesa-dev/2016-November/134770.html


>>
>>  - 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.
>
If you haven't already, do throw it in the general graphics TODO bag.
Thus others can crab and help out. IIRC I initially poked you about
this some 2 years ago :-\

>>
>>  - util/disk_cache: disable by default on OpenBSD
>> Don't hack it away like this. You have MESA_GLSL_CACHE_DISABLE for
>> this reason ;-)
>
> The configure flag was removed.  An environment variable isn't
> really a replacement for that.
>
Why is that - if you really don't trust your browser/other app, then
any calls it makes to setenv out to fail.
Be that silently or not.

>>
>>
>> Last but not least, please poke the C runtime/compiler team about
>> disable-glx-tls.
>> You'd really want to enable this ;-)
>
> TLS isn't all there yet.  I'm aware it makes dispatch less painful.
Please include a bugreport (beside the configure toggle) + casually
poke the team. Otherwise it might take a decade to achieve ;-)

Thanks
Emil


More information about the Mesa-maintainers mailing list