On 18 January 2016 at 19:54, Gerd Hoffmann <kra...@redhat.com> 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 and toolkits tend to be bad at multithreading. So my idea is to > have a single thread dedicated to all the UI + rendering stuff, possibly > let even the virglrenderer run in ui thread context.
I'd still like virgl to run it its own thread at some point like dataplane but for virgl I suppose. We see cases where backend GLSL compiles and end up taking quite a while, and I'd prefer to not block the UI or qemu on those. 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 the UI and virtio-gpu thread to handle things like screen resize etc. http://cgit.freedesktop.org/~airlied/qemu/commit/?h=dave3d&id=fe22a0955255afef12b947c4a91efa57e7a7c429 is my previous horror patch. Dave.
