AMD Graphics card ID
12 Oct 2019 16:20:30 UTC
Topic 219765
(moderation:
Yesterday, after an update, my LINUX box crashed taking about 200 tasks to a watery grave. After several attempts at recovery, I abandoned the LINUX partition and restarted the box under Windows 7. What I found odd is, under Windows, my graphics card identifies as an RX560 where, under LINUX, it identified as an RX460. GPU-Z also identifies the card as an RX560, Arctic Islands, and Polaris 10, (going from memory). I'll need to verify that. The box says it is a RX-560D4S 4GB GDDR5.
I wonder if I had the wrong LINUX driver?
Clear skies,
Matt
Make that a Polaris 21.
)
Make that a Polaris 21.
Matt White wrote:Yesterday,
)
What command or program did you use to query the name? I have a Linux host running both a RX460 and a RX560. I'm curious to know what names that command comes up with for me.
Ideas are not fixed, nor should they be; we live in model-dependent reality.
cecht wrote:What command or
)
BOINC/E@H identified the card as an RX460 when I was running LINUX. Using the exact same hardware under Windows 7, BOINC identifies the GPU as an RX560. The card is, in fact, an RX560 according to the box.
That's why I was questioning if I had inadvertently loaded the wrong driver.
BOINC identifies the card
)
BOINC identifies the card type and name from the exported names provided by the card API. AMD's API in your case. If the API does not correctly identify the card, BOINC only can report what the API tells it. As far as I can tell, the AMD API is different among each of the AMD driver installations. AMDGPU and AMDGPU-PRO and RoCM all have different API's.
[Edit] From gpu_opencl.cpp
// get vendor string from renderer
// For some GPUs, one API returns "ATI" but the other API returns
// "AMD" in the model name, so we normalize both to "AMD"
// Could not get model name from IOKit, so use renderer name
You have RX 560D which is a
)
You have RX 560D which is a re-brand of RX 460.
https://www.techpowerup.com/forums/threads/amd-officially-but-silently-downgrades-radeon-rx-560-with-an-896-sp-variant.239421/
shuhui1990 wrote:You have RX
)
Right you are! Good catch.
Ideas are not fixed, nor should they be; we live in model-dependent reality.
That would explain a great
)
That would explain a great many things. The card wasn't terribly expensive so as the old saying goes; "You get what you pay for."
Matt White wrote:That would
)
I hear ya, although the RX460 OEM I first bought for a good price turned out to be a RX 460 1024SP, which has an OEM BIOS upgrade that unlocks all 1024 cores making it run as a RX 560. The RX 560 that I subsequently bought, however, thinking it would give equivalent performance, turned out to be, as suihui1990 said, a RX 560D, which has only the RX 460's 896 active cores. So yeah, my "RX 460" is faster than my "RX 560".
It became confusing when I was trying to tune parameters of those cards with amdgpu-utils on my Linux system because both cards were identified as "RX 460". The package amdgpu-utils uses a pci.ids file, sourced from https://pci-ids.ucw.cz/, to extract and report a short name of AMD GPUs. So I submitted to the pci-ids database the specific ID codes for the RX 560D so that it would be called what it is. The name, RX 560D OEM OC 2 GB, is longer than the one I submitted, but the database moderator went with the more descriptive name used by TechPowerUp GPU DB.
I suppose if I were adventurous I would flash the RX 560D's BIOS to unlock all its cores. Hmmm ...
Ideas are not fixed, nor should they be; we live in model-dependent reality.
cecht wrote:I suppose if I
)
I would be careful about doing that unless I really knew what I was doing. If one was privy to inside information and code, it might be worth a shot. Other than that, one runs the risk of "bricking" the card.
I have to wonder if the methodology behind this is similar to what some companies do in the 2-way radio world? (Motorola, IFR) A unit is manufactured to be hardware compatible with all the features and options, and a piece of code called a flash-code determines the feature set. This reduces the number of assembly lines needed for a particular product families. IFR does the same thing with the service monitors. The only difference between a $20K box and a $50K box is the flash-code.