-
Notifications
You must be signed in to change notification settings - Fork 63
Open
Description
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.sobecause Xorg fails to initializeDRI2. - 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 swrastProposal
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