lkml.org 
[lkml]   [2015]   [Nov]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel
    From
    Date
      Hi,

    > > Yes, vGPU may have additional features, like a framebuffer area, that
    > > aren't present or optional for direct assignment. Obviously we support
    > > direct assignment of GPUs for some vendors already without this feature.
    >
    > For exposing framebuffers for spice/vnc I highly recommend against
    > anything that looks like a bar/fixed mmio range mapping. First this means
    > the kernel driver needs to internally fake remapping, which isn't fun.

    Sure. I don't think we should remap here. More below.

    > My recoomendation is to build the actual memory access for underlying
    > framebuffers on top of dma-buf, so that it can be vacuumed up by e.g. the
    > host gpu driver again for rendering.

    We want that too ;)

    Some more background:

    OpenGL support in qemu is still young and emerging, and we are actually
    building on dma-bufs here. There are a bunch of different ways how
    guest display output is handled. At the end of the day it boils down to
    only two fundamental cases though:

    (a) Where qemu doesn't need access to the guest framebuffer
    - qemu directly renders via opengl (works today with virtio-gpu
    and will be in the qemu 2.5 release)
    - qemu passed on the dma-buf to spice client for local display
    (experimental code exists).
    - qemu feeds the guest display into gpu-assisted video encoder
    to send a stream over the network (no code yet).

    (b) Where qemu must read the guest framebuffer.
    - qemu's builtin vnc server.
    - qemu writing screenshots to file.
    - (non-opengl legacy code paths for local display, will
    hopefully disappear long-term though ...)

    So, the question is how to support (b) best. Even with OpenGL support
    in qemu improving over time I don't expect this going away completely
    anytime soon.

    I think it makes sense to have a special vfio region for that. I don't
    think remapping makes sense there. It doesn't need to be "live", it
    doesn't need support high refresh rates. Placing a copy of the guest
    framebuffer there on request (and convert from tiled to linear while
    being at it) is perfectly fine. qemu has a adaptive update rate and
    will stop doing frequent update requests when the vnc client
    disconnects, so there will be nothing to do if nobody wants actually see
    the guest display.

    Possible alternative approach would be to import a dma-buf, then use
    glReadPixels(). I suspect when doing the copy in the kernel the driver
    could ask just the gpu to blit the guest framebuffer. Don't know gfx
    hardware good enough to be sure though, comments are welcome.

    cheers,
    Gerd




    \
     
     \ /
      Last update: 2015-11-24 14:01    [W:2.312 / U:2.752 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site