virtio_gpu: add support for xf86-video-scfb

[tiga]

Summary

virtio_gpu: add support for xf86-video-scfb

Added virtio_gpu support for UTM/MacOS configured with virtio-gpu-pci.
Tunable parameters:

• hw.virtio_gpu.width
• hw.virtio_gpu.height
• hw.virtio_gpu.flush_enabled (default is disabled)

Dynamic sysctl parameters:

• dev.vtgpu.X.flush_enabled (read-only)
• dev.vtgpu.X.refresh_rate

To enable, the following line needs to be written to /boot/loader.conf:

hw.virtio_gpu.flush_enabled=1

Tested with FreeBSD 15 (arm64) running on MacOS 26.2 and UTM (version 4.7.5 / qemu 10.0.2).

[lwhsu]

ref: https://bugs.freebsd.org/292982

[imp]

So I don't understand the underlying code well enough to have a good take on this... It seems like this is always active, but maybe shouldn't be.
It would be helpful, though, if you could upload the next set of diffs created with -U9999 so that we get enough context in phabricator. It made it hard to check on stuff

sys/dev/virtio/gpu/virtio_gpu.c

374

why is this. unconditional?

405

this seems backwards.

423

Do we always need this periodic flush, or just when this feature is active?

473

when would this get called before initialized is true?

[tiga]

sys/dev/virtio/gpu/virtio_gpu.c

374

I am guessing that VirtIO GPU always allocates the framebuffer in system RAM rather than mapping actual GPU VRAM, so I decided to use VM_MEMATTR_DEFAULT. I am not sure 100% about this, though, but it seemed right...

405

yes, i agree looks very strange. when running my tests, it turns out that after registering with fbd_register, the device /dev/fb0 appears, and the result if EEXIST. not really sure why...
I propose to change the code to the following (tested and seems working):

} else {
    device_printf(dev, "/dev/fb0 created\n");
    sc->vtgpu_fb_registered = true;
}

423

You are right - this periodic flush should only be done when sc->vtgpu_fb_registered is true
I will change the code to reflect this, and test it again

473

i tried to do some defensive programming here, you are right, when this function is called, the vtgpu_initialized should always be true. this check can be reduced to

if (!sc->vtgpu_detaching)

i will change accordingly and test

[tiga]

Updated code according to review comments:

• removed vtgpu_initialized flag
• flush task only started when /dev/fd0 is available
• improved logic for device_printf when attached
• removed unnecessary if conditions

[tiga]

Sorry, new here... still learning
This patch has -U9999, as requested

[andrew]

What is the overhead form all the extra wakeups this adds? I'd prefer we add a way for userspace to tell the kernel to perform an update.

[tiga]

In D55012#1261935, @andrew wrote:

What is the overhead form all the extra wakeups this adds? I'd prefer we add a way for userspace to tell the kernel to perform an update.

Hi. In my computer, the overhead is not really noticeable - and if this is a problem, it can be controlled with the "refresh_rate" setting...
This is for sure not a "good" solution, but it is kind of working...
I see this as temporary until we can have a solution that e.g. properly implements 3D / hardware acceleration - unfortunately I do not know how to do this.
In any case, this is my first patch - I am open to suggestions, in case someone knows a better way to implement this :-)

[tiga]

Hi. Sorry for not being too active on this - just wanted to give a heads-up that I am looking at disabling the functionality by default as asked by @imp; currently I am "under water" with lots of things to do at work and with family, and therefore having difficulties to find time to look at this; however this is not forgotten, and I will come back asap. Thanks!

[tiga]

Finally I found some time to look again into this...

and... I have made some changes according to the review comments.
Now the framebuffer is deactivated per default.
To enable the functionality, a tunable parameter must be set in /boot/loader.conf

[tiga]

Improvement: only start the refresh once the memory is mmap'ed first; so, if we boot the system only to console and dont start X, the refresh does not kick in.
Also, added shutdown pre sync defensively, as this is also done similarly in other drivers.

[tiga]

Rebase to current main (16.0-CURRENT) and retested

[denis.borovikov_gmail.com]

Hi,

I just submitted a DRM/KMS port of the linux virtio-gpu driver (2D) to
drm-kmod: https://github.com/freebsd/drm-kmod/pull/499. sway works with
the pixman renderer under UTM/QEMU on 15.1 aarch64. Looks complementary
to this patch (console and X via scfb here, KMS/wayland there), happy
to coordinate.

Re the extra wakeups discussion - the drm path ends up being what
andrew suggested: updates are driven from userspace, the compositor
sends explicit damage and the driver only transfers what changed, so
there is no periodic flush. Doesn't help the scfb case of course, but
wayland users won't need the refresh timer once drm-kmod has the
driver.

Denis

[tiga]

In D55012#1357788, @denis.borovikov_gmail.com wrote:

Hi,

I just submitted a DRM/KMS port of the linux virtio-gpu driver (2D) to
drm-kmod: https://github.com/freebsd/drm-kmod/pull/499. sway works with
the pixman renderer under UTM/QEMU on 15.1 aarch64. Looks complementary
to this patch (console and X via scfb here, KMS/wayland there), happy
to coordinate.

Re the extra wakeups discussion - the drm path ends up being what
andrew suggested: updates are driven from userspace, the compositor
sends explicit damage and the driver only transfers what changed, so
there is no periodic flush. Doesn't help the scfb case of course, but
wayland users won't need the refresh timer once drm-kmod has the
driver.

Denis

Hi Denis,
thanks for pointing it out to me. I will check it and come back ASAP.
Sorry for the delay in the reply - was on vacation and only recently started "coming back to life" again :-)
Best,
Tiago