Even With MeeGo, Poulsbo & Moorestown Are Crap
Phoronix: Even With MeeGo, Poulsbo & Moorestown Are Crap
MeeGo 1.0 was released last week and we found its netbook performance to be competitive and beat Ubuntu Netbook Remix, Moblin, and Fedora. While the performance of this joint project between Intel and Nokia may be nice, it doesn't improve the situation for the Poulsbo graphics situation under Linux...
In my opinion, Intel should just buy out PowerVR (or at least buy a controlling stake in the company) and then treat their PowerVR-based chipsets the same as their in-house chipsets (i.e. release specs under NDA (or in the clear) so that open-source drivers may be written for them).
Can't wait for those AMD based netbooks to become available. Luckily it seems we will have a choice and won't have to run windows 7 "craper edition" because intel can't/won't/whatever make a decent linux driver. And Intel used to be a very safe choice when it came to linux. Talk about shooting yourself in the foot...
I bought an ASUS EeePC 1201T from Newegg. It has an AMD CPU, GPU and motherboard, and it comes without an OS, so no Windows tax. There was a story about it on Slashdot a while back. Overall, it's a good machine. The sole drawback is its RTL8192SE WiFi chipset. For whatever reason, while all the other chipsets in the 8192 series have drivers written by Greg Kroah-Hartman, the r8192se_pci driver was written by some nameless person at Realtek. It's been pretty stable on 2.5.35-rc1, but not so much on the stock Ubuntu kernel. I've also run into an unsecured network that the driver just plain doesn't like. It will appear to connect just fine, and I can ping the gateway router just fine, but any connection attempt will time out. As if that weren't enough, running PowerTop as root will cause a kernel panic if r8192se_pci is loaded. FAIL.
Originally Posted by devius
As I said, all other aspects of the machine are great.
I like the windows tax free part. What about its battery life? It does use a cpu based on an old design that's not very power efficient. The biggest reason why I bought the 1000H was its battery life that was the best at that time.
When I mentioned AMD I was refering to the fusion processors which are said to be powerful yet power efficient. When these come out, if they can live up to the expectations, they will probably be a good option.
An interesting thing I note, after rereading your article... you mention about intel's failed attempt in the past to get the DRM into the kernel... first off, the response wasn't a matter of "drop dead and go to hell"... it was simply a matter of some adjustments needed to the proposed DRM. It looks (from the DRI list) that Greg was going to make the (very minor) changes needed to get the DRM into staging, went on vacation, and dropped the ball.
I really see no reason why, given everything that was said on the DRI list, that they wouldn't be able to get this DRM into staging... possibly requiring some changes, but I don't see it as being particularly far off.
Battery life is acceptable. It uses a Neo CPU, which is more efficient than a Turion, but not as efficient as the Atom. It looks like with FGLRX (for GPU power management) I can get 3-4 hours on a charge, which I think is in line with the expected battery life under Windows. I've been trying the 2.6.35-rc1 kernel, and it looks like I can get comparable battery life with that if I set the options for the radeon kernel module properly, which is good because FGLRX is a pain (poor 2D performance, no KMS).
Originally Posted by devius
Well, the first drm push was rejected mainly on account of a complete lack of open source userspace drivers. I thought that the objective in their new driver was to be able to get some basic open source functionality to work with the DRM and just limit the proprietary add-ons to certain advanced functionality, like 3D acceleration and video decoding...
In any case, it matters less for it to be included in mainline than it matters that there is simple ***SOME KIND*** of support for their hardware. SGX535 hasn't worked properly in any version of Xorg server newer than 1.6. Now hopefully the various userspace driver(s) will start to show up soon.
Now the big question on my mind is this: what is the difference between these two drivers? I.e. the updated psb driver and the emgd driver? I've seen hints within meego previously of there being two drivers -- one classic mesa and one G3D.... is that the difference? That the emgd drm is to support the new G3D driver? Or is one mainline and the other advanced/binaryblob? Presumably the one that's tagged mainline:never (emgd) is to be a blob driver? I also note that the emgd driver appears to come with a bunch of video decoder firmware....
AFAICS, there are up to 6 (yes, six) drivers for Intel products based on SGX535.
Originally Posted by droidhacker
- 1 driver for Canmore/Sodaville
- 1 driver for US15W (from UMG)
- 1 driver for MRST (DRI2 capable), that also includes support for older US15W
- 1 driver for US15W (IEGD 10.x)
- 1 driver for MRST/US15W with support for Android (OpenGL ES)
- 1 driver for MRST/US15W. That new EMGD that looks derived from IEGD.
The "psb" drivers have two branches. What people have for US15W + some updates to Intel customers. The newer branch, that supports dri2 and other features for VA-API, is targetted to Moorestown users, but it could also work with older Poulsbo. This is not publicly available because the platforms are not publicly available either... Thinking about it further, there might be three branches actually: the one with support for Android platforms.
The "iegd" driver is the officially supported driver from Intel. It has regular updates (every quarter). VA-API wise, differences between psb and iegd is the way vaPutSurface() is implemented. IEGD is more power efficient, but has fewer VA-API features implemented (for now).
The "emgd" driver is totally unknown to me. It looks derived from IEGD.
I suspect that the EMGD may mean the end for US15W support from IEGD. The reason for doing this is simple: The SGX535 is non-intel IP, the rest of IEGD is for intel-IP GPUs. That basically means that implementing new levels of support for IEGD for intel-IP requires the added step of intel implementing the same level of support for non-intel-IP and requires 3rd party approval.
Originally Posted by gbeauche