Re: [Qemu-devel] RFC: running the user interface in a thread ...

On 21/01/2016 11:39, Gerd Hoffmann wrote: > How does BH signaling work? I know I can qemu_bh_schedule from !main > thread to kick BH in main thread context. The other way around works > using aio_bh_new + aio_bh_call I guess? Yes. The code will run in the iothread. Note that I'm modifying

Re: [Qemu-devel] RFC: running the user interface in a thread ...

On 21/01/2016 10:52, Gerd Hoffmann wrote: >> > Instead of having a full-blown thread, are there things (such as the >> > TGSI->GLSL conversion) that could be simply offloaded to a userspace >> > thread pool, either in QEMU or in virglrenderer? > I think virglrenderer would have to do that.

Re: [Qemu-devel] RFC: running the user interface in a thread ...

On 18 January 2016 at 19:54, Gerd Hoffmann wrote: > Hi folks, > > I'm starting to investigate if and how we can move the user interface > code into its own thread instead of running it in the iothread and > therefore avoid blocking the guest in case some UI actions take a

Re: [Qemu-devel] RFC: running the user interface in a thread ...

On 21/01/2016 09:44, Dave Airlie wrote: > I've hacked on this before, but only with SDL and it was pretty dirty, > and it gave a fairly decent > speed up. > > My thoughts are to use dataplane like design to process the queue in a > separate thread, > and then have some sort of channel between

Re: [Qemu-devel] RFC: running the user interface in a thread ...

Hi, > What are taking long time? Can you give a few examples? Didn't profile things, but UI code is handling bulky graphics data, which of course takes time, especially in case some software scaling is involved. For sdl-1 I remember complains about it slowing down guests alot. IIRC I checked

Re: [Qemu-devel] RFC: running the user interface in a thread ...

Hi, > That sounds good in theory (but see below) since AioContext integrates > with the glib main loop because it is a GSource. QEMU code should use > AioContext where we have high resolution timers and APIs for file > descriptor, EventNotifier, and BH. Sounds good. > Use BH or EventNotifier

Re: [Qemu-devel] RFC: running the user interface in a thread ...

On Mon, 01/18 10:54, Gerd Hoffmann wrote: > Hi folks, > > I'm starting to investigate if and how we can move the user interface > code into its own thread instead of running it in the iothread and > therefore avoid blocking the guest in case some UI actions take a little > longer. > > opengl

Re: [Qemu-devel] RFC: running the user interface in a thread ...

On Tue, Jan 19, 2016 at 01:51:09PM +0100, Kevin Wolf wrote: > Am 18.01.2016 um 10:54 hat Gerd Hoffmann geschrieben: > > Hi folks, > > > > I'm starting to investigate if and how we can move the user interface > > code into its own thread instead of running it in the iothread and > > therefore

Re: [Qemu-devel] RFC: running the user interface in a thread ...

On Do, 2016-01-21 at 10:05 +0100, Paolo Bonzini wrote: > > On 21/01/2016 09:44, Dave Airlie wrote: > > I've hacked on this before, but only with SDL and it was pretty dirty, > > and it gave a fairly decent > > speed up. > > > > My thoughts are to use dataplane like design to process the queue in

Re: [Qemu-devel] RFC: running the user interface in a thread ...

On Thu, Jan 21, 2016 at 09:58:11AM +, Stefan Hajnoczi wrote: > On Tue, Jan 19, 2016 at 01:51:09PM +0100, Kevin Wolf wrote: > > Am 18.01.2016 um 10:54 hat Gerd Hoffmann geschrieben: > > > Hi folks, > > > > > > I'm starting to investigate if and how we can move the user interface > > > code

Re: [Qemu-devel] RFC: running the user interface in a thread ...

On 21 January 2016 at 19:05, Paolo Bonzini wrote: > > > On 21/01/2016 09:44, Dave Airlie wrote: >> I've hacked on this before, but only with SDL and it was pretty dirty, >> and it gave a fairly decent >> speed up. >> >> My thoughts are to use dataplane like design to process

Re: [Qemu-devel] RFC: running the user interface in a thread ...

On 22 January 2016 at 16:59, Gerd Hoffmann wrote: > Hi, > >> In theory Mesa could help here, but GL isn't thread friendly at all, >> so it probably won't help in the virgl >> case even if it did. Since most GL apps compile a shader and block on >> using it straight away doing

Re: [Qemu-devel] RFC: running the user interface in a thread ...

Hi, > In theory Mesa could help here, but GL isn't thread friendly at all, > so it probably won't help in the virgl > case even if it did. Since most GL apps compile a shader and block on > using it straight away doing it > in a thread won't help unblock things. > > So I think it would be best

Re: [Qemu-devel] RFC: running the user interface in a thread ...

Hi, > >> Related: Possibly we should move UIs to another *process* instead? > >> At least the ones which use a UI toolkit (i.e. sdl, gtk, cocoa). > > > > Is the worth the effort ? The majority of mgmt apps use spice/vnc which > > is already out of process. When you are using libvirt you are

Re: [Qemu-devel] RFC: running the user interface in a thread ...

Am 19.01.2016 um 15:14 hat Gerd Hoffmann geschrieben: > Hi, > > > That does feel safer, if you can find an efficient way to do the graphics. > > A lot less code running with the privs of the qemu process. > > That is where it starts to become tricky ... > > On modern linux we can simply use

Re: [Qemu-devel] RFC: running the user interface in a thread ...

Hi, > As a general note though, mixing GTK and threads is really not something > I'd encourage in general. Sure, thats why I think qemu should have *one* ui thread, and that one will be the only one calling into gtk (and also the only one running opengl in case that is enabled). cheers,

Re: [Qemu-devel] RFC: running the user interface in a thread ...

On 01/19/2016 08:28 AM, Daniel P. Berrange wrote: > On Tue, Jan 19, 2016 at 02:01:47PM +0100, Gerd Hoffmann wrote: >> Hi, >> >>> That, and so the UI can use localization without corrupting other >>> threads that MUST use the C locale (QMP parsing/output of floating point >>> is particularly

Re: [Qemu-devel] RFC: running the user interface in a thread ...

Hi, > That, and so the UI can use localization without corrupting other > threads that MUST use the C locale (QMP parsing/output of floating point > is particularly important to get right with '.' instead of ',' for a > decimal separator). A quick look at the setlocale manpage doesn't make

Re: [Qemu-devel] RFC: running the user interface in a thread ...

Hi, > That does feel safer, if you can find an efficient way to do the graphics. > A lot less code running with the privs of the qemu process. That is where it starts to become tricky ... On modern linux we can simply use dma-bufs. On older linux and generic posix (*bsd etc) we should be

Re: [Qemu-devel] RFC: running the user interface in a thread ...

Am 18.01.2016 um 10:54 hat Gerd Hoffmann geschrieben: > Hi folks, > > I'm starting to investigate if and how we can move the user interface > code into its own thread instead of running it in the iothread and > therefore avoid blocking the guest in case some UI actions take a little > longer. >

Re: [Qemu-devel] RFC: running the user interface in a thread ...

* Gerd Hoffmann (kra...@redhat.com) wrote: > Hi, > > > That, and so the UI can use localization without corrupting other > > threads that MUST use the C locale (QMP parsing/output of floating point > > is particularly important to get right with '.' instead of ',' for a > > decimal separator).

Re: [Qemu-devel] RFC: running the user interface in a thread ...

On Tue, Jan 19, 2016 at 02:01:47PM +0100, Gerd Hoffmann wrote: > Hi, > > > That, and so the UI can use localization without corrupting other > > threads that MUST use the C locale (QMP parsing/output of floating point > > is particularly important to get right with '.' instead of ',' for a > >

Re: [Qemu-devel] RFC: running the user interface in a thread ...

Gerd Hoffmann writes: > Hi, > >> That, and so the UI can use localization without corrupting other >> threads that MUST use the C locale (QMP parsing/output of floating point >> is particularly important to get right with '.' instead of ',' for a >> decimal separator). > > A

Re: [Qemu-devel] RFC: running the user interface in a thread ...

On Mon, Jan 18, 2016 at 10:54:40AM +0100, Gerd Hoffmann wrote: > Hi folks, > > I'm starting to investigate if and how we can move the user interface > code into its own thread instead of running it in the iothread and > therefore avoid blocking the guest in case some UI actions take a little >

[Qemu-devel] RFC: running the user interface in a thread ...

Hi folks, I'm starting to investigate if and how we can move the user interface code into its own thread instead of running it in the iothread and therefore avoid blocking the guest in case some UI actions take a little longer. opengl and toolkits tend to be bad at multithreading. So my idea

Re: [Qemu-devel] RFC: running the user interface in a thread ...

On 01/18/2016 02:54 AM, Gerd Hoffmann wrote: > Hi folks, > > I'm starting to investigate if and how we can move the user interface > code into its own thread instead of running it in the iothread and > therefore avoid blocking the guest in case some UI actions take a little > longer. That, and