[Qemu-devel] [PATCH] opengl rendering in the sdl window

[Qemu-devel] [PATCH] opengl rendering in the sdl window

[Stefano Stabellini]

This patch comes from xen-unstable and adds opengl support for rendering
the guest framebuffer in the SDL window.
SDL is needed anyway to open the window and handle the events.
Opengl rendering is optional and can be turned off at both compile time
and run time (--disable-opengl).
Some of the benefits of using opengl are:

-faster rendering, less CPU intensive, especially with good graphic
cards;

-makes the window resizing possible and hardware accelerated, thus very
efficient and smooth;

-allows other optimizations like sharing directly a buffer in vram with
the guest (not yet implemented). 

Opengl rendering actually is enabled only when the buffer is shared to
avoid adding one more copy of the pixel buffer.

This patch depends upon the shared buffer patch and the previous sdl
patch.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

---

diff --git a/configure b/configure
index acb4a4a..a794827 100755
--- a/configure
+++ b/configure
@@ -271,6 +271,8 @@ for opt do
   ;;
   --disable-sdl) sdl="no"
   ;;
+  --disable-opengl) opengl="no"
+  ;;
   --fmod-lib=*) fmod_lib="$optarg"
   ;;
   --fmod-inc=*) fmod_inc="$optarg"
@@ -749,6 +751,26 @@ else
 fi # -z $sdl
 
 ##########################################
+# OpenGL test
+
+if test -z "$opengl" && test "$sdl" = "yes"
+then
+cat > $TMPC << EOF
+#include <GL/gl.h>
+#ifndef GL_TEXTURE_RECTANGLE_ARB
+#error "Opengl doesn't support GL_TEXTURE_RECTANGLE_ARB"
+#endif
+int main( void ) { return (int) glGetString(GL_EXTENSIONS); }
+EOF
+if $cc -o $TMPE $TMPC -lGL 2> /dev/null
+then
+opengl="yes"
+else
+opengl="no"
+fi
+fi
+
+##########################################
 # VNC TLS detection
 if test "$vnc_tls" = "yes" ; then
 cat > $TMPC <<EOF
@@ -941,6 +963,7 @@ if test "$sdl" != "no" ; then
     echo "SDL static link   $sdl_static"
 fi
 echo "curses support    $curses"
+echo "OpenGL support    $opengl"
 echo "mingw32 support   $mingw32"
 echo "Audio drivers     $audio_drv_list"
 echo "Extra audio cards $audio_card_list"
@@ -1199,6 +1222,14 @@ if test "$sdl1" = "yes" ; then
     echo "SDL_CFLAGS=`$sdl_config --cflags`" >> $config_mak
   fi
 fi
+if test $opengl = "yes"
+then
+    echo "#define CONFIG_OPENGL 1" >> $config_h
+    echo "CONFIG_OPENGL=yes" >> $config_mak
+    echo "SDL_CFLAGS+=-I/usr/include/GL" >> $config_mak
+    echo "SDL_LIBS+=-lXext" >> $config_mak
+    echo "SDL_LIBS+=-lGL" >> $config_mak
+fi
 if test "$cocoa" = "yes" ; then
   echo "#define CONFIG_COCOA 1" >> $config_h
   echo "CONFIG_COCOA=yes" >> $config_mak
diff --git a/console.h b/console.h
index 7d252b7..a2004ba 100644
--- a/console.h
+++ b/console.h
@@ -153,7 +153,7 @@ void qemu_console_resize_shared(QEMUConsole *console, int width, int height,
                                 int depth, int linesize, void *pixels);
 
 /* sdl.c */
-void sdl_display_init(DisplayState *ds, int full_screen, int no_frame);
+void sdl_display_init(DisplayState *ds, int full_screen, int no_frame, int opengl_enable);
 
 /* cocoa.m */
 void cocoa_display_init(DisplayState *ds, int full_screen);
diff --git a/sdl.c b/sdl.c
index 8e78323..18792b4 100644
--- a/sdl.c
+++ b/sdl.c
@@ -31,6 +31,10 @@
 #include <signal.h>
 #endif
 
+#ifdef CONFIG_OPENGL
+#include <SDL_opengl.h>
+#endif
+
 static SDL_Surface *screen;
 static SDL_Surface *shared;
 static int gui_grab; /* if true, all keyboard/mouse events are grabbed */
@@ -50,9 +54,115 @@ static int absolute_enabled = 0;
 static int guest_cursor = 0;
 static int guest_x, guest_y;
 static SDL_Cursor *guest_sprite = 0;
+static int opengl_enabled;
 
 static void sdl_colourdepth(DisplayState *ds, int depth);
 
+#ifdef CONFIG_OPENGL
+static GLint tex_format;
+static GLint tex_type;
+static GLuint texture_ref = 0;
+static GLint gl_format;
+
+static void opengl_setdata(DisplayState *ds, void *pixels)
+{
+    glEnable(GL_TEXTURE_RECTANGLE_ARB);
+    glTexEnvi(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_REPLACE);
+    glClearColor(0, 0, 0, 0);
+    glDisable(GL_BLEND);
+    glDisable(GL_LIGHTING);
+    glDisable(GL_DEPTH_TEST);
+    glDepthMask(GL_FALSE);
+    glDisable(GL_CULL_FACE);
+    glViewport( 0, 0, screen->w, screen->h);
+    glMatrixMode(GL_PROJECTION);
+    glLoadIdentity();
+    glOrtho(0, screen->w, screen->h, 0, -1,1);
+    glMatrixMode(GL_MODELVIEW);
+    glLoadIdentity();
+    glClear(GL_COLOR_BUFFER_BIT);
+    ds->data = pixels;
+
+    if (texture_ref) {
+        glDeleteTextures(1, &texture_ref);
+        texture_ref = 0;
+    }
+
+    glGenTextures(1, &texture_ref);
+    glBindTexture(GL_TEXTURE_RECTANGLE_ARB, texture_ref);
+    glPixelStorei(GL_UNPACK_LSB_FIRST, 1);
+    switch (ds->depth) {
+        case 8:
+            if (ds->palette == NULL) {
+                tex_format = GL_RGB;
+                tex_type = GL_UNSIGNED_BYTE_3_3_2;
+            } else {
+                int i;
+                GLushort paletter[256], paletteg[256], paletteb[256];
+                for (i = 0; i < 256; i++) {
+                    uint8_t rgb = ds->palette[i] >> 16;
+                    paletter[i] = ((rgb & 0xe0) >> 5) * 65535 / 7;
+                    paletteg[i] = ((rgb & 0x1c) >> 2) * 65535 / 7;
+                    paletteb[i] = (rgb & 0x3) * 65535 / 3;
+                }
+                glPixelMapusv(GL_PIXEL_MAP_I_TO_R, 256, paletter);
+                glPixelMapusv(GL_PIXEL_MAP_I_TO_G, 256, paletteg);
+                glPixelMapusv(GL_PIXEL_MAP_I_TO_B, 256, paletteb);
+
+                tex_format = GL_COLOR_INDEX;
+                tex_type = GL_UNSIGNED_BYTE;
+            }
+            break;
+        case 16:
+            tex_format = GL_RGB;
+            tex_type = GL_UNSIGNED_SHORT_5_6_5;
+            break;
+        case 24:
+            tex_format = GL_BGR;
+            tex_type = GL_UNSIGNED_BYTE;
+            break;
+        case 32:
+            if (!ds->bgr) {
+                tex_format = GL_BGRA;
+                tex_type = GL_UNSIGNED_BYTE;
+            } else {
+                tex_format = GL_RGBA;
+                tex_type = GL_UNSIGNED_BYTE;                
+            }
+            break;
+    }   
+    glPixelStorei(GL_UNPACK_ROW_LENGTH, (ds->linesize * 8) / ds->depth);
+    glTexImage2D(GL_TEXTURE_RECTANGLE_ARB, 0, gl_format, ds->width, ds->height, 0, tex_format, tex_type, pixels);
+    glTexParameterf(GL_TEXTURE_RECTANGLE_ARB, GL_TEXTURE_PRIORITY, 1.0);
+    glTexParameteri(GL_TEXTURE_RECTANGLE_ARB, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
+    glTexParameteri(GL_TEXTURE_RECTANGLE_ARB, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
+    glTexParameteri(GL_TEXTURE_RECTANGLE_ARB, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE);
+    glTexParameteri(GL_TEXTURE_RECTANGLE_ARB, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE);
+    glBindTexture(GL_TEXTURE_RECTANGLE_ARB, 0);
+}
+
+static void opengl_update(DisplayState *ds, int x, int y, int w, int h)
+{  
+    int bpp = ds->depth / 8;
+    GLvoid *pixels = ds->data + y * ds->linesize + x * bpp;
+    glBindTexture(GL_TEXTURE_RECTANGLE_ARB, texture_ref);
+    glPixelStorei(GL_UNPACK_ROW_LENGTH, ds->linesize / bpp);
+    glTexSubImage2D(GL_TEXTURE_RECTANGLE_ARB, 0, x, y, w, h, tex_format, tex_type, pixels);
+    glBegin(GL_QUADS);
+        glTexCoord2d(0, 0);
+        glVertex2d(0, 0);
+        glTexCoord2d(ds->width, 0);
+        glVertex2d(screen->w, 0);
+        glTexCoord2d(ds->width, ds->height);
+        glVertex2d(screen->w, screen->h);
+        glTexCoord2d(0, ds->height);
+        glVertex2d(0, screen->h);
+    glEnd();
+    glBindTexture(GL_TEXTURE_RECTANGLE_ARB, 0);
+    SDL_GL_SwapBuffers();
+}
+#endif
+
 static void sdl_update(DisplayState *ds, int x, int y, int w, int h)
 {
     //    printf("updating x=%d y=%d w=%d h=%d\n", x, y, w, h);
@@ -117,7 +227,12 @@ static void sdl_resize_shared(DisplayState *ds, int w, int h, int depth, int lin
 
     sdl_colourdepth(ds, depth);
 
-    flags = SDL_HWSURFACE|SDL_ASYNCBLIT|SDL_HWACCEL|SDL_DOUBLEBUF|SDL_HWPALETTE;
+#ifdef CONFIG_OPENGL
+    if (ds->shared_buf && opengl_enabled)
+        flags = SDL_OPENGL|SDL_RESIZABLE;
+    else
+#endif
+        flags = SDL_HWSURFACE|SDL_ASYNCBLIT|SDL_HWACCEL|SDL_DOUBLEBUF|SDL_HWPALETTE;
 
     if (gui_fullscreen) {
         flags |= SDL_FULLSCREEN;
@@ -131,19 +246,33 @@ static void sdl_resize_shared(DisplayState *ds, int w, int h, int depth, int lin
 
  again:
     screen = SDL_SetVideoMode(w, h, 0, flags);
+
     if (!screen) {
         fprintf(stderr, "Could not open SDL display: %s\n", SDL_GetError());
+        if (opengl_enabled) {
+            /* Fallback to SDL */
+            opengl_enabled = 0;
+            ds->dpy_update = sdl_update;
+            ds->dpy_setdata = sdl_setdata;
+            ds->dpy_resize_shared = sdl_resize_shared;
+            sdl_resize_shared(ds, w, h, depth, linesize, pixels);
+            return;
+        }
         exit(1);
     }
-    if (!screen->pixels && (flags & SDL_HWSURFACE) && (flags & SDL_FULLSCREEN)) {
-        flags &= ~SDL_HWSURFACE;
-        goto again;
-    }
 
-    if (!screen->pixels) {
-        fprintf(stderr, "Could not open SDL display: %s\n", SDL_GetError());
-        exit(1);
+    if (!opengl_enabled) {
+        if (!screen->pixels && (flags & SDL_HWSURFACE) && (flags & SDL_FULLSCREEN)) {
+            flags &= ~SDL_HWSURFACE;
+            goto again;
+        }
+
+        if (!screen->pixels) {
+            fprintf(stderr, "Could not open SDL display: %s\n", SDL_GetError());
+            exit(1);
+        }
     }
+
     ds->width = w;
     ds->height = h;
     if (!ds->shared_buf) {
@@ -158,6 +287,25 @@ static void sdl_resize_shared(DisplayState *ds, int w, int h, int depth, int lin
         ds->linesize = screen->pitch;
     } else {
         ds->linesize = linesize;
+#ifdef CONFIG_OPENGL
+        switch(screen->format->BitsPerPixel) {
+        case 8:
+            gl_format = GL_RGB;
+            break;
+        case 16:
+            gl_format = GL_RGB;
+            break;
+        case 24:
+            gl_format = GL_RGB;
+            break;
+        case 32:
+            if (!screen->format->Rshift)
+                gl_format = GL_BGRA;
+            else
+                gl_format = GL_RGBA;
+            break;
+        };
+#endif
     }
     if (ds->shared_buf) ds->dpy_setdata(ds, pixels);
 }
@@ -176,6 +324,11 @@ static void sdl_colourdepth(DisplayState *ds, int depth)
     }
     ds->shared_buf = 1;
     ds->depth = depth;
+#ifdef CONFIG_OPENGL
+    if (opengl_enabled) {
+        ds->dpy_update = opengl_update;
+    }
+#endif
 }
 
 /* generic keyboard conversion */
@@ -388,8 +541,8 @@ static void sdl_send_mouse_event(int dx, int dy, int dz, int x, int y, int state
 	    absolute_enabled = 1;
 	}
 
-       dx = x * 0x7FFF / (width - 1);
-       dy = y * 0x7FFF / (height - 1);
+       dx = x * 0x7FFF / (screen->w - 1);
+       dy = y * 0x7FFF / (screen->h - 1);
     } else if (absolute_enabled) {
 	sdl_show_cursor();
 	absolute_enabled = 0;
@@ -437,7 +590,7 @@ static void sdl_refresh(DisplayState *ds)
     while (SDL_PollEvent(ev)) {
         switch (ev->type) {
         case SDL_VIDEOEXPOSE:
-            sdl_update(ds, 0, 0, screen->w, screen->h);
+            ds->dpy_update(ds, 0, 0, ds->width, ds->height);
             break;
         case SDL_KEYDOWN:
         case SDL_KEYUP:
@@ -601,6 +754,18 @@ static void sdl_refresh(DisplayState *ds)
                 }
             }
             break;
+#ifdef CONFIG_OPENGL
+        case SDL_VIDEORESIZE:
+        {
+            if (ds->shared_buf && opengl_enabled) {
+                SDL_ResizeEvent *rev = &ev->resize;
+                screen = SDL_SetVideoMode(rev->w, rev->h, 0, SDL_OPENGL|SDL_RESIZABLE);
+                opengl_setdata(ds, ds->data);
+                opengl_update(ds, 0, 0, ds->width, ds->height);
+            }
+            break;
+        }
+#endif
         default:
             break;
         }
@@ -676,15 +841,19 @@ static void sdl_mouse_define(int width, int height, int bpp,
 
 static void sdl_cleanup(void)
 {
+#ifdef CONFIG_OPENGL
+    if (texture_ref) glDeleteTextures(1, &texture_ref);
+#endif
     if (guest_sprite)
         SDL_FreeCursor(guest_sprite);
     SDL_Quit();
 }
 
-void sdl_display_init(DisplayState *ds, int full_screen, int no_frame)
+void sdl_display_init(DisplayState *ds, int full_screen, int no_frame, int opengl)
 {
     int flags;
     uint8_t data = 0;
+    opengl_enabled = opengl;
 
 #if defined(__APPLE__)
     /* always use generic keymaps */
@@ -711,6 +880,10 @@ void sdl_display_init(DisplayState *ds, int full_screen, int no_frame)
     ds->dpy_resize_shared = sdl_resize_shared;
     ds->dpy_refresh = sdl_refresh;
     ds->dpy_setdata = sdl_setdata;
+#ifdef CONFIG_OPENGL
+    if (opengl_enabled)
+        ds->dpy_setdata = opengl_setdata;
+#endif
     ds->dpy_fill = sdl_fill;
     ds->mouse_set = sdl_mouse_warp;
     ds->cursor_define = sdl_mouse_define;
diff --git a/vl.c b/vl.c
index 245177a..c661fa9 100644
--- a/vl.c
+++ b/vl.c
@@ -201,6 +201,11 @@ int graphic_height = 600;
 int graphic_depth = 15;
 #endif
 int full_screen = 0;
+#ifdef CONFIG_OPENGL
+int opengl_enabled = 1;
+#else
+int opengl_enabled = 0;
+#endif
 int no_frame = 0;
 int no_quit = 0;
 CharDriverState *serial_hds[MAX_SERIAL_PORTS];
@@ -7681,6 +7686,9 @@ static void help(int exitcode)
            "-no-frame       open SDL window without a frame and window decorations\n"
            "-alt-grab       use Ctrl-Alt-Shift to grab mouse (instead of Ctrl-Alt)\n"
            "-no-quit        disable SDL window close capability\n"
+#ifdef CONFIG_OPENGL
+           "-disable-opengl disable OpenGL rendering, using SDL\n"
+#endif
 #endif
 #ifdef TARGET_I386
            "-no-fd-bootchk  disable boot signature checking for floppy disks\n"
@@ -7881,6 +7889,7 @@ enum {
     QEMU_OPTION_no_frame,
     QEMU_OPTION_alt_grab,
     QEMU_OPTION_no_quit,
+    QEMU_OPTION_disable_opengl,
     QEMU_OPTION_pidfile,
     QEMU_OPTION_no_kqemu,
     QEMU_OPTION_kernel_kqemu,
@@ -7983,6 +7992,9 @@ const QEMUOption qemu_options[] = {
     { "no-frame", 0, QEMU_OPTION_no_frame },
     { "alt-grab", 0, QEMU_OPTION_alt_grab },
     { "no-quit", 0, QEMU_OPTION_no_quit },
+#ifdef CONFIG_OPENGL
+    { "disable-opengl", 0, QEMU_OPTION_disable_opengl },
+#endif
 #endif
     { "pidfile", HAS_ARG, QEMU_OPTION_pidfile },
     { "win2k-hack", 0, QEMU_OPTION_win2k_hack },
@@ -8729,6 +8741,11 @@ int main(int argc, char **argv)
             case QEMU_OPTION_no_quit:
                 no_quit = 1;
                 break;
+#ifdef CONFIG_OPENGL
+            case QEMU_OPTION_disable_opengl:
+                opengl_enabled = 0;
+                break;
+#endif
 #endif
             case QEMU_OPTION_pidfile:
                 pid_file = optarg;
@@ -9104,7 +9121,7 @@ int main(int argc, char **argv)
 #endif
     {
 #if defined(CONFIG_SDL)
-        sdl_display_init(ds, full_screen, no_frame);
+        sdl_display_init(ds, full_screen, no_frame, opengl_enabled);
 #elif defined(CONFIG_COCOA)
         cocoa_display_init(ds, full_screen);
 #else

Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[Ian Jackson]

Stefano Stabellini writes ("[Qemu-devel] [PATCH] opengl rendering in the sdl window"):
> This patch comes from xen-unstable and adds opengl support for rendering
> the guest framebuffer in the SDL window.
...
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Ian.

Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[Anthony Liguori]

Stefano Stabellini wrote:
> This patch comes from xen-unstable and adds opengl support for rendering
> the guest framebuffer in the SDL window.
> SDL is needed anyway to open the window and handle the events.
> Opengl rendering is optional and can be turned off at both compile time
> and run time (--disable-opengl).
> Some of the benefits of using opengl are:
>
> -faster rendering, less CPU intensive, especially with good graphic
> cards;
>   

Have you measured this or is this just intuition?  I've measured it with 
gtk-vnc and I did not observe any CPU usage decrease in using OpenGL for 
rendering verses an XShmImage.

> -makes the window resizing possible and hardware accelerated, thus very
> efficient and smooth;
>   

This is neat, but, I'm unsure if the right way to support OpenGL is 
through SDL.  For instance, there were Cocoa OpenGL patches posted a bit 
ago that would be largely similar.  It may make more sense to have an 
OpenGL front-end that has conditional code for SDL/Cocoa/X/etc.

Then again, I've been kicking around the idea of doing a GTK front-end.  
An obvious thing to do here would be a glext based OpenGL version (as we 
do in gtk-vnc).

I think we need to have some discussion about what the long term 
front-end should be for QEMU.  Otherwise, we're going to end up with a 
proliferation of front-ends.  Personally, I'd rather move from SDL to 
GTK so that we can build a proper user interface.

Regards,

Anthony Liguori

Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[Gerd Hoffmann]

  Hi,

> I think we need to have some discussion about what the long term
> front-end should be for QEMU.  Otherwise, we're going to end up with a
> proliferation of front-ends.  Personally, I'd rather move from SDL to
> GTK so that we can build a proper user interface.

I really like vnc.  Main reason is that the VM and the display are
separate, so you can close the window and the VM keeps running.  So when
creating a nifty user interface I'd put that into a separate process
which talks to qemu via monitor and vnc.  Or maybe better some shared
memory approach for the display.

cheers,
  Gerd

Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[Daniel P. Berrange]

On Wed, Sep 03, 2008 at 10:00:31PM -0500, Anthony Liguori wrote:
> Stefano Stabellini wrote:
> >This patch comes from xen-unstable and adds opengl support for rendering
> >the guest framebuffer in the SDL window.
> >SDL is needed anyway to open the window and handle the events.
> >Opengl rendering is optional and can be turned off at both compile time
> >and run time (--disable-opengl).
> >Some of the benefits of using opengl are:
> >
> >-faster rendering, less CPU intensive, especially with good graphic
> >cards;
> >  
> 
> Have you measured this or is this just intuition?  I've measured it with 
> gtk-vnc and I did not observe any CPU usage decrease in using OpenGL for 
> rendering verses an XShmImage.
> 
> >-makes the window resizing possible and hardware accelerated, thus very
> >efficient and smooth;
> >  
> 
> This is neat, but, I'm unsure if the right way to support OpenGL is 
> through SDL.  For instance, there were Cocoa OpenGL patches posted a bit 
> ago that would be largely similar.  It may make more sense to have an 
> OpenGL front-end that has conditional code for SDL/Cocoa/X/etc.
> 
> Then again, I've been kicking around the idea of doing a GTK front-end.  
> An obvious thing to do here would be a glext based OpenGL version (as we 
> do in gtk-vnc).

Actually I'm not so sure this was a good idea in the end. I'm seriously
considering re-writing the GTK-VNC stuff to use Cairo, which in turn
can use 2-d hardware acceleration primitives - it really doesn't need
the full 3-d acceleration stack just for scaling. 

> I think we need to have some discussion about what the long term 
> front-end should be for QEMU.  Otherwise, we're going to end up with a 
> proliferation of front-ends.  Personally, I'd rather move from SDL to 
> GTK so that we can build a proper user interface.

As long as that's optional, because in a server deployment scenario like
oVirt I don't want to pull in the GTK stack just to run QEMU vms. We currently
have a minimal OS image target of < 64 MB in size. Adding GTK and its deps
will totally blow that limit. 

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[Andreas Färber]

Am 04.09.2008 um 11:42 schrieb Daniel P. Berrange:

> On Wed, Sep 03, 2008 at 10:00:31PM -0500, Anthony Liguori wrote:
>> I think we need to have some discussion about what the long term
>> front-end should be for QEMU.  Otherwise, we're going to end up  
>> with a
>> proliferation of front-ends.  Personally, I'd rather move from SDL to
>> GTK so that we can build a proper user interface.
>
> As long as that's optional, because in a server deployment scenario  
> like
> oVirt I don't want to pull in the GTK stack just to run QEMU vms. We  
> currently
> have a minimal OS image target of < 64 MB in size. Adding GTK and  
> its deps
> will totally blow that limit.

All graphical frontends have been optional (--disable-sdl,  
undocumented --disable-gfx-check).

Andreas

Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[Daniel P. Berrange]

On Thu, Sep 04, 2008 at 12:06:22PM +0200, Andreas F?rber wrote:
> 
> Am 04.09.2008 um 11:42 schrieb Daniel P. Berrange:
> 
> >On Wed, Sep 03, 2008 at 10:00:31PM -0500, Anthony Liguori wrote:
> >>I think we need to have some discussion about what the long term
> >>front-end should be for QEMU.  Otherwise, we're going to end up  
> >>with a
> >>proliferation of front-ends.  Personally, I'd rather move from SDL to
> >>GTK so that we can build a proper user interface.
> >
> >As long as that's optional, because in a server deployment scenario  
> >like
> >oVirt I don't want to pull in the GTK stack just to run QEMU vms. We  
> >currently
> >have a minimal OS image target of < 64 MB in size. Adding GTK and  
> >its deps
> >will totally blow that limit.
> 
> All graphical frontends have been optional (--disable-sdl,  
> undocumented --disable-gfx-check).

It gets a little more complicated when you have to ship this still in 
binary packages though. Users typically expect us to enable all the
compile time options which are a available for a particular OS distro,
so they'd expect GTK enabled by default if we had that. At the same 
time many people won't want QEMU to have a dep on GTK. I don't want
to end up building multiple binary packages of QEMU, with & without
the frontend. It might warrant having a libqemu, and separate graphical
frontends, one GTK, one VNC,...  That of course raises a question if
ABI for libqemu - it could be put in a private lib directory just for
the official frontends to use, and declared 'not for public use'.

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[Andreas Färber]

Am 04.09.2008 um 12:20 schrieb Daniel P. Berrange:

> On Thu, Sep 04, 2008 at 12:06:22PM +0200, Andreas F?rber wrote:
>>
>> Am 04.09.2008 um 11:42 schrieb Daniel P. Berrange:
>>
>>> On Wed, Sep 03, 2008 at 10:00:31PM -0500, Anthony Liguori wrote:
>>>> I think we need to have some discussion about what the long term
>>>> front-end should be for QEMU.  Otherwise, we're going to end up
>>>> with a
>>>> proliferation of front-ends.  Personally, I'd rather move from  
>>>> SDL to
>>>> GTK so that we can build a proper user interface.
>>>
>>> As long as that's optional, because in a server deployment scenario
>>> like
>>> oVirt I don't want to pull in the GTK stack just to run QEMU vms. We
>>> currently
>>> have a minimal OS image target of < 64 MB in size. Adding GTK and
>>> its deps
>>> will totally blow that limit.
>>
>> All graphical frontends have been optional (--disable-sdl,
>> undocumented --disable-gfx-check).
>
> It gets a little more complicated when you have to ship this still in
> binary packages though. Users typically expect us to enable all the
> compile time options which are a available for a particular OS distro,
> so they'd expect GTK enabled by default if we had that. At the same
> time many people won't want QEMU to have a dep on GTK.

True. I've seen headless storage nodes run even without X11 installed,  
which would probably be just as problematic for SDL.

Debian Etch for instance has a similar issue, it pulls in the whole  
OOo suite if I install GNOME in a VM for XDMCP. It's always a  
balancing act, between "standard" Linux desktop and more advanced users.

Anyway, this is still a bikeshed discussion until Anthony provides  
details of what he's up to. :)

Andreas

Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[Avi Kivity]

Daniel P. Berrange wrote:
> It gets a little more complicated when you have to ship this still in 
> binary packages though. Users typically expect us to enable all the
> compile time options which are a available for a particular OS distro,
> so they'd expect GTK enabled by default if we had that. At the same 
> time many people won't want QEMU to have a dep on GTK. I don't want
> to end up building multiple binary packages of QEMU, with & without
> the frontend. It might warrant having a libqemu, and separate graphical
> frontends, one GTK, one VNC,...  That of course raises a question if
> ABI for libqemu - it could be put in a private lib directory just for
> the official frontends to use, and declared 'not for public use'.
>   

Alternatively, we can have qemu dlopen() the graphical frontends (and 
maybe even block format drivers, or even emulated devices).

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[Anthony Liguori]

Daniel P. Berrange wrote:
> On Wed, Sep 03, 2008 at 10:00:31PM -0500, Anthony Liguori wrote:
>   
> Actually I'm not so sure this was a good idea in the end. I'm seriously
> considering re-writing the GTK-VNC stuff to use Cairo, which in turn
> can use 2-d hardware acceleration primitives - it really doesn't need
> the full 3-d acceleration stack just for scaling. 
>   

I tried to originally write the GTK-VNC scaling stuff in Cairo.  Could 
not get it to perform well at all.  I'd be really interested if you had 
better luck with it.

>> I think we need to have some discussion about what the long term 
>> front-end should be for QEMU.  Otherwise, we're going to end up with a 
>> proliferation of front-ends.  Personally, I'd rather move from SDL to 
>> GTK so that we can build a proper user interface.
>>     
>
> As long as that's optional, because in a server deployment scenario like
> oVirt I don't want to pull in the GTK stack just to run QEMU vms. We currently
> have a minimal OS image target of < 64 MB in size. Adding GTK and its deps
> will totally blow that limit. 
>   

Of course.

Regards,

Anthony Liguori

> Daniel
>   

Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[Daniel P. Berrange]

On Sat, Sep 06, 2008 at 10:07:10PM -0500, Anthony Liguori wrote:
> Daniel P. Berrange wrote:
> >On Wed, Sep 03, 2008 at 10:00:31PM -0500, Anthony Liguori wrote:
> >  
> >Actually I'm not so sure this was a good idea in the end. I'm seriously
> >considering re-writing the GTK-VNC stuff to use Cairo, which in turn
> >can use 2-d hardware acceleration primitives - it really doesn't need
> >the full 3-d acceleration stack just for scaling. 
> >  
> 
> I tried to originally write the GTK-VNC scaling stuff in Cairo.  Could 
> not get it to perform well at all.  I'd be really interested if you had 
> better luck with it.

I've just posted patches to the GTK-VNC devel list demonstrating use of
Cairo for all rendering. I can't notice any serious drop in performance
when enabling scaling with Cairo. If you confirm my tests, it'd be worth
evaluating Cairo as an alternative to OpenGL in QEMU too.

Regards,
Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[Anthony Liguori]

[-- Attachment #1: Type: text/plain, Size: 1139 bytes --]

Daniel P. Berrange wrote:
> On Sat, Sep 06, 2008 at 10:07:10PM -0500, Anthony Liguori wrote:
>   
>> Daniel P. Berrange wrote:
>>     
>>> On Wed, Sep 03, 2008 at 10:00:31PM -0500, Anthony Liguori wrote:
>>>  
>>> Actually I'm not so sure this was a good idea in the end. I'm seriously
>>> considering re-writing the GTK-VNC stuff to use Cairo, which in turn
>>> can use 2-d hardware acceleration primitives - it really doesn't need
>>> the full 3-d acceleration stack just for scaling. 
>>>  
>>>       
>> I tried to originally write the GTK-VNC scaling stuff in Cairo.  Could 
>> not get it to perform well at all.  I'd be really interested if you had 
>> better luck with it.
>>     
>
> I've just posted patches to the GTK-VNC devel list demonstrating use of
> Cairo for all rendering. I can't notice any serious drop in performance
> when enabling scaling with Cairo. If you confirm my tests, it'd be worth
> evaluating Cairo as an alternative to OpenGL in QEMU too.
>   

Here's the beginning of a GTK front-end in case someone wants to try 
adapting the Cairo patches to QEMU.

Regards,

Anthony Liguori

> Regards,
> Daniel
>   


[-- Attachment #2: gtk.patch --]
[-- Type: text/x-patch, Size: 26161 bytes --]

diff --git a/Makefile b/Makefile
index 0472e16..3927c40 100644
--- a/Makefile
+++ b/Makefile
@@ -124,6 +124,9 @@ ifdef CONFIG_CURSES
 OBJS+=curses.o
 endif
 OBJS+=vnc.o d3des.o
+ifdef CONFIG_GTK
+OBJS+=gtk.o
+endif
 
 ifdef CONFIG_COCOA
 OBJS+=cocoa.o
@@ -145,6 +148,9 @@ cocoa.o: cocoa.m
 sdl.o: sdl.c keymaps.c sdl_keysym.h
 	$(CC) $(CFLAGS) $(CPPFLAGS) $(SDL_CFLAGS) -c -o $@ $<
 
+gtk.o: gtk.c
+	$(CC) $(CFLAGS) $(CPPFLAGS) $(GTK_CFLAGS) -c -o $@ $<
+
 vnc.o: vnc.c keymaps.c sdl_keysym.h vnchextile.h d3des.c d3des.h
 	$(CC) $(CFLAGS) $(CPPFLAGS) $(CONFIG_VNC_TLS_CFLAGS) -c -o $@ $<
 
diff --git a/Makefile.target b/Makefile.target
index 42162c3..572b44b 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -515,6 +515,10 @@ CPPFLAGS += $(CONFIG_VNC_TLS_CFLAGS)
 LIBS += $(CONFIG_VNC_TLS_LIBS)
 endif
 
+ifdef CONFIG_GTK
+LIBS += $(GTK_LIBS)
+endif
+
 # SCSI layer
 OBJS+= lsi53c895a.o esp.o
 
diff --git a/configure b/configure
index 0a3b7c9..d0e63fa 100755
--- a/configure
+++ b/configure
@@ -90,6 +90,7 @@ EXESUF=""
 gdbstub="yes"
 slirp="yes"
 vde="yes"
+gtk="yes"
 fmod_lib=""
 fmod_inc=""
 vnc_tls="yes"
@@ -283,6 +284,8 @@ for opt do
   ;;
   --disable-vde) vde="no"
   ;;
+  --disable-gtk) gtk="no"
+  ;;
   --disable-kqemu) kqemu="no"
   ;;
   --disable-brlapi) brlapi="no"
@@ -436,6 +439,7 @@ echo "  --fmod-inc               path to FMOD includes"
 echo "  --enable-uname-release=R Return R for uname -r in usermode emulation"
 echo "  --sparc_cpu=V            Build qemu for Sparc architecture v7, v8, v8plus, v8plusa, v9"
 echo "  --disable-vde            disable support for vde network"
+echo "  --disable-gtk            disable support for GTK"
 echo ""
 echo "NOTE: The object files are built at the place where configure is launched"
 exit 1
@@ -758,6 +762,20 @@ EOF
     fi
 fi
 
+if test "$gtk" = "yes" ; then
+    cat > $TMPC <<EOF
+#include <gtk/gtk.h>
+int main(int argc, char **argv) { gtk_init(&argc, &argv); return 0; }
+EOF
+    gtk_cflags=`pkg-config --cflags gtk+-2.0`
+    gtk_libs=`pkg-config --libs gtk+-2.0`
+    if $cc $ARCH_CFLAGS -o $TMPE $TMPC $gtk_cflags $gtk_libs ; then
+	:
+    else
+	gtk="no"
+    fi
+fi
+
 ##########################################
 # Sound support libraries probe
 
@@ -923,6 +941,7 @@ echo "Documentation     $build_docs"
 echo "uname -r          $uname_release"
 echo "NPTL support      $nptl"
 echo "vde support       $vde"
+echo "gtk support       $gtk"
 
 if test $sdl_too_old = "yes"; then
 echo "-> Your SDL version is too old - please upgrade to have SDL support"
@@ -1097,6 +1116,12 @@ if test "$vde" = "yes" ; then
   echo "#define CONFIG_VDE 1" >> $config_h
   echo "VDE_LIBS=-lvdeplug" >> $config_mak
 fi
+if test "$gtk" = "yes" ; then
+  echo "CONFIG_GTK=yes" >> $config_mak
+  echo "#define CONFIG_GTK 1" >> $config_h
+  echo "GTK_CFLAGS=$gtk_cflags" >> $config_mak
+  echo "GTK_LIBS=$gtk_libs" >> $config_mak
+fi
 for card in $audio_card_list; do
     def=CONFIG_`echo $card | tr '[:lower:]' '[:upper:]'`
     echo "$def=yes" >> $config_mak
diff --git a/console.h b/console.h
index e852dd1..92de255 100644
--- a/console.h
+++ b/console.h
@@ -140,6 +140,11 @@ void qemu_console_resize(QEMUConsole *console, int width, int height);
 /* sdl.c */
 void sdl_display_init(DisplayState *ds, int full_screen, int no_frame);
 
+/* gtk.c */
+void gtk_display_init(DisplayState *ds, int *argc, char ***argv);
+
+void gtk_display_main_loop(DisplayState *ds, int (*func)(void));
+
 /* cocoa.m */
 void cocoa_display_init(DisplayState *ds, int full_screen);
 
diff --git a/gdk_keysym.h b/gdk_keysym.h
new file mode 100644
index 0000000..2dce2ad
--- /dev/null
+++ b/gdk_keysym.h
@@ -0,0 +1,280 @@
+typedef struct {
+	const char* name;
+	int keysym;
+} name2keysym_t;
+static name2keysym_t name2keysym[]={
+/* ascii */
+    { "space",                GDK_space},
+    { "exclam",               GDK_exclam},
+    { "quotedbl",             GDK_quotedbl},
+    { "numbersign",           GDK_numbersign},
+    { "dollar",               GDK_dollar},
+    { "percent",              GDK_percent},
+    { "ampersand",            GDK_ampersand},
+    { "apostrophe",           GDK_apostrophe},
+    { "parenleft",            GDK_parenleft},
+    { "parenright",           GDK_parenright},
+    { "asterisk",             GDK_asterisk},
+    { "plus",                 GDK_plus},
+    { "comma",                GDK_comma},
+    { "minus",                GDK_minus},
+    { "period",               GDK_period},
+    { "slash",                GDK_slash},
+    { "0",                    GDK_0},
+    { "1",                    GDK_1},
+    { "2",                    GDK_2},
+    { "3",                    GDK_3},
+    { "4",                    GDK_4},
+    { "5",                    GDK_5},
+    { "6",                    GDK_6},
+    { "7",                    GDK_7},
+    { "8",                    GDK_8},
+    { "9",                    GDK_9},
+    { "colon",                GDK_colon},
+    { "semicolon",            GDK_semicolon},
+    { "less",                 GDK_less},
+    { "equal",                GDK_equal},
+    { "greater",              GDK_greater},
+    { "question",             GDK_question},
+    { "at",                   GDK_at},
+    { "A",                    GDK_A},
+    { "B",                    GDK_B},
+    { "C",                    GDK_C},
+    { "D",                    GDK_D},
+    { "E",                    GDK_E},
+    { "F",                    GDK_F},
+    { "G",                    GDK_G},
+    { "H",                    GDK_H},
+    { "I",                    GDK_I},
+    { "J",                    GDK_J},
+    { "K",                    GDK_K},
+    { "L",                    GDK_L},
+    { "M",                    GDK_M},
+    { "N",                    GDK_N},
+    { "O",                    GDK_O},
+    { "P",                    GDK_P},
+    { "Q",                    GDK_Q},
+    { "R",                    GDK_R},
+    { "S",                    GDK_S},
+    { "T",                    GDK_T},
+    { "U",                    GDK_U},
+    { "V",                    GDK_V},
+    { "W",                    GDK_W},
+    { "X",                    GDK_X},
+    { "Y",                    GDK_Y},
+    { "Z",                    GDK_Z},
+    { "bracketleft",          GDK_bracketleft},
+    { "backslash",            GDK_backslash},
+    { "bracketright",         GDK_bracketright},
+    { "asciicircum",          GDK_asciicircum},
+    { "underscore",           GDK_underscore},
+    { "grave",                GDK_grave},
+    { "a",                    GDK_a},
+    { "b",                    GDK_b},
+    { "c",                    GDK_c},
+    { "d",                    GDK_d},
+    { "e",                    GDK_e},
+    { "f",                    GDK_f},
+    { "g",                    GDK_g},
+    { "h",                    GDK_h},
+    { "i",                    GDK_i},
+    { "j",                    GDK_j},
+    { "k",                    GDK_k},
+    { "l",                    GDK_l},
+    { "m",                    GDK_m},
+    { "n",                    GDK_n},
+    { "o",                    GDK_o},
+    { "p",                    GDK_p},
+    { "q",                    GDK_q},
+    { "r",                    GDK_r},
+    { "s",                    GDK_s},
+    { "t",                    GDK_t},
+    { "u",                    GDK_u},
+    { "v",                    GDK_v},
+    { "w",                    GDK_w},
+    { "x",                    GDK_x},
+    { "y",                    GDK_y},
+    { "z",                    GDK_z},
+    { "braceleft",            GDK_braceleft},
+    { "bar",                  GDK_bar},
+    { "braceright",           GDK_braceright},
+    { "asciitilde",           GDK_asciitilde},
+
+/* latin 1 extensions */
+{ "nobreakspace",         GDK_nobreakspace},
+{ "exclamdown",           GDK_exclamdown},
+{ "cent",         	  GDK_cent},
+{ "sterling",             GDK_sterling},
+{ "currency",             GDK_currency},
+{ "yen",                  GDK_yen},
+{ "brokenbar",            GDK_brokenbar},
+{ "section",              GDK_section},
+{ "diaeresis",            GDK_diaeresis},
+{ "copyright",            GDK_copyright},
+{ "ordfeminine",          GDK_ordfeminine},
+{ "guillemotleft",        GDK_guillemotleft},
+{ "notsign",              GDK_notsign},
+{ "hyphen",               GDK_hyphen},
+{ "registered",           GDK_registered},
+{ "macron",               GDK_macron},
+{ "degree",               GDK_degree},
+{ "plusminus",            GDK_plusminus},
+{ "twosuperior",          GDK_twosuperior},
+{ "threesuperior",        GDK_threesuperior},
+{ "acute",                GDK_acute},
+{ "mu",                   GDK_mu},
+{ "paragraph",            GDK_paragraph},
+{ "periodcentered",       GDK_periodcentered},
+{ "cedilla",              GDK_cedilla},
+{ "onesuperior",          GDK_onesuperior},
+{ "masculine",            GDK_masculine},
+{ "guillemotright",       GDK_guillemotright},
+{ "onequarter",           GDK_onequarter},
+{ "onehalf",              GDK_onehalf},
+{ "threequarters",        GDK_threequarters},
+{ "questiondown",         GDK_questiondown},
+{ "Agrave",               GDK_Agrave},
+{ "Aacute",               GDK_Aacute},
+{ "Acircumflex",          GDK_Acircumflex},
+{ "Atilde",               GDK_Atilde},
+{ "Adiaeresis",           GDK_Adiaeresis},
+{ "Aring",                GDK_Aring},
+{ "AE",                   GDK_AE},
+{ "Ccedilla",             GDK_Ccedilla},
+{ "Egrave",               GDK_Egrave},
+{ "Eacute",               GDK_Eacute},
+{ "Ecircumflex",          GDK_Ecircumflex},
+{ "Ediaeresis",           GDK_Ediaeresis},
+{ "Igrave",               GDK_Igrave},
+{ "Iacute",               GDK_Iacute},
+{ "Icircumflex",          GDK_Icircumflex},
+{ "Idiaeresis",           GDK_Idiaeresis},
+{ "ETH",                  GDK_ETH},
+{ "Eth",                  GDK_Eth},
+{ "Ntilde",               GDK_Ntilde},
+{ "Ograve",               GDK_Ograve},
+{ "Oacute",               GDK_Oacute},
+{ "Ocircumflex",          GDK_Ocircumflex},
+{ "Otilde",               GDK_Otilde},
+{ "Odiaeresis",           GDK_Odiaeresis},
+{ "multiply",             GDK_multiply},
+{ "Ooblique",             GDK_Ooblique},
+{ "Oslash",               GDK_Oslash},
+{ "Ugrave",               GDK_Ugrave},
+{ "Uacute",               GDK_Uacute},
+{ "Ucircumflex",          GDK_Ucircumflex},
+{ "Udiaeresis",           GDK_Udiaeresis},
+{ "Yacute",               GDK_Yacute},
+{ "THORN",                GDK_THORN},
+{ "Thorn",                GDK_Thorn},
+{ "ssharp",               GDK_ssharp},
+{ "agrave",               GDK_agrave},
+{ "aacute",               GDK_aacute},
+{ "acircumflex",          GDK_acircumflex},
+{ "atilde",               GDK_atilde},
+{ "adiaeresis",           GDK_adiaeresis},
+{ "aring",                GDK_aring},
+{ "ae",                   GDK_ae},
+{ "ccedilla",             GDK_ccedilla},
+{ "egrave",               GDK_egrave},
+{ "eacute",               GDK_eacute},
+{ "ecircumflex",          GDK_ecircumflex},
+{ "ediaeresis",           GDK_ediaeresis},
+{ "igrave",               GDK_igrave},
+{ "iacute",               GDK_iacute},
+{ "icircumflex",          GDK_icircumflex},
+{ "idiaeresis",           GDK_idiaeresis},
+{ "eth",                  GDK_eth},
+{ "ntilde",               GDK_ntilde},
+{ "ograve",               GDK_ograve},
+{ "oacute",               GDK_oacute},
+{ "ocircumflex",          GDK_ocircumflex},
+{ "otilde",               GDK_otilde},
+{ "odiaeresis",           GDK_odiaeresis},
+{ "division",             GDK_division},
+{ "oslash",               GDK_oslash},
+{ "ooblique",             GDK_ooblique},
+{ "ugrave",               GDK_ugrave},
+{ "uacute",               GDK_uacute},
+{ "ucircumflex",          GDK_ucircumflex},
+{ "udiaeresis",           GDK_udiaeresis},
+{ "yacute",               GDK_yacute},
+{ "thorn",                GDK_thorn},
+{ "ydiaeresis",           GDK_ydiaeresis},
+{"EuroSign", GDK_EuroSign},
+
+    /* modifiers */
+{"Control_L", GDK_Control_L},
+{"Control_R", GDK_Control_R},
+{"Alt_L", GDK_Alt_L},
+{"Alt_R", GDK_Alt_R},
+{"Caps_Lock", GDK_Caps_Lock},
+{"Meta_L", GDK_Meta_L},
+{"Meta_R", GDK_Meta_R},
+{"Shift_L", GDK_Shift_L},
+{"Shift_R", GDK_Shift_R},
+{"Super_L", GDK_Super_L},
+{"Super_R", GDK_Super_R},
+
+    /* special keys */
+{"BackSpace", GDK_BackSpace},
+{"Tab", GDK_Tab},
+{"Return", GDK_Return},
+{"Right", GDK_Right},
+{"Left", GDK_Left},
+{"Up", GDK_Up},
+{"Down", GDK_Down},
+{"Page_Down", GDK_Page_Down},
+{"Page_Up", GDK_Page_Up},
+{"Insert", GDK_Insert},
+{"Delete", GDK_Delete},
+{"Home", GDK_Home},
+{"End", GDK_End},
+{"Scroll_Lock", GDK_Scroll_Lock},
+{"F1", GDK_F1},
+{"F2", GDK_F2},
+{"F3", GDK_F3},
+{"F4", GDK_F4},
+{"F5", GDK_F5},
+{"F6", GDK_F6},
+{"F7", GDK_F7},
+{"F8", GDK_F8},
+{"F9", GDK_F9},
+{"F10", GDK_F10},
+{"F11", GDK_F11},
+{"F12", GDK_F12},
+{"F13", GDK_F13},
+{"F14", GDK_F14},
+{"F15", GDK_F15},
+{"Sys_Req", GDK_Sys_Req},
+{"KP_0", GDK_KP_0},
+{"KP_1", GDK_KP_1},
+{"KP_2", GDK_KP_2},
+{"KP_3", GDK_KP_3},
+{"KP_4", GDK_KP_4},
+{"KP_5", GDK_KP_5},
+{"KP_6", GDK_KP_6},
+{"KP_7", GDK_KP_7},
+{"KP_8", GDK_KP_8},
+{"KP_9", GDK_KP_9},
+{"KP_Add", GDK_KP_Add},
+{"KP_Decimal", GDK_KP_Decimal},
+{"KP_Divide", GDK_KP_Divide},
+{"KP_Enter", GDK_KP_Enter},
+{"KP_Equal", GDK_KP_Equal},
+{"KP_Multiply", GDK_KP_Multiply},
+{"KP_Subtract", GDK_KP_Subtract},
+{"help", GDK_Help},
+{"Menu", GDK_Menu},
+#if 0
+{"Power", GDK_Power},
+#endif
+{"Print", GDK_Print},
+{"Mode_switch", GDK_Mode_switch},
+{"Multi_Key", GDK_Multi_key},
+{"Num_Lock", GDK_Num_Lock},
+{"Pause", GDK_Pause},
+{"Escape", GDK_Escape},
+
+{0,0},
+};
diff --git a/gtk.c b/gtk.c
new file mode 100644
index 0000000..9d45bef
--- /dev/null
+++ b/gtk.c
@@ -0,0 +1,356 @@
+/*
+ * GTK Front-end support for QEMU
+ *
+ * Copyright IBM, Corp. 2008
+ *
+ * Authors:
+ *  Anthony Liguori   <aliguori@us.ibm.com>
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ */
+
+#include "qemu-common.h"
+#include "console.h"
+#include "sysemu.h"
+
+#include <gtk/gtk.h>
+#include <gdk/gdkkeysyms.h>
+
+typedef struct GtkDisplayState
+{
+    DisplayState *ds;
+    GtkWidget *window;
+    GtkWidget *widget;
+    GdkImage *image;
+    GdkGC *gc;
+    gint mouse_x, mouse_y;
+    gint mouse_buttons;
+} GtkDisplayState;
+
+static void gtk_dpy_update(DisplayState *ds, int x, int y, int w, int h)
+{
+    GtkDisplayState *s = ds->opaque;
+
+    /* Queuing the drawing area will cause an expose event to occur which is
+     * where we really draw the screen */
+    gtk_widget_queue_draw_area(s->widget, x, y, w, h);
+}
+
+static void gtk_dpy_resize(DisplayState *ds, int w, int h)
+{
+    GtkDisplayState *s = ds->opaque;
+    GdkVisual *visual;
+
+    /* Free old buffer if we have to */
+    if (s->image) {
+        g_object_unref(s->image);
+        s->image = NULL;
+    }
+    ds->data = NULL;
+
+    /* Initialize new buffer */
+    ds->width = w;
+    ds->height = h;
+
+    /* FIXME valid all DisplayState assumptions */
+    visual = gtk_widget_get_visual(s->widget);
+    s->image = gdk_image_new(GDK_IMAGE_FASTEST, visual, ds->width, ds->height);
+    ds->depth = s->image->bpp * 8;
+    ds->linesize = s->image->bpl;
+    if (s->image->byte_order == GDK_MSB_FIRST)
+        ds->bgr = 1;
+    else
+        ds->bgr = 0;
+    ds->data = s->image->mem;
+
+    /* Set the size of the widget being used to display the VGA screen. */
+    gtk_widget_set_size_request(s->widget, ds->width, ds->height);
+}
+
+static void update_caption(GtkDisplayState *s)
+{
+    char buf[1024];
+    const char *status = "";
+
+    if (!vm_running)
+        status = " [Stopped]";
+#if 0
+    else if (gui_grab)
+        status = " - Press Ctrl-Alt to exit grab";
+#endif
+
+    if (qemu_name)
+        snprintf(buf, sizeof(buf), "QEMU (%s)%s", qemu_name, status);
+    else
+        snprintf(buf, sizeof(buf), "QEMU%s", status);
+
+    gtk_window_set_title(GTK_WINDOW(s->window), buf);
+}
+
+static void gtk_dpy_refresh(DisplayState *ds)
+{
+    GtkDisplayState *s = ds->opaque;
+    static int last_vm_running = -1;
+
+    if (last_vm_running != vm_running) {
+        last_vm_running = vm_running;
+        update_caption(s);
+    }
+
+    vga_hw_update();
+
+    while (gtk_events_pending()) {
+        if (gtk_main_iteration()) {
+            /* GTK main loop has been exited */
+            qemu_system_shutdown_request();
+            vm_start();
+            break;
+        }
+    }
+}
+
+static gboolean gtk_dpy_expose(GtkWidget *widget, GdkEventExpose *expose,
+                               gpointer opaque)
+{
+    GtkDisplayState *s = opaque;
+    gint x, y, w, h;
+
+    /* The widget may be exposed before we are ready to go.  Be defensive */
+    if (widget->window == NULL || s->image == NULL)
+        return FALSE;
+
+    /* Create a graphics context if we need to */
+    if (s->gc == NULL)
+        s->gc = gdk_gc_new(widget->window);
+
+    /* Clip expose area to DisplayState */
+    x = MIN(expose->area.x, s->ds->width);
+    y = MIN(expose->area.y, s->ds->height);
+    w = MIN(expose->area.x + expose->area.width, s->ds->width);
+    h = MIN(expose->area.y + expose->area.height, s->ds->height);
+    w -= x;
+    h -= y;
+
+    /* Draw screen */
+    gdk_draw_image(widget->window, s->gc, s->image, x, y, x, y, w, h);
+
+    return TRUE;
+}
+
+#include "gdk_keysym.h"
+#include "keymaps.c"
+
+static kbd_layout_t *kbd_layout;
+
+static uint8_t gtk_keyevent_to_keycode_generic(GdkEventKey *key)
+{
+    return keysym2scancode(kbd_layout, key->keyval);
+}
+
+static uint8_t gtk_keyevent_to_keycode(GdkEventKey *key)
+{
+    int keycode;
+
+    keycode = key->hardware_keycode;
+
+    if (keycode < 9) {
+        keycode = 0;
+    } else if (keycode < 97) {
+        keycode -= 8;
+    } else if (keycode < 212) {
+        keycode = _translate_keycode(keycode - 97);
+    } else {
+        keycode = 0;
+    }
+
+    return keycode;
+}
+
+static gboolean gtk_dpy_key(GtkWidget *widget, GdkEventKey *key,
+                            gpointer opaque)
+{
+    int keycode, v;
+
+    if (key->keyval == GDK_Pause) {
+        v = 0;
+        if (key->type == GDK_KEY_PRESS)
+            v |= 0x80;
+        kbd_put_keycode(0xe1);
+        kbd_put_keycode(0x1d | v);
+        kbd_put_keycode(0x45 | v);
+        return TRUE;
+    }
+
+    if (kbd_layout)
+        keycode = gtk_keyevent_to_keycode_generic(key);
+    else
+        keycode = gtk_keyevent_to_keycode(key);
+
+    if (keycode & 0x80)
+        kbd_put_keycode(0xe0);
+    if (key->type == GDK_KEY_RELEASE)
+        kbd_put_keycode(keycode | 0x80);
+    else
+        kbd_put_keycode(keycode & 0x7f);
+
+    return TRUE;
+}
+
+static gboolean gtk_dpy_motion(GtkWidget *widget, GdkEventMotion *motion,
+                               gpointer opaque)
+{
+    GtkDisplayState *s = opaque;
+    int dx, dy;
+
+    if (kbd_mouse_is_absolute()) {
+        dx = (gint)motion->x * 0x7FFF / (s->ds->width - 1);
+        dy = (gint)motion->y * 0x7FFF / (s->ds->height - 1);
+    } else {
+        dx = (gint)motion->x - s->mouse_x;
+        dy = (gint)motion->y - s->mouse_y;
+    }
+
+    s->mouse_x = (gint)motion->x;
+    s->mouse_y = (gint)motion->y;
+
+    kbd_mouse_event(dx, dy, 0, s->mouse_buttons);
+
+    return TRUE;
+}
+
+static gboolean gtk_dpy_button(GtkWidget *widget, GdkEventButton *button,
+                               gpointer opaque)
+{
+    GtkDisplayState *s = opaque;
+    gint mask;
+
+    mask = 0;
+    if (button->button == 1)
+        mask |= MOUSE_EVENT_LBUTTON;
+    else if (button->button == 2)
+        mask |= MOUSE_EVENT_MBUTTON;
+    else if (button->button == 3)
+        mask |= MOUSE_EVENT_RBUTTON;
+
+    /* make sure to ignore double and triple clicks */
+    if (button->type == GDK_BUTTON_PRESS)
+        s->mouse_buttons |= mask;
+    else if (button->type == GDK_BUTTON_RELEASE)
+        s->mouse_buttons &= ~mask;
+
+    if (kbd_mouse_is_absolute())
+        kbd_mouse_event(s->mouse_x, s->mouse_y, 0, s->mouse_buttons);
+    else
+        kbd_mouse_event(0, 0, 0, s->mouse_buttons);
+
+    return TRUE;
+}
+
+static gboolean gtk_dpy_scroll(GtkWidget *widget, GdkEventScroll *scroll,
+                               gpointer opaque)
+{
+    GtkDisplayState *s = opaque;
+    gint dz = 0;
+
+    if (scroll->direction == GDK_SCROLL_UP)
+        dz = -1;
+    else if (scroll->direction == GDK_SCROLL_DOWN)
+        dz = 1;
+
+    if (kbd_mouse_is_absolute())
+        kbd_mouse_event(s->mouse_x, s->mouse_y, dz, s->mouse_buttons);
+    else
+        kbd_mouse_event(0, 0, dz, s->mouse_buttons);
+
+    return TRUE;
+}
+
+void gtk_display_init(DisplayState *ds, int *argc, char ***argv)
+{
+    GtkDisplayState *s;
+
+    gtk_init(argc, argv);
+
+    if (keyboard_layout) {
+        kbd_layout = init_keyboard_layout(keyboard_layout);
+        if (!kbd_layout)
+            exit(1);
+    }
+
+    s = qemu_mallocz(sizeof(*s));
+    if (s == NULL) {
+        fprintf(stderr, "failed to allocate GtkDisplayState\n");
+        exit(1);
+    }
+
+    s->ds = ds;
+    s->widget = gtk_drawing_area_new();
+    s->window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
+    gtk_window_set_resizable(GTK_WINDOW(s->window), FALSE);
+    gtk_container_add(GTK_CONTAINER(s->window), s->widget);
+    gtk_widget_show_all(s->window);
+
+    gtk_signal_connect(GTK_OBJECT(s->widget), "key-press-event",
+                       GTK_SIGNAL_FUNC(gtk_dpy_key), s);
+    gtk_signal_connect(GTK_OBJECT(s->widget), "key-release-event",
+                       GTK_SIGNAL_FUNC(gtk_dpy_key), s);
+    gtk_signal_connect(GTK_OBJECT(s->widget), "motion-notify-event",
+                       GTK_SIGNAL_FUNC(gtk_dpy_motion), s);
+    gtk_signal_connect(GTK_OBJECT(s->widget), "button-press-event",
+                       GTK_SIGNAL_FUNC(gtk_dpy_button), s);
+    gtk_signal_connect(GTK_OBJECT(s->widget), "button-release-event",
+                       GTK_SIGNAL_FUNC(gtk_dpy_button), s);
+    gtk_signal_connect(GTK_OBJECT(s->widget), "scroll-event",
+                       GTK_SIGNAL_FUNC(gtk_dpy_scroll), s);
+    gtk_signal_connect(GTK_OBJECT(s->widget), "expose-event",
+                       GTK_SIGNAL_FUNC(gtk_dpy_expose), s);
+    gtk_signal_connect(GTK_OBJECT(s->window), "delete-event",
+                       GTK_SIGNAL_FUNC(gtk_main_quit), NULL);
+
+    GTK_WIDGET_SET_FLAGS(s->widget, GTK_CAN_FOCUS);
+
+    gtk_widget_add_events(s->widget,
+                          GDK_POINTER_MOTION_MASK |
+                          GDK_BUTTON_PRESS_MASK |
+                          GDK_BUTTON_RELEASE_MASK |
+                          GDK_BUTTON_MOTION_MASK |
+                          GDK_SCROLL_MASK |
+                          GDK_KEY_PRESS_MASK |
+                          GDK_KEY_RELEASE_MASK);
+
+    gtk_widget_set_double_buffered(s->widget, FALSE);
+    gtk_widget_grab_focus(s->widget);
+
+    ds->dpy_update = gtk_dpy_update;
+    ds->dpy_resize = gtk_dpy_resize;
+    ds->dpy_refresh = gtk_dpy_refresh;
+    ds->opaque = s;
+
+    gtk_dpy_resize(ds, 640, 480);
+    update_caption(s);
+}
+
+/* GTK has it's own main loop and while it provides a mechanism to
+ * asynchronously iterate the main loop, assumes that these methods are being
+ * called from something invoked by the main loop.  To work around this, we
+ * register an idle callback that runs the QEMU main loop, and then we use the
+ * asynchronous iteration functions from the refresh callback.  This makes GTK
+ * happy while allowing QEMU to control the main loop. */
+static gboolean run_main_loop(gpointer opaque)
+{
+    void (*func)(void);
+
+    func = opaque;
+    func();
+    return FALSE;
+}
+
+/* @func is the QEMU main loop.  We pass in as a function pointer to avoid
+ * exporting the function from vl.c */
+void gtk_display_main_loop(DisplayState *ds, int (*func)(void))
+{
+    g_idle_add(run_main_loop, func);
+    gtk_main();
+}
diff --git a/hw/ps2.c b/hw/ps2.c
index 054b92f..daccc93 100644
--- a/hw/ps2.c
+++ b/hw/ps2.c
@@ -284,6 +284,8 @@ static void ps2_mouse_send_packet(PS2MouseState *s)
     unsigned int b;
     int dx1, dy1, dz1;
 
+    printf("sending packet\n");
+
     dx1 = s->mouse_dx;
     dy1 = s->mouse_dy;
     dz1 = s->mouse_dz;
@@ -332,6 +334,8 @@ static void ps2_mouse_event(void *opaque,
 {
     PS2MouseState *s = opaque;
 
+    printf("status - %d\n", (s->mouse_status & MOUSE_STATUS_ENABLED));
+
     /* check if deltas are recorded when disabled */
     if (!(s->mouse_status & MOUSE_STATUS_ENABLED))
         return;
@@ -345,6 +349,9 @@ static void ps2_mouse_event(void *opaque,
 	return;
     s->mouse_buttons = buttons_state;
 
+    printf("remote: %d\n", !(s->mouse_status & MOUSE_STATUS_REMOTE));
+    printf("queue count %d\n", s->common.queue.count);
+
     if (!(s->mouse_status & MOUSE_STATUS_REMOTE) &&
         (s->common.queue.count < (PS2_QUEUE_SIZE - 16))) {
         for(;;) {
@@ -392,6 +399,7 @@ void ps2_write_mouse(void *opaque, int val)
             ps2_queue(&s->common, AUX_ACK);
             break;
         case AUX_SET_STREAM:
+            printf("stream\n");
             s->mouse_status &= ~MOUSE_STATUS_REMOTE;
             ps2_queue(&s->common, AUX_ACK);
             break;
@@ -400,6 +408,7 @@ void ps2_write_mouse(void *opaque, int val)
             ps2_queue(&s->common, AUX_ACK);
             break;
         case AUX_SET_REMOTE:
+            printf("remote\n");
             s->mouse_status |= MOUSE_STATUS_REMOTE;
             ps2_queue(&s->common, AUX_ACK);
             break;
diff --git a/vl.c b/vl.c
index 03cd386..0410bff 100644
--- a/vl.c
+++ b/vl.c
@@ -9012,7 +9012,9 @@ int main(int argc, char **argv)
     } else
 #endif
     {
-#if defined(CONFIG_SDL)
+#if defined(CONFIG_GTK)
+        gtk_display_init(ds, &argc, &argv);
+#elif defined(CONFIG_SDL)
         sdl_display_init(ds, full_screen, no_frame);
 #elif defined(CONFIG_COCOA)
         cocoa_display_init(ds, full_screen);
@@ -9146,7 +9148,11 @@ int main(int argc, char **argv)
 	close(fd);
     }
 
+#if defined(CONFIG_GTK)
+    gtk_display_main_loop(ds, main_loop);
+#else
     main_loop();
+#endif
     quit_timers();
 
 #if !defined(_WIN32)

Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[Stefano Stabellini]

Anthony Liguori wrote:

> Stefano Stabellini wrote:
>> This patch comes from xen-unstable and adds opengl support for rendering
>> the guest framebuffer in the SDL window.
>> SDL is needed anyway to open the window and handle the events.
>> Opengl rendering is optional and can be turned off at both compile time
>> and run time (--disable-opengl).
>> Some of the benefits of using opengl are:
>>
>> -faster rendering, less CPU intensive, especially with good graphic
>> cards;
>>   
> 
> Have you measured this or is this just intuition?  I've measured it with
> gtk-vnc and I did not observe any CPU usage decrease in using OpenGL for
> rendering verses an XShmImage.


I wrote that because before my patches all the colour conversions were
done in vga_template; after the sdl shared buffer patch the colour
conversions are done by SDL that sadly most of the time still implements
them using CPU based algorithms.
The opengl code should be able to offload all the colour conversions to
the GPU.
So I was referring to SDL vs. OpenGL.

Then there is the video memory versus system memory discussion: the
opengl patch loads the guest framebuffer into video memory then does the
conversion and blitting video->video that should be accelerated.
SDL_CreateRGBSurfaceFrom creates the surface in system memory so the
blitting shouldn't be accelerated.
I am saying should and shouldn't because it also depends on the video
card drivers and the opengl implementation.

Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[Jamie Lokier]

Stefano Stabellini wrote:
> Anthony Liguori wrote:
> 
> > Stefano Stabellini wrote:
> >> This patch comes from xen-unstable and adds opengl support for rendering
> >> the guest framebuffer in the SDL window.
> >> SDL is needed anyway to open the window and handle the events.
> >> Opengl rendering is optional and can be turned off at both compile time
> >> and run time (--disable-opengl).
> >> Some of the benefits of using opengl are:
> >>
> >> -faster rendering, less CPU intensive, especially with good graphic
> >> cards;
> >>   
> > 
> > Have you measured this or is this just intuition?  I've measured it with
> > gtk-vnc and I did not observe any CPU usage decrease in using OpenGL for
> > rendering verses an XShmImage.
> 
> 
> I wrote that because before my patches all the colour conversions were
> done in vga_template; after the sdl shared buffer patch the colour
> conversions are done by SDL that sadly most of the time still implements
> them using CPU based algorithms.
> The opengl code should be able to offload all the colour conversions to
> the GPU.
> So I was referring to SDL vs. OpenGL.

Fwiw, in my experience with Xine and mplayer, drawing video updates to
the screen using OpenGL was quite a lot slower than drawing them with
XShmImage.  That needs colour conversion as video doesn't even use RGB.

Probably OpenGL is faster on some hardware, and slower on some hardware.
Don't assume it's always faster.

> Then there is the video memory versus system memory discussion: the
> opengl patch loads the guest framebuffer into video memory then does the
> conversion and blitting video->video that should be accelerated.
> SDL_CreateRGBSurfaceFrom creates the surface in system memory so the
> blitting shouldn't be accelerated.
> I am saying should and shouldn't because it also depends on the video
> card drivers and the opengl implementation.

Yes it very much depends on the drivers and opengl implementation.  It
isn't always possible to map the guest framebuffer into video
(texture) memory, and also some opengl implementations are not
particularly fast at copying textures from CPU memory to texture memory.

Another way to map guest framebuffer to video memory is the XF86DGA
extension, which is great when you can use it.  I think VMware uses it
in full-screen mode.

-- Jamie

Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[Samuel Thibault]

Jamie Lokier, le Fri 05 Sep 2008 13:02:15 +0100, a écrit :
> Another way to map guest framebuffer to video memory is the XF86DGA
> extension, which is great when you can use it.

It is being deprecated and probably never works nowadays anyway :)

Samuel

Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[Jamie Lokier]

Samuel Thibault wrote:
> Jamie Lokier, le Fri 05 Sep 2008 13:02:15 +0100, a écrit :
> > Another way to map guest framebuffer to video memory is the XF86DGA
> > extension, which is great when you can use it.
> 
> It is being deprecated and probably never works nowadays anyway :)

That's a shame as the alternatives are all slower on old video cards.
Understandable, though.

-- Jamie

Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[Samuel Thibault]

Jamie Lokier, le Sun 07 Sep 2008 00:27:23 +0100, a écrit :
> Samuel Thibault wrote:
> > Jamie Lokier, le Fri 05 Sep 2008 13:02:15 +0100, a écrit :
> > > Another way to map guest framebuffer to video memory is the XF86DGA
> > > extension, which is great when you can use it.
> > 
> > It is being deprecated and probably never works nowadays anyway :)
> 
> That's a shame as the alternatives are all slower on old video cards.

Yes, and because alternatives don't provide so much performance.
Ideally, once switched to fullscreen you could just let the guest
directly write to the actual video memory (particularly interesting for
Xen and KVM).

Samuel

Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[Paul Brook]

On Sunday 07 September 2008, Samuel Thibault wrote:
> Jamie Lokier, le Sun 07 Sep 2008 00:27:23 +0100, a écrit :
> > Samuel Thibault wrote:
> > > Jamie Lokier, le Fri 05 Sep 2008 13:02:15 +0100, a écrit :
> > > > Another way to map guest framebuffer to video memory is the XF86DGA
> > > > extension, which is great when you can use it.
> > >
> > > It is being deprecated and probably never works nowadays anyway :)
> >
> > That's a shame as the alternatives are all slower on old video cards.
>
> Yes, and because alternatives don't provide so much performance.
> Ideally, once switched to fullscreen you could just let the guest
> directly write to the actual video memory (particularly interesting for
> Xen and KVM).

You really don't want to have the guest writing directly to host video ram. 
Video ram tends to be high-latency, so you want to write to regular memory, 
then use a wide block transfer or DMA to copy to video ram.

If you really need zero-copy then you should have the renderer read the data 
directly out of the guest framebuffer.

Paul

Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[Samuel Thibault]

Paul Brook, le Sun 07 Sep 2008 15:36:51 +0100, a écrit :
> > Ideally, once switched to fullscreen you could just let the guest
> > directly write to the actual video memory (particularly interesting for
> > Xen and KVM).
> 
> You really don't want to have the guest writing directly to host video ram. 
> Video ram tends to be high-latency, so you want to write to regular memory, 
> then use a wide block transfer or DMA to copy to video ram.

How often?  Which part(s) of the framebuffer?

> If you really need zero-copy then you should have the renderer read the data 
> directly out of the guest framebuffer.

Same questions.

Samuel

Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[Paul Brook]

On Sunday 07 September 2008, Samuel Thibault wrote:
> Paul Brook, le Sun 07 Sep 2008 15:36:51 +0100, a écrit :
> > > Ideally, once switched to fullscreen you could just let the guest
> > > directly write to the actual video memory (particularly interesting for
> > > Xen and KVM).
> >
> > You really don't want to have the guest writing directly to host video
> > ram. Video ram tends to be high-latency, so you want to write to regular
> > memory, then use a wide block transfer or DMA to copy to video ram.
>
> How often?  

You probably want to sync the updates to the vertical refresh. Updating more 
often than that is pointless.

> Which part(s) of the framebuffer? 

Whichever parts have changed.

Paul

Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[Samuel Thibault]

Paul Brook, le Sun 07 Sep 2008 16:03:30 +0100, a écrit :
> On Sunday 07 September 2008, Samuel Thibault wrote:
> > Paul Brook, le Sun 07 Sep 2008 15:36:51 +0100, a écrit :
> > > > Ideally, once switched to fullscreen you could just let the guest
> > > > directly write to the actual video memory (particularly interesting for
> > > > Xen and KVM).
> > >
> > > You really don't want to have the guest writing directly to host video
> > > ram. Video ram tends to be high-latency, so you want to write to regular
> > > memory, then use a wide block transfer or DMA to copy to video ram.
> >
> > How often?  
> 
> You probably want to sync the updates to the vertical refresh. Updating more 
> often than that is pointless.

Sure.

> > Which part(s) of the framebuffer? 
> 
> Whichever parts have changed.

Sure, how do you detect that?
The previous Xen memcmp method was eating 10% cpu for a 30Hz refresh,
just for the memcmp.  Now it uses the pagetable dirty bits and after
some idleness, trapping, but having the guest just write to actual
video memory (when it _has_ to be shown on the screen anyway) seems the
fastest way.

Samuel

Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[Paul Brook]

> > > Which part(s) of the framebuffer?
> >
> > Whichever parts have changed.
>
> Sure, how do you detect that?
> The previous Xen memcmp method was eating 10% cpu for a 30Hz refresh,
> just for the memcmp.  Now it uses the pagetable dirty bits and after
> some idleness, trapping, but having the guest just write to actual
> video memory (when it _has_ to be shown on the screen anyway) seems the
> fastest way.

Page granularity dirtyness is trivial. In fact qemu already does this. I'd be 
surprised if finer granularity gave any real benefit.

It also depends what testcase you're benchmarking. A few pixels changing every 
frame is IMHO not a particularly interesting case. The only time this really 
happens is mouse movement, and there are better ways of fixing that (proper 
hardware mouse cursors). The interesting cases are guest completely idle, and 
large screen updates.

Paul

Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[Samuel Thibault]

Paul Brook, le Sun 07 Sep 2008 16:35:54 +0100, a écrit :
> It also depends what testcase you're benchmarking. A few pixels changing every 
> frame is IMHO not a particularly interesting case.

But we shouldn't spend time on it.  For qemu it's trivial to get the
dirtyness of course. For Xen/KVM it's far less.

> The interesting cases are guest completely idle,

Which needs to be somehow detected.

> and large screen updates.

In that case, why blitting from main memory to video memory?  Sure video
memory is slow.  But the guest already does tricky stuff to cope with
that...

Samuel

Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[Paul Brook]

> > and large screen updates.
>
> In that case, why blitting from main memory to video memory?  Sure video
> memory is slow.  But the guest already does tricky stuff to cope with
> that...

I'd bet that tricky stuff doesn't work inside qemu.

Paul

Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[Anthony Liguori]

Samuel Thibault wrote:
> Paul Brook, le Sun 07 Sep 2008 16:35:54 +0100, a écrit :
>   
>> It also depends what testcase you're benchmarking. A few pixels changing every 
>> frame is IMHO not a particularly interesting case.
>>     
>
> But we shouldn't spend time on it.  For qemu it's trivial to get the
> dirtyness of course. For Xen/KVM it's far less.
>   

It's actually pretty simple with KVM.

FWIW, I don't see guests consume a tremendous amount of CPU when idle 
with KVM.  Can ya'll post some numbers with OpenGL and QEMU that show 
reduced CPU consumption?  I'm going to try out the patches myself but if 
you have a test case that is known to benefit, that would be helpful.

Regards,

Anthony Liguori

Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[Samuel Thibault]

Anthony Liguori, le Sun 07 Sep 2008 19:08:30 -0500, a écrit :
> Samuel Thibault wrote:
> >Paul Brook, le Sun 07 Sep 2008 16:35:54 +0100, a écrit :
> >>It also depends what testcase you're benchmarking. A few pixels changing 
> >>every frame is IMHO not a particularly interesting case.
> >
> >But we shouldn't spend time on it.  For qemu it's trivial to get the
> >dirtyness of course. For Xen/KVM it's far less.
> 
> It's actually pretty simple with KVM.

Well, you still have to ask the kernel for the dirty pages
(qemu_kvm_get_dirty_pages). Much less simple and efficient than just
reading from qemu's dirty array.

> FWIW, I don't see guests consume a tremendous amount of CPU when idle 
> with KVM.  Can ya'll post some numbers with OpenGL and QEMU that show 
> reduced CPU consumption?

I wasn't arguing for OpenGL, but for DGA (and thus have no numbers since
it doesn't work any more).

Samuel

Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[Jamie Lokier]

Paul Brook wrote:
> On Sunday 07 September 2008, Samuel Thibault wrote:
> > Jamie Lokier, le Sun 07 Sep 2008 00:27:23 +0100, a écrit :
> > > Samuel Thibault wrote:
> > > > Jamie Lokier, le Fri 05 Sep 2008 13:02:15 +0100, a écrit :
> > > > > Another way to map guest framebuffer to video memory is the XF86DGA
> > > > > extension, which is great when you can use it.
> > > >
> > > > It is being deprecated and probably never works nowadays anyway :)
> > >
> > > That's a shame as the alternatives are all slower on old video cards.
> >
> > Yes, and because alternatives don't provide so much performance.
> > Ideally, once switched to fullscreen you could just let the guest
> > directly write to the actual video memory (particularly interesting for
> > Xen and KVM).
> 
> You really don't want to have the guest writing directly to host video ram. 
> Video ram tends to be high-latency, so you want to write to regular memory, 
> then use a wide block transfer or DMA to copy to video ram.

Latency applies mainly when reading.

A good quality guest _expects_ that reading its video RAM will be
slow, and only writes to its video RAM, and possible by preparing images
off-screen then wide block transfers. :-)

> If you really need zero-copy then you should have the renderer read the data 
> directly out of the guest framebuffer.

That still forces one extra copy compared with XF86DGA.  "Renderer
reads the data directly out of the guest framebuffer" is the extra copy.

It's negligable on modern 3d cards, but slow on machines or those
where fast blitting or 3d isn't supported.

-- Jamie

Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[Stefano Stabellini]

Jamie Lokier wrote:

> Paul Brook wrote:
>> On Sunday 07 September 2008, Samuel Thibault wrote:
>>> Jamie Lokier, le Sun 07 Sep 2008 00:27:23 +0100, a écrit :
>>>> Samuel Thibault wrote:
>>>>> Jamie Lokier, le Fri 05 Sep 2008 13:02:15 +0100, a écrit :
>>>>>> Another way to map guest framebuffer to video memory is the XF86DGA
>>>>>> extension, which is great when you can use it.
>>>>> It is being deprecated and probably never works nowadays anyway :)
>>>> That's a shame as the alternatives are all slower on old video cards.
>>> Yes, and because alternatives don't provide so much performance.
>>> Ideally, once switched to fullscreen you could just let the guest
>>> directly write to the actual video memory (particularly interesting for
>>> Xen and KVM).
>> You really don't want to have the guest writing directly to host video ram. 
>> Video ram tends to be high-latency, so you want to write to regular memory, 
>> then use a wide block transfer or DMA to copy to video ram.
> 
> Latency applies mainly when reading.
> 
> A good quality guest _expects_ that reading its video RAM will be
> slow, and only writes to its video RAM, and possible by preparing images
> off-screen then wide block transfers. :-)

That is a really good point.
Usually the safe way to handle the video ram VS main memory problem is
to write to main memory then copy the whole buffer to video ram every so
often.
But in our case the guest thinks that he is writing to video ram
already, so in theory he is already using all precautions needed to
handle the latency problem.
It is actually probable that the guest is handling another buffer in his
own memory and syncing that one with what he thinks to be the video ram.

Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[Jamie Lokier]

Stefano Stabellini wrote:
> > A good quality guest _expects_ that reading its video RAM will be
> > slow, and only writes to its video RAM, and possible by preparing images
> > off-screen then wide block transfers. :-)
> 
> That is a really good point.
> Usually the safe way to handle the video ram VS main memory problem is
> to write to main memory then copy the whole buffer to video ram every so
> often.
> But in our case the guest thinks that he is writing to video ram
> already, so in theory he is already using all precautions needed to
> handle the latency problem.
> It is actually probable that the guest is handling another buffer in his
> own memory and syncing that one with what he thinks to be the video ram.

Yes, especially with any guest in the last 15 years :-), so I would
imagine that mapping to video RAM as directly as you can would give
the best results (e.g. using an OpenGL memory-mapped texture or X11
MIT-SHM image if they're possible to protect safely).  That's also
saving power, by the way, even if your machine is plenty fast enough
that extra full-screen image copies aren't humanly visible.

That said, numbers talk better than hand-waving.

-- Jamie

Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[Stefano Stabellini]

Jamie Lokier wrote:

> 
> Fwiw, in my experience with Xine and mplayer, drawing video updates to
> the screen using OpenGL was quite a lot slower than drawing them with
> XShmImage.  That needs colour conversion as video doesn't even use RGB.
> 
> Probably OpenGL is faster on some hardware, and slower on some hardware.
> Don't assume it's always faster.


Yes, good point.

 
> Yes it very much depends on the drivers and opengl implementation.  It
> isn't always possible to map the guest framebuffer into video
> (texture) memory, and also some opengl implementations are not
> particularly fast at copying textures from CPU memory to texture memory.


This is also true.

 
> Another way to map guest framebuffer to video memory is the XF86DGA
> extension, which is great when you can use it.  I think VMware uses it
> in full-screen mode.

I went with OpenGL because I wanted the accelerated window resize
feature, and because I think it will give us more opportunities for
further improvements (for example using PBOs as soon as they are
supported by at least one open source graphic card driver).

Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[Daniel P. Berrange]

On Fri, Sep 05, 2008 at 05:44:55PM +0100, Stefano Stabellini wrote:
> Jamie Lokier wrote:
> > Another way to map guest framebuffer to video memory is the XF86DGA
> > extension, which is great when you can use it.  I think VMware uses it
> > in full-screen mode.
> 
> I went with OpenGL because I wanted the accelerated window resize
> feature, and because I think it will give us more opportunities for
> further improvements (for example using PBOs as soon as they are
> supported by at least one open source graphic card driver).

The problem with OpenGL is that it has horrible rendering issues if you
are also using a compositing window manager like Compiz. You need an X
server & driver which supports Redirected Direct Rendering [1]. No distro 
currently has any official support for this yet. AFAIK, the next Fedora 10
will be the first to support it, and even then only on Intel hardware[2].
ATI is still a fair way off, and NVidia support is nowhere to be seen. For
accelerated resize of windows though you shouldn't need 3d - the graphics
driver 2-d hardware acceleration  support ought to be sufficient I'd
imagine

Regards,
Daniel

[1] http://hoegsberg.blogspot.com/2007/08/redirected-direct-rendering.html
[2] http://hoegsberg.blogspot.com/2008/03/i-just-committed-last-bit-of-dri2-work.html
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[Stefano Stabellini]

Daniel P. Berrange wrote:

> The problem with OpenGL is that it has horrible rendering issues if you
> are also using a compositing window manager like Compiz. You need an X
> server & driver which supports Redirected Direct Rendering [1]. No distro 
> currently has any official support for this yet. AFAIK, the next Fedora 10
> will be the first to support it, and even then only on Intel hardware[2].
> ATI is still a fair way off, and NVidia support is nowhere to be seen.


I don't think this should impact our choice, these are all issues that
will be solved sooner or later (hopefully sooner).

> For
> accelerated resize of windows though you shouldn't need 3d - the graphics
> driver 2-d hardware acceleration  support ought to be sufficient I'd
> imagine
> 

SDL doesn't offer this feature, and OpenGL is not just for 3D.

Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[Anthony Liguori]

Stefano Stabellini wrote:
> Daniel P. Berrange wrote:
>
>   
>> The problem with OpenGL is that it has horrible rendering issues if you
>> are also using a compositing window manager like Compiz. You need an X
>> server & driver which supports Redirected Direct Rendering [1]. No distro 
>> currently has any official support for this yet. AFAIK, the next Fedora 10
>> will be the first to support it, and even then only on Intel hardware[2].
>> ATI is still a fair way off, and NVidia support is nowhere to be seen.
>>     
>
>
> I don't think this should impact our choice, these are all issues that
> will be solved sooner or later (hopefully sooner).
>   

Practically speaking, it's a royal pain.  It means it has to be disabled 
by default.  What's most annoying is that Ubuntu enables compiz by 
default so there are a lot of users that will be affected.

There are a lot of outstanding SDL/VNC patches right now.  I'm going to 
spend time testing/applying them tomorrow.  OpenGL support is neat but 
I'm on the fence about whether it's the right thing to apply it.

I'd like to see if it really makes a difference performance wise to 
render with OpenGL.  I've had good results in the past using software 
bilinear interpolation to do scaling.  If OpenGL doesn't provide a 
measurable performance advantage, doing it in software may be the right 
thing to do.

Regards,

Anthony Liguori

>> For
>> accelerated resize of windows though you shouldn't need 3d - the graphics
>> driver 2-d hardware acceleration  support ought to be sufficient I'd
>> imagine
>>
>>     
>
> SDL doesn't offer this feature, and OpenGL is not just for 3D.
>
>
>   

Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[Stefano Stabellini]

Anthony Liguori wrote:

> I'd like to see if it really makes a difference performance wise to
> render with OpenGL.  I've had good results in the past using software
> bilinear interpolation to do scaling.  If OpenGL doesn't provide a
> measurable performance advantage, doing it in software may be the right
> thing to do.
> 

I'll do some tests and try to post some results soon.

Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[Jamie Lokier]

Anthony Liguori wrote:
> I'd like to see if it really makes a difference performance wise to 
> render with OpenGL.  I've had good results in the past using software 
> bilinear interpolation to do scaling.  If OpenGL doesn't provide a 
> measurable performance advantage, doing it in software may be the right 
> thing to do.

Software interpolation, especially bilinear or other filter, is
relatively slow if you're expanding a lot of pixels e.g. 640x384 to
1920x1200.  OpenGL will surely beat it.

On the other hand, OpenGL can to be relatively slow (in my experience)
if there is no colour conversion and scaling to do and X11-SHM would
be a straight 2d blit on the server side.

In principle OpenGL should as fast as the 2d blit or faster on
implementations where the image in client app's memory is a
memory-mapped texture, but that seems to be still a work in progress
on BSD and Linux.  DRI2 was dropped this summer because the TTM
texture memory manager was ousted in favour of the GEM texture memory
manager... and they haven't caught up with each other yet.  You need
some kind of good shared texture memory to get great speed out of
OpenGL displaying a texture which is being constantly updated by the
client app.

Imho, if there is an OpenGL backend (overlaid on SDL, Xlib, or
whatever), it should be a switch, for the next few years probably
defaulting to X11-SHM (or plain X11 when remote), and changing the
default to OpenGL in a few years when that's working really well
everywhere.

-- Jamie

Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[Stefano Stabellini]

Jamie Lokier wrote:

> Anthony Liguori wrote:
>> I'd like to see if it really makes a difference performance wise to 
>> render with OpenGL.  I've had good results in the past using software 
>> bilinear interpolation to do scaling.  If OpenGL doesn't provide a 
>> measurable performance advantage, doing it in software may be the right 
>> thing to do.
> 
> Software interpolation, especially bilinear or other filter, is
> relatively slow if you're expanding a lot of pixels e.g. 640x384 to
> 1920x1200.  OpenGL will surely beat it.
> 
> On the other hand, OpenGL can to be relatively slow (in my experience)
> if there is no colour conversion and scaling to do and X11-SHM would
> be a straight 2d blit on the server side.
> 
> In principle OpenGL should as fast as the 2d blit or faster on
> implementations where the image in client app's memory is a
> memory-mapped texture, but that seems to be still a work in progress
> on BSD and Linux.  DRI2 was dropped this summer because the TTM
> texture memory manager was ousted in favour of the GEM texture memory
> manager... and they haven't caught up with each other yet.  You need
> some kind of good shared texture memory to get great speed out of
> OpenGL displaying a texture which is being constantly updated by the
> client app.
> 
> Imho, if there is an OpenGL backend (overlaid on SDL, Xlib, or
> whatever), it should be a switch, for the next few years probably
> defaulting to X11-SHM (or plain X11 when remote), and changing the
> default to OpenGL in a few years when that's working really well
> everywhere.
> 

I agree with you on everything.

Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[Jamie Lokier]

Anthony Liguori wrote:
> Practically speaking, it's a royal pain.  It means it has to be disabled 
> by default.  What's most annoying is that Ubuntu enables compiz by 
> default so there are a lot of users that will be affected.

I'm under the impression that the Compiz problem in stable distros is
that OpenGL rendering isn't redirected by the compositor, so it
doesn't follow the transformed window in rotating-cube desktops, faded
or wobbly windows etc.  (Much like Xv for video players sits over
everything).

If that's all (not crashes etc.) that might be acceptable.

-- Jamie

Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[Daniel P. Berrange]

On Mon, Sep 08, 2008 at 02:41:40PM +0100, Jamie Lokier wrote:
> Anthony Liguori wrote:
> > Practically speaking, it's a royal pain.  It means it has to be disabled 
> > by default.  What's most annoying is that Ubuntu enables compiz by 
> > default so there are a lot of users that will be affected.
> 
> I'm under the impression that the Compiz problem in stable distros is
> that OpenGL rendering isn't redirected by the compositor, so it
> doesn't follow the transformed window in rotating-cube desktops, faded
> or wobbly windows etc.  (Much like Xv for video players sits over
> everything).

The rotating-cube issue is a one annoyance - the bigger problem is that
it'll render over the top of other windows, even when it doesn't have
input focus, and when you move the window, the area where it used to be
doesn't get refreshed. This makes overlapping window management pretty 
unusable :-(

  http://people.redhat.com/berrange/glxgears_compiz.png

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[Gerd Hoffmann]

Daniel P. Berrange wrote:
> The rotating-cube issue is a one annoyance - the bigger problem is that
> it'll render over the top of other windows, even when it doesn't have
> input focus, and when you move the window, the area where it used to be
> doesn't get refreshed. This makes overlapping window management pretty 
> unusable :-(

Oh, that reminds my of the horrible mess we had in the early tv card
days, when DMA'img the TV image directly to the visible frame buffer,
behind the X-Servers back.  Then try to track window clipping changes,
update the DMA instructions for the TV card (*after* the X-Server
changed the window stacking), then use dirty tricks to force the
X-Server refreshing the screen to remove tv image artefacts from the
window just raised.  Certainly nothing we should try again ...

Beside that I still think it would be a good idea to separate qemu and
the gui into two separate processes, so you can close the GUI window and
keep the VM running.  It also solves the dependency issue for distros as
the gtk frontend with all the dependencies can just go into a separate
sub-package.

cheers,
  Gerd

Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[Jamie Lokier]

Gerd Hoffmann wrote:
> Beside that I still think it would be a good idea to separate qemu and
> the gui into two separate processes, so you can close the GUI window and
> keep the VM running.  It also solves the dependency issue for distros as
> the gtk frontend with all the dependencies can just go into a separate
> sub-package.

Extending VNC with a "shared memory" extension, similar to Xlib's
MIT-SHM extension, and implementing it in QEMU and Gtk-VNC would be a
nice way to do this.

Right now VNC works very well except for the overhead of sending the
image over a socket :-)

The Gtk-VNC widget (currently used by the Vinagre application)
accelerated in that way would work nicely inside a Gtk GUI providing
buttons etc. for controlling QEMU.

-- Jamie

Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[Gerd Hoffmann]

Jamie Lokier wrote:
> Gerd Hoffmann wrote:
>> Beside that I still think it would be a good idea to separate qemu and
>> the gui into two separate processes, so you can close the GUI window and
>> keep the VM running.  It also solves the dependency issue for distros as
>> the gtk frontend with all the dependencies can just go into a separate
>> sub-package.
> 
> Extending VNC with a "shared memory" extension, similar to Xlib's
> MIT-SHM extension, and implementing it in QEMU and Gtk-VNC would be a
> nice way to do this.

Or use the monitor, which the gui needs anyway to implement the nice
control buttons for the user.  Which would it make easier to re-attach
the gui to the vm as all you need to know is where the monitor is ...

cheers,
  Gerd

Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[Jamie Lokier]

Gerd Hoffmann wrote:
> Jamie Lokier wrote:
> > Gerd Hoffmann wrote:
> >> Beside that I still think it would be a good idea to separate qemu and
> >> the gui into two separate processes, so you can close the GUI window and
> >> keep the VM running.  It also solves the dependency issue for distros as
> >> the gtk frontend with all the dependencies can just go into a separate
> >> sub-package.
> > 
> > Extending VNC with a "shared memory" extension, similar to Xlib's
> > MIT-SHM extension, and implementing it in QEMU and Gtk-VNC would be a
> > nice way to do this.
> 
> Or use the monitor, which the gui needs anyway to implement the nice
> control buttons for the user.  Which would it make easier to re-attach
> the gui to the vm as all you need to know is where the monitor is ...

You want to transmit the image or the image-blit-please protocol over
the monitor connection?  I think the monitor would need a few
improvements before it could do that well.

A nice thing about VNC-SHM would be the GUI could run on a different
machine to the emulator (SHM not used then), since it only needs VNC
and monitor, which can both be remote.

-- Jamie

Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[Gerd Hoffmann]

Jamie Lokier wrote:
> Gerd Hoffmann wrote:
>> Or use the monitor, which the gui needs anyway to implement the nice
>> control buttons for the user.  Which would it make easier to re-attach
>> the gui to the vm as all you need to know is where the monitor is ...
> 
> You want to transmit the image or the image-blit-please protocol over
> the monitor connection?

Negotiate a shared memory segment somehow, then send just notifications.
Have to think about how to to that in detail, ideally this would be a
shared memory segment shared by all three instances involved: the gui
process, the qemu process and the X-Server.  So qemu can render directly
into a XShmImage, although it has no (direct) connection to the X-Server.

> I think the monitor would need a few
> improvements before it could do that well.

Sure, we'll need (a) multiple connections at the same time and (b) some
"select <eventtype>" command for async notify for that.  I think they
will come anyway for several other reasons.

> A nice thing about VNC-SHM would be the GUI could run on a different
> machine to the emulator (SHM not used then), since it only needs VNC
> and monitor, which can both be remote.

For the remote case it certainly doesn't make sense to reinvent VNC.
But you'll probably use some management layer like libvirt anyway then,
ssh'ing into the remote machine for starting / stopping VM's isn't very
handy.

I'm targeting the local desktop use case.  But maybe vnc +
shmem-extention works equally well here.

cheers,
  Gerd

Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[Anthony Liguori]

Gerd Hoffmann wrote:
> Jamie Lokier wrote:
>   
>> Gerd Hoffmann wrote:
>>     
>>> Or use the monitor, which the gui needs anyway to implement the nice
>>> control buttons for the user.  Which would it make easier to re-attach
>>> the gui to the vm as all you need to know is where the monitor is ...
>>>       
>> You want to transmit the image or the image-blit-please protocol over
>> the monitor connection?
>>     
>
> Negotiate a shared memory segment somehow, then send just notifications.
> Have to think about how to to that in detail, ideally this would be a
> shared memory segment shared by all three instances involved: the gui
> process, the qemu process and the X-Server.  So qemu can render directly
> into a XShmImage, although it has no (direct) connection to the X-Server.
>   

This is exactly how my VNC Shm patches worked.  The protocol extension 
is generic but it happens to work very well with an XShmImage.

If someone wants to resurrect these patches, they can find them on 
gtk-vnc-devel (probably).  Otherwise, I'll queue them up for when I have 
some free time.  Now with Dan's cairo patches, the impact to gtk-vnc 
should be minimal.

Regards,

Anthony Liguori

Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[Gerd Hoffmann]

Anthony Liguori wrote:
> Gerd Hoffmann wrote:
>> Negotiate a shared memory segment somehow, then send just notifications.
>> Have to think about how to to that in detail, ideally this would be a
>> shared memory segment shared by all three instances involved: the gui
>> process, the qemu process and the X-Server.  So qemu can render directly
>> into a XShmImage, although it has no (direct) connection to the X-Server.
> 
> This is exactly how my VNC Shm patches worked.  The protocol extension
> is generic but it happens to work very well with an XShmImage.

Oh, great.  Lets dig out and polish the patches then.

cheers,
  Gerd

Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[Jamie Lokier]

Gerd Hoffmann wrote:
> > A nice thing about VNC-SHM would be the GUI could run on a different
> > machine to the emulator (SHM not used then), since it only needs VNC
> > and monitor, which can both be remote.
> 
> For the remote case it certainly doesn't make sense to reinvent VNC.

It doesn't make sense to use a completely different protocol in _every
way_ for the local case than the remote case, does it?

> But you'll probably use some management layer like libvirt anyway then,

Nope.

> ssh'ing into the remote machine for starting / stopping VM's isn't very
> handy.

I disagree: it's exactly the same as the local case in every respect,
except you put the words "ssh host" before the qemu/kvm command you
would have run locally.

This holds even for a hypothetical GUI app running locally which wraps
a VNC widget and has some QEMU control buttons.  It just needs to know
the qemu/kvm command it runs starts with "ssh host ...".

If there was a GUI app which runs well locally - why would you want to
use something completely different to control a VM which happens to
run on another machine?  That would be a really annoying and
artificial distinction.  The same GUI controls are useful in either case.

> I'm targeting the local desktop use case.  But maybe vnc +
> shmem-extention works equally well here.

It's worth a try.

Personally I run a few local kvms and a few remote kvms and I can
hardly tell the difference.  Either way I run a kvm command, then a
VNC client.  (I stopped using SDL after accidentally killing VMs by
clicking on the close button too many times.)

-- Jamie

Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[Daniel P. Berrange]

On Mon, Sep 08, 2008 at 04:08:01PM +0100, Jamie Lokier wrote:
> Gerd Hoffmann wrote:
> > Beside that I still think it would be a good idea to separate qemu and
> > the gui into two separate processes, so you can close the GUI window and
> > keep the VM running.  It also solves the dependency issue for distros as
> > the gtk frontend with all the dependencies can just go into a separate
> > sub-package.
> 
> Extending VNC with a "shared memory" extension, similar to Xlib's
> MIT-SHM extension, and implementing it in QEMU and Gtk-VNC would be a
> nice way to do this.

Funny you should mention that. Anthony had code todo exactly that against
for both QEMU and GTK-VNC a while back. We had it in the GTK-VNC for a 
short while but removed it due to some race conditions in its impl, and
it interracted badly with our OpenGL impl. We could easily revisit this
idea if it were thought to be important / useful.

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[Anthony Liguori]

Daniel P. Berrange wrote:
> On Mon, Sep 08, 2008 at 04:08:01PM +0100, Jamie Lokier wrote:
>   
>> Gerd Hoffmann wrote:
>>     
>>> Beside that I still think it would be a good idea to separate qemu and
>>> the gui into two separate processes, so you can close the GUI window and
>>> keep the VM running.  It also solves the dependency issue for distros as
>>> the gtk frontend with all the dependencies can just go into a separate
>>> sub-package.
>>>       
>> Extending VNC with a "shared memory" extension, similar to Xlib's
>> MIT-SHM extension, and implementing it in QEMU and Gtk-VNC would be a
>> nice way to do this.
>>     
>
> Funny you should mention that. Anthony had code todo exactly that against
> for both QEMU and GTK-VNC a while back. We had it in the GTK-VNC for a 
> short while but removed it due to some race conditions in its impl, and
> it interracted badly with our OpenGL impl. We could easily revisit this
> idea if it were thought to be important / useful.
>   

The difficulty is deleting the shared memory segment reliably.

Normally, what you want to do is:

shmget()
shmat()
shmctl(IPC_RMID)

...

shmdt()

And the first sequence has to be as reliable and quick as possible 
because if you exit before the shmctl(), you'll leak the shared memory.

Unfortunately, you have to shmget() in the client and shmat() in the 
server and client, so that means:

shmget()
shmat()

...

notify server of key
wait for server to confirm shmat()

...

shmctl(IPC_RMID)

..

shmdt()

Which leaves a huge window open where bad things can happen.  The client 
can exit, the client can crash.  This is particularly troublesome in a 
library because it's really not nice to try and register an atexit() 
handler or something like that from a library.

It would be nice to come up with a solution to this.

Regards,

Anthony Liguori

> Daniel
>   

Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[Mike Kronenberg]

Hi,

Some OS (especially *nix) versions have pretty small size restrictions  
on shmem.
OS X for instance has a restriction of total 4mb for all processes.

I first ran into this limits with an early server/viewer patch  
submitted to this list using terminal/shmem. (Was it submitted by  
Anthony? The Idea was dropped in favor of VNC later.)

Then some months ago, after the last cocoa OpenGL patch, I started a  
new OpenGL version of Q, with qemu as a separate server and Q as a  
viewer app.
The Idea was to have a lean qemu server process running and then  
attach a viewer/controller to it and have fast/resizable/fullscreen  
video opposed to the vnc solution.
They share the video-buffer with mmap instead of shmem. I've got some  
notes on the experiment and shmem size limitation on this blogentry http://mike.kronenberg.org/?p=40

For the OpenGL implementation, look at cocoa.m... I think my last  
patch was never applied... but the OpenGL code should work correctly.

Just some thoughts.

Mike Kronenberg



On 08.09.2008, at 18:05, Anthony Liguori wrote:

> Daniel P. Berrange wrote:
>> On Mon, Sep 08, 2008 at 04:08:01PM +0100, Jamie Lokier wrote:
>>
>>> Gerd Hoffmann wrote:
>>>
>>>> Beside that I still think it would be a good idea to separate  
>>>> qemu and
>>>> the gui into two separate processes, so you can close the GUI  
>>>> window and
>>>> keep the VM running.  It also solves the dependency issue for  
>>>> distros as
>>>> the gtk frontend with all the dependencies can just go into a  
>>>> separate
>>>> sub-package.
>>>>
>>> Extending VNC with a "shared memory" extension, similar to Xlib's
>>> MIT-SHM extension, and implementing it in QEMU and Gtk-VNC would  
>>> be a
>>> nice way to do this.
>>>
>>
>> Funny you should mention that. Anthony had code todo exactly that  
>> against
>> for both QEMU and GTK-VNC a while back. We had it in the GTK-VNC  
>> for a short while but removed it due to some race conditions in its  
>> impl, and
>> it interracted badly with our OpenGL impl. We could easily revisit  
>> this
>> idea if it were thought to be important / useful.
>>
>
> The difficulty is deleting the shared memory segment reliably.
>
> Normally, what you want to do is:
>
> shmget()
> shmat()
> shmctl(IPC_RMID)
>
> ...
>
> shmdt()
>
> And the first sequence has to be as reliable and quick as possible  
> because if you exit before the shmctl(), you'll leak the shared  
> memory.
>
> Unfortunately, you have to shmget() in the client and shmat() in the  
> server and client, so that means:
>
> shmget()
> shmat()
>
> ...
>
> notify server of key
> wait for server to confirm shmat()
>
> ...
>
> shmctl(IPC_RMID)
>
> ..
>
> shmdt()
>
> Which leaves a huge window open where bad things can happen.  The  
> client can exit, the client can crash.  This is particularly  
> troublesome in a library because it's really not nice to try and  
> register an atexit() handler or something like that from a library.
>
> It would be nice to come up with a solution to this.
>
> Regards,
>
> Anthony Liguori
>
>> Daniel
>>
>
>
>

Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[Gerd Hoffmann]

Mike Kronenberg wrote:
> Hi,
> 
> Some OS (especially *nix) versions have pretty small size restrictions
> on shmem.
> OS X for instance has a restriction of total 4mb for all processes.

I bet that can be configured somewhere.

Linux had that too long ago (2.2.x or so?), and there was a knob to tune
that limit.

But even shmem allocation failing shouldn't be a fundamental problem,
vnc can just fallback to non-shm mode then.

cheers,
  Gerd

Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[Mike Kronenberg]

On 08.09.2008, at 21:21, Gerd Hoffmann wrote:

> Mike Kronenberg wrote:
>> Hi,
>>
>> Some OS (especially *nix) versions have pretty small size  
>> restrictions
>> on shmem.
>> OS X for instance has a restriction of total 4mb for all processes.
>
> I bet that can be configured somewhere.
>
> Linux had that too long ago (2.2.x or so?), and there was a knob to  
> tune
> that limit.
>
> But even shmem allocation failing shouldn't be a fundamental problem,
> vnc can just fallback to non-shm mode then.
>
> cheers,
>  Gerd
>
>

Tuning is no problem, it just needs root access to change it and a  
reboot.
But i don't like the thought of programs manipulating my system  
defaults :)

cheers
Mike

Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[Jamie Lokier]

Anthony Liguori wrote:
> The difficulty is deleting the shared memory segment reliably.
> 
> Normally, what you want to do is:
> 
> shmget()
> shmat()
> shmctl(IPC_RMID)
> 
> ...
> 
> shmdt()
> 
> And the first sequence has to be as reliable and quick as possible 
> because if you exit before the shmctl(), you'll leak the shared memory.

Yes, it's ugly, but it's the same problem faced by Gtk apps etc. which
are writing images - doesn't even SDL have this problem?

The nearest thing to "right" I found in X11-SHM apps is:

   - Catch many signals and shmctl(SHM_RMID) in the handler before
     re-raising the signal to kill the program.
   - Try to recognise old, stale shm segments when starting anew
     and remove them.  This can be done by putting a signature into
     them somewhere which won't be overridden in use.

(There is also some trickiness in ensuring that the connection really
is local, and you're not doing a remote connection which just happens
to successfully attach to a SHM segment on a different machine with
the same id.  With SSH X11 forwarding and other ways X11 is proxied, I
found the only way to be sure is create a segment, write strong random
values to it, ask the X server to read from it and return the pixel
values over the normal connection, and verify if they match.)

But that's X11-SHM.  For a new protocol, you can do this:

   - fd = shm_open()
   - shm_unlink()
   - pass file descriptor over the connection.

Or even this:

   - fd = open("/tmp/XXX")
   - unlink()
   - pass file descriptor over the connection.

Both ends call mmap().

It's not perfect (there really should be a create-shmem-with-no-name
syscall), but the window for leaks is quite small, and it's fine to
use in a library.

-- Jamie

Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[Jamie Lokier]

Anthony Liguori wrote:
> shmget()
> shmat()
> 
> ...
> 
> notify server of key
> wait for server to confirm shmat()
> 
> ...
> 
> shmctl(IPC_RMID)
> 
> ..
> 
> shmdt()
> 
> Which leaves a huge window open where bad things can happen.  The client 
> can exit, the client can crash.  This is particularly troublesome in a 
> library because it's really not nice to try and register an atexit() 
> handler or something like that from a library.

Another way to do it, which ought to be quite reliable, is to fork()
(and maybe exec) a child helper process which calls shmget() then
prints out the ID, for the parent to read, then waits on its input.
There is also a pipe from parent to child.  If the parent closes the
pipe to child or dies, the child kills the shm ID immediately.  This
catches all kinds of parent crashing and deliberate kills, and you can
still close the pipe as soon as the parent confirms everyone is
attached to the segment.

What do Gtk and/or Qt and/or Gecko do?  They're likely to have thought
about it.

-- Jamie

Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[Anthony Liguori]

Jamie Lokier wrote:
> Anthony Liguori wrote:
>   
>> shmget()
>> shmat()
>>
>> ...
>>
>> notify server of key
>> wait for server to confirm shmat()
>>
>> ...
>>
>> shmctl(IPC_RMID)
>>
>> ..
>>
>> shmdt()
>>
>> Which leaves a huge window open where bad things can happen.  The client 
>> can exit, the client can crash.  This is particularly troublesome in a 
>> library because it's really not nice to try and register an atexit() 
>> handler or something like that from a library.
>>     
>
> Another way to do it, which ought to be quite reliable, is to fork()
> (and maybe exec) a child helper process which calls shmget() then
> prints out the ID, for the parent to read, then waits on its input.
> There is also a pipe from parent to child.  If the parent closes the
> pipe to child or dies, the child kills the shm ID immediately.  This
> catches all kinds of parent crashing and deliberate kills, and you can
> still close the pipe as soon as the parent confirms everyone is
> attached to the segment.
>   

But you still leak if both processes are killed at once (think killall 
qemu-system-x86_64).  An exec would be a little safer but it's pretty 
hideous.

> What do Gtk and/or Qt and/or Gecko do?  They're likely to have thought
> about it.
>   

It's not a problem for Gtk because the window of possibly leaking is so 
short.  It creates the shmid, send it to the x server, shmat, then 
shmctl.  The key point is that it interacts with the X server 
synchronously so not much bad can happen while it's talking to the X server.

It's probably not a huge problem in practice, but I've never liked 
this.  Sys V shared memory is really just crappy.

Regards,

Anthony Liguori

> -- Jamie
>   

Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[Jamie Lokier]

Anthony Liguori wrote:
> But you still leak if both processes are killed at once (think killall 
> qemu-system-x86_64).  An exec would be a little safer but it's pretty 
> hideous.

I agree it's not pretty.

> 
> >What do Gtk and/or Qt and/or Gecko do?  They're likely to have thought
> >about it.
> >  
> 
> It's not a problem for Gtk because the window of possibly leaking is so 
> short.  It creates the shmid, send it to the x server, shmat, then 
> shmctl.  The key point is that it interacts with the X server 
> synchronously so not much bad can happen while it's talking to the X server.

Gtk is a library too.  Sure, it's usually used synchronously, but
other user threads can terminate the program while Gtk is doing its
stuff.  Not _that_ different from providing an async VNC client
library with an API function "vnc_cleanup - call this if your program
terminates and you might not have closed all VNC connections".  User
program can call atexit() themselves, or g_atexit() if it's a Gtk
program.  That's reasonably conventional.

> It's probably not a huge problem in practice, but I've never liked 
> this.  Sys V shared memory is really just crappy.

Yes, and POSIX shm seems to perpetuate the silliness, though a bit
more flexible in what you can put into an ID.

-- Jamie

Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[Daniel P. Berrange]

On Mon, Sep 08, 2008 at 04:47:00PM +0100, Daniel P. Berrange wrote:
> On Mon, Sep 08, 2008 at 04:08:01PM +0100, Jamie Lokier wrote:
> > Gerd Hoffmann wrote:
> > > Beside that I still think it would be a good idea to separate qemu and
> > > the gui into two separate processes, so you can close the GUI window and
> > > keep the VM running.  It also solves the dependency issue for distros as
> > > the gtk frontend with all the dependencies can just go into a separate
> > > sub-package.
> > 
> > Extending VNC with a "shared memory" extension, similar to Xlib's
> > MIT-SHM extension, and implementing it in QEMU and Gtk-VNC would be a
> > nice way to do this.
> 
> Funny you should mention that. Anthony had code todo exactly that against
> for both QEMU and GTK-VNC a while back. We had it in the GTK-VNC for a 
> short while but removed it due to some race conditions in its impl, and
> it interracted badly with our OpenGL impl. We could easily revisit this
> idea if it were thought to be important / useful.

Just thought I'd mention one other thing - it is not actually clearcut / or
guarenteed that XShm + VNC would improve performance in all circumstances.
This is because X pixmaps created via XShm apparently cannot live in video
memory, and thus it is not so easy to get full performance advantage of
hardware acceleration - this could impact scaling for example. The need to
perform XSync operations when updating the pixmaps may also negate the
benefit of avoiding the socket I/O. It would all depend on the size of the
updates vs frequency of them. Still defintely worth a try to see what kind
of difference Shm makes in a real world scenario with QEMU.

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[Jamie Lokier]

Daniel P. Berrange wrote:
> Just thought I'd mention one other thing - it is not actually clearcut / or
> guarenteed that XShm + VNC would improve performance in all circumstances.
> This is because X pixmaps created via XShm apparently cannot live in video
> memory, and thus it is not so easy to get full performance advantage of
> hardware acceleration - this could impact scaling for example.

I haven't seen any scaling with VNC so far, but it would be nice sometimes.

How does sending the image over the wire then asking the server to
scale it using RENDER improve on sending it over XShm then asking the
server to xscale the pixel using RENDER?  Or is there something else
you can do when you don't use XShm?

> The need to
> perform XSync operations when updating the pixmaps may also negate the
> benefit of avoiding the socket I/O.

You don't have to do XSync, if you don't mind a bit of tearing which
you're probably going to get anyway, or if you do some fancy locking
until you receive XShmCompletionEvent asynchronously and the blit is
fast.  Or you can double-buffer or triple-buffer with multiple XShm
pixmaps; I don't know how that compares with sending the image over
the socket.  Or you can do both: switch to a new buffer only when the
guest writes to video memory before receiving XShmCopmletionEvent,
otherwise stay with the old buffer.

-- Jamie

Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[Anthony Liguori]

Jamie Lokier wrote:
> Daniel P. Berrange wrote:
>   
>> Just thought I'd mention one other thing - it is not actually clearcut / or
>> guarenteed that XShm + VNC would improve performance in all circumstances.
>> This is because X pixmaps created via XShm apparently cannot live in video
>> memory, and thus it is not so easy to get full performance advantage of
>> hardware acceleration - this could impact scaling for example.
>>     
>
> I haven't seen any scaling with VNC so far, but it would be nice sometimes.
>   

It's been supported in gtk-vnc for a while now.

> How does sending the image over the wire then asking the server to
> scale it using RENDER improve on sending it over XShm then asking the
> server to xscale the pixel using RENDER?  Or is there something else
> you can do when you don't use XShm?
>   

The key point being you can avoid a copy even when using a shared memory 
extension because you don't necessarily have to back the shared memory 
with an XShmImage.  Even if you have to copy from shared memory to a 
hardware framebuffer, you avoid copying the data to the kernel socket 
buffer.

But copying data isn't super expensive assuming you're hitting the cpu 
cache (which you probably are). So I don't know how much it saves in 
real life.

Regards,

Anthony Liguori

Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[Jamie Lokier]

Anthony Liguori wrote:
> But copying data isn't super expensive assuming you're hitting the cpu 
> cache (which you probably are). So I don't know how much it saves in 
> real life.

Indeed.  Framebuffers are sometimes a bit big to fit in the CPU cache,
if the whole picture is being updated.  But I see what you mean when
there's a partial update.

-- Jamie

Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[Anthony Liguori]

Jamie Lokier wrote:
> Anthony Liguori wrote:
>   
>> Practically speaking, it's a royal pain.  It means it has to be disabled 
>> by default.  What's most annoying is that Ubuntu enables compiz by 
>> default so there are a lot of users that will be affected.
>>     
>
> I'm under the impression that the Compiz problem in stable distros is
> that OpenGL rendering isn't redirected by the compositor, so it
> doesn't follow the transformed window in rotating-cube desktops, faded
> or wobbly windows etc.  (Much like Xv for video players sits over
> everything).
>   

No, the window overlays get all messed up and the screen quickly becomes 
garbage.  Even in the absence of all of the desktop effects.

Regards,

Anthony Liguori

> If that's all (not crashes etc.) that might be acceptable.
>
> -- Jamie
>
>
>   

Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[Avi Kivity]

Daniel P. Berrange wrote:
> On Fri, Sep 05, 2008 at 05:44:55PM +0100, Stefano Stabellini wrote:
>   
>> Jamie Lokier wrote:
>>     
>>> Another way to map guest framebuffer to video memory is the XF86DGA
>>> extension, which is great when you can use it.  I think VMware uses it
>>> in full-screen mode.
>>>       
>> I went with OpenGL because I wanted the accelerated window resize
>> feature, and because I think it will give us more opportunities for
>> further improvements (for example using PBOs as soon as they are
>> supported by at least one open source graphic card driver).
>>     
>
> The problem with OpenGL is that it has horrible rendering issues if you
> are also using a compositing window manager like Compiz. 

I would say that this is a compiz problem.

> You need an X
> server & driver which supports Redirected Direct Rendering [1]. No distro 
> currently has any official support for this yet. 

Or a distro problem.

> AFAIK, the next Fedora 10
> will be the first to support it, and even then only on Intel hardware[2].
> ATI is still a fair way off, and NVidia support is nowhere to be seen. For
> accelerated resize of windows though you shouldn't need 3d - the graphics
> driver 2-d hardware acceleration  support ought to be sufficient I'd
> imagine
>   

I don't see how distros can enable compiz if it breaks opengl 
applications like this.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[Daniel P. Berrange]

On Sun, Sep 07, 2008 at 10:48:39AM +0300, Avi Kivity wrote:
> Daniel P. Berrange wrote:
> >On Fri, Sep 05, 2008 at 05:44:55PM +0100, Stefano Stabellini wrote:
> >  
> >>Jamie Lokier wrote:
> >>    
> >>>Another way to map guest framebuffer to video memory is the XF86DGA
> >>>extension, which is great when you can use it.  I think VMware uses it
> >>>in full-screen mode.
> >>>      
> >>I went with OpenGL because I wanted the accelerated window resize
> >>feature, and because I think it will give us more opportunities for
> >>further improvements (for example using PBOs as soon as they are
> >>supported by at least one open source graphic card driver).
> >>    
> >
> >The problem with OpenGL is that it has horrible rendering issues if you
> >are also using a compositing window manager like Compiz. 
> 
> I would say that this is a compiz problem.

Not really. Its a limitation of current X server driver architecture
which is being addressed by DRI2 / Redirected direct rendering work

> >You need an X
> >server & driver which supports Redirected Direct Rendering [1]. No distro 
> >currently has any official support for this yet. 
> 
> Or a distro problem.

The distros can't do anything about it, until X driver architecture work
is done.

> >AFAIK, the next Fedora 10
> >will be the first to support it, and even then only on Intel hardware[2].
> >ATI is still a fair way off, and NVidia support is nowhere to be seen. For
> >accelerated resize of windows though you shouldn't need 3d - the graphics
> >driver 2-d hardware acceleration  support ought to be sufficient I'd
> >imagine
> 
> I don't see how distros can enable compiz if it breaks opengl 
> applications like this.

This is exactly why Fedora does not yet enable compiz by default. Many
users still enable it though.

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[Avi Kivity]

Daniel P. Berrange wrote:

   

>>> The problem with OpenGL is that it has horrible rendering issues if you
>>> are also using a compositing window manager like Compiz. 
>>>       
>> I would say that this is a compiz problem.
>>     
>
> Not really. Its a limitation of current X server driver architecture
> which is being addressed by DRI2 / Redirected direct rendering work
>
>   
>> Or a distro problem.
>>     
>
> The distros can't do anything about it, until X driver architecture work
> is done.
>
>   

The distros can avoid shipping compiz until it is resolved one way or 
another.  Are wobbly windows worth breaking applications?

> This is exactly why Fedora does not yet enable compiz by default. Many
> users still enable it though.
>   

Ah, okay then.  The gui should probably say something about voiding the 
warranty, etc.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[Stefano Stabellini]

I completely agree with Avi: Opengl has been around since 1992, and now
you tell me that it is better not to use it because it breaks Compiz?!
To say the least it would be a bad long term engineering decision.

Avi Kivity wrote:

>> Daniel P. Berrange wrote:
>> The distros can't do anything about it, until X driver architecture work
>> is done.
>>
> 
> The distros can avoid shipping compiz until it is resolved one way or
> another.  Are wobbly windows worth breaking applications?
> 
>> This is exactly why Fedora does not yet enable compiz by default. Many
>> users still enable it though.
>>   
> 
> Ah, okay then.  The gui should probably say something about voiding the
> warranty, etc.
> 

Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[Daniel P. Berrange]

On Mon, Sep 08, 2008 at 11:30:09AM +0100, Stefano Stabellini wrote:
> I completely agree with Avi: Opengl has been around since 1992, and now
> you tell me that it is better not to use it because it breaks Compiz?!
> To say the least it would be a bad long term engineering decision.

It would be a bad decision *if* OpenGL were the only technical solution
to the problem. There are a variety of possible solutions with various
pluses & minuses. If it is possible to do an implementation which uses
hardware acceleration for scaling to get the same level of performance
as the OpenGL proposal, it is good sense to evaluate it. Blindly going
for OpenGL when it has known problems without evaluating alternatives
would be the bad engineering  decision.

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[Stefano Stabellini]

Daniel P. Berrange wrote:

> On Mon, Sep 08, 2008 at 11:30:09AM +0100, Stefano Stabellini wrote:
>> I completely agree with Avi: Opengl has been around since 1992, and now
>> you tell me that it is better not to use it because it breaks Compiz?!
>> To say the least it would be a bad long term engineering decision.
> 
> It would be a bad decision *if* OpenGL were the only technical solution
> to the problem. There are a variety of possible solutions with various
> pluses & minuses. If it is possible to do an implementation which uses
> hardware acceleration for scaling to get the same level of performance
> as the OpenGL proposal, it is good sense to evaluate it. Blindly going
> for OpenGL when it has known problems without evaluating alternatives
> would be the bad engineering  decision.


You are right that we have a variety of possible solution each one with
its own pros and cons.
I think removing SDL(+Opengl) for Gtk and Cairo is not a good idea *but*
we could add another Gtk based fronted.
We are already forced to work with multiple frontend because of vnc, so
at this point adding another one won't cause any harm.

Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[Daniel P. Berrange]

On Mon, Sep 08, 2008 at 11:53:57AM +0100, Stefano Stabellini wrote:
> Daniel P. Berrange wrote:
> 
> > On Mon, Sep 08, 2008 at 11:30:09AM +0100, Stefano Stabellini wrote:
> >> I completely agree with Avi: Opengl has been around since 1992, and now
> >> you tell me that it is better not to use it because it breaks Compiz?!
> >> To say the least it would be a bad long term engineering decision.
> > 
> > It would be a bad decision *if* OpenGL were the only technical solution
> > to the problem. There are a variety of possible solutions with various
> > pluses & minuses. If it is possible to do an implementation which uses
> > hardware acceleration for scaling to get the same level of performance
> > as the OpenGL proposal, it is good sense to evaluate it. Blindly going
> > for OpenGL when it has known problems without evaluating alternatives
> > would be the bad engineering  decision.
> 
> 
> You are right that we have a variety of possible solution each one with
> its own pros and cons.
> I think removing SDL(+Opengl) for Gtk and Cairo is not a good idea *but*
> we could add another Gtk based fronted.

Sorry, I wasn't being entirely clear in my suggestion. Cairo itself is not
tied to any toolkit - its dependancy is on libX11 / the RENDER extension.
So, use of Cairo is rather tangential to question of GTK vs SDL - you can
use Cairo with either of them. That said, it may turn out that SDL does
not expose enough of its X11 internals to allow an efficient use of Cairo.
It would need some experimentation to determine for sure, because the docs
aren't entirely clear on this question.

Regards,
Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[François Revol]

> On Mon, Sep 08, 2008 at 11:53:57AM +0100, Stefano Stabellini wrote:
> > Daniel P. Berrange wrote:
> >
> > > On Mon, Sep 08, 2008 at 11:30:09AM +0100, Stefano Stabellini
> > > wrote:
> > >> I completely agree with Avi: Opengl has been around since 1992,
> > > > and now
> > >> you tell me that it is better not to use it because it breaks
> > > > Compiz?!
> > >> To say the least it would be a bad long term engineering
> > > > decision.
> > >
> > > It would be a bad decision *if* OpenGL were the only technical
> > > solution
> > > to the problem. There are a variety of possible solutions with
> > > various
> > > pluses & minuses. If it is possible to do an implementation which
> > > uses
> > > hardware acceleration for scaling to get the same level of
> > > performance
> > > as the OpenGL proposal, it is good sense to evaluate it. Blindly
> > > going
> > > for OpenGL when it has known problems without evaluating
> > > alternatives
> > > would be the bad engineering  decision.
> >
> >
> > You are right that we have a variety of possible solution each one
> > with
> > its own pros and cons.
> > I think removing SDL(+Opengl) for Gtk and Cairo is not a good idea
> > *but*
> > we could add another Gtk based fronted.
>
> Sorry, I wasn't being entirely clear in my suggestion. Cairo itself
> is not
> tied to any toolkit - its dependancy is on libX11 / the RENDER
> extension.
> So, use of Cairo is rather tangential to question of GTK vs SDL - you
> can
> use Cairo with either of them. That said, it may turn out that SDL
> does
> not expose enough of its X11 internals to allow an efficient use of
> Cairo.
> It would need some experimentation to determine for sure, because the
> docs
> aren't entirely clear on this question.

It would definitely make things much less portable...
Cairo itself is quite a beast to port I heard... (not everyone uses
X11...)

François.

Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[Jamie Lokier]

François Revol wrote:
> > Sorry, I wasn't being entirely clear in my suggestion. Cairo itself
> > is not
> > tied to any toolkit - its dependancy is on libX11 / the RENDER
> > extension.
> > So, use of Cairo is rather tangential to question of GTK vs SDL - you
> > can
> > use Cairo with either of them. That said, it may turn out that SDL
> > does
> > not expose enough of its X11 internals to allow an efficient use of
> > Cairo.
> > It would need some experimentation to determine for sure, because the
> > docs
> > aren't entirely clear on this question.
> 
> It would definitely make things much less portable...
> Cairo itself is quite a beast to port I heard... (not everyone uses
> X11...)

Cairo can work with a basic framebuffer, I think, so in principle that
should be easy to use on any target, but not accelerated.

Cairo's software renderer is said not to be particularly fast, as
those things go, in various places (including on the Cairo list last
summer).

Don't Mozilla/Firefox use Cairo these days?  Do they use it on Windows?

Regarding SDL and X11, a "raw" Xlib front end (no SDL) would not be
much code, if the intent is to do the rendering with something other
than SDL, since all it does is create a window and support a few basic
events.  (It might still not be worth the work, though).

-- Jamie

Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[Anthony Liguori]

> It would definitely make things much less portable...
> Cairo itself is quite a beast to port I heard... (not everyone uses 
> X11...)
>   

It compiles fine on Windows.

Regards,

Anthony Liguori

> François.
>
>
>   

Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[François Revol]

>
> > It would definitely make things much less portable...
> > Cairo itself is quite a beast to port I heard... (not everyone uses
> > X11...)
> >
>
> It compiles fine on Windows.
>

I wasn't thinking about windows.

François.

Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[malc]

On Fri, 5 Sep 2008, Stefano Stabellini wrote:

> Jamie Lokier wrote:
>
>>
>> Fwiw, in my experience with Xine and mplayer, drawing video updates to
>> the screen using OpenGL was quite a lot slower than drawing them with
>> XShmImage.  That needs colour conversion as video doesn't even use RGB.
>>
>> Probably OpenGL is faster on some hardware, and slower on some hardware.
>> Don't assume it's always faster.
>
>
> Yes, good point.
>
>
>> Yes it very much depends on the drivers and opengl implementation.  It
>> isn't always possible to map the guest framebuffer into video
>> (texture) memory, and also some opengl implementations are not
>> particularly fast at copying textures from CPU memory to texture memory.
>
>
> This is also true.
>
>
>> Another way to map guest framebuffer to video memory is the XF86DGA
>> extension, which is great when you can use it.  I think VMware uses it
>> in full-screen mode.
>
> I went with OpenGL because I wanted the accelerated window resize
> feature, and because I think it will give us more opportunities for
> further improvements (for example using PBOs as soon as they are
> supported by at least one open source graphic card driver).

I have code that uses PBO or PDR or XAMM, for cirrus it was always
on par with the standard SDL drawing speed wise, and i expected it
to be faster with VMWare SVGA, but back when i was musing with it
VMWare SVGA didn't quite work with Linux guests, then it was fixed
but i got carried away by different stuff. I can probably brush it
up and release if anybody is interested.

-- 
mailto:av1474@comtv.ru

Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[Stefano Stabellini]

Anthony Liguori wrote:

 > This is neat, but, I'm unsure if the right way to support OpenGL is
> through SDL.  For instance, there were Cocoa OpenGL patches posted a bit
> ago that would be largely similar.  It may make more sense to have an
> OpenGL front-end that has conditional code for SDL/Cocoa/X/etc.
> 
> Then again, I've been kicking around the idea of doing a GTK front-end. 
> An obvious thing to do here would be a glext based OpenGL version (as we
> do in gtk-vnc).


I don't think GTK support would add much to what qemu already has (aside
from more dependencies :).

 
> I think we need to have some discussion about what the long term
> front-end should be for QEMU.  Otherwise, we're going to end up with a
> proliferation of front-ends.  Personally, I'd rather move from SDL to
> GTK so that we can build a proper user interface.
> 

While decoupling the opengl code from the sdl code seems a good idea, in
 practice opengl is only for rendering and the sdl code handles so much
more than that.
Opengl depends heavily on SDL for everything else, so separating the two
of them may not be straightforward.

If you really want to go this route, probably the simplest way is to
treat opengl as a separate drop in reandering replacement for sdl (or
whatever other future frontend).
Opengl would substitute only few critical rendering related functions
(sdl_resize_shared, sdl_colourdepth, sdl_update, sdl_setdata).

Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[Anthony Liguori]

Stefano Stabellini wrote:
> Anthony Liguori wrote:
>
>  > This is neat, but, I'm unsure if the right way to support OpenGL is
>   
>> through SDL.  For instance, there were Cocoa OpenGL patches posted a bit
>> ago that would be largely similar.  It may make more sense to have an
>> OpenGL front-end that has conditional code for SDL/Cocoa/X/etc.
>>
>> Then again, I've been kicking around the idea of doing a GTK front-end. 
>> An obvious thing to do here would be a glext based OpenGL version (as we
>> do in gtk-vnc).
>>     
>
>
> I don't think GTK support would add much to what qemu already has (aside
> from more dependencies :).
>   

Well the goal would be to replace the monitor with a menu/toolbar.

Pressing ctrl-alt-2, then typing change ide0-cd0 'path/to/file' without 
being able to use copy/paste and with funky completion is pretty 
unfriendly IMHO.

Being able to use a familiar file browser for this sort of thing would 
go a long way in improving user experience, I think.

Regards,

Anthony Liguori

Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[Andreas Färber]

Am 04.09.2008 um 05:00 schrieb Anthony Liguori:

> Stefano Stabellini wrote:
>> -makes the window resizing possible and hardware accelerated, thus  
>> very
>> efficient and smooth;
>>
>
> This is neat, but, I'm unsure if the right way to support OpenGL is  
> through SDL.  For instance, there were Cocoa OpenGL patches posted a  
> bit ago that would be largely similar.  It may make more sense to  
> have an OpenGL front-end that has conditional code for SDL/Cocoa/X/ 
> etc.
>
> Then again, I've been kicking around the idea of doing a GTK front- 
> end.  An obvious thing to do here would be a glext based OpenGL  
> version (as we do in gtk-vnc).
>
> I think we need to have some discussion about what the long term  
> front-end should be for QEMU.  Otherwise, we're going to end up with  
> a proliferation of front-ends.  Personally, I'd rather move from SDL  
> to GTK so that we can build a proper user interface.

Anthony, you are aware of the Gtk+ QEMU Launcher?
https://gna.org/projects/qemulaunch/

Haven't used it personally but it's installed on all our Fedora lab  
machines.

In general I thought fancy ("proper") graphical frontends were left to  
the famous Management Applications. But I agree it could be useful to  
rethink the relation of QEMU to such secondary projects. I remember  
seeing the issue in Q that some parts of QEMU assume readability of  
stderr (e.g., when assigning more RAM than the default sparc machine  
allows), which is unhandy for a graphical app launched from the OS X  
Dock or GNOME menu. Having a clear set of macros/functions that can  
and should be overwritten by frontends (a separate header file that  
can be exchanged instead of constantly breaking patches) might help.  
In general maybe also a solution similar in spirit to Glauber's QEMU  
Accel tree might be useful. Q has a patch in their tree for instance  
that hooks into IDE to display disk activity. Food for thought.

Andreas