[vbox-dev] fw:Re: 3d acceleration of android-x86 for virtualbox

Huihong Luo huisinro at yahoo.com
Sun Jul 23 13:59:43 GMT 2017


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> wrote:
> 
> 2017-07-19 7:05 GMT+08:00 tim3385 <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 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.1 on the guest with our own one: 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: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 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 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 (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
> https://www.virtualbox.org/mailman/listinfo/vbox-dev




More information about the vbox-dev mailing list