Originally posted by 89c51
View Post
Announcement
Collapse
No announcement yet.
R600 Gallium3D Disables LLVM Back-End By Default
Collapse
X
-
Test signature
-
Originally posted by edoantonioco View PostDoes this means less performance? And are we talking about mesa 10.2?, because its not explained.
Comment
-
Some time ago in mesa 9.2 there was a new feature (the r600 back-end) that bring better performance, but it was disabled by default (enabled by default in 10.0). I activate that feature with
R600_DEBUG=sb,nollvm
and the performance was better, but if I did this
R600_DEBUG=sb
the performance was even better.
That means than the LLVM stuff meant more performance. Thats why I was curious about how the performance would be affected now than the feature is going to be disabled.
Comment
-
Does this mean we shouldn't expect llvmpipe to reach parity with the hardware drivers for some time? Is the reason for these features not being implemented because of an issue with upstream, with the current implementation of llvm, or with the codebase?
Comment
-
Originally posted by liam View PostDoes this mean we shouldn't expect llvmpipe to reach parity with the hardware drivers for some time? Is the reason for these features not being implemented because of an issue with upstream, with the current implementation of llvm, or with the codebase?
It's about the r600 backend inside llvm, which isn't as good as the compiler and sb optimizer inside mesa's r600g driver. Nothing else.
And the reason it's not is because no one is really working on it - everyone on the llvm side is busy getting OpenCL and the radeonSI driver working. Nobody cares about getting it working for r600g because that driver already works without it.Last edited by smitty3268; 18 April 2014, 02:16 AM.
Comment
-
Originally posted by marek View PostWhy people think LLVM should be faster is a mystery to me.
Contrastly Vadim's work, while VERY appreciated and applauded, is a compiler that was written by one person for one task and currently receives an unknown amount of attention and optimization. Meanwhile the development effort on LLVM is known.
Also there's the issue of LLVM's expanding usage in many things and the assumption that comes with that growth that LLVM would be flexible enough to handle anything and everything, including graphics shader work.All opinions are my own not those of my employer if you know who they are.
Comment
-
Originally posted by Ericg View PostI think its more along the lines of people think LLVM should be faster eventually and could be made to be faster. LLVM brings to the table quick compilation, ontop of a full compiler that can be optimized to be very platform specific. With at least a chance of getting free performance bumps from optimizations made to other parts of LLVM.
Contrastly Vadim's work, while VERY appreciated and applauded, is a compiler that was written by one person for one task and currently receives an unknown amount of attention and optimization. Meanwhile the development effort on LLVM is known.
Also there's the issue of LLVM's expanding usage in many things and the assumption that comes with that growth that LLVM would be flexible enough to handle anything and everything, including graphics shader work.
Also, there's the whole thing of having the SI driver use it. People think if the newer driver is requiring it, there has to be a good reason they went that way, and in the realm of 3d drivers that often equates to better performance.
Comment
Comment