Marek Looking To Tackle Large RadeonSI Performance Bottleneck

[bridgman]

Thanks, internal names are a bit confusing, i tought R600 is for chip name, not for Northern Islands chips. My approach was (obviously invalid) that all pre-GCN GPU's use radeon driver, S.Islands use radeonsi, and newer AMDGPU, but looking at x.org website, it seems that all use radeon kernel driver, except V.Islands+. So my bad in naming.

Yep... you are mixing kernel and mesa driver names, which makes it really hard to understand

The mesa drivers are named for the *first* chip they support (since we don't know what the last chip will be when creating a new driver), so...

---

r300 mesa driver supports r3xx, 4xx, 5xx

r600 mesa driver supports r6xx, 7xx, Evergreen, Northern Islands

radeonsi mesa driver supports SI, CI, VI and beyond

----

radeon kernel driver supports everything from r100 through CI

amdgpu kernel driver supports SI, CI, VI and beyond, however SI support is recent and we are still adding chip support, SI and CI upstream default is still radeon.

It's probably easiest to think about amdgpu initially supporting VI and up, then being extended *back* to include SI so that the amdgpu-pro stack can fully replace the previous fglrx/Catalyst Linux stack..

[leipero]

Yep... you are mixing kernel and mesa driver names, which makes it really hard to understand

The mesa drivers are named for the *first* chip they support (since we don't know what the last chip will be when creating a new driver), so...

---

r300 mesa driver supports r3xx, 4xx, 5xx

r600 mesa driver supports r6xx, 7xx, Evergreen, Northern Islands

radeonsi mesa driver supports SI, CI, VI and beyond

----

radeon kernel driver supports everything from r100 through CI

amdgpu kernel driver supports SI, CI, VI and beyond, however SI support is recent and we are still adding chip support, SI and CI upstream default is still radeon.

It's probably easiest to think about amdgpu initially supporting VI and up, then being extended *back* to include SI.

Yeah that makes sense, tought naming could be more fortunate (as it is on kernel), but I'm sure there's a reason why it is named as it is.

[duby229]

Right. Strictly speaking we call it r600g on Phoronix forums to distinguish it from the old non-Gallium3D drivers, but since they no longer exist we should probably just call it r300 to match what we have in the source tree.

leipero, if it helps you can look in the Mesa source tree and see the actual drivers:

https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers

IIRC the r300, r600 and radeonsi folders hold actual drivers; the radeon folder holds common code that is shared between them.

Ok thanks, I'll remember that. I do vaguely recall the old classic driver being called r300c and then when gallium came out it was ported to r300g. I was using a X1950pro at that point in time. Since now the old classic driver no longer exists I think you're right that it doesn't make any sense to distinguish it anymore.

[bridgman]

Yeah that makes sense, tought naming could be more fortunate (as it is on kernel), but I'm sure there's a reason why it is named as it is.

In some ways the mesa driver naming is cleaner than the kernel driver naming; we just have *more* mesa drivers. We couldn't use the mesa "name it for the first chip generation it supports" model when introducing amdgpu because we developed it on CI, planned for VI to be the first "must use amdgpu" generation, and had been planning to extend it back to SI eventually as well. The kernel driver source tree was also getting pretty big so we wanted to introduce some top-level folders, eg include, powerplay, amdgpu, amdkfd etc...

[Tomin]

I think this is a nice tool: https://mesamatrix.net/drivers.php
Works only for AMD cards and not exactly always even then. Polaris is still missing completely.