AMD graphics

AMD GC 12.0 IP-discovery graphics context

A source-backed graphics-block context for modern amdgpu reports; no exact Radeon product is inferred.

On this page
  1. Overview & identity
  2. Driver & binding
  3. Firmware
  4. Read-only diagnostics
  5. Limitations & related issues
  6. References

Overview & identity

This is a context profile without a curated PCI product ID. The snapshot has AMD display-class fallback entries marked CHIP_IP_DISCOVERY, and the discovery implementation selects gfx_v12_0 for GC IP versions 12.0.0 and 12.0.1. An amdgpu module or AMD display class alone does not prove GC 12.0; the device initialization report must actually identify the IP block.

This is an explicit class, transport or driver-context profile. It is not an exact numeric product match.

A numeric match establishes a candidate family within the reviewed evidence. Marketing names, board variants, subsystem conditions and successful operation remain separate questions.

Driver & binding

The PCI fallback and graphics-IP selection are different stages. This explains why a new AMD GPU can lack a literal per-product row in the older-style PCI table while still entering discovery code. A table fallback is not a promise that discovery, firmware or every engine succeeds for an arbitrary device.

  • amdgpu — kernel driver/module candidate

Detected, bound, operational: learn the difference

Firmware

Device/revision dependent

Both filenames are explicitly declared by gfx_v12_0.c. They illustrate separate 12.0.0 and 12.0.1 paths, not files required together by every GPU. The actual IP version and exact kernel request select the relevant image; other engines also have independent firmware requirements.

Checked examples or filename branches, not a complete installation list:

  • amdgpu/gc_12_0_0_pfp.bin
  • amdgpu/gc_12_0_1_rlc_kicker.bin

Inspect firmware packaging on your distribution

Read-only diagnostics

Run one displayed command at a time. Replace uppercase placeholders with the affected device, interface or module from your own output. Commands are never executed here. Read-only output can still contain private identifiers.

Read the numeric PCI identity and binding

lspci -nnk -s BDF

Replace BDF with the address of the AMD IP-discovery display function. No sudo is normally required for this summary. The numeric vendor/device pair is the evidence for identity; “Kernel driver in use” is evidence of the current binding. A “Kernel modules” list is only a list of candidates.

Confirm the owner of this PCI function

readlink /sys/bus/pci/devices/BDF/driver

Use the full domain:bus:slot.function address in BDF, for example the form shown by lspci -D. This read-only symlink normally needs no elevated privileges. Its last component names the bound driver. An absent link can also mean an unbound, removed or guest-assigned function; it does not prove that no Linux driver exists.

Read initialization and failure context

journalctl -k -b --no-pager

Look for the discovery-reported GC IP version before using a gc_12_0_* firmware name. A PCI ID label from a name database is not equivalent to that report. This reads the current boot only. Correlate the PCI address and timestamps before connecting a message to this GPU. Journal access depends on local group permissions; a permission error is not a hardware result.

Limitations & related issues

Do not translate a GC version into an exact RX model, board design or stability claim. This page does not classify an unrecognized AMD PCI pair as supported. A crash without a final kernel log entry remains unresolved; firmware declarations do not reproduce a reported hard-lock.

These guides are linked for relevant observations, not as known defects of every device in this family.

Choose a hardware diagnostic workflow · Inspect a log excerpt in Fix Lab

References

Source review records a checked implementation or document, not a reproduced hardware test. Version-specific tables do not establish a minimum kernel or guaranteed operation.