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

[Gerd Hoffmann <kraxel@xxxxxxxxxx>]

  Hi,

> > iGVT-g_Setup_Guide.txt mentions a "Indirect Display Mode", but doesn't
> > explain how the guest framebuffer can be accessed then.
> 
> You can check "fb_decoder.h". One thing to clarify. Its format is
> actually based on drm definition, instead of OpenGL. Sorry for
> that.

drm is fine.  That header explains the format, but not how it can be
accessed.  Is the guest fb exported as dma-buf?

> > So, for non-opengl rendering qemu needs the guest framebuffer data so it
> > can feed it into the vnc server.  The vfio framebuffer region is meant
> > to support this use case.
> 
> what's the format requirement on that framebuffer? If you are familiar
> with Intel Graphics, there's a so-called tiling feature applied on frame
> buffer so it can't be used as a raw input to vnc server. w/o opengl you
> need do some conversion on CPU first.

Yes, that conversion needs to happen, qemu can't deal with tiled
graphics.  Anything which pixman can handle will work.  Prefered would
be PIXMAN_x8r8g8b8 (aka DRM_FORMAT_XRGB8888 on little endian host) which
is the format used by the vnc server (and other places in qemu)
internally.

qemu can also use the opengl texture for the guest fb, then fetch the
data with glReadPixels().  Which will probably do exactly the same
conversion.  But it'll add a opengl dependency to the non-opengl
rendering path in qemu, would be nice if we can avoid that.

While being at it:  When importing a dma-buf with a tiled framebuffer
into opengl (via eglCreateImageKHR + EGL_LINUX_DMA_BUF_EXT) I suspect we
have to pass in the tile size as attribute to make it work.  Is that
correct?

cheers,
  Gerd



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel