All of lore.kernel.org
 help / color / mirror / Atom feed
* understanding virtio-gpu
@ 2021-06-30  9:25 Enrico Weigelt, metux IT consult
  2021-07-21 10:49 ` Gerd Hoffmann
  0 siblings, 1 reply; 2+ messages in thread
From: Enrico Weigelt, metux IT consult @ 2021-06-30  9:25 UTC (permalink / raw)
  To: David Airlie, Gerd Hoffmann, dri-devel

Hello folks,


I'm currently trying to understand how the virtio-gpu driver actually
works and got a few noob questions:

1. virtio_gpu_pci_quirk():

   * what is the explicit framebuffer removal about ?

     Do virtio-gpu devices support several framebuffer types (but only
     one at a time) ? How does it happen that we can have that vga
     framebuffer standing in our way in the first place ?

   * why is it necessary to rename the device with "pci:" prefix ?

     since (IMHO) virtio is an actual bus, that may even exist in HW,
     but there're also several different virtio transports (got word that
     somebody's also working on an socket-based one), it smells very
     strange to me, making it look like a pci device.

     does it only work w/ pci transport ?
     what's the background of this ?

2. features[] array:

   * virgl seems only supported on little endian, and the comment tells
     that's because virgl is sending the command stream in native endian.

   * IMHO, this approach isn't entirely correct, since here we're just
     looking whether the driver/guest side is LE, but looking at the
     host/device side. otoh, it should still work if both sides are BE.

   * shouldn't we add some endianess handshake to the protocol ?
     maybe both should announce what's their native endianess and whether
     they're capable of doing the conversion, so they can aggree on what
     to do exactly ?


I'm currently trying to find ways for using virgl in containers instead
of VMs, so the container workload doesn't need to have any gpu specific
(userland) drivers anymore. Not sure whether I'll need special kernel
support for this at all.


thx,
--mtx

-- 
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@metux.net -- +49-151-27565287

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: understanding virtio-gpu
  2021-06-30  9:25 understanding virtio-gpu Enrico Weigelt, metux IT consult
@ 2021-07-21 10:49 ` Gerd Hoffmann
  0 siblings, 0 replies; 2+ messages in thread
From: Gerd Hoffmann @ 2021-07-21 10:49 UTC (permalink / raw)
  To: Enrico Weigelt, metux IT consult; +Cc: David Airlie, dri-devel

  Hi,

> 1. virtio_gpu_pci_quirk():
> 
>   * what is the explicit framebuffer removal about ?

unregister boot framebuffer (typically efifb or vesafb on x86).

>   * why is it necessary to rename the device with "pci:" prefix ?
> 
>     does it only work w/ pci transport ?
>     what's the background of this ?

IIRC an Xorg hardware probing quirk.

>   * shouldn't we add some endianess handshake to the protocol ?

Doable, but worth the effort?  Which bigendian hardware platform has
hardware-accelerated mesa opengl drivers?  With even ppc moving to le
these days s390x is the only relevant bigendian platform left, and it
isn't exactly famous for their graphics performance ;)

take care,
  Gerd


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2021-07-21 10:49 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-06-30  9:25 understanding virtio-gpu Enrico Weigelt, metux IT consult
2021-07-21 10:49 ` Gerd Hoffmann

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.