The plan to enable GLES hardware acceleration for unsupported GPUs

[Chih-Wei Huang]

Hi all,
This is a technical document that describes the plan to enable OpenGL
ES hardware acceleration for some x86 GPUs which don't have native
Android support from the open source community or their vendors. It's
intended for the developers who want to contribute to this field.

* Background

There are several steps to enable GLES hardware acceleration on Android:

1. Linux kernel driver that supports 3D
2. Userspace GLES libraries for Android
3. Graphic HAL (the gralloc)

In Android arm world, these are almost provided by the chip vendors
(qcom, ti, nv, ...) in their BSP. Usually 1 and 3 are open sourced,
but 2 is almost proprietary and provided by the chip vendors in the
binary form. For Google Nexus series, Google allows the public to
download 2 from the web
http://code.google.com/intl/en/android/nexus/drivers.html so platform
developer can use them to create an Android image with hardware
acceleration for the Nexus products.


* The Current Status of Android-x86

Unfortunately in the Android-x86 world we are not that lucky. It's a
shame that no x86 vendor is willing to provide these things to help us
to enable GLES hardware acceleration on our x86 devices. It's on our
own to create them.

Currently we only support hardware acceleration for some Intel
integrated GPU and AMD Radeon based on

1. Kernel drivers: i915, radeon
2. GLES libraries: Mesa libraries (src: external/mesa, external/drm)
3. Graphic HAL: gralloc.drm (src: hardware/drm_gralloc)

Mesa (http://www.mesa3d.org/) is an open-source implementation of the
OpenGL specification - a system for rendering interactive 3D graphics.
It is usually used by X window system for the 3D hardware
acceleration. We have ported Mesa to Android to support hardware
acceleration on Android-x86. Most of the work was done by Chia-I Wu
(olv) since 2011-2012 and has merged to the Mesa upstream.

There are some Intel chip equipped with PowerVR engine by Imagination
Inc., say, Z5xx(GMA500), Z6xx(GMA600, SGX535), N2600, D2500 (Cedar
Trail, SGX545), Z2xxx (Clover Trail) . PowerVR is proprietary that
doesn't have open source implementation yet. GNU has highlighted it as
"New High Priority Project: PowerVR drivers"
(http://www.fsf.org/blogs/community/new-high-priority-project-powervr-drivers).
However, so far the progress is very slow as I know. Those who are
interesting in the project may read its web:
http://powervr.gnu.org.ve/doku.php

Nvidia chip is supposed to be supported by Mesa using the nouveau
driver. However, the porting of nouveau to Android-x86 is not
finished. Currently no any Android-x86 developer has Nvidia device or
is interesting in the porting. Nor any vendor is willing to provide us
some devices for the development. In short, Nvidia hardware
acceleration is not supported by Android-x86.


* Hardware OpenGL ES Emulation

Hardware OpenGL ES emulation is a new feature of the Android SDK
emulator introduced by Google since JellyBean. The basic idea is to
allow the emulator (guest) to utilize the OpenGL hardware acceleration
abilities of the host OS (e.g., Linux/Windows/MacOS). The guest has
GLES emulation libraries that collect the sequence of EGL/GLES
function calls and translate then into a custom wire protocol stream
that is sent to the emulator program through a high-speed
communication channel called a "QEMU Pipe". For more details and its
design, read the documents in the android source tree:

sdk/emulator/opengl/README
sdk/emulator/opengl/DESIGN

In the original Google design, the guest and the host are different
OSes (Android vs Linux/Windows/MacOS). However, it's possible to
combine Android and the traditional Linux X window system into one
filesystem and use one kernel to run both of them. In other word, the
guest and the host are the same OS. We just need to replace "QEMU
Pipe" by a tcp or unix socket to do the communication. In this way the
hardware acceleration of Android (guest) is enabled via the X window
(host) OpenGL libraries.


* Tasks TODO

Using N2600 Cedar Trail platform as an example, the Meego project has
a hardware accelerated image for it:

http://repo.meego.com/MeeGo/updates/1.2.0/images/meego-netbook-ia32-cedartrail/
http://repo.meego.com/MeeGo/updates/1.2.0/repos/non-oss/ia32/packages/
-- PowerVR libs rpms

It's kernel based on 3.2 with Android patches are available in our git server:

git clone http://git.android-x86.org/kernel/cdv

Here are the steps to do:

- Port its cedarview_gfx module (PowerVR driver for Cedar Trail) to kernel 3.8.
- Combine a stripped Meego cedartrail filesystem with Android-x86
("stripped" means a minimal filesystem that can run accelerated X window)
- Modify the guest GLES emulation libraries to communicate with the
host renderer
- Implement a host renderer which is an X application render the GL
commands from the guest

The most different part is the host renderer. However, we can refer
to the emulator code. Especially the renderer library is located under
sdk/emulator/opengl/host/libs/libOpenglRender/.


If you have any question or suggestion to the plan, feel free to send
it to the android-x86 mailing list.


Regards,
--
Chih-Wei
Android-x86 project
http://www.android-x86.org

[Christopher Price]

Here's my feedback:

* I have some concerns with the X-atop-Android pipeline. It's one I've been pitched before, in various ways. Here's the problem, what kind of overhead are we talking here? Most of these GPUs are being strained as-is, and adding an X composition atop an Android framebuffer is going to slow things down. If you have a GTX 680 from NVIDIA, this might not be such a big deal... but if you even have an Intel HD 2000 or HD 3000, I suspect things are going to be sluggish.

I propose that this driver be a fallback driver, and that the main goal continue to be getting Android-compatible GPU drivers into the mainline. We don't want to send a message to AMD and NVIDIA that what they have done (in terms of publicly-released desktop GPU Android support) is good enough. They may complain that there isn't enough interest - which is mostly because we can't innovate unless we have drivers to create innovative devices with.

* I like the idea of using the MeeGo Cedar Trail driver for Android-x86, it's something i've looked at myself recently with all these Clover Trail tablets becoming insanely cheap. ASUS had a Clover Trail Windows 8 tablet for under $400 on Amazon recently, after rebate.

I'm not sure how stable it is though - or if it will work properly. Taking an abandoned Kernel 3.2 GPU driver and modernizing it is going to be very difficult, especially since the driver itself binary. I think there may be too many bugs to get it working with a Jelly Bean-intensive GPU landscape... MeeGo 1.2 was actually less GPU intensive, and more fault-tolerant than Jelly Bean is today in my opinion.

Finally, on the Intel/PowerVR front, I question the need. I realize there are tons of devices out there, and if you have one, you really want it to work... but Intel has said quite clearly, and publicly, at IDF and CES that they are moving away from PowerVR. These devices all run Windows 8 well, I think the efforts here would be better spent into integrating the mainline GPU workflow.

* In conclusion, I think the first task has a lot of merit - creating an X composition layer that would allow for desktop GPU drivers to fire up Linux, fire up X, but draw nothing but a chainloaded Android - is a great idea. But I think for the Cedar/Clover trail GPUs, it won't work. I think this would work much better initially, by targeting a much more powerful GPU, like a modern Radeon HD or NVIDIA GTX GPU. There, you would be able to learn what works, what doesn't, and then scale down to slower GPUs like PowerVR on Intel Atom.

Also, using that approach, you could target a much more stable stack (Ubuntu + Radon Linux Driver) that would be more likely to work from day one, and then backport up to the MeeGo/Cedar/Clover driver.

[Greg McGee]

This actually plays into what is (in the amusement park of my mind) going to be a common setup with android-x86--- running x86 (or x86_64) Linux distros in a chroot for a self-hosting devel environment of sorts. (virtualbox then also becomes an option running WinX as a guest, for the all inclusive geek fests)
One of the issues is either a native xserver or Android can be accelerated---pick one.

There are a few existing Xserver apps for android that could fill the gap, and may allow you to run X11 as just another full screen Android app---with accelleration. I am unsure if they are fully open source and includeable in the project, but it might be useful to have a look at having an Android xserver with a high level of integration, rather than a native Linux version using it's own VT.

[Christopher Price]

The existing X11 server apps for Android are all unaccelerated. Canonical is trying to create a GLES-accelerated X11 server inside of Mir, where Mir would run chrooted atop Android, and could then call Mir apps or run X11 and run legacy Ubuntu apps. I think this is for Ubuntu for Android - can't say for sure, they seem to be too busy to talk of late.

The main drawbacks to that however, are that GLES and Android are still in charge. You still have to run Android-compatible graphics drivers, and you still have to operate within the confines of GLES.

Running an X server inside of Android doesn't fix anything from the standpoint of adding additional GPU driver support.

P.S. If you want to see VirtualBox+Android, go give AndroVM a try. Daniel already wired up Android's goldfish emulator to pipe GLES commands through to the X session, much as Huang I think is trying to accomplish, but in a distribution-friendly way.

The main issue there is when you actually put AndroVM to the test, it only works at tolerable levels on very high performance GPUs. An Atom GPU will choke on Angry birds. Even if you were to use a pared-down version of Linux, the overhead would still kill GPU performance I'm afraid on slower GPUs.

And even then, it's glitchy. Yes, Angry Birds will play. Go try running NOVA 3. Even on a powerful GTX card, you're going to watch it crash and burn. The problem is GLES commands do not route well through all these composition layers - it's an embedded spec meant to be piped directly, even tough all these layers make for all this stuff to be possible... it was never meant to be done for end-user stuff. It was meant purely for debugging.

I would re-iterate though that it might solve the problem of getting Android to run on powerful GPUs. We're using another method in-house for development, but it would only work for what we're developing. Others I know are working on the notion of using Linux/X to get high-performance GPUs to run Android apps... but it's a task you need to go in knowing what you're getting yourself into.

Christopher Price

ChristopherPrice.net

--
You received this message because you are subscribed to a topic in the Google Groups "Android-x86" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/android-x86/RaIP7qcVitw/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to android-x86...@googlegroups.com.
To post to this group, send email to andro...@googlegroups.com.
Visit this group at http://groups.google.com/group/android-x86?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Greg McGee]

Thanks, I had a feeling that it couldn't possibly be that simple ;-)

The other alternative that popped in my head is probably too simplistic to be doable in reality:
translate Androids graphics layer to X11 and use accelerated x11 drivers fully, as they exist.
(x11s protocol alleged speed penalty//overhead via unix pipes is virtually nil, it gets a bad rap mostly from folks who have never looked at it)

On Saturday, March 30, 2013 2:40:39 PM UTC-5, Chih-Wei Huang wrote:

[Greg McGee]

Self correcting---x11 uses Unix sockets where available, not pipes, although the overhead/speed penalty in either case is very, very low.

[Chih-Wei Huang]

2013/3/31 Greg McGee <gjm...@gmail.com>:

>
> The other alternative that popped in my head is probably too simplistic to
> be doable in reality:
> translate Androids graphics layer to X11 and use accelerated x11 drivers
> fully, as they exist.

This is eaxctly the plan is going to do.

[Chih-Wei Huang]

Indeed the AndroVMplayer is just a host renderer as described
in this plan. Unfortunately it is not open sourced (yet)
so it's hard to modify it to fit our purpose.

2013/3/31 Christopher Price <ch...@christopherprice.net>:

[Greg McGee]

Ah, so I'm not the only crazy person here.
Cool ;-).

[Chih-Wei Huang]

2013/3/31 Christopher Price <ch...@christopherprice.net>:

> Finally, on the Intel/PowerVR front, I question the need. I realize there
> are tons of devices out there, and if you have one, you really want it to
> work... but Intel has said quite clearly, and publicly, at IDF and CES that
> they are moving away from PowerVR. These devices all run Windows 8 well, I
> think the efforts here would be better spent into integrating the mainline
> GPU workflow.

I really DON'T CARE what Intel's plan is.
What does it do with me exactly?
Intel doesn't care the customers who want to run android as their favorite OS.
Intel just wants to sell more new products. It is so abominable.

If you are an android fan who (unfortunately) bought an Intel PowerVR
based product,
just tell Intel you want to use android as your favorite OS.
Tell Intel you will not buy any its new product if it is not going to
support android.
This is the only way that the things may change.

> * In conclusion, I think the first task has a lot of merit - creating an X
> composition layer that would allow for desktop GPU drivers to fire up Linux,
> fire up X, but draw nothing but a chainloaded Android - is a great idea. But
> I think for the Cedar/Clover trail GPUs, it won't work. I think this would
> work much better initially, by targeting a much more powerful GPU, like a
> modern Radeon HD or NVIDIA GTX GPU. There, you would be able to learn what
> works, what doesn't, and then scale down to slower GPUs like PowerVR on
> Intel Atom.

Well, I don't think any developer has these devices.
If you are going to donate some, I'm happy to give it a try.

> Also, using that approach, you could target a much more stable stack (Ubuntu
> + Radon Linux Driver) that would be more likely to work from day one, and
> then backport up to the MeeGo/Cedar/Clover driver.

[Douglas Santillan]

Some vendors seem to slowly release code, this is going on all around,
SunXi, Amlogic are good examples. It is like pullin' teeth though. I
am not sure if this may help, but Mediatek cpus also use PowerVR and
GPL portions of the kernel exist. Per example, Alcatel released a
bunch of tar sources available here:

http://sourceforge.net/projects/alcatel/files/

Say OT_916_20120725.tar.xz path \mediatek\source\kernel\drivers\gpu\pvr
pvrsrkm mtklfb and mtkbc are the SGX modules for Mediatek implementation

Extracted from from one of the sgxdefs.h:

/**********************************************************************
*
* Copyright(c) 2008 Imagination Technologies Ltd. All rights reserved.
*
* This program is free software; you can redistribute it and/or modify it
* under the terms and conditions of the GNU General Public License,
* version 2, as published by the Free Software Foundation.
*
* This program is distributed in the hope it will be useful but, except
* as otherwise stated in writing, without any warranty; without even the
* implied warranty of merchantability or fitness for a particular purpose.
* See the GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License along with
* this program; if not, write to the Free Software Foundation, Inc.,
* 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA.
*
* The full GNU General Public License is included in this distribution in
* the file called "COPYING".
*
* Contact Information:
* Imagination Technologies Ltd. <gpl-s...@imgtec.com>
* Home Park Estate, Kings Langley, Herts, WD4 8LZ, UK
*
******************************************************************************/

#ifndef _SGX520DEFS_KM_H_
#define _SGX520DEFS_KM_H_

Perhaps somebody would kindly use snail mail, request the sources and
see what happens.

> --
> You received this message because you are subscribed to the Google Groups "Android-x86" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to android-x86...@googlegroups.com.

[Chih-Wei Huang]

2013/3/31 Douglas Santillan <capri...@gmail.com>:

> Some vendors seem to slowly release code, this is going on all around,
> SunXi, Amlogic are good examples. It is like pullin' teeth though. I
> am not sure if this may help, but Mediatek cpus also use PowerVR and
> GPL portions of the kernel exist. Per example, Alcatel released a
> bunch of tar sources available here:
>
> http://sourceforge.net/projects/alcatel/files/
>
> Say OT_916_20120725.tar.xz path \mediatek\source\kernel\drivers\gpu\pvr
> pvrsrkm mtklfb and mtkbc are the SGX modules for Mediatek implementation

It's just the kernel driver, useless to us.

PVR is very sensitive to chip type. For example
It's not possible to use N2600 driver on Z670.
Let alone use arm driver on x86...

The key problem is not the kernel driver.
We already have kernel driver for oaktrail and cedartrail
(not sure for clovertrail)

The key problem is the userspace GLES PVR libs.
It's very sensitive to chip type and driver version.
For example, it's not possible to use libs 1.6.16.4120
with pvr driver 1.6.16.3999. It just refused to be loaded.

[Daniel Fages - android-x86]

Le 31 mars 2013 à 05:57, Chih-Wei Huang a écrit :

Indeed the AndroVMplayer is just a host renderer as described
in this plan. Unfortunately it is not open sourced (yet)
so it's hard to modify it to fit our purpose.

Hi,

I confirm AndroVMplayer is just what you describe, the main difference is that it now uses TCP connections from the host to the VM, so that it's easier for us to manage concurrent VMs and easier for us to integrate.

The host renderer libs are in fact already open source as they're part of the androVM github - https://github.com/androvm/platform_sdk/tree/androVM-4.1.1_r6.1/emulator/opengl

I cannot (yet ?) open source the current Qt-based AndroVMplayer but there's nothing related to OpenGL in it - mainly VirtualBox integration stuff.

If that helps I can release the previous SDL-based AndroVMplayer (which is just a wrapper around host renderer lib - libOpenglRender).

Concerning the performance concern raised by Christopher, I think the main bottleneck is the TCP connection between the VM and the host. Having Android running in the "same OS" as the Linux with x11 could let us use much more performant communication (as shared memory), or even directly integrate "OpenGL ES -> OpenGL" translation libraries in the Android GLES libs. 

Dan.

[Chih-Wei Huang]

2013/3/31 Daniel Fages - android-x86 <dfa...@android-x86.org>:

>
> Le 31 mars 2013 à 05:57, Chih-Wei Huang a écrit :
>
> Indeed the AndroVMplayer is just a host renderer as described
> in this plan. Unfortunately it is not open sourced (yet)
> so it's hard to modify it to fit our purpose.
>
>
> Hi,
> I confirm AndroVMplayer is just what you describe, the main difference is
> that it now uses TCP connections from the host to the VM, so that it's
> easier for us to manage concurrent VMs and easier for us to integrate.
> The host renderer libs are in fact already open source as they're part of
> the androVM github -
> https://github.com/androvm/platform_sdk/tree/androVM-4.1.1_r6.1/emulator/opengl
> I cannot (yet ?) open source the current Qt-based AndroVMplayer but there's
> nothing related to OpenGL in it - mainly VirtualBox integration stuff.

Yes, I understand that.

> If that helps I can release the previous SDL-based AndroVMplayer (which is
> just a wrapper around host renderer lib - libOpenglRender).

Thank you. It could be helpful.

> Concerning the performance concern raised by Christopher, I think the main
> bottleneck is the TCP connection between the VM and the host. Having Android
> running in the "same OS" as the Linux with x11 could let us use much more
> performant communication (as shared memory), or even directly integrate
> "OpenGL ES -> OpenGL" translation libraries in the Android GLES libs.

Totally agree.
Once we have the first implementation
we can benchmark it and see what the bottleneck is
and how to improve it.

[Christopher Price]

If you need more powerful hardware, ping me and let's get the ball rolling. I think that the penalty is large enough that it will make Cedar/Clover not pan out - but there is considerable potential for more powerful GPUs.

As to the Intel roadmap, I can commiserate with your unhappiness about the subject, but keep in mind that the MeeGo build is very prototype, it was aborted after MeeGo was cancelled months earlier. You're talking about getting GLES to run atop a buggy build of an aborted version of MeeGo (including the PowerVR driver), for which not one bug fix was ever released, let alone penciled in. All I'm saying is, don't get your hopes up for PowerVR.

Personally, I'd say you're better off trying to adapt Medfield's PowerVR Android driver to run, since stable PowerVR driver files exist for Jelly Bean x86 and ICS x86. Pulling that off might make it worth making a case for Intel to host the PowerVR binaries that they already have for Android.

Christopher Price
ChristopherPrice.net

[Douglas Santillan]

I understand. There seems to be an Intel tar Linux* PowerVR Graphics/Media Drivers see

 

https://downloadcenter.intel.com/confirm.aspx?httpDown=http://downloadmirror.intel.com/21938/eng/cdv-gfx-drivers-1.0.3_bee.tar.bz2&lang=eng&Dwnldid=21938

 

Driver versions seem newer than the ones mentioned in your reply. Hope this helps.

[Christopher Price]

While it's slightly newer, efforts to use it with X on other Linux implementations have failed. I've yet to hear one person get that driver working on Fedora or Ubuntu with even basic acceleration functional.

Intel has stated publicly that this frustration will end with the release of Valley View, which returns the Atom line to Intel-based GPUs.

I would be interested to see if the Medfield GPU driver from the RAZR i running Jelly Bean would fire up the GPU on Cedar/Clover. Unfortunately, I don't have any hardware (let alone the time) to go on that hunt. I suspect you'd run into display issues with the driver being optimized for the embedded display... but that might be easier to work around.

[Daniel Fages]

Hi
indeed I have a RAZR i running JB, I bought it just to have up to date Houdini libs.

Dan.

[Chih-Wei Huang]

The obsolete gingerbread image doesn't help.
The OpenGL ES support have a lot of change since ICS.
Even android-3.x libs won't work, not to mention with 2.3.

2013/5/12 Insignificant88 <schrei...@aol.com>:
> Hi, this may be a dumb question, but what about the 'official' Gingerbread
> image for the Z670 / Oak Trail platform?
> Doesn't they contain the driver?
>
> For example the Viewsonic viewpad 10pi. It was released with a DUAL BOOT
> solution from Archermind
> (http://en.archermind.com/column_sim.php?id=2011122210425115).
>
> You can still download the iso from
>
> http://www.cartft.com/support/il/1428
> http://www.cartft.com/support_db/support_files/CTFPAD-2_Android.zip
>
> I tried to open the img file, but i don't know how.
> Can someone else take a look at it?

> --
> You received this message because you are subscribed to the Google Groups
> "Android-x86" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to android-x86...@googlegroups.com.
> To post to this group, send email to andro...@googlegroups.com.
> Visit this group at http://groups.google.com/group/android-x86?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[bubb...@gmail.com]

This may be overly simplistic, but....

 

What version of MESA is in the Android mainline?

It seems that by just pulling the current MESA mainline into the android-x86 branch will solve 95% of these issues.

The MESA repo has drivers for the majority of GPU's (not sure aboout powerVR) and NVIDIA is reverse engineered in the Neouvou driver.

 

Seems like a big paypoff for a little bit of work.

[cj raverins]

I second that !

I managed to build 2 builds after reading this 

but I just need to figure out how to fix one problem

My ethernet or wifi doesnt want to run on my builds,

Any idea what could this be?

[Chih-Wei Huang]

2013/5/21 <bubb...@gmail.com>:

> This may be overly simplistic, but....
>
> What version of MESA is in the Android mainline?
> It seems that by just pulling the current MESA mainline into the android-x86
> branch will solve 95% of these issues.

I doubt if you have read my original post carefully.
Mesa is NOT a part of Android mainline.
It's ported by us for x86 GPUs.

Currently jb-x86 Mesa version is 8.0.5.
The Mesa mainline (9.1 branch) only supports i965 for android
because Intel engineers are working on it.
All other parts (i915, radeon) are broken.
Using mainline will NOT solve any issue, just getting worse,
unless you can fix them.

> The MESA repo has drivers for the majority of GPU's (not sure aboout
> powerVR) and NVIDIA is reverse engineered in the Neouvou driver.

Mesa never supports PowerVR, it's proprietary.
Open source implementation is impossible,
unless reverse engineering it. As I have mentioned,
GNU PowerVR project is the only open source project for it.
But it's progress is very slow.

For Nvidia, I also have said, the android porting is not finished.
You need to fix at least the drm_gralloc part.
Anyone want to work on it?

[Daniel Fages - android-x86]

Hi,

On 31 mars 2013, at 12:06, Chih-Wei Huang wrote:

2013/3/31 Daniel Fages - android-x86 <dfa...@android-x86.org>:

Le 31 mars 2013 à 05:57, Chih-Wei Huang a écrit :

Indeed the AndroVMplayer is just a host renderer as described

in this plan. Unfortunately it is not open sourced (yet)

so it's hard to modify it to fit our purpose.

Hi,

I confirm AndroVMplayer is just what you describe, the main difference is

that it now uses TCP connections from the host to the VM, so that it's

easier for us to manage concurrent VMs and easier for us to integrate.

The host renderer libs are in fact already open source as they're part of

the androVM github -

https://github.com/androvm/platform_sdk/tree/androVM-4.1.1_r6.1/emulator/opengl

I cannot (yet ?) open source the current Qt-based AndroVMplayer but there's

nothing related to OpenGL in it - mainly VirtualBox integration stuff.

Yes, I understand that.

If that helps I can release the previous SDL-based AndroVMplayer (which is

just a wrapper around host renderer lib - libOpenglRender).

Thank you. It could be helpful.

It took some time but the SDL-based AndroVMplayer source code is now available : https://github.com/androvm/SDLplayer

Did anybody begin to work on the "Hardware OpenGL ES emulation" solution of Chih-Wei's original mail of his thread ?

Dan.

Concerning the performance concern raised by Christopher, I think the main

bottleneck is the TCP connection between the VM and the host. Having Android

running in the "same OS" as the Linux with x11 could let us use much more

performant communication (as shared memory), or even directly integrate

"OpenGL ES -> OpenGL" translation libraries in the Android GLES libs.

Totally agree.
Once we have the first implementation
we can benchmark it and see what the bottleneck is
and how to improve it

--
Chih-Wei
Android-x86 project
http://www.android-x86.org

--
You received this message because you are subscribed to the Google Groups "Android-x86" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-x86...@googlegroups.com.

[Chih-Wei Huang]

2013/6/20 Daniel Fages - android-x86 <dfa...@android-x86.org>:

> Hi,
>
> On 31 mars 2013, at 12:06, Chih-Wei Huang wrote:
> If that helps I can release the previous SDL-based AndroVMplayer (which is
>
> just a wrapper around host renderer lib - libOpenglRender).
>
> Thank you. It could be helpful.
>
> It took some time but the SDL-based AndroVMplayer source code is now
> available : https://github.com/androvm/SDLplayer
> Did anybody begin to work on the "Hardware OpenGL ES emulation" solution of
> Chih-Wei's original mail of his thread ?

Many thanks!

There is a team promised to work on it.
I'll forward your message to them.
Thank you again.

[Nahkju Jeong]

Thanks..

 

But, lib/linux64 directory is missed. Please, check it up..

2013년 6월 20일 목요일 오전 6시 23분 38초 UTC+9, Daniel Fages 님의 말:

[Daniel Fages - android-x86]

Sorry for that.

Updated.

Dan.

Visit this group at http://groups.google.com/group/android-x86.

[Rishi Ranjan]

Hi Daniel,

              I am trying to run the android x86 on virtualbox but want to get the display on my own player. I was able to change the android x86 to stream open GLES commands to host.

I am using AndroVM player to start with. But when I start my VM, I keep on getting an error "Renderer error: failed to create/resize pbuffer!!".

Parameters passed to AndroVM Player:

1. I did start the AndroVM player with width and height set to width and height of my VM.
2. DPI of my VM is 123 but my display DPI is 96. So I passed in dpi of 96.

I know that Android emulator does some mapping of AVD DPI to Display dpi but I am still going through the code to understand this.

Can you please let me know if there is something I can try to make SDLPlayer work?

Thanks,
Rishi

[Azis Naufal]

Hi,

I have ASUS EeePC 1225C with Intel Atom N2600 Inside.
How can i use kernel/cdv in android-x86 4.4 RC2?
Please help, and keep kernel/cdv project alive and grow.
I love your project.

Thanks & Regards.

[Christopher Price]

I would discourage building atop binary drivers that aren’t issued by Intel. For one, they could be modified specifically for that device, especially ASUS Zenfone/Padfone. For two, they’re unlicensed and poison the open-source well.

In Radeon speak, “modern” Radeon graphics refers to the GCN core first deployed on Radeon HD 7xxx GPUs. This is the first major rewrite of the Radeon silicon since ATI was acquired by AMD, and the Mesa Radeon driver is having to be re-written from scratch - which broke Android-x86.

Radeon HD 5870M should, in theory, work with some Android-x86.org builds, possibly earlier ones.

Christopher Price

ChristopherPrice.net

On May 29, 2014, at 12:50 PM, Robert Omanon <spikey...@gmail.com> wrote:

When you guys say "Modern Radeon HD" how "modern" are we talking? In a few months I could donate a system that runs a Radeon HD 5870m, if that would be helpful.

As far as libs are concerned, would a dump of the contents of an Asus Zenfone 6 be of any use? That's where I got the Houdini libs I posts in a recent thread in this group. It runs an Intel Atom Z2580 / PowerVR SGX544MP2.

--
You received this message because you are subscribed to a topic in the Google Groups "Android-x86" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/android-x86/RaIP7qcVitw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to android-x86...@googlegroups.com.

To post to this group, send email to andro...@googlegroups.com.
Visit this group at http://groups.google.com/group/android-x86.

For more options, visit https://groups.google.com/d/optout.

[Evgeny Telny]

i very please u add support for Nvidia graphical card 7000m (Acer Aspire 5220). In next release)

суббота, 30 марта 2013 г., 21:40:39 UTC+2 пользователь Chih-Wei Huang написал:

[Antony Stone]

On Wednesday 24 September 2014 at 16:19:08 (EU time), Evgeny Telny wrote:

> i very please u add support for Nvidia graphical card 7000m (Acer Aspire
> 5220). In next release)

I think maybe you didn't read the following in the post you quoted:

> > Nvidia chip is supposed to be supported by Mesa using the nouveau
> > driver. However, the porting of nouveau to Android-x86 is not

> > finished. Currently no Android-x86 developer has Nvidia device or
> > is interesting in the porting. Nor is any vendor willing to provide us
> > with devices for the development. In short, Nvidia hardware

> > acceleration is not supported by Android-x86.

Regards,


Antony.

--
Atheism is a non-prophet-making organisation.

Please reply to the list;
please *don't* CC me.

[Mauro Rossi]

Hi Evgeny,

If you want to give a try to an experimental version of Android-x86 built with Gallium nouveau mesa driver, there are some ISO links posted in "Nouveau *experiments*" thread.

GeForce 7000M is an NV40 famility chipset, so you would find that current HAL gralloc draft implementations/experiments have some work to do to be finalized,
like for example an "Invisible mouse bug" affecting NV40 chipsets families (GeForce 6150/6200/7000) like yours.

NOTE: mouse works perfectly on those chipsets and you can manage, using keyboard to go in Settings and set Configuration to highlighting mouse coordinates, trace and setting visual effects for touch (mouse click), it is just the cursor that is invisible, but "present" so-to-speak.

When that problem will be solved your could try Android-x86 experimental image without becoming crazy to chase the invisible mouse cursor (like I do sometimes).

Looking at 'dumpsys SurfaceFlinger' output, collected on a 7400M laptop, we can even see the allocated buffer, highlighted in red, but no joy...

I am personally trying to understand if NV40 chipsets need specific surface parameters settings (memtype, tile_mode) to have "mouse cursor back again in visible wavelengths" ;-)

Mauro

SurfaceFlinger global state:
EGL implementation : 1.4 (Gallium)
EGL_KHR_image_base EGL_KHR_reusable_sync EGL_KHR_fence_sync EGL_KHR_surfaceless_context EGL_ANDROID_image_native_buffer
GLES: nouveau, Gallium 0.4 on NV46, OpenGL ES 2.0 Mesa 10.3.0-devel (git-534e493)

...
h/w composer state:
  h/w composer not present and enabled
Allocated buffers:
0x41550cb0: 4000.00 KiB | 1280 (1280) x  800 |        5 | 0x00000900
0x415f3430: 4000.00 KiB | 1280 (1280) x  800 |        5 | 0x00001a00
0x4161f750: 4000.00 KiB | 1280 (1280) x  800 |        5 | 0x00001a00
0x4161fa30: 10240.00 KiB | 1920 (2048) x 1280 |        5 | 0x00000900
0x416201b0: 4000.00 KiB | 1280 (1280) x  800 |        5 | 0x00001a00
0x41620270:  240.00 KiB | 1280 (1280) x   48 |        5 | 0x00000900
0x42ab2e20:    3.50 KiB |   22 (  32) x   28 |        1 | 0x00000933
0x42acfa60:  125.00 KiB | 1280 (1280) x   25 |        5 | 0x00000900
0x42ad1e30:  125.00 KiB | 1280 (1280) x   25 |        5 | 0x00000900
0x42ad4920: 4000.00 KiB | 1280 (1280) x  800 |        5 | 0x00000900
0x42ad4de0:  125.00 KiB | 1280 (1280) x   25 |        5 | 0x00000900
0x42bea440: 4000.00 KiB | 1280 (1280) x  800 |        5 | 0x00000900
0x42c01710:  240.00 KiB | 1280 (1280) x   48 |        5 | 0x00000900
0x42c01870:  240.00 KiB | 1280 (1280) x   48 |        5 | 0x00000900
Total allocated (estimate): 35338.50 KB