Discussion:
The plan to enable GLES hardware acceleration for unsupported GPUs
(too old to reply)
Chih-Wei Huang
2013-03-30 19:40:39 UTC
Permalink
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
2013-03-30 21:39:53 UTC
Permalink
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.
Post by 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
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
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
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
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
git clone http://git.android-x86.org/kernel/cdv
- 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
--
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+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To post to this group, send email to android-x86-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
Visit this group at http://groups.google.com/group/android-x86?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Chih-Wei Huang
2013-03-31 05:12:29 UTC
Permalink
Post by Christopher Price
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.
Post by Christopher Price
* 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.
Post by Christopher Price
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.
--
Chih-Wei
Android-x86 project
http://www.android-x86.org
Douglas Santillan
2013-03-31 06:15:06 UTC
Permalink
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-support-1AXoQHu6uovQT0dZR+***@public.gmane.org>
* 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.


On Sat, Mar 30, 2013 at 11:12 PM, Chih-Wei Huang
Post by Chih-Wei Huang
Post by Christopher Price
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.
Post by Christopher Price
* 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.
Post by Christopher Price
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.
--
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.
Visit this group at http://groups.google.com/group/android-x86?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Chih-Wei Huang
2013-03-31 07:25:51 UTC
Permalink
Post by 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
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.
--
Chih-Wei
Android-x86 project
http://www.android-x86.org
Douglas Santillan
2013-04-04 01:28:16 UTC
Permalink
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.
Post by Chih-Wei Huang
Post by 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
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.
--
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
Visit this group at http://groups.google.com/group/android-x86?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
--
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+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To post to this group, send email to android-x86-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
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
2013-03-31 02:10:59 UTC
Permalink
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.
Post by 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
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
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
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
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
git clone http://git.android-x86.org/kernel/cdv
- 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
--
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+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To post to this group, send email to android-x86-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
Visit this group at http://groups.google.com/group/android-x86?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Christopher Price
2013-03-31 02:22:14 UTC
Permalink
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
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.
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
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
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
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
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
git clone http://git.android-x86.org/kernel/cdv
- 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
--
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.
Visit this group at http://groups.google.com/group/android-x86?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
--
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+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To post to this group, send email to android-x86-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
Visit this group at http://groups.google.com/group/android-x86?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Chih-Wei Huang
2013-03-31 03:57:19 UTC
Permalink
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.
Post by 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.
Daniel Fages - android-x86
2013-03-31 09:33:08 UTC
Permalink
Post by 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.
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.
--
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+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To post to this group, send email to android-x86-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
Visit this group at http://groups.google.com/group/android-x86?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Chih-Wei Huang
2013-03-31 10:06:07 UTC
Permalink
Post by 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.
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.
Post by Chih-Wei Huang
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.
Post by Chih-Wei Huang
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+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To post to this group, send email to android-x86-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
Visit this group at http://groups.google.com/group/android-x86?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Christopher Price
2013-03-31 10:31:22 UTC
Permalink
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
Post by Chih-Wei Huang
Post by 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.
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.
Post by Chih-Wei Huang
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.
Post by Chih-Wei Huang
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 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.
Visit this group at http://groups.google.com/group/android-x86?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
--
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+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To post to this group, send email to android-x86-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
Visit this group at http://groups.google.com/group/android-x86?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Rishi Ranjan
2014-05-14 02:33:46 UTC
Permalink
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
Sorry for that.
Updated.
Dan.
Thanks..
But, lib/linux64 directory is missed. Please, check it up..
Post by Chih-Wei Huang
Hi,
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
Visit this group at http://groups.google.com/group/android-x86?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
--
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
.
Visit this group at http://groups.google.com/group/android-x86.
For more options, visit https://groups.google.com/groups/opt_out.
--
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+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To post to this group, send email to android-x86-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
Visit this group at http://groups.google.com/group/android-x86.
For more options, visit https://groups.google.com/d/optout.
Greg McGee
2013-03-31 02:51:47 UTC
Permalink
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)
Post by 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
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
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
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
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
git clone http://git.android-x86.org/kernel/cdv
- 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
--
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+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To post to this group, send email to android-x86-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
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
2013-03-31 02:55:47 UTC
Permalink
Self correcting---x11 uses Unix sockets where available, not pipes,
although the overhead/speed penalty in either case is very, very low.
Post by 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
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)
Post by 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
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
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
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
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
git clone http://git.android-x86.org/kernel/cdv
- 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
--
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+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To post to this group, send email to android-x86-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
Visit this group at http://groups.google.com/group/android-x86?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Chih-Wei Huang
2013-03-31 03:43:15 UTC
Permalink
Post by Greg McGee
The other alternative that popped in my head is probably too simplistic to
translate Androids graphics layer to X11 and use accelerated x11 drivers
fully, as they exist.
This is eaxctly the plan is going to do.
Greg McGee
2013-03-31 05:02:11 UTC
Permalink
Ah, so I'm not the only crazy person here.
Cool ;-).
Post by Chih-Wei Huang
Post by Greg McGee
The other alternative that popped in my head is probably too simplistic
to
Post by Greg McGee
translate Androids graphics layer to X11 and use accelerated x11 drivers
fully, as they exist.
This is eaxctly the plan is going to do.
--
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+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To post to this group, send email to android-x86-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
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
2013-03-31 02:54:59 UTC
Permalink
Self correcting---x11 uses Unix sockets where available, not pipes,
although the overhead/speed penalty in either case is very, very low.
Post by 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
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
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
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
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
git clone http://git.android-x86.org/kernel/cdv
- 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
--
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+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To post to this group, send email to android-x86-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
Visit this group at http://groups.google.com/group/android-x86?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Insignificant88
2013-05-12 01:23:20 UTC
Permalink
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?
Post by 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
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
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
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
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
git clone http://git.android-x86.org/kernel/cdv
- 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
--
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+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To post to this group, send email to android-x86-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
Visit this group at http://groups.google.com/group/android-x86?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Chih-Wei Huang
2013-05-14 06:06:13 UTC
Permalink
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.
Post by Insignificant88
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?
Post by 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
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
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
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
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
git clone http://git.android-x86.org/kernel/cdv
- 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
--
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
Visit this group at http://groups.google.com/group/android-x86?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
--
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+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To post to this group, send email to android-x86-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
Visit this group at http://groups.google.com/group/android-x86?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
b***@public.gmane.org
2013-05-21 14:24:35 UTC
Permalink
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.
--
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+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To post to this group, send email to android-x86-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
Visit this group at http://groups.google.com/group/android-x86?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
cj raverins
2013-05-21 19:22:41 UTC
Permalink
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?
Post by b***@public.gmane.org
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.
--
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+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To post to this group, send email to android-x86-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
Visit this group at http://groups.google.com/group/android-x86?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Chih-Wei Huang
2013-05-22 03:29:27 UTC
Permalink
Post by b***@public.gmane.org
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.
Post by b***@public.gmane.org
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?
Azis Naufal
2014-05-29 07:58:07 UTC
Permalink
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.
Robert Omanon
2014-05-29 16:50:53 UTC
Permalink
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 the Google Groups "Android-x86" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-x86+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To post to this group, send email to android-x86-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
Visit this group at http://groups.google.com/group/android-x86.
For more options, visit https://groups.google.com/d/optout.
Christopher Price
2014-05-30 12:14:43 UTC
Permalink
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
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.
Visit this group at http://groups.google.com/group/android-x86.
For more options, visit https://groups.google.com/d/optout.
--
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+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To post to this group, send email to android-x86-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
Visit this group at http://groups.google.com/group/android-x86.
For more options, visit https://groups.google.com/d/optout.
Evgeny Telny
2014-09-24 14:19:08 UTC
Permalink
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
Post by 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
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
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
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
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
git clone http://git.android-x86.org/kernel/cdv
- 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
--
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 android-***@googlegroups.com.
Visit this group at http://groups.google.com/group/android-x86.
For more options, visit https://groups.google.com/d/optout.
Antony Stone
2014-09-24 14:25:40 UTC
Permalink
Post by Evgeny Telny
i very please u add support for Nvidia graphical card 7000m (Acer Aspire
5220). In next release)
Post by Chih-Wei Huang
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.
--
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 android-***@googlegroups.com.
Visit this group at http://groups.google.com/group/android-x86.
For more options, visit https://groups.google.com/d/optout.
Mauro Rossi
2014-09-24 19:04:59 UTC
Permalink
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
--
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 android-***@googlegroups.com.
Visit this group at http://groups.google.com/group/android-x86.
For more options, visit https://groups.google.com/d/optout.
Loading...