From: Dave Airlie <airlied@gmail.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: qemu-devel@nongnu.org, Juan Quintela <quintela@redhat.com>
Subject: Re: [Qemu-devel] Re: approaches to 3D virtualisation
Date: Sun, 13 Dec 2009 11:46:02 +1000 [thread overview]
Message-ID: <21d7e9970912121746r23ba1f52u7661ad88a1dd757a@mail.gmail.com> (raw)
In-Reply-To: <4B23B589.7030402@codemonkey.ws>
On Sun, Dec 13, 2009 at 1:23 AM, Anthony Liguori <anthony@codemonkey.ws> wrote:
> Juan Quintela wrote:
>>
>> Dave Airlie <airlied@gmail.com> wrote:
>>
>>>>>
>>>>> Current existing solutions in the area:
>>>>> a) VMware virtual graphics adapter - based on DX9, has an open
>>>>> KMS/Gallium3D driver stack recently released by vmware, has certified
>>>>> Windows drivers and has a documented vGPU interface (it could be
>>>>> documented a lot better)
>>>>>
>>>
>>>
>>> http://vmware-svga.svn.sourceforge.net/viewvc/vmware-svga/trunk/doc/gpu-wiov.pdf?revision=1
>>>
>>> is a good whitepaper on the different 3D virtualisation approaches and
>>> why
>>> vmware picked what they did also.
>>>
>>> Dave.
>>>
>>
>> I have zero clue of 3D, but for the qemu part, vmware_vga is the "nicer"
>> driver.
>>
>
> I like the design of the vmware_vga driver but it has one critical flaw.
> The Windows drivers has a EULA that prohibits their use outside of VMware.
Good point, I hadn't read the vmware EULA, this does put a spanner in the works,
unless someone is willing to write alternate drivers.
My reason for liking vmware is its not a redesign it all at once
solution, you can bring
up the emulated adapter using known working drivers (the Linux ones
have no EULA),
and confirm it works, if you then want to write Windows drivers
outside the EULA, at
least you have two platforms to validate them on, Someone could in theory write
Windows drivers under VMware itself and we could work in parallel
>
> Without reasonably licensed Windows drivers, I don't think it's viable.
>
> I'm hoping QXL can fill this niche.
It would be nice, its just the design everything at once approach
never sits well
with me, having to do the host side interface, guest vGPU and guest drivers
all at once requires a lot of blame hunting, i.e. where correct fixes go etc.
But yes ideally an open QXL that can challenge VMware would be coolest
Maybe the QXL interface can leverage some of the VMware design at least
rather than reinventing the wheel
Dave.
next prev parent reply other threads:[~2009-12-13 1:46 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-12 1:58 [Qemu-devel] approaches to 3D virtualisation Dave Airlie
2009-12-12 2:00 ` [Qemu-devel] " Dave Airlie
2009-12-12 9:32 ` Dave Airlie
2009-12-12 12:08 ` Juan Quintela
2009-12-12 15:23 ` Anthony Liguori
2009-12-13 1:46 ` Dave Airlie [this message]
2009-12-12 15:30 ` Carl-Daniel Hailfinger
2009-12-13 2:13 ` [Qemu-devel] " Mark Williamson
2009-12-14 14:50 ` Stefano Stabellini
2009-12-14 12:03 ` Paul Brook
2009-12-15 13:19 ` Avi Kivity
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=21d7e9970912121746r23ba1f52u7661ad88a1dd757a@mail.gmail.com \
--to=airlied@gmail.com \
--cc=anthony@codemonkey.ws \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).