The Current RadeonSI Benefits Of Switching To Mesa 13.1-dev Git On Ubuntu 16.10

[Electric-Gecko]

I'm sorry if anyone already brought this up, but Dota 2 is the only program to be benchmarked on two different resolutions. There should have been testing on both resolutions for a game such as Metro Last Light or Xonotic, which had big performance improvements with the new MESA. Dota 2 had very small gains in either test, so it's less valuable. Michael should have noticed this, and added a benchmark of one of the formerly mentioned games in 1080p. When we are looking at performance differences from software upgrades, it's handy to know if the improvements are CPU or GPU related.

[dungeon]

Last time i tried (but OK several years ago) -Ofast was much faster but only because it breaks fog in some games or something like that happened Doing -O3 was not also safe, some older apps refusing to launch, probably even -O2 is not total safe too but is recommended way.

[dungeon]

That said, I have tried Ofast and LTO and I did not notice major differences in games. I did notice major differences in compile time though. LTO easily triples the time it takes to build mesa for (currently) very little benefit.

Probably most benefit is going from -O0 to -O1, then -O2... going to -O3, -Ofast there is least and least benefits and just more chance for breakages

[peppercats]

You meant bloated? Just compare the run time of apt-get update; apt-get upgrade to pacman -Syu for a similar sized update. I know, apt is doing more work, but the result is that it takes much, much longer.

I don't think compiler optimizations are doing a lot for mesa right now. Even with -O0 -ggdb3, real games are only somewhat slower. I think that even small improvements in how mesa handles OpenGL will have most likely a bigger impact, so I believe starting to look into the hardcore compiler optimizations will make sense, once mesa is really well optimized through and through.

That said, I have tried Ofast and LTO and I did not notice major differences in games. I did notice major differences in compile time though. LTO easily triples the time it takes to build mesa for (currently) very little benefit.

use threaded LTO(I think it's gcc-only right now) with -flto=# where # is the number of threads.

Most of the projects I work on compile faster with LTO now than without. It essentially combines the best of unity builds(LTO part) with separate compilation units(uses multiple threads)

[dungeon]

I took another look but most of the tickets on there are pretty old... TF2 was the only one that was still a big problem AFAIK. There may be others but I don't think it's fair to say "any game that stresses the driver".

TF2 is probably just most popular of those which hangs Probably not *any* but it might be any depending how long you play some game, here Marek reproduced it with XCOM:

The hangs usually happen between 1 minutes and 8 hours.

https://bugs.freedesktop.org/show_bug.cgi?id=80419#c142

[Marc Driftmeyer]

Aricles like this sounds always like "why you should not use Ubuntu, but ArchLinux"




Manjaro; Linux4.8; Mesa 13; Blender 2.78.a; R9 380 - no crash.

The difference is Distribution built against Mesa 13 where Debian isn't. What version of LLVM is your libdrm for amdgpu built against? I'm betting it's LLVM 3.9 across the board support for both the Producer and Reader.

Custom built distributions for the bleeding edge aren't Debian Sid or even Experimental.

mdriftme[email protected]:~/Downloads$ CYCLES_OPENCL_SPLIT_KERNEL_TEST=1 blender
ndof: unknown Logitech product c52f
ndof: unknown Logitech product 082d
Read new prefs: /home/mdriftmeyer/.config/blender/2.78/config/userpref.blend
found bundled python: /usr/lib/blender/2.78/python
archimesh: Imported multifiles
version 3 imported
measureit: Imported multifiles
Rock generator settings file found:
/usr/lib/blender/2.78/scripts/addons_contrib/add_mesh_rocks/add_mesh_rocks.xml
Rock Generator: Numpy found.
OSError: Python file "/usr/lib/blender/reset_excepthook.py" could not be opened: No such file or directory
read blend: /home/mdriftmeyer/Blender/doorCurves.blend
Device init success
Device init success
Compiling OpenCL program base
OpenCL build failed with error CL_BUILD_PROGRAM_FAILURE, errors in console.
OpenCL program base build output: Invalid record (Producer: 'LLVM3.9.0' Reader: 'LLVM 3.8.1')
Error: Failed loading render kernel, see console for errors

^CTraceback (most recent call last):
File "/usr/lib/blender/2.78/scripts/addons/object_boolean_tools.py", line 389, in HandleScene
@persistent
KeyboardInterrupt
Saved session recovery to '/home/mdriftmeyer/Blender/Temp/quit.blend'

Blender quit

[jatone]

I agree in general except I can reproduce it as I'm one of the people impacted. If the problem was in isolation I'd agree, but people keep reporting it.

[dungeon]

Ideally AMD should build one blob and magically avoid most of bugs and advise people to try or use that ... but again opensource people usually want something else

[dungeon]

You can bacisically ignore 90% bugs on bugzilla , what you read there does not mean it will happen to you too... only if you can reproduce something is sort of valuable validation.

Opencourse software consist on diversifications, in reality there is no that much bugs per user machine, no

[jatone]

The tickets are old because the issue is old, new responses come in occassionally. I've basically stopped trying to help because I'm not familiar enough with the tech stack to get decent debugging information. I'm actually willing to go through the effort of tracking it down since I can reproduce it extremely reliably but not without some help in making sure I'm getting useful information towards solving the issue.