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 it
>> in a thread w
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
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 the queue in a
>> sepa
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
Ai
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 in
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
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. Unfor
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 avo
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
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
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 th
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 an
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 little
> longer.
>
> op
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 dm
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 n
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,
Gerd
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 impor
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
> l
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
> > d
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 quick look at the s
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 able
* 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).
>
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 clea
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.
>
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
25 matches
Mail list logo
