Radeon Memory Boost: Up To 50%+ Better Performance

[Kemosabe]

I wished X-Plane would start with FOSS drivers. This is the only reason i have to use catalyst...

[Redi44]

Interesting, I wonder if this affects APUs as well. A super low-end AMD netbook I maintain might like these changes once I switch to the open drivers (which is as soon as Gentoo stabilises 3.13, which might be in a week or in a month).

Writing from AMD C-60 netbook running Fedora 20 and Gnome shell. It's pretty much on par with the blob...

BTW is this only for the r600 or does it affect radeonsi too?

[smitty3268]

Writing from AMD C-60 netbook running Fedora 20 and Gnome shell. It's pretty much on par with the blob...

BTW is this only for the r600 or does it affect radeonsi too?

I think this kernel code is good for any radeon card, or at least r300+. It looks like it requires some changes in Mesa to take best advantage of it, so we'll see if Marek submits changes to r300g along with r600g and SI. I'm pretty certain he'll at least do the last 2.

I don't think it will affect APU's, though. It seems to mostly be changing how memory is evicted from the GPU memory and sent to system memory, which doesn't exist unless you have a discrete card.

*disclaimer - i'm not a kernel or graphics dev, and this is just my understanding of the code i read in the ML

[schmidtbag]

Interesting, I wonder if this affects APUs as well. A super low-end AMD netbook I maintain might like these changes once I switch to the open drivers (which is as soon as Gentoo stabilises 3.13, which might be in a week or in a month).

I think this would have a bigger effect on APUs than anything else. The major drawback to APUs is the memory bandwidth. If Marek's fix lowers memory activity, then that should have an immense impact on APUs.

[log0]

I think this would have a bigger effect on APUs than anything else. The major drawback to APUs is the memory bandwidth. If Marek's fix lowers memory activity, then that should have an immense impact on APUs.

The changes deal with ram-vram transfers, apus (and igps) should not be affected afaiu.

[NomadDemon]

Marek is fkn genius ! this man is awesome !

[Kemosabe]

The changes deal with ram-vram transfers, apus (and igps) should not be affected afaiu.

This is not obvious and imho it doesn't make sense. Can you explain please?
igpus split their vram from ram but its still split off ...

[agd5f]

This affects all radeons so it could help on older cards as well. It will also help on APUs and IGPs. Even though APUs don't have dedicated vram, they use a stolen chunk of system memory as a vram pool. This is faster than regular system memory mapped through the gart since it's contiguous an non-snooped.

[Drago]

This affects all radeons so it could help on older cards as well. It will also help on APUs and IGPs. Even though APUs don't have dedicated vram, they use a stolen chunk of system memory as a vram pool. This is faster than regular system memory mapped through the gart since it's contiguous an non-snooped.

Lets just wait for the benchmarks then.

[GreatEmerald]

Writing from AMD C-60 netbook running Fedora 20 and Gnome shell. It's pretty much on par with the blob...

Hah, it's C-50 here Well, I'm using the blob there because the FOSS drivers used to eat more battery, but with DPM it should be good (and will finally allow it to wake up from sleep properly). Hence why I'm waiting for 3.13, where DPM is enabled by default and its issues are already ironed out (don't really have the incentive to change a working scheme until then).

This affects all radeons so it could help on older cards as well. It will also help on APUs and IGPs. Even though APUs don't have dedicated vram, they use a stolen chunk of system memory as a vram pool. This is faster than regular system memory mapped through the gart since it's contiguous an non-snooped.

Ah, good to know!