Radeon HD 7xxx Performance is Depressing With Wine...?

[Guest]

I have two computers, one is a Desktop with a single Radeon HD 7850, and the other is a laptop with AMD Dual Graphics (7660G on the APU + 7670M dGPU). I currently use Xubuntu 13.04.

The only thing that is really bothering me currently is how a single game performs under Wine (Guild Wars 2). I've tried both fglrx (13.4 and 13.8b2) and radeonsi drivers along with a CSMT-patched Wine to no real success.

GW2 is just non-ideally slow on radeonsi.

GW2 on fglrx seems to run well, when I can actually get in-game (less than 5% of the time if that even; with CSMT). The game either locks up at the character select screen (most of the time), or locks up at the loading screen while trying to enter the world. I actually got on a character one time, and graphics were semi-glitchy, but wasn't able to experiment as to what was causing it. Without CSMT, GW2 runs, but is non-ideally slow too.

GW2 isn't the only game I've had issues with though, but generally speaking, I don't think anything I've ran in Wine actually ran as-expected. The few Steam-native games I've played run ok (on fglrx) though.

Is this expected? From my understanding, any "real" performance on 7xxx hardware is only to be expected on fglrx currently, and apparently both radeon and radeonsi aren't nearly as-good, for 3D. Is there any other suggestions as to what I can do for more performance? I'd rather keep my 7xxx hardware.

[curaga]

Both your laptop cards are HD6000 rebrands, so they should work fine using r600g (not radeonsi).

For your desktop, not much you can do but wait.

[Guest]

Both your laptop cards are HD6000 rebrands, so they should work fine using r600g (not radeonsi).

For your desktop, not much you can do but wait.

Hmm, what's the driver for r600g? I was also under the impression that radeonsi was the best FOSS AMD/ATI driver currently?

[Tyler_K]

From my understanding, any "real" performance on 7xxx hardware is only to be expected on fglrx currently, and apparently both radeon and radeonsi aren't nearly as-good, for 3D
...
Hmm, what's the driver for r600g? I was also under the impression that radeonsi was the best FOSS AMD/ATI driver currently?

What you have written betrays that you don't have a good understanding of the stack. Here is a very brief (and grossly simplified) description of (the key components of) that for contemporary AMD graphics adapters under the X Display Server:

• kernel component
  • DRM/KMS kernel driver .... the radeon driver (radeon.ko) ... what you see listed if you use "lsmod", "lspci", etc..
• userspace components
  • DDX driver ... the Xorg driver (radeon_drv.so)
  • 3D/OpenGL (Mesa) driver) ... for which there exists, applicable to the particular hardware, the r300g (r300_dri.so), r600g (r600_dri.so), radeonsi (radeonsi_dri.so)

As for the 3D drivers, their naming represents a class of hardware that the driver begins coverage for (Example: r600g begins for r600 adapters up through to NI (Northern Islands)). The g appended on the names of the two listed above denotes that they are a gallium type of Mesa driver (distinguishing it from classic Mesa drivers ... there used to be (actually, originally were only) classic r300 & r600 drivers, but these have since been removed when the gallium versions became mature). Support for SI (Southern Islands) class hardware (and now extended above for the future CIK/Sea Islands adapters) was developed using a gallium driver from the very beginning, so no such naming distinction is used (needed). The support for SI devices (i.e. radeonsi driver) is slowly coming along, but is still not as mature or feature-full as the r600g.

[agd5f]

If you are using kernel 3.11 or newer, enable dpm (append radeon.dpm=1 to the kernel command line in grub), otherwise the SI chip will be using really slow boot up clocks.

[dffx]

Both your laptop cards are HD6000 rebrands, so they should work fine using r600g (not radeonsi).

I'm not sure that this is correct. Do you have source on this?

EDIT: Looks like the 78xxM (and lower) cards are a rebrand, while the 7970M (which I have) is still RadeonSI -- it's a downclocked version of the HD7870

[Guest]

Both your laptop cards are HD6000 rebrands, so they should work fine using r600g (not radeonsi).

Hmm, are they rebrand in the sense of the GPU chip itself being exactly similar? Like if a driver performed one way on the 6000-series equivalent to my dGPU, I should expect very similar, if not the same performance on my 7670M dGPU?

If you are using kernel 3.11 or newer, enable dpm (append radeon.dpm=1 to the kernel command line in grub), otherwise the SI chip will be using really slow boot up clocks.

Does that command work on non-SI chips (specifically, my NI chips in my laptop)? I believe I tried it, and felt slightly better performance, but still lower than that of fglrx by a good bit.

[curaga]

I'm not sure that this is correct. Do you have source on this?

EDIT: Looks like the 78xxM (and lower) cards are a rebrand, while the 7970M (which I have) is still RadeonSI -- it's a downclocked version of the HD7870

Your original post said 7670M, not 7970M - which is it?

[curaga]

@dffx:

Sorry, I got confused, you weren't the OP.

Hmm, are they rebrand in the sense of the GPU chip itself being exactly similar? Like if a driver performed one way on the 6000-series equivalent to my dGPU, I should expect very similar, if not the same performance on my 7670M dGPU?

A rebrand means the same chip with a new sticker on top. So exact same performance.

[bridgman]

Does that command work on non-SI chips (specifically, my NI chips in my laptop)? I believe I tried it, and felt slightly better performance, but still lower than that of fglrx by a good bit.

Yes, radeon.dpm=1 should enable dpm on all GPUs back to rv6xx on the 3.11 or 3.12 kernels.

IIRC the original r600 did not have dpm hardware, but everything from rv610 up did. The actual dpm hardware changes significantly between earlier and later generations but the dpm code is always enabled the same way.

Note that you need fairly recent userspace code as well to get the best performance from the open source stack.