From: Dave Airlie <airlied@gmail.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: "Paolo Bonzini" <pbonzini@redhat.com>,
"Marc-André Lureau" <mlureau@redhat.com>,
qemu-devel <qemu-devel@nongnu.org>,
"David Airlie" <airlied@redhat.com>
Subject: Re: [Qemu-devel] RFC: running the user interface in a thread ...
Date: Fri, 22 Jan 2016 17:14:44 +1000 [thread overview]
Message-ID: <CAPM=9tyFyeqBEtD2S6-jUo16VXC13FnWZsGTVTgX3BmmKVS4Og@mail.gmail.com> (raw)
In-Reply-To: <1453445964.17005.4.camel@redhat.com>
On 22 January 2016 at 16:59, Gerd Hoffmann <kraxel@redhat.com> 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 won't help unblock things.
>>
>> So I think it would be best to have all the virgl vq processing happen
>> in it's own thread with some API
>> to the UI to do UI resizes (the most difficult) and dirty regions etc.
>
> We can move only virgl into its own thread, but then we'll have two
> threads (virgl and main which runs ui) which use opengl. So I was
> thinking maybe it is better to have a single thread which runs both
> virgl and ui (and thats why I've started this thread ...).
In theory as long as we have separate contexts bound in each thread it
should be fine.
OpenGL is okay as long as one context is bound in one thread at a time.
Since the only sharing we have between contexts are textures, they
should be okay
between shared contexts.
Dave.
next prev parent reply other threads:[~2016-01-22 7:14 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-18 9:54 [Qemu-devel] RFC: running the user interface in a thread Gerd Hoffmann
2016-01-18 20:34 ` Eric Blake
2016-01-19 13:01 ` Gerd Hoffmann
2016-01-19 13:38 ` Dr. David Alan Gilbert
2016-01-19 14:14 ` Gerd Hoffmann
2016-01-20 14:33 ` Kevin Wolf
2016-01-19 15:19 ` Markus Armbruster
2016-01-19 15:28 ` Daniel P. Berrange
2016-01-20 5:05 ` Eric Blake
2016-01-20 8:45 ` Gerd Hoffmann
2016-01-19 12:51 ` Kevin Wolf
2016-01-21 9:58 ` Stefan Hajnoczi
2016-01-21 10:39 ` Gerd Hoffmann
2016-01-21 10:52 ` Paolo Bonzini
2016-01-21 10:40 ` Daniel P. Berrange
2016-01-19 15:37 ` Daniel P. Berrange
2016-01-20 7:13 ` Gerd Hoffmann
2016-01-21 8:44 ` Dave Airlie
2016-01-21 9:05 ` Paolo Bonzini
2016-01-21 9:52 ` Gerd Hoffmann
2016-01-21 10:16 ` Paolo Bonzini
2016-01-22 1:38 ` Dave Airlie
2016-01-22 6:59 ` Gerd Hoffmann
2016-01-22 7:14 ` Dave Airlie [this message]
2016-01-21 9:00 ` Fam Zheng
2016-01-21 9:45 ` Gerd Hoffmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAPM=9tyFyeqBEtD2S6-jUo16VXC13FnWZsGTVTgX3BmmKVS4Og@mail.gmail.com' \
--to=airlied@gmail.com \
--cc=airlied@redhat.com \
--cc=kraxel@redhat.com \
--cc=mlureau@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.