AMD RadeonSI & R600g Gallium3D Tests On Mesa 11.0 + DRM-Next

[edoantonioco]

I have been expecting some performance improvement for the r600 driver and then I saw this :/ R600 needs to receive some performance love from the devs before they will decide to stop actively supporting it, supposing they haven't yet done.

[Veerappan]

It was a release build; optimizations enabled, assertions disabled.

Sounds good. I figured that you'd probably taken that into account, especially since there's a giant warning in the configure/make process if you create a debug build (which is the default).

[smitty3268]

Apply this patch to rc1 and retest again It is known one and will be in rc2:

http://cgit.freedesktop.org/mesa/mes...bab900006648aa

Yeah, I think the win in Valley probably comes from a newer LLVM shader backend, and the losses mostly come from that commit which got reverted.

[andrei_me]

Michael

Any system on linuxbenchmarking hit one of these regressions?
If you dig the results, there is any indication of this regressions?

[darkbasic]

Apply this patch to rc1 and retest again It is known one and will be in rc2:

http://cgit.freedesktop.org/mesa/mes...bab900006648aa

BTW generally that mesa 11 + llvm 3.8-git does not make sense to me Really, you want RC of all (mesa 11 and llvm 3.7) or git heads of all

Agree. Please test all git, you missed great perf improvements in mesa with this commit.

[darkbasic]

Michael

Any system on linuxbenchmarking hit one of these regressions?
If you dig the results, there is any indication of this regressions?

Unfortunately Linuxbenchmarking is simply useless in its current state for a number of reasons which I can't explain right now. I'm thinking about building my own to (seriously) test amdgpu resgressions on a per-commit base if Michael is willing to help me to setup the Phoromatic server plus making the needed modifications to the suite. Costs will be a problem of course, but I guess there are enough people willing to donate to cover expenses.

[haagch]

The results don't surprise me. I recently tried mesa 10.5 + llvm 3.5 on my HD 7970M.

Here are a few screenshots with a few GALLIUM_HUD graphs enabled: https://imgur.com/a/GrwtL

Here are a few screenshots with mesa git + llvm svn from a few days ago (without SI scheduler patch): https://imgur.com/a/kmMKD

I'm not completely sure because the units are different, but I think the buffer wait times were lower with mesa 10.5 and the gpu usage (load) was better (higher) with mesa 10.5.

Michael is there any chance to include information like this in the phoronix test suite tests so that more parameters can be compared?

Does mesa support printing the GALLIUM_HUD info to the console or a log file, or does it only support displaying it in an overlay? If the first, how do developers feel about adding logging to a file or so?

[haagch]

Agree. Please test all git, you missed great perf improvements in mesa with this commit.

On the plus side, we will be able to compare the impact of this revert for different GPUs once Michael tests again.

[Michael]

The results don't surprise me. I recently tried mesa 10.5 + llvm 3.5 on my HD 7970M.
Michael is there any chance to include information like this in the phoronix test suite tests so that more parameters can be compared?

Does mesa support printing the GALLIUM_HUD info to the console or a log file, or does it only support displaying it in an overlay? If the first, how do developers feel about adding logging to a file or so?

As far as I know, there is no dumping support right now for the GALLIUM HUD data. But if there was, it would be trivial to support by the Phoronix Test Suite.

[SystemCrasher]

Hmm, btw... it's quite big omission there is no way to dump raw gallium hud data into file. I found HUD quite useful for getting idea what goes on, but sometimes I need to do automated/batch processing of this kind of data and Gallium HUD would not help with that. This is very sad, since it actually got most code and data in hand and it literally about being able to write it to some file.