Gallium3d Sgx Drivers
Posted 19 June 2008 - 08:39 AM
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.
Posted 09 July 2008 - 04:22 PM
Posted 09 July 2008 - 07:37 PM
Posted 09 July 2008 - 08:09 PM
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:
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.
Posted 10 July 2008 - 04:55 AM
So I take it something official with TG and ImgTec about this hasn't been explored.
Posted 11 July 2008 - 04:13 AM
Posted 11 July 2008 - 11:14 PM
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).
Posted 12 July 2008 - 02:12 AM
The only downside is that you won't be able to run any X based apps.
Posted 31 August 2008 - 04:06 AM
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.
Posted 31 August 2008 - 04:15 AM
Posted 31 August 2008 - 04:19 AM
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.
Posted 31 August 2008 - 04:57 AM
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.
Posted 31 August 2008 - 04:53 PM
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.