[vbox-dev] fw:Re: 3d acceleration of android-x86 for virtualbox
michael.thayer at oracle.com
Mon Jul 24 06:23:05 UTC 2017
Hello Dong Hao,
23.07.2017 18:08, tim3385 wrote:
> Thanks for your reply.
> I heard of virgil is not enough mature. So I think "passthough into host
> 3d api" is a easy way for now. And "gles pipes" @Luo meantioned is the
> same meaning?
This is the first time that I am hearing of GLES pipes too. Perhaps Luo
(Huihong Luo, is that the right way to address you? Sorry that I keep
asking that!) will tell us more.
> The 3D feature for other linux distribution just like Ubuntu is our good
> reference. But it is not easy to run hardware 3D in Ubuntu successfully.
> I don't why. If it works well, we will start to analyze the difference
> between the addtion of Ubuntu and Android-x86 as entry point. If you
> know some detail to tell us, it is will much helpful, thanks.
More information welcome on what does not work there. I assume you
meant testing our 3D pass-through on an Ubuntu distribution. If you do
that I would suggest you try 17.04, not 17.10. Note that Chromium has
bad issues with it, which would probably be fixable if someone took the
time to look - it might even be a good way for you to get to know our
code. And as I said, it would make sense for you to do your own tests
and comparisons of our code, Virgl in Qemu and possibly also our
experimental VMWare graphics emulation.
> btw. Cross wall from China mainland is not stable in these days. We
> can't access andorid-x86/google/android.com <http://android.com>and
> etc~~. And we are busy for some other affair. We will take more time
> from the end of this month.
> Dong Hao
> Sent from YoMail for Gmail <http://www.yomail.com/?utm_source=signature>
> *发件人：* Huihong Luo <mailto:huisinro at yahoo.com>
> *发送时间：* 2017-07-23 21:59:43
> *收件人：* Chih-Wei Huang <mailto:cwhuang at android-x86.org>
> *抄送：* Michael Thayer <mailto:michael.thayer at oracle.com>;
> vbox-dev at virtualbox.org <mailto:vbox-dev at virtualbox.org>; zhengxuwen
> <mailto:zhengxuwen at c2engine.com>; tim3385 <mailto:tim3385 at gmail.com>
> *主题：* Re: [vbox-dev] fw:Re: 3d acceleration of android-x86 for
> Another option, which is more doable, is to use emulator's gles pipes.
> Sent from my iPhone
> > On Jul 19, 2017, at 4:35 AM, Chih-Wei Huang
> <cwhuang at android-x86.org <mailto:cwhuang at android-x86.org>> wrote:
> > 2017-07-19 7:05 GMT+08:00 tim3385 <tim3385 at gmail.com
> <mailto:tim3385 at gmail.com>>:
> >> <Michael Thayer> 在 2017-07-18 16:20:43 写道:
> >> Hello Dong Hao,
> >> (Is that the right way to address you?)
> >> 15.07.2017 19:57, tim3385 wrote:
> >> [...]
> >>> vboxguest, vboxvideo and vboxsf have been probed into android-x86.
> >>> We are finding the entrance of translate android-x86 3d implement to
> >>> host OS.
> >>> We have a few questions about virtualbox, thanks^^:
> >>> 1 "external_vboxguest-linux-module" is a driver for virtualbox's
> >>> hardware, is my understanding right?
> >> The vboxguest module drives the virtual "guest" device which does
> >> of the work of letting the Guest Additions communicate with the host.
> >>> 2 There is a sentense "Hardware 3D acceleration under Ubuntu
> 10.10 and
> >>> Fedora 14 have been tested and confirmed as working"
> >>> in http://www.virtualbox.org/manual/ch04.html#guestadd-video .
> Can you
> >>> introduce the theory? eg. where is the entrance that The additon
> >>> translate 3d api invoke to host?
> >> I see that our manual needs some adjusting not to refer to
> precise guest
> >> versions which get out of date quickly. To repeat: the theory is that
> >> we replace libGL.so <http://libgl.so>.1 on the guest with our own
> one: VBoxOGL.so <http://vboxogl.so>, with
> >> various dependencies VBoxOGL*.so. Those marshall OpenGL API calls
> >> (though they deal with some things locally in the address space
> of the
> >> caller) which they send through the guest device using the HGCM
> >> transport (though it can also be done through the graphics device
> >> the HGSMI transport) to the host for rendering. See the make file
> >> src/VBox/Additions/common/crOpenGL/Makefile.kmk
> >> for an overview of what goes into those libraries. The source
> files are
> >> rather scattered over the tree, and some are auto-generated, but
> if you
> >> want to do something here you will not get around doing a lot of
> >> of source. We could probably answer specific questions, but generic
> >> explanations of "how it works" will probably not help much
> without that
> >> reading.
> >> See though my suggestion by private e-mail of modifying the vboxvideo
> >> graphics device to be able to channel Qemu's virgl rendering protocol
> >> through to the host. You would be able to leave the guest rendering
> >> code in Mesa almost unmodified (just changed enough to recognise
> >> vboxvideo as a supported device) and re-use the host rendering
> code (the
> >> virglrenderer library) which would just need to be hooked, more
> or less
> >> unmodified, into our host code. The changes to vboxvideo itself
> >> be reasonably trivial too. In comparison, reworking our current
> 3D code
> >> will be a lot of work.
> > Hi Michael,
> > Thank you for the detailed reply.
> > Let me sum it up to see if I understand
> > your words correctly:
> > * Modify Mesa to recognize vboxvideo
> > * Modify vboxvideo to send virgl rendering protocol to the host
> > * Hook virglrenderer to vbox host code
> > I have concern about the third step.
> > As I know currently virglrenderer only supports Linux.
> > (though I saw some Windows's patches are ongoing)
> > That would limit our supported hosts.
> > Besides, I think currently virglrenderer is still not stable
> > or complete enough. As I tested on QEMU with virgl,
> > many 3D benchmark apps don't work.
> > (just crash or black screen)
> > The only famous benchmark app that works on it
> > is GLXBench.
> > I'm still thinking if it's possible to use your current 3D code
> > directly. Could you give us more ideas how it work
> > for Linux or Windows guests? Or point us which
> > code to read. Thanks a lot!
> >>> 3 We want to do some modification based
> >>> on "external_vboxguest-linux-module". Could you please give us some
> >>> suggestions or samples?
> >> That is hard without knowing what you want to do.
> >>> 4 About android-x86: is there some way to directly(like by usb
> >>> wire) connect host to android-x86 in virtualbox by adb? We only
> >>> the way "adb connect IP" can success, and the "IP" must be a lan IP
> >>> but 127.0.0.1 so that the transfer speed would be low.
> >> Not that I know of, though I don't know much about adb. In theory you
> >> could write a virtual USB device to do that, but I suspect you have
> >> already set more than enough work for yourself.
> >>> 5 How can sound card of virtualbox Android-x86 work fine?
> >> Sound is being worked on. What problems are you experiencing?
> >> Regards
> >> Michael
> >>> best
> >>> Dong Hao
> >>> Sent from YoMail for Gmail
> >>> < Michael Thayer <mailto:michael.thayer at oracle.com
> <mailto:michael.thayer at oracle.com>>> 在 2017-07-12
> >>> 19:17:49 写道:
> >>> 10.07.2017 10:52, tim3385 wrote:
> >>>> Dear Sirs:
> >>>> I want to make virtualbox addition for android-x86 to improve the
> >>>> efficient of 3d and 2d.
> >>>> Mr. Chih-Wei Huang, current project maintainer of android-x86, has
> >>> given
> >>>> me some reference about android-x86 3d acceleration. They just
> >>>> this with VWare.
> >>>> I want to look for somebody who can help me begin. thanks.
> >>> Hello Tim (is that the right name to address you by?),
> >>> I'm afraid that no one has a lot of time to help you with this.
> I will
> >>> make a quick suggestion about where you could start looking. You
> >>> probably have most luck studying the code and asking precise
> >>> when things are not clear.
> >>> You will probably want to start by looking at the X11 libGL.so
> <http://libgl.so> and its
> >>> dependencies. This is a purely user-space library which
> marshalls the
> >>> OpenGL command stream and some information from GLX commands and
> >>> it to the host, currently via the "guest" device, on Windows
> through the
> >>> graphics device. On the host the 3D content is rendered to a host
> >>> window - a separate one from the normal guest screen window, which
> >>> sometimes causes unwanted artefacts when 2D and 3D guest
> rendering are
> >>> mixed.
> >>> It will probably take you a while to get used to our build system to
> >>> work out what goes into libGL.so <http://libgl.so> (including
> generated files), but you
> >>> will probably have to go through that.
> >>> Hope that helps for a start.
> >>> Regards
> >>> Michael
> >> [...]
> > --
> > Chih-Wei
> > Android-x86 project
> > http://www.android-x86.org
> > _______________________________________________
> > vbox-dev mailing list
> > vbox-dev at virtualbox.org <mailto:vbox-dev at virtualbox.org>
> > https://www.virtualbox.org/mailman/listinfo/vbox-dev
Michael Thayer | VirtualBox engineer
ORACLE Deutschland B.V. & Co. KG | Werkstr. 24 | D-71384 Weinstadt
ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstraße 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603
Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister
der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
More information about the vbox-dev