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. Regards Michael > 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. > > best > Dong Hao > ------------------------------------------------------------------------ > Sent from YoMail for Gmail <http://www.yomail.com/?utm_source=signature> > > *发件人：* Huihong Luo <mailto:[email protected]> > *发送时间：* 2017-07-23 21:59:43 > *收件人：* Chih-Wei Huang <mailto:[email protected]> > *抄送：* Michael Thayer <mailto:[email protected]>; > [email protected] <mailto:[email protected]>; zhengxuwen > <mailto:[email protected]>; tim3385 <mailto:[email protected]> > *主题：* Re: [vbox-dev] fw:Re: 3d acceleration of android-x86 for > virtualbox > > 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 > <[email protected] <mailto:[email protected]>> wrote: > > > > 2017-07-19 7:05 GMT+08:00 tim3385 <[email protected] > <mailto:[email protected]>>: > >> <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 > virtual > >>> hardware, is my understanding right? > >> > >> The vboxguest module drives the virtual "guest" device which does > most > >> 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 > using > >> 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 > reading > >> 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 > should > >> 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 > found > >>> 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 > <http://www.yomail.com/?utm_source=signature> > >>> > >>> < Michael Thayer <mailto:[email protected] > <mailto:[email protected]>>> 在 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 > discuss > >>>> 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 > will > >>> probably have most luck studying the code and asking precise > questions > >>> 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 > sends > >>> 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 > > [email protected] <mailto:[email protected]> > > 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 _______________________________________________ vbox-dev mailing list [email protected] https://www.virtualbox.org/mailman/listinfo/vbox-dev
