On 11/12/2010 06:14 AM, Ian Molton wrote:
On 10/11/10 17:47, Anthony Liguori wrote:
On 11/10/2010 11:22 AM, Ian Molton wrote:
Ping ?
I think the best way forward is to post patches.
I posted links to the git trees. I can post patches, but they are
*large*. Do you really want me to post the
On 10/11/10 17:47, Anthony Liguori wrote:
On 11/10/2010 11:22 AM, Ian Molton wrote:
Ping ?
I think the best way forward is to post patches.
I posted links to the git trees. I can post patches, but they are
*large*. Do you really want me to post them?
To summarize what I was trying to exp
On 11/10/2010 11:22 AM, Ian Molton wrote:
Ping ?
I think the best way forward is to post patches.
To summarize what I was trying to express in the thread, I think this is
not the right long term architecture but am not opposed to it as a short
term solution. I think having a new virtio devi
Ping ?
On 05/11/10 18:05, Ian Molton wrote:
On 03/11/10 18:17, Anthony Liguori wrote:
On 11/03/2010 01:03 PM, Ian Molton wrote:
Why is it better than using virtio-serial?
For one thing, it enforces the PID in kernel so the guests processes
cant screw each other over by forging the PID pass
On 03/11/10 18:17, Anthony Liguori wrote:
On 11/03/2010 01:03 PM, Ian Molton wrote:
Why is it better than using virtio-serial?
For one thing, it enforces the PID in kernel so the guests processes
cant screw each other over by forging the PID passed to qemu.
My current patch touches a tin
On 04/11/10 09:13, Alon Levy wrote:
On Wed, Nov 03, 2010 at 06:03:50PM +, Ian Molton wrote:
On 01/11/10 13:28, Anthony Liguori wrote:
On 11/01/2010 06:53 AM, Alon Levy wrote:
While we (speaking as part of the SPICE developers) want to have the same
support in our virtual GPU for 3d as we
On Wed, Nov 03, 2010 at 06:03:50PM +, Ian Molton wrote:
> On 01/11/10 13:28, Anthony Liguori wrote:
> >On 11/01/2010 06:53 AM, Alon Levy wrote:
>
> >>While we (speaking as part of the SPICE developers) want to have the same
> >>support in our virtual GPU for 3d as we have for 2d, we just don't
On 11/03/2010 01:03 PM, Ian Molton wrote:
The virtio driver enfoces the PID field and understands the packet
format used. Its better than using serial. Its also just one driver -
which doesnt have any special interdependencies and can be extended or
got rid of in future if and when better thi
On 01/11/10 13:28, Anthony Liguori wrote:
On 11/01/2010 06:53 AM, Alon Levy wrote:
While we (speaking as part of the SPICE developers) want to have the same
support in our virtual GPU for 3d as we have for 2d, we just don't at
this point of time.
Would it be helpful to you to have /something
On 29/10/10 12:18, Rusty Russell wrote:
On Wed, 27 Oct 2010 11:30:31 pm Ian Molton wrote:
On 19/10/10 11:39, Avi Kivity wrote:
On 10/19/2010 12:31 PM, Ian Molton wrote:
2. should start with a patch to the virtio-pci spec to document what
you're doing
Where can I find that spec?
http://oz
On 01/11/10 15:57, Anthony Liguori wrote:
It very much is. It supports fully visually integrated rendering (no
overlay windows) and even compositing GL window managers work fine,
even if running 3D apps under them.
Does the kernel track userspace pid and pass that information to qemu?
Yes. A
On 11/01/2010 10:49 AM, Ian Molton wrote:
On 01/11/10 13:21, Anthony Liguori wrote:
On 11/01/2010 05:42 AM, Avi Kivity wrote:
On 10/28/2010 03:52 PM, Ian Molton wrote:
On 28/10/10 15:24, Avi Kivity wrote:
Waiting for a response is fine, but can't the guest issue a second
batch while waiting
On 01/11/10 10:42, Avi Kivity wrote:
No, not really. the guest may call for the scene to be rendered at
any time and we have to wait for that to happen before we can
return the data to it.
Waiting for a response is fine, but can't the guest issue a second
batch while waiting for the first?
No
On 01/11/10 13:21, Anthony Liguori wrote:
On 11/01/2010 05:42 AM, Avi Kivity wrote:
On 10/28/2010 03:52 PM, Ian Molton wrote:
On 28/10/10 15:24, Avi Kivity wrote:
Waiting for a response is fine, but can't the guest issue a second
batch while waiting for the first?
The other scenario would
On 11/01/2010 06:53 AM, Alon Levy wrote:
The alternative proposal is Spice which so far noone has mentioned.
Right now, Spice seems to be taking the right approach to guest 3d
support.
While we (speaking as part of the SPICE developers) want to have the same
support in our virtual GPU for
On 11/01/2010 05:42 AM, Avi Kivity wrote:
On 10/28/2010 03:52 PM, Ian Molton wrote:
On 28/10/10 15:24, Avi Kivity wrote:
The caller is intended to block as the host must perform GL rendering
before allowing the guests process to continue.
Why is that? Can't we pipeline the process?
No, no
- "Anthony Liguori" wrote:
> On 10/29/2010 06:18 AM, Rusty Russell wrote:
> >> Fixed - updated patch tested and attached.
> >>
> > OK. FWIW, I think this is an awesome idea.
>
> Paravirtual OpenGL or the actual proposed implementation? Have you
> looked at the actual code?
>
> If I
On 10/28/2010 03:52 PM, Ian Molton wrote:
On 28/10/10 15:24, Avi Kivity wrote:
The caller is intended to block as the host must perform GL rendering
before allowing the guests process to continue.
Why is that? Can't we pipeline the process?
No, not really. the guest may call for the scene
On 10/29/2010 06:18 AM, Rusty Russell wrote:
Fixed - updated patch tested and attached.
OK. FWIW, I think this is an awesome idea.
Paravirtual OpenGL or the actual proposed implementation? Have you
looked at the actual code?
If I understand correctly, the implementation is an RPC of
On Friday 29 October 2010 07:18:00 Rusty Russell wrote:
> On Wed, 27 Oct 2010 11:30:31 pm Ian Molton wrote:
> > On 19/10/10 11:39, Avi Kivity wrote:
> > > On 10/19/2010 12:31 PM, Ian Molton wrote:
> >
> > >>> 2. should start with a patch to the virtio-pci spec to document what
> > >>> you're doing
On Wed, 27 Oct 2010 11:30:31 pm Ian Molton wrote:
> On 19/10/10 11:39, Avi Kivity wrote:
> > On 10/19/2010 12:31 PM, Ian Molton wrote:
>
> >>> 2. should start with a patch to the virtio-pci spec to document what
> >>> you're doing
> >>
> >> Where can I find that spec?
> >
> > http://ozlabs.org/~ru
On 28/10/10 21:14, Anthony Liguori wrote:
If this code was invasive to qemus core, I'd say 'no way' but its just
not. and as the GL device is versioned, we can keep using it even if
the passthrough is replaced by a virtual GPU.
The virtio-gl implementation is basically duplicating virtio-seria
On 10/28/2010 02:50 PM, Ian Molton wrote:
On 28/10/10 15:43, Anthony Liguori wrote:
On 10/28/2010 09:24 AM, Avi Kivity wrote:
On 10/28/2010 01:54 PM, Ian Molton wrote:
True, but then all that would prove is that I can write a spec to
match the code.
It would also allow us to check that the
On 28/10/10 15:43, Anthony Liguori wrote:
On 10/28/2010 09:24 AM, Avi Kivity wrote:
On 10/28/2010 01:54 PM, Ian Molton wrote:
True, but then all that would prove is that I can write a spec to
match the code.
It would also allow us to check that the spec matches the
requirements. Those two s
On 28/10/10 15:24, Avi Kivity wrote:
The caller is intended to block as the host must perform GL rendering
before allowing the guests process to continue.
Why is that? Can't we pipeline the process?
No, not really. the guest may call for the scene to be rendered at any
time and we have to w
On 10/28/2010 09:24 AM, Avi Kivity wrote:
On 10/28/2010 01:54 PM, Ian Molton wrote:
Well, I like to review an implementation against a spec.
True, but then all that would prove is that I can write a spec to
match the code.
It would also allow us to check that the spec matches the
require
On 10/28/2010 01:54 PM, Ian Molton wrote:
Well, I like to review an implementation against a spec.
True, but then all that would prove is that I can write a spec to
match the code.
It would also allow us to check that the spec matches the requirements.
Those two steps are easier than che
On 28/10/10 10:27, Avi Kivity wrote:
On 10/27/2010 03:00 PM, Ian Molton wrote:
On 19/10/10 11:39, Avi Kivity wrote:
On 10/19/2010 12:31 PM, Ian Molton wrote:
2. should start with a patch to the virtio-pci spec to document what
you're doing
Where can I find that spec?
http://ozlabs.org/~r
On 10/27/2010 03:00 PM, Ian Molton wrote:
On 19/10/10 11:39, Avi Kivity wrote:
On 10/19/2010 12:31 PM, Ian Molton wrote:
2. should start with a patch to the virtio-pci spec to document what
you're doing
Where can I find that spec?
http://ozlabs.org/~rusty/virtio-spec/
Ok, but I'm not p
On 19/10/10 11:39, Avi Kivity wrote:
On 10/19/2010 12:31 PM, Ian Molton wrote:
2. should start with a patch to the virtio-pci spec to document what
you're doing
Where can I find that spec?
http://ozlabs.org/~rusty/virtio-spec/
Ok, but I'm not patching that until theres been some review.
On 10/19/2010 12:31 PM, Ian Molton wrote:
an virtualization@, many virtio developers live there.
you mean virtualizat...@lists.osdl.org ?
Yes.
2. should start with a patch to the virtio-pci spec to document what
you're doing
Where can I find that spec?
http://ozlabs.org/~rusty/virt
On 10/10/10 16:11, Avi Kivity wrote:
On 10/06/2010 05:59 PM, Ian Molton wrote:
This patch implements a virtio-based transport for use by a
virtualised OpenGL passthrough implementation.
The libGL and qemu-gl code to support this patch are available here:
http://gitorious.org/vm-gl-accel/qemu-g
32 matches
Mail list logo
