Thanks for this Could you give any info on how you found this, and possibly what the next steps from here are? I'm no expert but it seems that with this info we can potentially port to and from most distributions, potentially is a Windows port also possible? As you've guessed I've not much idea here
The information is available from here: https://wiki.archlinux.org/index.php/Intel_GMA3600 Next steps are:
It could be ported to different Linux distributions targeted to PowerVR. However; as any other software project, access to source code is needed (as well as skillful developers interested in porting the drivers).
Regarding the Windows* port, I don't think it is possible, since Linux relies on X.org graphics server along with different system calls that are no compatible with Windows SysCalls. Hence, this impacts directly on how graphics sub-systems are implemented. Ideally, POSIX compliance systems should be somehow compatible enough to enable ports at such low-level bits.
Marvin Ortega wrote:
Be aware that the current version 1.03 (10/01/2012) has the following dependencies:
- Kernel: 3.0.0
- Mesa GL: 7.9
- Xorg: 1.9
- Kernel: 3.1.0
- Mesa GL: 7.11
- Xorg: 1.11
More information available from here:
There is no getting around the Xorg version dependency, required at xorg-1.11 for the 1.0.3 driver release with which the binary-only, closed-source userspace drivers were compiled, unfortunately. Also, the Mesa GL dependency seems not to be some hard requirement. I'm running mesa as follows in my system:
$ apt-show-versions | grep mesa
libgl1-mesa-dev/precise uptodate 9.2~git1307081709.1415a1~gd~p
libgl1-mesa-dri/precise uptodate 9.2~git1307081709.1415a1~gd~p
libgl1-mesa-glx/precise uptodate 9.2~git1307081709.1415a1~gd~p
libglapi-mesa/precise uptodate 9.2~git1307081709.1415a1~gd~p
libglu1-mesa/precise uptodate 8.0.4-0ubuntu0.6
libglu1-mesa-dev/precise uptodate 8.0.4-0ubuntu0.6
mesa-common-dev/precise uptodate 9.2~git1307081709.1415a1~gd~p
mesa-utils/precise uptodate 8.0.1+git20110129+d8f7d6b-0ubuntu2
The good news is that with the open-source cedarview-drm kernel driver release, you can get around the Kernel 3.1.0 requirement from the package by using this git repository, thanks to thomas001:
git clone hxxps://github.com/thomas001/cedarview-drm.git cedarview-drm-master
(replace hxxps with https, use for Linux Kernel releases 3.7 to 3.9), or
git clone -b linux-3.5 hxxps://github.com/thomas001/cedarview-drm.git cedarview-drm-linux-35
(replace hxxps with https, use for Linux Kernel releases 3.4 and 3.5)
Now you can make use of latest kernel releases. Check out mine:
System: Host: host Kernel: 3.9.9-zen i686 (32 bit, gcc: 4.6.4)
Desktop: Xfce 4.10.2 (Gtk 2.24.10) dm: lightdm Distro: Ubuntu precise (12.04.2 LTS)
Machine: System: LENOVO product: 20126 version: Ideapad S110 Chassis: type: 10 version: Type2 - Board Serial Number
Mobo: LENOVO model: 123456789 version: Type1Sku0 Bios: LENOVO version: 5BCN29WW date: 4/10/2012
CPU: Dual core Intel Atom CPU N2800 (-HT-MCP-) clocked at 1862.00 MHz
Graphics: Card: Intel Atom Processor D2xxx/N2xxx Integrated Graphics Controller bus-ID: 00:02.0 chip-ID: 8086:0be2
X.Org: 1.11.3 driver: N/A Resolution: firstname.lastname@example.org
GLX Renderer: PowerVR SGX545 GLX Version: 2.1 Direct Rendering: Yes
Network: Card-1: Realtek RTL8101E/RTL8102E PCI Express Fast Ethernet controller
driver: r8169 ver: 2.3LK-NAPI port: 4000 bus-ID: 01:00.0 chip-ID: 10ec:8136
Card-2: Realtek RTL8188CE 802.11b/g/n WiFi Adapter driver: rtl8192ce port: 3000 bus-ID: 02:00.0 chip-ID: 10ec:8176
Drives: HDD Total Size: 500.1GB (18.1% used)
Info: Processes: 162 Uptime: 6:13 Memory: 829.0/2014.3MB Runlevel: 2 Gcc sys: 4.6.4 alt: 4.7/4.8
Client: Shell (bash 4.2.25 running in xfce4-terminal) inxi: 1.9.11
A minor note: the cedarview-drm driver does not compile if the kernel was compiled with CONFIG_CC_OPTIMIZE_FOR_SIZE=y in the config, which adds -Os to the cflags, based on my experience.
Unfortunately, I have tried the latest Linux Kernel 3.10 release and there the cedarview-drm fails to compile. It would seem that this is the limit to which the cedarview-drm codebase can be made compatible with later kernel releases, until Intel/ImgTec releases an updated driver package.
Still, NO 64-BIT accelerated drivers until Intel/ImgTec provides 64-bit support. Sorry for those expecting to see more from my post.
So, Marvin Ortega, if you have some access to ArchWiki pages and if it wouldn't be too much to ask, can you please add the above to the GMA_3600 wiki for additional reference? Thank you.
Great information. Thank you for your contribution. I've added the information to the ArchLinux wiki: https://wiki.archlinux.org/index.php/Intel_GMA3600#Cedarview-drm_module_port
Highly appreciate it. Thanks
Anything to help other unfortunate Cedar Trail owners :-) I had to scour the net and piece together scattered information. I even went as far as doing Debian unstable with Ubuntu precise repositories for xorg-1.11, which is unavailable in any Debian repositories, except from the snapshots. I found that the performance was worse that way 2D-wise, so I settled with Ubuntu precise that showed acceptable 2D performance, and compiled updated versions of packages that interest me from there.
By the way, I made a minor edit above:
git clone -b linux-3.5 hxxps://github.com/thomas001/cedarview-drm.git cedarview-drm-linux-35
You can remove the hxxps and replace it directly with https in the wiki. I only did that in the above because this forum's editor auto-formats the link if it detects one.
You can also quote me on the accuracy of the information: I myself went from 3.7 to 3.9, successfully compiling the drm driver after each kernel release with DKMS, until I hit the proverbial wall on 3.10. You can see my bug report regarding this from the git repo.
Oh, and I want to express my thanks to the great ArchWiki pages. It is an indispensable source of information, no matter the distro one is using.
And I want to thank the Arch forums (hxxps://bbs.archlinux.org/viewtopic.php?id=144445&p=1), which gave me ideas to start off my adventure on this unfortunate piece of Intel hardware.
And thank you Marvin for updating the wiki page.
I updated the wiki with minor changes. Here is the diff log: https://wiki.archlinux.org/index.php?title=Intel_GMA3600&diff=265751&oldid=265725
I'm glad you posted such valuable information. It's a pleasure updating ArchLinux wiki page. By far, the most documented, up-to-date , accurate wiki in the Linux community.
Just to clarify the accelerated, binary-only, closed-source userspace (xorg) driver was not written by Alan Cox.
The 3D part of this xorg driver has "Very limited support for OpenGL API ("big GL"). (#101 #107 #230)", taken from the Intel Linux driver package (cdv-gfx-drivers-1.0.3_bee.tar.bz2) release notes
To answer your question: nope, the in-kernel module, gma500_gfx (I guess this what you meant by "written by Alan Cox"), is a framebuffer drm driver, and it needs an xorg framebuffer driver (fbdev). It is unaccelerated (no 2D, 3D, and, video GPU accel), but provides much better 2D performance than the proprietary xorg driver (the reason being "Poor 2D rendering performance through Xlib protocol. (#9 #125 #126)").
The cedarview_gfx kernel module, from the cedarview-drm source package, may also use the xorg framebuffer driver if you configure X to do so. But if you wish to make use of the accelerated xorg driver, then you need to use the cedarview_gfx module.
Indeed I was referring to the gma500_gfx module.
Since the 2D performance of the closed source binaries (thanks Intel!) is less than the gma500_gfx and 3D OpenGL support is minimal (what I am looking for), I believe that for now my best option is to stick with the gma500 driver.
Nevertheless, thank you very much for sharing your findings! You did a great job. There are quite some people waiting for recent and decent Linux drivers. Hopefully this is a step in the right direction.
Maybe Intel can help us on that? Oh wait, they are not responding anymore; except when you swear.
If you are torn between needing a fast 2D performance for regular, day-to-day use, and accelerated video (in my case I really appreciate the hardware-assisted HD video decode playback for supported codecs) or OpenGLES for HTML/WebGL, or even basic OpenGL for 3D, then why not run two Xsessions, each with its own X configuration!
That way, you can have, say, an Xsession configured with the framebuffer driver on vt7, and another Xsession with the proprietary driver on vt8, then switch between them like virtual terminals.
And that I have yet to do. You can read more on this idea, where I first learned about it, here https://bbs.archlinux.org/viewtopic.php?id=144445&p=2
Even in the face of less-than-stellar performance of this driver release from Intel, I really see so much potential in this Atom hardware -- 64-bit, dual-core hyptherthreading, a GPU that performs well in the ARM world, hardware-assisted decode, and let me also say DirectX 10 support from Windows -- all these great things only to be curtailed by poor software support.
I really wish Intel would release updated drivers, which will soon be more than a year since last released, for Cedar Trail on Linux. The Windows side has been seeing some small increments of driver version releases, and I wish Intel would follow up the same on the Linux front.
Although, people shoud understand that until Intel receives a green light from Imagination Technologies that owns the IP Intel obtained licensed from, opening the source code to the community may never see the light of day, until reverse-engineered of course.
And one more thing...
In the interest of the foregoing discussions, I wish to share with you some of my findings regarding support on our "adopted hardware-child of Intel" 
You can check to see if C-states for this Atom is active and enabled via powertop. You can find out more from the link.