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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
