Intel's Special Driver For Poulsbo Uses Gallium3D

[phoronix]

Phoronix: Intel's Special Driver For Poulsbo Uses Gallium3D

Yesterday afternoon we ran a story on a new Linux driver for the Intel Poulsbo chipset, which right now is known for being notorious with its troubling Linux support. However, Intel apparently had been working on a new "special driver" that the Linux Foundation was showing off recently in Munich at a mobile development camp...

http://www.phoronix.com/vr.php?view=NzY2Mg

[bugmenot]

bam! that's very interesting. and it's funny to see that they use TTM instead of GEM.

it's an interesting mix of closed and open source software. too bad that it can't be 100% open source.

[dilettante]

If this works with Sodaville, does this mean it'll work for Sodaville's predecessor, Canmore? Canmore also has a Poulsbo integrated in the SoC.

[d2kx]

That would have been excellent news if the Gallium3D driver wouldn't be closed source. But it's still better than a fully closed source stack.

[djtm]

I'm just happy if I finally have a working driver!!!

The netbook they used looked like an MSI U110, which currently does not work at all with Linux poulsbo drivers as far as I've tried it...

[Kazade]

Wait. Correct me if I'm wrong, but if the new driver uses Gallium3D, that would mean all calls from the closed driver will pass through the open Gallium3D layer...

So doesn't that mean that it would be quite easy to trace exactly what the closed source driver is doing and then create an open source driver that does the same?

Luke.

[val-gaav]

The new DRM code, which the developers will be working on merging upstream soon (after a failed attempt with their older code),

I just hope it will not be accepted ... VIA tried the same and it wasn't accepted or was it in the end ?

Anyway a year ago I said somewhere on those forums that intel is the number one as far as open drivers go and AMD/ATI is second (and nvidia non existant :D ) Right now though AMD/ATI is IMHO the number one. The poulsbo mess moves intel to a second place.

[Ant P.]

Wait. Correct me if I'm wrong, but if the new driver uses Gallium3D, that would mean all calls from the closed driver will pass through the open Gallium3D layer...

So doesn't that mean that it would be quite easy to trace exactly what the closed source driver is doing and then create an open source driver that does the same?

Luke.

I think that's the idea. PowerVR are being jerks, so Intel have given them what they want in a way that completely undermines them.

[Svartalf]

I think that's the idea. PowerVR are being jerks, so Intel have given them what they want in a way that completely undermines them.

I'd concur...but don't make the rumblings of that TOO loud. ;)

If something does come of it, it'd be nice to have FOSS drivers for the OMAP3... ;)

[Veerappan]

I'd concur...but don't make the rumblings of that TOO loud. ;)



Agreed. There's no reason a debug version of mesa couldn't be used to create an open-source version of this driver, and Intel very well knows this... but as you said, mum's the word. Except that it's already been posted publicly...

On the other hand, I'm really glad to see usable 3D acceleration, and in addition to video acceleration, for PowerVR chips in Linux. I could definitely see a future use for a mini-ITX atom/arm + powervr board as a mythtv front end, especially if there's full video decode acceleration. The power use should be fantastic, and it might still have enough performance for NES/SNES emulation (dare I hope for N64?).

[NeoBrain]

They could just as well fork Mesa into that 3D support blob as well, making it impossible to trace Gallium3D calls, couldn't they? That's at least how I understand Mesa's MIT license.

[cruiseoveride]

the closed-source component, which is the Gallium3D code to provide some fast OpenGL acceleration


Why is it that the really useful stuff is never open source?

[dfx.]

this news about blob-thing sucking from "new api for easy and simple driver implementation" is a very very disturbing.

bad tendency.

even whole "GEM except TTM, UXA instead EXA, overcomplicated stuff over 'modesetting_drv'\Gallium" wasn't cheering at all...

[MostAwesomeDude]

This is not as cool as you might think.

First, this driver uses an older Gallium API, probably version 0.1, so most of the current tools and state trackers won't magically work until it's updated.

Second, although dumping Gallium calls is a very easy trick due to trace and rbug, it doesn't help since those calls are one level above the closed-source layer. Since the DRM is open-source, however, you could definitely just use a trivial state tracker like python or dri to dump tiny bits of state, revenge-style, out of DRM, and build a reverse-engineered driver that way.

Third, Imagination has historically been absolutely horrible about code licensing terms, and I for one will not be surprised if this code includes the same "I agree to not reverse-engineer this shit for any reason" clause as the license that came with their GLES blob for OMAP3xxx chipsets. I was part of a team last year (the OSWALD project) that wanted to use SGX code and the team ended up shipping no 3D at all because of the licensing conditions. You may note that TG/VMWare has been sitting on this code for a while, and that's because Imagination's a company that really just doesn't like the open-source community.

~ C.

[cruiseoveride]

Just when I thought Intel was becoming less evil!

[Kano]

Interesting, is the vaapi part open source or binary?

[Veerappan]

This is not as cool as you might think.

First, this driver uses an older Gallium API, probably version 0.1, so most of the current tools and state trackers won't magically work until it's updated.

Second, although dumping Gallium calls is a very easy trick due to trace and rbug, it doesn't help since those calls are one level above the closed-source layer. Since the DRM is open-source, however, you could definitely just use a trivial state tracker like python or dri to dump tiny bits of state, revenge-style, out of DRM, and build a reverse-engineered driver that way.

Third, Imagination has historically been absolutely horrible about code licensing terms, and I for one will not be surprised if this code includes the same "I agree to not reverse-engineer this shit for any reason" clause as the license that came with their GLES blob for OMAP3xxx chipsets. I was part of a team last year (the OSWALD project) that wanted to use SGX code and the team ended up shipping no 3D at all because of the licensing conditions. You may note that TG/VMWare has been sitting on this code for a while, and that's because Imagination's a company that really just doesn't like the open-source community.

~ C.

I could dream... and then have my dreams crushed like a kid who just got back from Trick or Treating on Halloween and having their parents take away everything with sugar on it...

[BlackStar]

Third, Imagination has historically been absolutely horrible about code licensing terms, and I for one will not be surprised if this code includes the same "I agree to not reverse-engineer this shit for any reason" clause as the license that came with their GLES blob for OMAP3xxx chipsets

It's well known that Imagination Technologies is managed by morons, but the kernel module *is* GPL after all and there's no way they can stop people from modifying it once the shit hits the fan, so to speak.

This no-RE clause is pretty common fare and it hasn't really stopped anyone from picking blobs apart before (WiFi drivers immediately sprint to mind, but you could probably find examples in any category with a little digging). Clean room RE is protected pretty much everywhere in the world, so they don't have much to stand on.

Granted, there's a real danger of patent lawsuits here, but Imagination would have to be even larger morons than they currently are to go down that road.

[hubick]

Will this work on Menlow then? I don't even care about fast video or 3D, at this point I just want my web browser to work - the open source bits are enough for that, right? The VESA driver in Fedora 10 didn't even support my custom screen resolution out of the box, so I just gave up - I don't really have any time to mess around.

[mirza]

IMHO these new drivers are last minute fix (probably with big additional costs) of badly planned and executed project (Poulsbo). Result: by licensing Imagination technology Intel damaged perception of own HW and SW competence for mobile market.

[dashcloud]

Phoronix: Intel's Special Driver For Poulsbo Uses Gallium3D
...the video content shown in the videos were running with 1080i, due to the lack of 1080p content and testing.


I'm really disappointed in them here- this is a solved problem. Why didn't they do what every other company/individual who needs to demo HD content on their device/whatever do: Show the Big Buck Bunny movie. Sure, at this point, folks may have seen it a lot, but it fits the bill perfectly- it's completely free for any use, and has the original frames available for download & re-rendering if you need a different resolution than the ones currently available.

It's no Planet Earth torture clip, but then so few are.

[zapp42]

http://edc.intel.com/Software/Downloads/IEGD/#overview

Yes, it's closed, too, but it works quite well.

[AdamW]

This isn't much different from the existing situation. The current driver's X.org and kernel module components are open source, the closed source bits are the Mesa DRI driver and the VAAPI video playback acceleration widget. So basic 2D operation is open source, 3D and video playback acceleration are closed. Sounds much like this 'new' driver, in other words, they're just moving to some spiffy new technologies. (Which they'll probably implement just as badly as they implemented the old ones in the existing fricking driver).

Personally I care far less about spiffy new technologies than about them damn well open sourcing the code like they said they were going to for all their graphics hardware, years ago.

Oh well, at least if the new driver supports X.org server 1.7 it'll work on Fedora 12. Sigh.

[AdamW]

http://edc.intel.com/Software/Downloads/IEGD/#overview

Yes, it's closed, too, but it works quite well.

That's more or less the same code as the psb driver you can get out of Ubuntu repositories, that is packaged for Fedora and Mandriva. It doesn't have any features beyond that implementation of the driver, the difference is primarily the delivery method. The IEGD driver is a pain to work with from a packaging perspective, given that it lives inside a Windows installer inside a 100+MB zip file behind an authentication wall.

The new IEGD version which is dated October 1st may have somewhat later code than the last psb version sent to Ubuntu repos (which was last touched in June), but I haven't had time to poke it yet.

[gbeauche]

That's more or less the same code as the psb driver you can get out of Ubuntu repositories, that is packaged for Fedora and Mandriva. It doesn't have any features beyond that implementation of the driver, the difference is primarily the delivery method. The IEGD driver is a pain to work with from a packaging perspective, given that it lives inside a Windows installer inside a 100+MB zip file behind an authentication wall.

The new IEGD version which is dated October 1st may have somewhat later code than the last psb version sent to Ubuntu repos (which was last touched in June), but I haven't had time to poke it yet.

Adam, this is not the same driver. Those are different branches and even different teams.

[AdamW]

gwenole: ah, really? thanks for the correction. I think I'm still correct that the feature support is the same between the two, though.

[gbeauche]

gwenole: ah, really? thanks for the correction. I think I'm still correct that the feature support is the same between the two, though.

The main difference is IEGD is the officially maintained driver and problems will be escalated to engineering the usual way through Intel Premier Support. Now features-wise, well that's different too. e.g. IEGD does not require any special libdrm installation.