why did intel get tungsten to write drivers for gma 500 (imgtec powervr sgx)?

i'm non tech but i just wondered what tungsten have over img's own driver team - on their own design?
is this somehow about optimally modding drivers in line with something peculiar to the atom cpu instruction set?
like i stated, i don't really know what i'm talking about
would anyone care to enlighten me without baffling me too much?
just some sort of reasoning would be nice if it doesn't fall under some sort of nda umbrella
ta
 
Warning, wild guess follows ;)

Tungsten Graphics is headed by Brian Paul who has more than 15 years of experience developing OpenGL libraries (look at Mesa 3d history). They are some other very experienced programmers in that company. And on top of that, they only deal with graphics drivers.

Compare that to a small company that also design chips...

If I were Intel, I have no doubt I would chose TG over IMG for my drivers.
 
Not to mention Tungsten has some very interesting tools under their belt. It also ties into open source.

I suggest reading some of Zack Rusin's (zrusin.blogspot.com) blogs about Tungsten, and graphics in general.
 
Intel had previously used Tungsten for various integrated "intel" graphics and so had a good relationship with them and obviously were happy they knew what they needed. Also remember that Intels own in-house graphics are in some ways not dissimilar to IMG, in that they use a form of tile-based and deferred rendering.

As has already been said, the Atom is not only for windows but for mobile OSes, and again Tungsten has a lot of experience in that general area

I assume that IMG provide the basic driver primitives etc to Tungsten for them to optimise, both for the Atom platform and to Intels exact requirements .
 
Experience or not, the graphics drivers for SGX based SoCs up to now are not delivering the same graphics performance as the PVR reference drivers. Those interested may contact Harold; he may be able to give a rough estimate what the ballpark in difference is.

Afaik Intel or Tungsten for that matter are not using the reference drivers, but could also be wrong.

Tungsten Graphics is headed by Brian Paul who has more than 15 years of experience developing OpenGL libraries (look at Mesa 3d history). They are some other very experienced programmers in that company. And on top of that, they only deal with graphics drivers.

Compare that to a small company that also design chips...

If I were Intel, I have no doubt I would chose TG over IMG for my drivers.

Considering the above I don't see where the "obvious" choice is. If IMG would not deliver reference drivers it would be a totally different story. It would be highly unlikely that a 3rd party can write better drivers than the IP designing company itself, especially when you have to deal with a quite "unique" architecture like the PowerVR.

If I judge by Intel's graphics drivers up to today, there's nothing ever been in those to write home about. I guess castrating hardware through drivers is another sign of any kind of "experience" heh.
 
Experience or not, the graphics drivers for SGX based SoCs up to now are not delivering the same graphics performance as the PVR reference drivers. Those interested may contact Harold; he may be able to give a rough estimate what the ballpark in difference is.
I didn't know Tungsten already had delivered drivers. For instance, IMG still hasn't delivered drivers that support X on OMAP35; all I have seen is a beta driver for the framebuffer.

Unless someone posts hard numbers, I will take that as a guessing like I said my post was.
Considering the above I don't see where the "obvious" choice is. If IMG would not deliver reference drivers it would be a totally different story. It would be highly unlikely that a 3rd party can write better drivers than the IP designing company itself, especially when you have to deal with a quite "unique" architecture like the PowerVR.
My experience is that it's not because you're the company designing an IP that you're the best candidate to provide efficient software that makes use of it. And no I am not saying that IMG doesn't have excellent developers and drivers, I am just saying that Tungsten have excellent developers with a long experience, and I don't have evidence that IMG has such a team.
If I judge by Intel's graphics drivers up to today, there's nothing ever been in those to write home about. I guess castrating hardware through drivers is another sign of any kind of "experience" heh.
Are you judging based on previous drivers written internally at Intel or on something else?
 
I didn't know Tungsten already had delivered drivers. For instance, IMG still hasn't delivered drivers that support X on OMAP35; all I have seen is a beta driver for the framebuffer.

Unless someone posts hard numbers, I will take that as a guessing like I said my post was.

Well then here's a challenge to you to prove that through the Tungsten drivers actually hardware vertex shading is working and not a software driven sollution.

My experience is that it's not because you're the company designing an IP that you're the best candidate to provide efficient software that makes use of it. And no I am not saying that IMG doesn't have excellent developers and drivers, I am just saying that Tungsten have excellent developers with a long experience, and I don't have evidence that IMG has such a team.

Your experience should tell you that in such a case company X contacts IP designing company in order to consult for A, B, C etc in order to find out how X, Y or Z works. As long as something like that doesn't occur it won't give you an adequate result. IMG has both a DevRel department and a competent driver team where their experience counts from the late 90's till today and its size should be roughly equivalent to ARM's Falanx engineering team. In fact they're eager to support as many sw platforms as possible unlike some competing IHVs that support namely Windows Mobile and call it a day.
 
Well then here's a challenge to you to prove that through the Tungsten drivers actually hardware vertex shading is working and not a software driven sollution.
I said I was "wild guessing". If you have more insight (and it seems you have) then it's OK. But we still don't have any proof :)

IMG has both a DevRel department and a competent driver team where their experience counts from the late 90's till today and its size should be roughly equivalent to ARM's Falanx engineering team. In fact they're eager to support as many sw platforms as possible unlike some competing IHVs that support namely Windows Mobile and call it a day.
I may have sounded negative to IMG, it was not my intent, I was positive to Tungsten in fact.

As far as IMG support goes, they will indeed provide OpenGL ES/VG drivers for Linux; but a decision had to be taken between FB and X11 for OMAP3, we'll get X11. That certainly is much better than Windows only, but might frustrate some embedded developers (not me BTW ;)).
 
I said I was "wild guessing". If you have more insight (and it seems you have) then it's OK. But we still don't have any proof :)

I don't think any IMG employee can discuss any such matters in public, since its a way too delicate issue. There's an onboard firmware that sits there unused and I've already said too much I guess.

I may have sounded negative to IMG, it was not my intent, I was positive to Tungsten in fact.

I don't think anyone (with a bit common sense) has anything against any company per se. Since you sound like a developer you very well know what the performance disrepancies are between software and hardware vertex processing and I'm also quite positive that you have both the experience and tools to find out on an ATOM platform whether it's the case or not.

In the end it boils down to Intel's responsibility; when you sell a core to your partners with X triangle throughput then it should actually be able to deliver those rates. My former comment about Intel's philosophy concerning graphics comes in exactly here. It took them eons to enable hardware geometry processing on their D3D10 IGPs, let alone deliver a D3D10 compliant driver. Then again who cares about performance on such small cores, when they're still selling in a gazillion of pieces....
 
Back
Top