No it does not. The LLVM work on VLIW was originally intended for compute paths only, not graphics paths, but Tom was using graphics paths to test the new compiler code before an OpenCL framework was available. The results (graphics + llvm + VLIW) looked sufficiently promising to pursue further. Compute paths would continue to use llvm AFAIK.
Originally Posted by 89c51
It won't affect performance. llvm has never been enabled by default in r600g. The llvm support in r600g was only originally intended to support OpenCL, it was just enabled optionally for OpenGL for testing purposes, but it never got full support for a lot of the features required for OpenGL. What this patch does is disable OpenGL llvm support by default when it's enabled in the driver.
Originally Posted by edoantonioco
As far as I remember, the LLVM backend has always been slower on R600 since Vadim's backend was merged. Why people think LLVM should be faster is a mystery to me.
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
and the performance was better, but if I did this
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.
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?
This has nothing to do with llvmpipe, or even radeonSI.
Originally Posted by liam
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; 04-18-2014 at 02:16 AM.
I 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.
Originally Posted by marek
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.
Faster than what?
Originally Posted by Ericg
Vadim's sb compiler
Originally Posted by dee.
I don't think most people really give it that much thought. LLVM has become a buzzword. People see it and automatically think it must be better.
Originally Posted by Ericg
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.