So the Google Android team just posted this: http://feedproxy.google.com/~r/blogspot/hsDu/~3/OCt1AQzfyWI/faster-emulator-...
Which shows their device emulator running w/ hardware acceleration. Since I know they started with qemu, I was curious if there was any details as to if these sorts of changes were making it back upstream to qemu, or if qemu had its own plans for hardware acceleration?
Unfortunately there's little technical details in the post above. The video is clearly running on OS X, so I'm not sure if this will also be usable w/ Linux hosts, but I could be wrong there.
thanks -john
On 10 April 2012 07:13, John Stultz johnstul@us.ibm.com wrote:
So the Google Android team just posted this: http://feedproxy.google.com/~r/blogspot/hsDu/~3/OCt1AQzfyWI/faster-emulator-...
Which shows their device emulator running w/ hardware acceleration. Since I know they started with qemu, I was curious if there was any details as to if these sorts of changes were making it back upstream to qemu, or if qemu had its own plans for hardware acceleration?
Unfortunately there's little technical details in the post above. The video is clearly running on OS X, so I'm not sure if this will also be usable w/ Linux hosts, but I could be wrong there.
Hi John. Peter can say more, but I think they've done two things: pass OpenGL operations through to the host and run a virtualised x86 Android image instead of a JITted ARM Android image. I don't know what's going upstream but the Google QEMU people are friendly and have cherry picked from us before.
-- Michael
On 9 April 2012 20:13, John Stultz johnstul@us.ibm.com wrote:
So the Google Android team just posted this: http://feedproxy.google.com/~r/blogspot/hsDu/~3/OCt1AQzfyWI/faster-emulator-...
Which shows their device emulator running w/ hardware acceleration. Since I know they started with qemu, I was curious if there was any details as to if these sorts of changes were making it back upstream to qemu, or if qemu had its own plans for hardware acceleration?
Unfortunately Google's Android emulator has diverged a lot from upstream QEMU, to the extent that I don't think it very likely that it will ever merge back again. (I'd love to be proved wrong, of course, but we had a look at adding basic support for the Goldfish virtual platform to upstream QEMU as part of a Google Summer of Code project last year, and it turns out that you would basically have to rewrite most of the device models to get anything upstream would accept as following current QEMU frameworks/APIs/etc. Since then the upstream QEMU API for device models has evolved again...)
The idea of hardware graphics acceleration (ie OpenGL(ES) passthrough) for upstream QEMU has been discussed (and even the odd patch series or two has been submitted though not committed); but I think that there isn't anybody who wants it enough to be able to dedicate the time to thrashing out a design acceptable to everybody and getting it accepted by upstream.
-- PMM
-
John Stultz -
Michael Hope -
Peter Maydell