[Mesa-dev] r600g: status of my work on the shader optimization

[Vadim Girlin]

On 02/15/2013 04:06 PM, Michel � wrote:
> On Fre, 2013-02-15 at 15:00 +0400, Vadim Girlin wrote:
>> On 02/14/2013 02:42 PM, Christian K�nig wrote:
>>>
>>> nice work, I think you've made quite a progress here, but on the other
>>> hand it should be clear that the LLVM backend is the future and we
>>> should concentrate on that.
>>
>> "LLVM backend is the future" is a pretty abstract argument. I prefer to
>> operate with real facts. After a year of LLVM backend development what
>> are the real benefits for the users? What are the real use cases where
>> the users might prefer LLVM backend? To me this situation looks like the
>> use of LLVM requires a lot more time and development efforts than the
>> custom solution, despite the initial expectations. Maybe you are right
>> and the LLVM backend will become the best alternative for users sometime
>> in the future, but I only have some today's results:
>>
>> Heaven 3.0, all settings high/enabled, 1280x720, HD5750:
>>     default backend : 20.0 fps
>>     llvm backend    : 18.8 fps
>>     r600-sb         : 38.0 fps
>>
>> When I'm looking at these results, the benefits of LLVM-based solution
>> are not very clear to me.
>
> Those are really impressive numbers, but to put things into perspective
> a little bit:
>
> When comparing two solutions, there will always be cases where one beats
> others like this. I think I've also seen reports of cases where the LLVM
> backend provides similar speedups over the default one, though of course
> your branch might still be even better there.
>
> Also, it's not like the LLVM backend for r600g has been heavily tuned
> for performance over the last year. Most of the effort went into support
> for radeonsi and compute support for r600g. Only recently have people
> like Vincent started making serious improvements to the LLVM backend for
> r600g graphics support. It might be possible to apply at least some of
> the lessons learned from your branch to the LLVM backend as well.
>

I understand that it's not tuned for performance, and I understand why, 
and I think one of the reasons is that it's really hard to tune it for 
performance for such a non-standard (for LLVM) architecture as r600.

I appreciate Tom's and Vincent's hard work, but my point is that 
efficient compiler for GL shaders for r600g doesn't have to require as 
much efforts as it seems with LLVM backend for r600g. Not to mention 
that a lot of required efforts were intended not to improve the compiler 
itself, but to collaborate with LLVM people, maintain the separate 
branch of LLVM for mesa, etc. I understand that it is a hard work, 
that's why in the end I preferred the way that seemed more simple to me.

Also I'll be happy if this branch in the end will help to improve LLVM 
backend to the state where it will have comparable performance, so that 
we can forget about this custom implementation at some point. My goal is 
not to push some code into mesa/r600g, but to improve the performance, 
and it doesn't matter what exactly will do it under the hood. Even if 
this branch will never be merged, it can help to understand which 
optimizations are really significant and which are not worth the 
efforts. At least for me it's a lot easier to try something in this 
branch than to implement it in the LLVM backend just to find out that 
the effect is not noticeable. E.g. just look at the implementation of 
the if-conversion in this branch and compare it's complexity to the 
implementation of the if-conversion on the CFGs in the LLVM.

I think some kind of competition created by this branch might also help 
to make the users more happy in the end.

Vadim