[virglrenderer-devel] Debian packaging, project status?

[Daniel Pocock]

On 03/03/16 23:11, Dave Airlie wrote:
> On 3 March 2016 at 19:17, Daniel Pocock <daniel at pocock.pro> wrote:
>>
>> A Debian package[1] of virglrenderer is now in progress and there is
>> discussion about enabling it in qemu builds[2].
>>
>> Could anybody make any comment about the status of the project and other
>> things that may need to be packaged to support it?
> 
> You pretty much need this library and qemu linked against it.
> 
> I'd probably say status of project is, initial implementation in
> process of upstreaming.
> 
>> - is there any architecture diagram?  Could somebody add one to the main
>> web site[3]?
> 
> Not really, I'm not a drawer but I could probably try and draw something.

Would it be easier to add it into an existing architecture diagram for
qemu of KVM?

Does it use any functionality of the GPU on the host (or is that the aim
in future) or does it do everything in the host CPU?

>>
>> - is there any quickstart or HOWTO guide for people who want to try it?
> 
> Nope. the idea is to get the pieces upstream first and then have it just work.
> 
>> - which client software needs to be used to access a VM using Virgil 3D?
> 
> Again project is currently on its way upstream, making definitive comments is
> hard as they go out of date too quick. So the answer to this question is it
> dependson what version of what stuff you have. qemu 2.5 only works with local
> VMs using GTK+. qemu 2.6 is hoped with the correct spice pieces in place to work
> wih spice. There are of course libvirt pices to put in the place as
> well and then
> boxes for GNOME will need work. This stuff is all mostly in progress
> upstreaming,
> and awaiting releases of various components in the virt stack, like spice*.
> 
>>
>> - the web page mentions specific kernel versions, are these only
>> required for the guest OS or also for the host OS?
> 
> The guest OS requires 4.4, the host OS really needs dma-buf but otherwise
> should work with modern mesa based GL drivers.
> 
>>
>> - what is the current status of support for non-Linux guests, e.g.
>> Windows in a VM?  I saw Direct3D mentioned as a future possibility, has
>> anybody expressed interest in doing that work though or could the
>> Windows driver from another virtualization platform be used?
> 
> Nothing is known on this. No other driver can be used. Red Hat has an
> interest in doing that work at some point but there is no timeline, and no
> real work been done, so if anyone wanted to learn about writing WDDM
> drivers here's a good time to learn!.
> 

Have you thought about advertising that for a GSoC student project?
Student application deadline is 25 March, so now would be the time to
advertise it.  It could potentially go under any of these communities:

http://qemu-project.org/Google_Summer_of_Code_2016
http://wiki.libvirt.org/page/Google_Summer_of_Code_2016
https://fedoraproject.org/wiki/Summer_coding_ideas_for_2016

As there is no existing code and nobody else working on that, does that
mean a student could work somewhat independently without bumping into
anyone?

Is there any remotely relevant driver code from any similar project that
could be used as a model?

>> - are there any specific applications or games you are aiming to support
>> with it or testing it with on a regular basis?
> 
> gnome-shell is the only thing I have to care about from a Red Hat perspective,
> we've been testing various games and using piglit on it. Most things
> run, but it's
> exactly blisteringly fast yet, we've left a fair bit of performance
> work for after the
> initial implementation is upstream.
> 

In the discussions about GPU passthrough I've noticed a lot of people
mention gaming and two other things that come up from time to time are
AutoCAD and virtualizing OS X.

I wonder if Red Hat is tempted to see a business application like
AutoCAD running this way on a Red Hat desktop with Windows as a VM?

I suspect OS X is going to want to see something that looks like real
Apple-approved hardware though.  Emulating a specific model of
proprietary GPU and related hardware APIs would be beyond the scope of
what you are currently aiming for?

Have you also seen the KVMGT project, how do your aims compare to that?
https://events.linuxfoundation.org/sites/events/files/slides/KVMGT-a%20Full%20GPU%20Virtualization%20Solution_1.pdf

They only support Intel Haswell right now.

Regards,

Daniel