[Mesa-maintainers] Dealing with conflicting files [Re: Downstream patches and package recipes
Andreas Boll
andreas.boll.dev at gmail.com
Thu Feb 23 13:13:11 UTC 2017
2017-02-23 13:29 GMT+01:00 Jonathan Gray <jsg at jsg.id.au>:
> On Thu, Feb 23, 2017 at 01:20:45PM +0100, Andreas Boll wrote:
>> 2017-02-23 11:39 GMT+01:00 Emil Velikov <emil.l.velikov at gmail.com>:
>> > On 23 February 2017 at 10:10, Andreas Boll <andreas.boll.dev at gmail.com> wrote:
>> >> 2017-02-22 15:31 GMT+01:00 Emil Velikov <emil.l.velikov at gmail.com>:
>> >>> [splitting out of the main thread]
>> >>>
>> >>> On 22 February 2017 at 13:52, Pedretti Fabio <pedretti.fabio at gmail.com> wrote:
>> >>>> I can see an issue with swrast and i915, both have classic and gallium
>> >>>> versions. They can be both built fine, but they get installed in the same
>> >>>> dri directory and one (apparently the gallium one) overwrite the other.
>> >>>> There should be a way to be able to build and install both without special
>> >>>> tricks and have a way the use can select one or the other.
>> >>>>
>> >>> Thanks for bringing this up Fabio.
>> >>>
>> >>> At the moment, we have:
>> >>> - cases where the files are overwritten at install stage
>> >>> swrast being the most common one - oibaf PPA, Debian/Ubuntu (?), Arch,
>> >>> Suse, Fedora (?)
>> >>
>> >> Debian & Ubuntu don't overwrite those files because they never build both
>> >> swrast at the same time.
>> >> It's split in architectures where llvm is enabled:
>> >> -> building gallium swrast only
>> >> and architectures where llvm is disabled:
>> >> -> building classic swrast only
>> >>
>> > Well placed the question mark ;-) Thanks for the correction.
>> >
>> >>> - special handling for classic vs gallium files
>> >>> Manage which one is picked via a script/tool - Gentoo (I really like
>> >>> the approach)
>> >>> - building only one of the two
>> >>
>> >> Exactly what Debian & Ubuntu are doing.
>> >>
>> >>> Nearly nobody builds i915g.
>> >>>
>> >>> What we need - make install should:
>> >>> - produce correctly named files
>> >>> - place them where such they can be used
>> >>>
>> >>> At the same time:
>> >>> - at runtime, there is no clear heuristic to check if the classic or
>> >>> gallium one is required.
>> >>> - we cannot retroactively fix old mesa (libGL/libEGL/libgbm) and
>> >>> xorg-server (libglx.so) loaders
>> >>>
>> >>>
>> >>> Thus the following ideas that come to mind (in order of personal preference):
>> >>> - use/import library management similar to the Gentoo one
>> >>> - make them mutually exclusive, similar to {classic,gallium}osmesa
>> >>> - rename to {swrast,i915}g_dri.so and add fallback(s) in the loaders
>> >>> Icky, retro-fix old mesa/xorg ?
>> >>> - deprecate (from build perspective) classic swrast, i915g
>> >>
>> >> Debian & Ubuntu:
>> >> We don't build i915g (only classic i915) and we are trying to deprecate classic
>> >> swrast on most architectures.
>> >> I'm planning to enable llvm on more architectures but unfortunately not on all.
>> >>
>> > Need to check with devs, if this will fly. In the meanwhile do you see
>> > any alternative solutions, do you think that any of my other
>> > suggestions are forth the shot ?
>>
>> I'd vote for:
>> - make them mutually exclusive, similar to {classic,gallium}osmesa
>>
>> Shouldn't be that much work and would also be a step into deprecating classic
>> swrast.
>> Furthermore I'd add a deprecation warning if one enables classic swrast.
>> IMO people should really use llvmpipe and only build classic swrast if one can't
>> use llvm for some reason.
>
> gallium softpipe works without llvm. On OpenBSD we only build softpipe
> and not classic swrast on all archs including some such as hppa that are
> unlikely to ever get a llvm backend.
Good point. Will switch to softpipe on the remaining architectures.
More information about the Mesa-maintainers
mailing list