Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1282744 > unrolled thread

RE: [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel

Started by"Tian, Kevin" <kevin.tian@intel.com>
First post2015-12-03 08:00 +0100
Last post2015-12-04 11:20 +0100
Articles 2 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  RE: [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a  Mediated Graphics Passthrough Solution from Intel "Tian, Kevin" <kevin.tian@intel.com> - 2015-12-03 08:00 +0100
    Re: [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a  Mediated Graphics Passthrough Solution from Intel Gerd Hoffmann <kraxel@redhat.com> - 2015-12-04 11:20 +0100

#1282744 — RE: [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel

From"Tian, Kevin" <kevin.tian@intel.com>
Date2015-12-03 08:00 +0100
SubjectRE: [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel
Message-ID<qBw1Y-1pQ-9@gated-at.bofh.it>
PiBGcm9tOiBUaWFuLCBLZXZpbg0KPiBTZW50OiBGcmlkYXksIE5vdmVtYmVyIDIwLCAyMDE1IDQ6
MzYgUE0NCj4gDQo+ID4NCj4gPiA+ID4gU28sIGZvciBub24tb3BlbmdsIHJlbmRlcmluZyBxZW11
IG5lZWRzIHRoZSBndWVzdCBmcmFtZWJ1ZmZlciBkYXRhIHNvIGl0DQo+ID4gPiA+IGNhbiBmZWVk
IGl0IGludG8gdGhlIHZuYyBzZXJ2ZXIuICBUaGUgdmZpbyBmcmFtZWJ1ZmZlciByZWdpb24gaXMg
bWVhbnQNCj4gPiA+ID4gdG8gc3VwcG9ydCB0aGlzIHVzZSBjYXNlLg0KPiA+ID4NCj4gPiA+IHdo
YXQncyB0aGUgZm9ybWF0IHJlcXVpcmVtZW50IG9uIHRoYXQgZnJhbWVidWZmZXI/IElmIHlvdSBh
cmUgZmFtaWxpYXINCj4gPiA+IHdpdGggSW50ZWwgR3JhcGhpY3MsIHRoZXJlJ3MgYSBzby1jYWxs
ZWQgdGlsaW5nIGZlYXR1cmUgYXBwbGllZCBvbiBmcmFtZQ0KPiA+ID4gYnVmZmVyIHNvIGl0IGNh
bid0IGJlIHVzZWQgYXMgYSByYXcgaW5wdXQgdG8gdm5jIHNlcnZlci4gdy9vIG9wZW5nbCB5b3UN
Cj4gPiA+IG5lZWQgZG8gc29tZSBjb252ZXJzaW9uIG9uIENQVSBmaXJzdC4NCj4gPg0KPiA+IFll
cywgdGhhdCBjb252ZXJzaW9uIG5lZWRzIHRvIGhhcHBlbiwgcWVtdSBjYW4ndCBkZWFsIHdpdGgg
dGlsZWQNCj4gPiBncmFwaGljcy4gIEFueXRoaW5nIHdoaWNoIHBpeG1hbiBjYW4gaGFuZGxlIHdp
bGwgd29yay4gIFByZWZlcmVkIHdvdWxkDQo+ID4gYmUgUElYTUFOX3g4cjhnOGI4IChha2EgRFJN
X0ZPUk1BVF9YUkdCODg4OCBvbiBsaXR0bGUgZW5kaWFuIGhvc3QpIHdoaWNoDQo+ID4gaXMgdGhl
IGZvcm1hdCB1c2VkIGJ5IHRoZSB2bmMgc2VydmVyIChhbmQgb3RoZXIgcGxhY2VzIGluIHFlbXUp
DQo+ID4gaW50ZXJuYWxseS4NCg0KTm93IHRoZSBmb3JtYXQgaXMgcmVwb3J0ZWQgYmFzZWQgb24g
Z3Vlc3Qgc2V0dGluZy4gU29tZSBhZ2VudCBuZWVkcyB0bw0KZG8gZm9ybWF0IGNvbnZlcnNpb24g
aW4gdXNlciBzcGFjZS4NCg0KPiA+DQo+ID4gcWVtdSBjYW4gYWxzbyB1c2UgdGhlIG9wZW5nbCB0
ZXh0dXJlIGZvciB0aGUgZ3Vlc3QgZmIsIHRoZW4gZmV0Y2ggdGhlDQo+ID4gZGF0YSB3aXRoIGds
UmVhZFBpeGVscygpLiAgV2hpY2ggd2lsbCBwcm9iYWJseSBkbyBleGFjdGx5IHRoZSBzYW1lDQo+
ID4gY29udmVyc2lvbi4gIEJ1dCBpdCdsbCBhZGQgYSBvcGVuZ2wgZGVwZW5kZW5jeSB0byB0aGUg
bm9uLW9wZW5nbA0KPiA+IHJlbmRlcmluZyBwYXRoIGluIHFlbXUsIHdvdWxkIGJlIG5pY2UgaWYg
d2UgY2FuIGF2b2lkIHRoYXQuDQo+ID4NCj4gPiBXaGlsZSBiZWluZyBhdCBpdDogIFdoZW4gaW1w
b3J0aW5nIGEgZG1hLWJ1ZiB3aXRoIGEgdGlsZWQgZnJhbWVidWZmZXINCj4gPiBpbnRvIG9wZW5n
bCAodmlhIGVnbENyZWF0ZUltYWdlS0hSICsgRUdMX0xJTlVYX0RNQV9CVUZfRVhUKSBJIHN1c3Bl
Y3Qgd2UNCj4gPiBoYXZlIHRvIHBhc3MgaW4gdGhlIHRpbGUgc2l6ZSBhcyBhdHRyaWJ1dGUgdG8g
bWFrZSBpdCB3b3JrLiAgSXMgdGhhdA0KPiA+IGNvcnJlY3Q/DQo+ID4NCj4gDQo+IEknZCBndWVz
cyBzbywgYnV0IG5lZWQgZG91YmxlIGNvbmZpcm0gbGF0ZXIgd2hlbiByZWFjaGluZyB0aGF0IGxl
dmVsIG9mIGRldGFpbC4NCj4gc29tZSBob21ld29yayBvbiBkbWEtYnVmIGlzIHJlcXVpcmVkIGZp
cnN0LiA6LSkNCj4gDQoNCmJ0dyBzb21lIHF1ZXN0aW9ucyBoZXJlOg0KDQpmb3Igbm9uLWdsIGFu
ZCBnbCByZW5kZXJpbmcgaW4gUWVtdSwgYXJlIHRoZXkgYmFzZWQgb24gZG1hLWJ1ZiBhbHJlYWR5
Pw0KDQpvbmNlIHdlIGNhbiBleHBvcnQgZ3Vlc3QgZnJhbWVidWZmZXIgaW4gZG1hLWJ1ZiwgaXMg
dGhlcmUgYWRkaXRpb25hbCB3b3JrDQpyZXF1aXJlZCBvciBqdXN0IHN0cmFpZ2h0Zm9yd2FyZCB0
byBpbnRlZ3JhdGUgd2l0aCBTUElDRT8NCg0KVGhhbmtzDQpLZXZpbg0K
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]


#1283689

FromGerd Hoffmann <kraxel@redhat.com>
Date2015-12-04 11:20 +0100
Message-ID<qBVD4-1m5-3@gated-at.bofh.it>
In reply to#1282744
  Hi,

> btw some questions here:
> 
> for non-gl and gl rendering in Qemu, are they based on dma-buf already?

> once we can export guest framebuffer in dma-buf, is there additional work
> required or just straightforward to integrate with SPICE?

Right now we are busy integrating dma-buf support into spice, which will
be used for the gl rendering path, for virtio-gpu.

For intel-vgpu the wireup inside qemu will be slightly different:  We'll
get a dma-buf handle from the igd driver, whereas virtio-gpu renders
into a texture, then exports that texture as dma-buf.

But in both cases we'll go pass the dma-buf with the guest framebuffer
(and meta-data such as fourcc and size) to spice-server, which in turn
will pass on the dma-buf to spice-client for (local) display.  So we
have a common code path in spice for both virtio-gpu and intel-vgpu,
based on dma-bufs.  spice-server even doesn't need to know what kind of
graphics device the guest has, it'll go just process the dma-bufs.

longer-term we also plan to support video-encoding for a remote display.
Again based on dma-bufs, by sending them to the gpu video encoder.


The non-gl rendering path needs to be figured out.

With virtio-gpu we'll go simply turn off 3d support, so the guest will
fallback to do software rendering, we'll get a classic DisplaySurface
and the vnc server can work with that.

That isn't going to fly with intel-vgpu though, so we need something
else.  Import dma-buf, then glReadPixels into a DisplaySurface would
work.  But as mentioned before I'd prefer a code path which doesn't
require opengl support in qemu, and one option for that would be the
special vfio region.  I've written up a quick draft meanwhile:


diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
index 751b69f..91b928d 100644
--- a/include/uapi/linux/vfio.h
+++ b/include/uapi/linux/vfio.h
@@ -596,6 +596,28 @@ struct vfio_iommu_spapr_tce_remove {
 };
 #define VFIO_IOMMU_SPAPR_TCE_REMOVE    _IO(VFIO_TYPE, VFIO_BASE + 20)
 
+/* -------- Additional API for vGPU -------- */
+
+/*
+ * framebuffer meta data
+ * subregion located at the end of the framebuffer region
+ */
+struct vfio_framebuffer {
+       __u32 argsz;
+
+       /* out */
+       __u32 format;    /* drm fourcc */
+       __u32 offset;    /* relative to region start */
+       __u32 width;     /* in pixels */
+       __u32 height;    /* in pixels */
+       __u32 stride;    /* in bytes  */
+
+       /* in+out */
+#define VFIO_FB_STATE_REQUEST_UPDATE   1  /* userspace requests update
*/
+#define VFIO_FB_STATE_UPDATE_COMPLETE  2  /* kernel signals completion
*/
+       __u32 state;     /* VFIO_FB_STATE_ */
+};
+
 /* ***************************************************************** */
 
 #endif /* _UAPIVFIO_H */

cheers,
  Gerd

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web