AMD Radeon Graphics Performance With The Linux 3.19 Kernel

[haagch]

I just tested the llvm and mesa patches. Performance probably somewhat improved, but much, much, much more important for PRIME:

This extreme flickering

https://www.youtube.com/watch?v=d1Fn3gmaa2A

https://www.youtube.com/watch?v=LwpRnUEE4ko

is basically gone.

Old frames still sometimes flicker, but it's very rare now.

There's still visible tearing at low fps because of https://bugs.freedesktop.org/show_bug.cgi?id=76367, but at least it's bearable now.

[mannerov]

I just tested the llvm and mesa patches. Performance probably somewhat improved, but much, much, much more important for PRIME:

This extreme flickering

https://www.youtube.com/watch?v=d1Fn3gmaa2A

https://www.youtube.com/watch?v=LwpRnUEE4ko

is basically gone.

Old frames still sometimes flicker, but it's very rare now.

There's still visible tearing at low fps because of https://bugs.freedesktop.org/show_bug.cgi?id=76367, but at least it's bearable now.

This flickering is a race between the amd card writing the buffer and the intel card reading it.
It happens with DRI3 DRI_PRIME, while with DRI2 DRI_PRIME you get tearings.

Initially, when DRI3 DRI_PRIME was merged, radeonsi would use dma blit to write the buffer content, and thus it was very fast and you didn't have triangles: either the intel card was reading all correct, or reading an old frame.
And generally you didn't have that much issues because dma blit is fast and for most apps the intel card would read after the card wrote.

But due to instability on some cards, they disabled dma copy entirely. the copy is slower, and the intel card reads much more often things that are not yet written entirely, thus the triangles (the copy is then done with a simple shader drawing two triangles).

This general synchronisation issue wasn't supposed to last long, since kernel was to get dma-buf synchronisations, but as of today, intel card still don't implement dma-buf synchronisation.

For gallium-nine, we use a different method and use a separate submitting thread for DRI_PRIME. We don't need dma-buf synchronisation to get content right.

[haagch]

Well, thanks for the explanations, but that's basically what I already knew.

But I'm still saying that even at comparably low framerates the extreme stuttering and flashing is much improved. Maybe there are other effects involved in introducing latency to frames.

But due to instability on some cards, they disabled dma copy entirely.

Oh, is it still? But R600_DEBUG=forcedma still enables it, right?

For gallium-nine, we use a different method and use a separate submitting thread for DRI_PRIME. We don't need dma-buf synchronisation to get content right.

Sorry, to bring it up, but with nine with intel+radeonsi PRIME I see the same: https://www.youtube.com/watch?v=cdGjWcsfUAc
I think it's gotten a little bit better, but you still see that it's not only tearing, but also old frames flashing keep flashing and create the impression of extreme stuttering... (watch second 6 and 7 on 0.25x speed to see what I mean)

[mannerov]

Well, thanks for the explanations, but that's basically what I already knew.

But I'm still saying that even at comparably low framerates the extreme stuttering and flashing is much improved. Maybe there are other effects involved in introducing latency to frames.


Oh, is it still? But R600_DEBUG=forcedma still enables it, right?


Sorry, to bring it up, but with nine with intel+radeonsi PRIME I see the same: https://www.youtube.com/watch?v=cdGjWcsfUAc
I think it's gotten a little bit better, but you still see that it's not only tearing, but also old frames flashing keep flashing and create the impression of extreme stuttering... (watch second 6 and 7 on 0.25x speed to see what I mean)

Try thread_submit=true in addition to DRI_PRIME. IT should realize wonders (it's not on by default because not enough testers yet)

[mannerov]

I tried that one vgpr-spilling-Jan07-2014 yesterday, there is no corruption there... there are slight, but those big perfromance improvments i didn't see there, only in perf branches... so dunno, maybe only happens on big chips like that one R9 280X

To help get the issues fixed, you can help find the faulty shaders.
Ie
. find the smallest application that has bugs
. or take a buggy application, take a trace with apitrace, replay piece by piece until you find the faulty shader

[haagch]

Try thread_submit=true in addition to DRI_PRIME. IT should realize wonders (it's not on by default because not enough testers yet)

I tested it with skyrim. I didn't notice any bad effects. It helps a lot with tearing and choppy flashing of old frames - it looks that they are completely gone.

I don't know, the performance is still a little low in comparison with windows. But it's already a good improvement over wined3d and not nine's fault I think.

So... Thanks for your great work, it really pays off.

[dungeon]

To help get the issues fixed, you can help find the faulty shaders.
Ie
. find the smallest application that has bugs
. or take a buggy application, take a trace with apitrace, replay piece by piece until you find the faulty shader

Not sure it is a shader, more seems like only/any 64bit opengl apps are affected... i already found culprit in scheduler commit few days ago, only today i will have a time to doublecheck that. If i remember right this part broke it:

http://cgit.freedesktop.org/~tstellar/llvm/diff/test/CodeGen/R600/smrd.ll?h=perf-Jan-08-2015&id=f11db5d5151e41e445cc8965f0d370414297ba23

[dungeon]

Blah, weird bisect It is just one in the end:

http://cgit.freedesktop.org/~tstellar/llvm/commit/?h=perf-Jan-08-2015&id=e106085e92a081aa4328a1297c9f0ff3f1ddca2d

But things seems fine and fast even before that ... so once enableSubRegLiveness is true rendering gets broken.

[mannerov]

Blah, weird bisect It is just one in the end:

http://cgit.freedesktop.org/~tstellar/llvm/commit/?h=perf-Jan-08-2015&id=e106085e92a081aa4328a1297c9f0ff3f1ddca2d

But things seems fine and fast even before that ... so once enableSubRegLiveness is true rendering gets broken.

And if you try reverting this patch only, does it work ?

[mannerov]

I tested it with skyrim. I didn't notice any bad effects. It helps a lot with tearing and choppy flashing of old frames - it looks that they are completely gone.

I don't know, the performance is still a little low in comparison with windows. But it's already a good improvement over wined3d and not nine's fault I think.

So... Thanks for your great work, it really pays off.

For performance, even with forcedma, dma copy is just used for 1D buffers.
Using a custom patch to reenable it, I get a small performance boost (because instead of doing the copy required every frame for DRI_PRIME with the graphic engine which has other things to do, you use the dma engine).

Then to get better performance increase, there's improvement to the SI compiler that are being worked on for a long time.
This branch http://cgit.freedesktop.org/~tstella...rf-Jan-08-2015 + the 4 last patches of http://cgit.freedesktop.org/~tstella...ing-Jan07-2014 give me a consistent 15% boost.
And it has the potential to be even more with some more improvements.

With these two, I get 70% of win performance for Skyrim. I think with even more compiler improvements, we could go to 85%. As for the remaining bits, it's surely in the driver (the constant engine to upload data faster isn't used at all)