As far as I can tell it was changed (perhaps inadvertently) by Mesa commit 0cb42c57c569443b0af8296dfff4da1e6ab241ef. Previously "AMD" string would be present in the renderer string for cases where there was no marketing name (i.e. Etaash's gpu would have a GL_RENDERER value beginning with "AMD RENOIR").
Looks plausible enough; ideally we'd get that fixed.
As far as I can tell, radeonsi has only ever reported a GL_VENDOR of "X.org" or (more recently) "AMD", so we've been relying on "AMD" being present in the renderer string.
It's slightly worse, actually. Cards with a "marketing" name will have a renderer string like "Radeon RX Vega (VEGA10, ...)", so for these we'd depend on the "Radeon"/"FirePro" strings. If the vendor string now includes "AMD" we'd certainly want to use that; in that regard the original commit is fine.
It may also be a good idea to try matching the card vendor based on the PCI vendor first; I imagine that will remain a bit more stable against changes like this.
Yes, I think that would be helpful.
On 9/13/22 07:13, Henri Verbeet (@hverbeet) wrote:
As far as I can tell, radeonsi has only ever reported a GL_VENDOR of "X.org" or (more recently) "AMD", so we've been relying on "AMD" being present in the renderer string.
It's slightly worse, actually. Cards with a "marketing" name will have a renderer string like "Radeon RX Vega (VEGA10, ...)", so for these we'd depend on the "Radeon"/"FirePro" strings. If the vendor string now includes "AMD" we'd certainly want to use that; in that regard the original commit is fine.
Actually I think in general the renderer did (and still does) contain "AMD". E.g. I have a machine whose renderer string is "AMD Radeon RX 560 Series (polaris11, LLVM 14.0.6, DRM 3.46, 5.18.0-4-amd64)".
-
Henri Verbeet (＠hverbeet) -
Zebediah Figura