On 08/22/2014 02:17 PM, Tom Stellard wrote:
> On Fri, Aug 22, 2014 at 02:10:03PM -0700, Ian Romanick wrote:
>> On 08/20/2014 11:58 AM, Tom Stellard wrote:
>>> On Wed, Aug 20, 2014 at 11:13:13AM -0700, Kenneth Graunke wrote:
>>>> On Wednesday, August 20, 2014 06:41:08 PM Michel Dänzer wrote:
>>>>> On 20.08.2014 00:04, Connor Abbott wrote:
>>>>>> On Mon, Aug 18, 2014 at 8:52 PM, Michel Dänzer <mic...@daenzer.net>
>>>>>> wrote:
>>>>>>> On 19.08.2014 01:28, Connor Abbott wrote:
>>>>>>>> On Mon, Aug 18, 2014 at 4:32 AM, Michel Dänzer <mic...@daenzer.net>
>>>>>>>> wrote:
>>>>>>>>> On 16.08.2014 09:12, Connor Abbott wrote:
>>>>>>>>>> I know what you might be thinking right now. "Wait, *another* IR?
>>>>>>>>>> Don't
>>>>>>>>>> we already have like 5 of those, not counting all the driver-specific
>>>>>>>>>> ones? Isn't this stuff complicated enough already?" Well, there are
>>>>>>>>>> some
>>>>>>>>>> pretty good reasons to start afresh (again...). In the years we've
>>>>>>>>>> been
>>>>>>>>>> using GLSL IR, we've come to realize that, in fact, it's not what we
>>>>>>>>>> want *at all* to do optimizations on.
>>>>>>>>>
>>>>>>>>> Did you evaluate using LLVM IR instead of inventing yet another one?
>>>>>>>>
>>>>>>>> Yes. See
>>>>>>>>
>>>>>>>> http://lists.freedesktop.org/archives/mesa-dev/2014-February/053502.html
>>>>>>>>
>>>>>>>> and
>>>>>>>>
>>>>>>>> http://lists.freedesktop.org/archives/mesa-dev/2014-February/053522.html
>>>>>>>
>>>>>>> I know Ian can't deal with LLVM for some reason. I was wondering if
>>>>>>> *you* evaluated it, and if so, why you rejected it.
>>>>>
>>>>> First of all, thank you for sharing more specific information than
>>>>> 'table-flipping rage'.
>>>>>
>>>>>
>>>>>> * LLVM is on a different release schedule (6 months vs. 3 months), has
>>>>>> a different review process, etc., which means that to add support for
>>>>>> new functionality that involves shaders, we now have to submit patches
>>>>>> to two separate projects, and then 2 months later when we ship Mesa it
>>>>>> turns out that nobody can actually use the new feature because it
>>>>>> depends upon an unreleased version of LLVM that won't be released for
>>>>>> another 3 months and then packaged by distros even later...
>>>>>
>>>>> This has indeed been frustrating at times, but it's better now for
>>>>> backend changes since Tom has been making LLVM point releases.
>>>>
>>>> Yeah - absolutely.
>>>>
>>>>> As for the GLSL frontend, I agree with Tom that it shouldn't require
>>>>> that much direct interaction with the LLVM project.
>>>>>
>>>>>
>>>>>> we've already had problems where distros refused to ship newer Mesa
>>>>>> releases because radeon depended on a version of LLVM newer than the
>>>>>> one they were shipping, [...]
>>>>>
>>>>> That's news to me, can you be more specific?
>>>>>
>>>>> That sounds like basically a distro issue though, since different LLVM
>>>>> versions can be installed in parallel (and the one used by default
>>>>> doesn't have to be the newest one). And it even works if another part of
>>>>> the same process uses a different version of LLVM.
>>>>
>>>> Yes, one can argue that it's a distribution issue - but it's an extremely
>>>> painful problem for distributions.
>>>>
>>>> For example, Debian was stuck on Mesa 9.2.2 for 4 months (2013-12-08 to
>>>> 2014-03-22), and I was told this was because of LLVM versioning changes in
>>>> the other drivers (primarily radeon, I believe, but probably also
>>>> llvmpipe).
>>>>
>>>> Mesa 9.2.2 hung the GPU every 5-10 minutes on Sandybridge, and we fixed
>>>> that in Mesa 9.2.3. But we couldn't get people to actually ship it, and
>>>> had to field tons of bug reports from upset users for several months.
>>>>
>>>> Gentoo has also had trouble updating for similar reasons; Matt (the Gentoo
>>>> Mesa package mantainer) can probably comment more.
>>>>
>>>> I've also heard stories from friends of mine who use radeonsi that they
>>>> couldn't get new GL features or compiler fixes unless they upgrade both
>>>> Mesa /and/ LLVM, and that LLVM was usually either not released or not
>>>> available in their distribution for a few months.
>>>>
>>>> Those are the sorts of things I'd like to avoid. The compiler is easily
>>>> the most crucial part of a modern graphics stack; splitting it out into a
>>>> separate repository and project seems like a nightmare for people who care
>>>> about getting new drivers released and shipped in distributions in a
>>>> timely fashion.
>>>>
>>>> Or, looking at it the other way: today, everything you need as an Intel or
>>>> (AFAIK) Nouveau 3D user is nicely contained within Mesa. Our community
>>>> has complete control over when we do those releases. New important bug
>>>> fixes, performance improvements, or features? Ship a new Mesa, and you're
>>>> done. That's a really nice feature I'd hate to lose.
>>>>
>>>
>>> It has been a challenge to match versions of LLVM and Mesa for radeonsi,
>>> but as Michel mention this has been made easier now that we are doing
>>> LLVM point releases.
>>>
>>> However, as I mentioned before if we were using LLVM IR as a common IR
>>> it is unlikely that there would be any new features in Mesa that would
>>> depend on changes in LLVM. The only thing we would need to modify LLVM
>>> for would be:
>>> - Extending the C API
>>> - Bug fixes for optimization passes
>>> - Optimization pass improvements
>>>
>>> And remember all these changes would be for improving common code that
>>> is shared between drivers. All of the important compiler features would
>>> still go into the driver specific backends, which for most drivers are a
>>> part of Mesa.
>>>
>>> Even for a big new feature like geometry shaders you wouldn't need
>>> to make any modifications to LLVM to add it to the GLSL compiler in
>>> Mesa. The only reason radeonsi has such a hard dependency on LLVM
>>> is because the entire compiler is part of LLVM.
>>
>> Speaking of new shader stages... how would LLVM handle the 'precise'
>> keyword in tesselation shaders? I can envision ways to handle this in
>> an IR that we control, but it's less obvious how we would handle it in
>> LLVM or another external compiler package.
>>
>
> What exactly does precise do? LLVM has fast-math flags you can apply to
> instructions and also some global flags.
Through various means, you can tag a calculation (and expression tree)
so that the same calculation in different shaders will produce the exact
same result. This generally limits a lot of optimizations on such
calculations. For example:
// shader A
precise o = a * b + c;
// shader B
x = a * b;
precise o = a * b + c;
If shader A generates a MAD for the expression, shader B must also
generate a MAD... even if that means being less efficient. This is also
why ARB_gpu_shader5 adds the fma function: many fma instructions have
extra precision vs MUL+ADD.
This is often used in tesselation shaders so that neighboring patches
with different materials won't have cracks between them.
> -Tom
>
>>> -Tom
>>>
>>> _______________________________________________
>>> mesa-dev mailing list
>>> mesa-dev@lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
