Hello Michel,
subject say it all ;-)
Second, we are now nearly on par with 3.16 on RV730 (AGP) with all your latest work, but I think about what we could get if we find the right commit between 3.16 (.4 here) and 3.17-rc1 (the transition from 3.16 to 3.17-next).
I do not have 3.16.x around (it is not any longer in the openSUSE kernel current tree) but with latest 3.16.4 I was faster then with all 3.17.x and 3.18/3.19-next kernels.
bisect do not work right or I couldn't revert the 'right' commit. WC helped on RV730 (AGP) with some apps, here:
mesa-demos e.g. vsraytrace fsraytrace objview
Any ideas?
-Dieter
On Wed, Oct 22, 2014 at 12:49 PM, Dieter Nützel Dieter@nuetzel-hh.de wrote:
Hello Michel,
subject say it all ;-)
The llvm support for r600g is for compute (OpenCL). The fact that is it somewhat usable for graphics is mainly for testing purposes. There are no plans to expand it to handle additional graphics features, although any interested parties are welcome to contribute to improving it. IIRC, even when you enable it, it currently only gets applied to compute shaders.
Second, we are now nearly on par with 3.16 on RV730 (AGP) with all your latest work, but I think about what we could get if we find the right commit between 3.16 (.4 here) and 3.17-rc1 (the transition from 3.16 to 3.17-next).
I do not have 3.16.x around (it is not any longer in the openSUSE kernel current tree) but with latest 3.16.4 I was faster then with all 3.17.x and 3.18/3.19-next kernels.
bisect do not work right or I couldn't revert the 'right' commit. WC helped on RV730 (AGP) with some apps, here:
How are you doing the bisection? If it's purely a performance issue it should be pretty straight forward.
mesa-demos e.g. vsraytrace fsraytrace objview
Any ideas?
Can you provide some additional detail? It would probably be easier to track this in a bug report.
Alex
On 23.10.2014 02:24, Alex Deucher wrote:
On Wed, Oct 22, 2014 at 12:49 PM, Dieter Nützel Dieter@nuetzel-hh.de wrote:
subject say it all ;-)
The llvm support for r600g is for compute (OpenCL). The fact that is it somewhat usable for graphics is mainly for testing purposes. There are no plans to expand it to handle additional graphics features, although any interested parties are welcome to contribute to improving it. IIRC, even when you enable it, it currently only gets applied to compute shaders.
The LLVM compiler is used automatically for OpenCL, even without --enable-r600-llvm-compiler. That option allows using LLVM for graphics as well, but it's currently disabled by default at runtime, the user needs to explicitly enable it via the environment variable R600_DEBUG=llvm or R600_LLVM=1. Due to the limitations of that (no geometry shader support and other missing functionality, lots of bugs), I'd currently recommend against enabling it unless you want to work on fixing its problems.
Second, we are now nearly on par with 3.16 on RV730 (AGP) with all your latest work, but I think about what we could get if we find the right commit between 3.16 (.4 here) and 3.17-rc1 (the transition from 3.16 to 3.17-next).
I do not have 3.16.x around (it is not any longer in the openSUSE kernel current tree) but with latest 3.16.4 I was faster then with all 3.17.x and 3.18/3.19-next kernels.
Faster doing what?
WC helped on RV730 (AGP) with some apps, here:
What exactly do you mean by 'WC helped'? CPU mappings of GTT have always used write-combining with AGP, so unless you disable AGP, the changes related to that shouldn't change anything.
dri-devel@lists.freedesktop.org
-
Alex Deucher -
Dieter Nützel -
Michel Dänzer