[Mesa-dev] r600g: status of my work on the shader optimization
vadimgirlin at gmail.com
Fri Feb 15 13:26:25 PST 2013
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.
More information about the mesa-dev