Skip to content

Implement VirtIO PCI transport layer #85

Description

@shengwen-tw

Background

During the development of VirtIO GPU in #34, a critical issue was identified: applications leveraging Mesa3D (e.g., glxgears, kmscube) consistently fall back to software rendering (softpipe), despite a correct configuration of X11, Mesa3D, and a host virglrenderer.

Analysis suggests this behavior is likely due to the current implementation of VirtIO GPU being based on VirtIO MMIO (registered as a platform device via the device tree), rather than utilizing the VirtIO PCI transport layer. Key observations include:

  • GLX/X11 path: Mesa3D does not load virtio_gpu_dri.so because Xorg fails to initialize DRI2.
  • Xorg logs: The GPU is not recognized as a PCI device (no primary bus or device found), which prevents DRI2 from initializing and causes a fallback to the software renderer (swrast).
[    29.010] (II) Platform probe for /sys/devices/platform/soc@F0000000/f4800000.virtio/drm/card0                                                 
[    29.018] (II) no primary bus or device found                                                                                                  
[    29.018]    falling back to /sys/devices/platform/soc@F0000000/f4800000.virtio/drm/card0
...
[    29.354] (II) modeset(0): using drv /dev/dri/card0                                                                      
...
[    29.666] (II) AIGLX: Screen 0 is not DRI2 capable
[    31.222] (II) IGLX: Loaded and initialized swrast

Proposal

To resolve this limitation and enable proper VirGL hardware acceleration, I propose implementing a VirtIO PCI transport layer for VirtIO GPU.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Fields

No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions