On Mi, 2013-12-04 at 17:02 +1000, Dave Airlie wrote:
> So I've hit a bit of a init ordering issue that I'm not sure how best to
> solve,
>
> Just some background:
> In order for the virt GPU and the UI layer (SDL or GTK etc) to
> interact properly over OpenGL use, I have created and OpenGL provider
> in the console, and the UI layer can register callbacks for a single
> GL provider (only one makes sense really) when it starts up. This is
> mainly to be used for context management and swap buffers management.
>
> Now in the virtio GPU I'd was going to use a virtio feature to say
> whether the qemu hw can support the 3D renderer, dependant on whether
> it was linked with the virgl renderer and whether the current UI was
> GL capable.
Hmm, why does it depend on the UI? Wasn't the plan to render into a
dma-buf no matter what? Then either read the rendered result from the
dmabuf (non-gl UI like vnc) or let the (gl-capable) UI pass the dma-buf
to the compositor?
Also note that the virtio-gpu gl-capability needs to be configurable for
live migration reasons, so you can migrate between hosts with different
3d capabilities. Something like -device
virtio-gpu,gl={none,gl2,gl3,host} where "none" turns it off, "gl
$version" specifies the gl support level and "host" makes it depend on
the host capabilities (simliar to -cpu host). For starters you can
leave out "host" and depend on the user set this.
> So is there a method to modify the advertised feature
> bits later in the setup sequence before the guest is started?
You can register a callback to be notified when the guest is
started/stopped (qemu_add_vm_change_state_handler). That could be used
although it is a bit hackish.
cheers,
Gerd
PS: Now that 1.7 is out of the door and 2.0 tree is open for development
we should start getting the bits which are ready merged to make your
patch backlog smaller. SDL2 would be a good start I think.
