RadeonSI Gallium3D Re-Enables SDMA For Sea Islands, Carrizo

[PuckPoltergeist]

The DMA engines are optimized for transfers between vram and system memory.

So it's most important for dGPUs. APUs won't have this benefit, cause VRAM and system memory are the same, right?

[haagch]

I don't know if people are interested in that.

I still have a laptop with ivy bridge + HD 7970M that would benefit. Just not really using it anymore, because SI is getting kinda old by now.

It's not a question of people interested, it's a question whether there are enough people with older hardware who would benefit.

[agd5f]

So it's most important for dGPUs. APUs won't have this benefit, cause VRAM and system memory are the same, right?

You can still see a benefit on APUs for a number of reasons:
- lower overhead for the actual transfer
- can be used asynchronously from gfx
- optimized addressing patterns for transfers to/from linear memory layouts

[haagch]

older hardware

I was actually thinking about the original 7xxx series.

But then I remembered that AMD is still selling their first generation GCN with the most current series branding: https://en.wikipedia.org/wiki/List_o...84xx.29_Series

Also, the popular (?) R7 370 is SI too. As is 270 and 280.

So yea, do it.

[dungeon]

He, he, only AMD can do that, most dGPUs are SI actually but it is unsupported by pro driver nearly a year... meanwhile TF2 lockup on open, does not have CL/VK, etc...

Here developers talks about some SDMA benefits on APUs, with seems no way to measure... so i don't know what to think other than start to think that might be nothing but a virus

[bridgman]

He, he, only AMD can do that, most dGPUs are SI actually but it is unsupported by pro driver nearly a year... meanwhile TF2 lockup on open, does not have CL/VK, etc...

To be clear, SI has been unsupported by the amdgpu-pro driver since 2012 since the workstation driver was and still is Catalyst Linux aka fglrx. Remember that essentially all of our workstation customers use slower-changing enterprise distros and so are still running Catalyst Linux.

We are in the process of replacing fglrx with amdgpu-pro, but in the meantime have been providing early releases of amdgpu-pro for consumer users while the open source stack comes up to speed, although the open source stack is pretty much there now other than a lot of remaining work on open sourcing Vulkan & OpenCL.

[dungeon]

Open will be up to speed only if it have threaded GL... to me main speed up feature in 200x decade was HyperZ and for 201x it is threaded GL... but as i like to say princess is in another castle

[marek]

I imagine the TexImage call could defer the transfer and execute it asynchronously as long as the next draw call confirmed that the transfer was complete before executing the draw, but in the case of ReadPixels I believe data needs to be CPU accessable as soon as the call returns.

We don't take advantage of asynchronous execution, since everything is synchronized in GL. The only advantage of SDMA for us is that it can achieve peak PCIe throughput when doing writes/reads to/from linear textures in GART, while the 3D engine is really really bad at that (i.e. slower by an order of magnitude).

[dungeon]

To be clear, SI has been unsupported by the amdgpu-pro driver since 2012 since the workstation driver was and still is Catalyst Linux aka fglrx.

Not anymore that was yesterday, as of today as I see workstation driver is officially amdgpu-pro.

[dungeon]

Remember that essentially all of our workstation customers use slower-changing enterprise distros and so are still running Catalyst Linux.

Well i know those run Cat as what else of course? , but here is your recent SI customer comment I don't think you will miss that but just in case anyway

https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/907369-amdgpu-pro-16-40-released-for-ubuntu-red-hat-linux-systems?p=907465#post907465