21 replies to this topic

[sindbad]

I just remembered that the Tungsten Graphics folks worked on SGX drivers at some point. Has the possibility of collaborating with them for drivers been explored? I guess ImgTec would have to agree as well.

If a gallium3d pipe driver (even closed source) were do be made for SGX, the opengl part would become trivial. However, this would be more of a long term solution as gallium3d interfaces haven't settled.

[sindbad]

So, no one knows anything about this? Is it a definite no?

[Squidge]

We have official drivers already? Why would we want others?

[Svartalf]

We have official drivers already? Why would we want others?

Because they'd be consistent with the rendering and shader behavior that the rest of Linux would have in the very near future?

'sides, I've got a faint suspicion that the driver's already that way:

http://www.intelcomm...828025dd5293b46
http://www.tungsteng...pabilities.html

Keep in mind, just because TG is doing the drivers here in the case of the GMA500, doesn't go to the driver being open, or, for that matter, what we're getting.

Edited by Svartalf, 09 July 2008 - 08:13 PM.

[icurafu]

gma500 == sgx 535 for anyone who cares.

[sindbad]

It would add a lot of flexibility, like proper OpenGL in the short term, video decoding in the slightly longer term and some other cool things.

So I take it something official with TG and ImgTec about this hasn't been explored.

[cb88]

hmm i hadn't thought of it that way.... baisically galium3d is the driver api and we could write opengl support on top of that.... LOL i had read this post before but it just hit me what it meant...

[Tom Cooksey]

My understanding of the SGX drivers is that it's a mess. ImgTec did a basic implementation and others like Intel hired Tungston to improve the ImgTec drivers. Why?

Because the ImgTec drivers don't integrate with X very well. The only thing they do is query the server for the location of windows so it can calculate clip rects - and that's done over a socket via Xlib. So, for _every_ swap buffer, the driver has to do several round trips to the server to find out if there are any windows obscuring the 3D window. That's a whole lot of over head (unless the window is full-screen, where it just blits the back buffer directly to the front buffer and ignores clip rects). So that's _all_ the integration you get. Forget texture-from-pixmap, forget compiz. None of the fancy stuff modern x.org can do is possible.

The Gallium3D SGX drivers should allow much better x.org integration and provide the DRI2 interface. The problem is that there's a whole lot of stuff that needs to mature to take advantage. X.org has a massive dependency tree - even after modulerization. DRI2 interfaces are still not finalized, the TTM isn't mainlined yet (not that the SGX drivers would use it anyway). The list goes on (Ever tried to cross-compile X.org?).
In the long term, Gallium3D drivers for the SGX on the Pandora is going to be the way to go, but I suspect you're looking at 1-2 years. There's also the issue that the work Tungston does for Intel belongs to Intel and probably wont be open source. The pandora uses _the_ competing processor to the Atom - I doubt they want to give stuff away for free having spent a fortune with Tungston. However, I'm sure Tungston would do the _exact_ same work for Pandora (or perhaps TI) if given enough cash?

In the mean time, Pandora can use an older release of KDrive (before it was folded into X.org) and the ImgTec supplied drivers. Ok, so you don't get compiz - but you can still run full-screen games, which is what the Pandora is all about! You also don't get the X.org bloat. Or you can use Qt/Embedded - but I'm biast (see this if you're curious why - hint: 10:15 slot).

[warmi]

Yeah, I would definitely agree with your Qt/Embedded recommendation

The only downside is that you won't be able to run any X based apps.

[sindbad]

Zack's presentation at Akademy shines some more light on Gallium3D. He mentions PowerVR SGX, so this may be possible (thus proper opengl). Don't get your hopes up though.

[cb88]

https://wiki.ubuntu....bedded/Graphics

pretty sure they are refering to the SGX GMA 500.... not the one in the pandora though they may be pretty similar that wiki entry leads me to believe there will be no open source official 3D driver for the SGX

how hard would it be to get the gallium3d softpipe working on the pandora trivial or not? if it were trivial it might be worth the effort for someone to start hacking on the SGX now instead of 6 months to a year from now.. though they may have to rewrite their code a little they would also have the advantage of having figured out how the chip works by that time.

@Squidge why would anyone want open source nvidia drivers we have official ones ....yeah and they are buggy crap.... a blob is a blob is a blob you have little idea what it has in it

Edited by cb88, 31 August 2008 - 04:14 AM.

[sindbad]

I haven't look into it very carefully (i should), but the softpipe should be quite portable. It does use llvm for optimisations, but that has an ARM backend nowadays. It would be quite slow though.

[cb88]

yeah i know but it would at least be the fallback for whatever hacked up driver could be put together over time\\

hmm it might be a good idea for them to implement an option in the GUI to restart X with a driver of the users choice ie softpipe or proprietary at launch anyway

editing xorg.conf is fine and all but certainly not a pretty thing to do

Edited by cb88, 31 August 2008 - 04:22 AM.

[icurafu]

Intel GMA 500 == SGX 535
Pandora GPU == SGX 530.

The difference is support for DX9 and full OpenGL 2.0 instead of ES 2.0.

530 also has mobile D3D 7.0 support.

[cb88]

you can say that all you want but it doesn't make it fact... link please... also if it is true it further reinforces the crappy driver theory

also i bet they aren't going to make a binary that has opengl 2 for arm so you can't just gou use the GMA driver it is x86 remember? the hardware can be opengl 2 capable all day long but if the driver sucks ... oh well i betting that you are in fact right that the chip is nearly identical but the driver is going to be the primary factor

Edited by cb88, 31 August 2008 - 04:54 PM.