[virglrenderer-devel] Multiple Virtual Displays

Marc-André Lureau marcandre.lureau at gmail.com
Thu May 26 17:29:40 UTC 2016


Hi

On Thu, May 26, 2016 at 5:51 PM, Anderson, Jason <
jander10 at jaguarlandrover.com> wrote:

> Hi List,
>
> I asked this in the IRC channel, sorry if I am asking someone to repeat
> themselves.
>
> I am looking to setup a system using QEmu that we can use for testing and
> development.  The requirement is that the virtualized system must support
> 3d hardware acceleration, which has been provided by virgl renderer, as
> well as support up to 7 display outputs from a single GPU.
>

The multimonitor support is so far quite incomplete or untested afaik.


>
> I've dug through the QEmu side, and I see that the "max_outputs" property
> is set to 1 by default in virtio-gpu.c.  I have tried changing this to 3,
> which seems to expose 3 connectors/encoders/crtc to the driver when running
> the system; however, they do not seem to get attached to any fb.
>

Here I disable virgl, just to check if the basics/2d work:

You can enable extra monitors. For example, with the gtk display, switch
the monitor with the "View" menu, you should have several "virtio-vga"
outputs (as many as max_outputs). This will trigger a reconfiguration, that
you can verify with xrandr output. However, qemu gets wrong scanout
informations from the virtio drm driver. The +x+y offset is always +0+0,
and the resultion is the same (a single window) so the display is the same.

 Furthermore, I think qemu code is not complete once the offset will be
corrected:

diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
index f3b0f14..619d1ec 100644
--- a/hw/display/virtio-gpu.c
+++ b/hw/display/virtio-gpu.c
@@ -504,6 +504,7 @@ static void virtio_gpu_set_scanout(VirtIOGPU *g,
     uint32_t offset;
     int bpp;
     struct virtio_gpu_set_scanout ss;
+    uint8_t *data;

     VIRTIO_GPU_FILL_CMD(ss);
     trace_virtio_gpu_cmd_set_scanout(ss.scanout_id, ss.resource_id,
@@ -567,12 +568,17 @@ static void virtio_gpu_set_scanout(VirtIOGPU *g,
     format = pixman_image_get_format(res->image);
     bpp = (PIXMAN_FORMAT_BPP(format) + 7) / 8;
     offset = (ss.r.x * bpp) + ss.r.y * pixman_image_get_stride(res->image);
-    if (!scanout->ds || surface_data(scanout->ds)
-        != ((uint8_t *)pixman_image_get_data(res->image) + offset) ||
-        scanout->width != ss.r.width ||
-        scanout->height != ss.r.height) {
+    data = (uint8_t *)pixman_image_get_data(res->image) + offset;
+    g_debug("id:%d %d+%d offset %d", ss.scanout_id, ss.r.x, ss.r.y,
offset);
+    if (!scanout->ds || surface_data(scanout->ds) != data ||
+        surface_width(scanout->ds) != ss.r.width ||
+        surface_height(scanout->ds) != ss.r.height) {
         /* realloc the surface ptr */
-        scanout->ds = qemu_create_displaysurface_pixman(res->image);
+        scanout->ds =
+            qemu_create_displaysurface_from(ss.r.width, ss.r.height,
+                                            format,
+
pixman_image_get_stride(res->image),
+                                            data);
         if (!scanout->ds) {
             cmd->error = VIRTIO_GPU_RESP_ERR_UNSPEC;
             return;

I just started looking at kernel code to understand the wrong offset bug,
but I am quite confident Dave will be much faster at fixing it.


> In an ideal world, if I run QEmu with -dispaly sdl,gl=on,   I would like
> to see one window opened up for each virtual output.  If this is not
> possible, is it possible to have one very large frame buffer, and map
> different regions of it to different named outputs for use by Weston?  Are
> there any other options I am not considering, or am I crazy?
>

I would say it's still an ideal world, there is work to do to support
multiple monitors, especially with virgl, help appreciated!

regards

-- 
Marc-André Lureau
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/virglrenderer-devel/attachments/20160526/15b3a586/attachment.html>


More information about the virglrenderer-devel mailing list