Overview & identity
The checked modern PCI rule maps 1af4:1050 to virtio type 16 (gpu). This is a virtual function identity, not the host hardware model. Transitional PCI IDs use a different subsystem-ID rule and are deliberately not inferred here.
- Curated identifiers
pci 1af4:1050
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
virtio_gpu matches type 16 on the virtio bus. Host renderer, negotiated graphics features and guest Mesa stack determine the graphics path; the PCI identity alone cannot establish hardware acceleration. lspci can therefore correctly report virtio-pci while the child function is bound to virtio_gpu.
virtio_pci— kernel driver/module candidatevirtio_gpu— kernel driver/module candidate
Firmware
No host payload established here
No external firmware filename was established in the checked driver path. This does not describe firmware stored inside the device.
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.
Inspect the PCI function and binding
lspci -nnk -s BDFReplace BDF with the complete address, for example 0000:00:14.0. This read-only query needs pciutils and normally no sudo. “Kernel driver in use” is observed binding; “Kernel modules” lists candidates.
Inspect the virtio child function driver
ls -l /sys/bus/pci/devices/BDF/virtio*/driverReplace BDF with the full observed PCI address. Read the child driver link without sudo; virtio_pci is the PCI transport, while this link belongs to the function driver. A missing child or link means that this layer was not observed.
Inspect guest DRM device links
ls -l /sys/class/drm/Read DRM class metadata without sudo and without changing display modes. Associate card and render nodes with the virtio parent; their presence does not demonstrate accelerated rendering.
Limitations & related issues
A DRM node is not proof of Vulkan support, usable 3D rendering or a particular host GPU. Plain display operation and a host-assisted rendering path are separate capabilities requiring runtime evidence.
These guides are linked for relevant observations, not as known defects of every device in this family.
- Mesa falls back to CPU rendering · First documented next step
- Vulkan loader finds no usable driver · First documented next step
- Xorg exits with no screens found · First documented next step
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.
- Linux: drivers/virtio/virtio_pci_common.c
Reviewed upstream source
virtio_pci_id_table[] - Linux: drivers/virtio/virtio_pci_modern_dev.c
Reviewed upstream source
mdev->id.device = pci_dev->device - 0x1040; - Linux: include/uapi/linux/virtio_ids.h
Reviewed upstream source
#define VIRTIO_ID_GPU - Linux: drivers/gpu/drm/virtio/virtgpu_drv.c
Reviewed upstream source
{ VIRTIO_ID_GPU, - Linux: Documentation/driver-api/virtio/virtio.rst
Project or distribution documentation
Device discovery and probing