[Mesa-dev] [RFC PATCH 00/16] A new IR for Mesa

[Connor Abbott]

On Thu, Aug 28, 2014 at 5:07 AM, Christian König
<christian.koenig at amd.com> wrote:
>> At least with the other components on which Mesa relies (e.g., libdrm,
>> 2D drivers, etc.) it's largely the same group of people with the same
>> set of goals.
>
>
> This was only true until Tom Stellard started to manage LLVM point releases.

"one person managing point releases" =/= "largely the same group of
people with the same set of goals."

>
> Christian.
>
> Am 28.08.2014 um 00:07 schrieb Ian Romanick:
>
>> On 08/27/2014 02:55 PM, Marek Olšák wrote:
>>>
>>> Our plan is to always require the latest released version of LLVM
>>> because of new features in our LLVM backend that the radeonsi driver
>>> depends on to advertise all GL features. Some new features listed for
>>> the radeonsi driver in Mesa release notes are only enabled if you have
>>> latest LLVM from git/svn.
>>
>> I think this underscores the fundamental problem have having such a
>> critical, core piece of project infrastructure being completely out of
>> the control of the project.  For me, trying to ship a product on which
>> people rely, this is an absolute non-starter.
>>
>> At least with the other components on which Mesa relies (e.g., libdrm,
>> 2D drivers, etc.) it's largely the same group of people with the same
>> set of goals.
>>
>>> Marek
>>>
>>> On Wed, Aug 27, 2014 at 8:39 PM, Ilia Mirkin <imirkin at alum.mit.edu>
>>> wrote:
>>>>
>>>> On Wed, Aug 27, 2014 at 2:26 PM, John Kessenich <johnk at lunarg.com>
>>>> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> If Mesa used an LLVM IR for it's shader compiler stack, it would most
>>>>> likely
>>>>>
>>>>> Pick a specific shipped version.  Shipped versions are stable and
>>>>> unchanging.  Upgrading to a newer version would be done only by choice,
>>>>> on
>>>>> Mesa's schedule.
>>>>> Not bring the source into mesa: it works perfectly well sitting next to
>>>>> Mesa.
>>>>> Link it in statically so there are no distro/versioning issues and no
>>>>> interactions with other components of the system that independently use
>>>>> LLVM
>>>>> however they wish.  This is also quite small compared to other uses of
>>>>> LLVM
>>>>> people sometimes discuss.
>>>>>
>>>>> Externally, no one could even tell some helper functions within the
>>>>> compiler
>>>>> stack came from LLVM or a specific version of LLVM.
>>>>
>>>> So... what happens when some backend, say radeonsi, requires a newer
>>>> version? That would become linked to moving the rest of mesa up to a
>>>> newer version, or linking in 2 different versions of llvm (not sure if
>>>> that'd be possible...)
>>>>
>>>>    -ilia
>>>> _______________________________________________
>>>> mesa-dev mailing list
>>>> mesa-dev at lists.freedesktop.org
>>>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>>
>>> _______________________________________________
>>> mesa-dev mailing list
>>> mesa-dev at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
>> _______________________________________________
>> mesa-dev mailing list
>> mesa-dev at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev