New hope regarding the graphics driver?

[ivanovic]

In case you have not seen this article yet, it might interest you: http://www.phoronix...._item&px=OTg3MA


Looks like TI might be working on a new open source driver for the OMAP platform. Maybe this also tackles the chip shipped in the pandora. That is: The driver seems to be 2D only at the moment, but the dev working on it seems to at least think that there might be some more stuff within a month, too. So far it is clearly not usable, but it might be a viable alternative "some time in the future".


Of course this driver won't be fast and stable right from the start. But honestly, regarding stable the current driver really does lack a lot. The main benefit of an open source driver would be that it is actually possible to *fix* issues instead of just complaining about them existing and never expecting an update/fix.


So lets hope that there really will be an open source driver especially including a 3D part, too (no idea if this will ever happen!). Maybe this driver will be built upon mesa for 3D which would mean that *full* OpenGL should be possible as well as OpenGL ES 2.0...

 

[EvilDragon]

Sounds good

 

[Nintendo]

Awesome stuff!

 

[fusion_power]

Sounds interesting. But they also talk about Linux 3.3 Kernel which is far away and I guess to far away for the Pandora. ^^" AFAIk, the next Kernel Update on what Notaz works is not even 3.0. maybe he can build the new driver in the older kernel somehow but I guess this would be even more work than it is already.

 

[notaz]

This currently has nothing to do with SGX though, only another layer on top of DSS2 (2D part), which has been open for a long time. And it's unlikely to improve anything for pandora, except making it possible to try novelties like Wayland perhaps.

 

[fusion_power]

our mate notaz, always painfully down to earth

Yupp, as usual, the truth hurts. ^^"

 

[Linopoly]

So lets hope that there really will be an open source driver especially including a 3D part, too (no idea if this will ever happen!). Maybe this driver will be built upon mesa for 3D which would mean that *full* OpenGL should be possible as well as OpenGL ES 2.0...

Mesa is a software OpenGL implementation, so it actually doesn't need driver support other than for rendering the final frames. You can use it right now if you want.

 

[ivanovic]

So lets hope that there really will be an open source driver especially including a 3D part, too (no idea if this will ever happen!). Maybe this driver will be built upon mesa for 3D which would mean that *full* OpenGL should be possible as well as OpenGL ES 2.0...

Mesa is a software OpenGL implementation, so it actually doesn't need driver support other than for rendering the final frames. You can use it right now if you want.

Not exactly/completely true. Mesa is an OpenGL implementation supporting various "render backends", one of those being software based. Though on devices like the Pandora softwarerendering is basically completely unintersting since the CPU is too slow to handle this additional load. So for Mesa to provide hardware accelerated 3D you also need the "correct" DRM (not the copy protection kind!) bits so that it can communicate with the hardware.


Basically in a common Linux setup eg in case when using the AMD/ATI proprietary driver you'd have to install this to get the equivalent in OpenSource software:


1) (Kernel) DRM


2) DDX (Display Driver for X)


3) libdrm


4) Mesa (the actual implementation of OpenGL and various other acceleration bits)


What is currently missing for 3D OpenSource drivers for the PowerVR chips is the kernel DRM side as well as the part in mesa.

 

[Linopoly]

I was kind of misleading, but really what I'm trying to say is that it's not just the DRM and userspace components of a driver that are missing if one wants non-ES support. The main reason the ES spec exists is to free hardware vendors from implementing a bunch of miscellaneous features that aren't worth the chip real-estate in embedded contexts. It's basically OpenGL 2.0 with all of those features removed. A driver supporting OpenGL ES is going to be at least as fast as a comparable OpenGL driver, because it only has to support a subset of the features. It's also going to expose all of the features of the hardware, either through the base spec, or through extensions, since that's the API that nearly all customers are going to be using to access the hardware. If non-ES OpenGL support isn't going to result in improved speed or new features, what is there to be excited about?

 

[alastor]

I was kind of misleading, but really what I'm trying to say is that it's not just the DRM and userspace components of a driver that are missing if one wants non-ES support. The main reason the ES spec exists is to free hardware vendors from implementing a bunch of miscellaneous features that aren't worth the chip real-estate in embedded contexts. It's basically OpenGL 2.0 with all of those features removed. A driver supporting OpenGL ES is going to be at least as fast as a comparable OpenGL driver, because it only has to support a subset of the features. It's also going to expose all of the features of the hardware, either through the base spec, or through extensions, since that's the API that nearly all customers are going to be using to access the hardware. If non-ES OpenGL support isn't going to result in improved speed or new features, what is there to be excited about?

Don't you want to be able to play any new open source game you come across on the net ? Nearly all of open source game engines DO NOT support OpenGL ES. And I know for sure that all of people here want OpenGL 2 or 3 support and not just GLES1, GLES2, EGL.


The SGX family would easily handle OpenGL - just write the kernel+userspace driver.


After all the devs know what there are doing:


http://elinux.org/Create_Open_Source_PowerVR_GPU_driver


http://libreplanet.org/wiki/GroupowerVR_drivers


And why would this project be high priority ? Because we want OpenGL and don't care if it would be 10% or so slower then official GLES.


On the other hand ... as Notaz stated, that driver doesn't give anything extraordinary. ( Damn, I hoped it would have been open source Xorg driver with 2d acceleration using SGX supporting accelerated XVideo extension with scaling+colour conversation. )

 

[fusion_power]

It seems that there has to be alot happen, before the Drivers are as good and useful, as the Devs wish. It would be the best to make our own Chips including our own drivers for a possible "Pandora 2", with Hardware Access till down to the bare bones.

 

[ivanovic]

I was kind of misleading, but really what I'm trying to say is that it's not just the DRM and userspace components of a driver that are missing if one wants non-ES support. The main reason the ES spec exists is to free hardware vendors from implementing a bunch of miscellaneous features that aren't worth the chip real-estate in embedded contexts. It's basically OpenGL 2.0 with all of those features removed. A driver supporting OpenGL ES is going to be at least as fast as a comparable OpenGL driver, because it only has to support a subset of the features. It's also going to expose all of the features of the hardware, either through the base spec, or through extensions, since that's the API that nearly all customers are going to be using to access the hardware. If non-ES OpenGL support isn't going to result in improved speed or new features, what is there to be excited about?

But there are rumors that those graphics chips used in the pandora are (on the hardware side!) identical to the chips used by intel and loved under the name "pulsbo". So for netbooks those do feature "full" OpenGL. So yeah, it all comes down to a "software only" limitation, which is enforced by the proprietary driver.

 

[Linopoly]

Don't you want to be able to play any new open source game you come across on the net ? Nearly all of open source game engines DO NOT support OpenGL ES. And I know for sure that all of people here want OpenGL 2 or 3 support and not just GLES1, GLES2, EGL.


The SGX family would easily handle OpenGL - just write the kernel+userspace driver.


After all the devs know what there are doing:


http://elinux.org/Cr...erVR_GPU_driver


http://libreplanet.o...PowerVR_drivers


And why would this project be high priority ? Because we want OpenGL and don't care if it would be 10% or so slower then official GLES.


On the other hand ... as Notaz stated, that driver doesn't give anything extraordinary. ( Damn, I hoped it would have been open source Xorg driver with 2d acceleration using SGX supporting accelerated XVideo extension with scaling+colour conversation. )

Actually, game engines do support OpenGL ES, see for example ioQuake3, and OGRE. Any popular engine will have been ported to Android, iOS, Maemo, or WebOS, which all only support OpenGL ES. Any that haven't been ported yet should be portable with a manageable amount of effort. 10% is an unrealistic guess for how much slower OpenGL support would be. If it can't be supported by the hardware, then requests would be rendered by the CPU, and it would be unusably slow, more like 90+% slower. If you want that, you can have it right now without adding support to the driver.

But there are rumors that those graphics chips used in the pandora are (on the hardware side!) identical to the chips used by intel and loved under the name "pulsbo". So for netbooks those do feature "full" OpenGL. So yeah, it all comes down to a "software only" limitation, which is enforced by the proprietary driver.

Indeed, but the driver support for those was/is a big fiasco, and it's unclear to me that there is actually a reasonably working OpenGL driver for that hardware on Windows or Linux. See for example complaints like this, this, and this. Even if such support were possible, it wouldn't provide any acceleration features that aren't already usable via OpenGL ES.

 

[alastor]

Don't you want to be able to play any new open source game you come across on the net ? Nearly all of open source game engines DO NOT support OpenGL ES. And I know for sure that all of people here want OpenGL 2 or 3 support and not just GLES1, GLES2, EGL.


The SGX family would easily handle OpenGL - just write the kernel+userspace driver.


After all the devs know what there are doing:


http://elinux.org/Cr...erVR_GPU_driver


http://libreplanet.o...PowerVR_drivers


And why would this project be high priority ? Because we want OpenGL and don't care if it would be 10% or so slower then official GLES.


On the other hand ... as Notaz stated, that driver doesn't give anything extraordinary. ( Damn, I hoped it would have been open source Xorg driver with 2d acceleration using SGX supporting accelerated XVideo extension with scaling+colour conversation. )

Actually, game engines do support OpenGL ES, see for example ioQuake3, and OGRE. Any popular engine will have been ported to Android, iOS, Maemo, or WebOS, which all only support OpenGL ES. Any that haven't been ported yet should be portable with a manageable amount of effort. 10% is an unrealistic guess for how much slower OpenGL support would be. If it can't be supported by the hardware, then requests would be rendered by the CPU, and it would be unusably slow, more like 90+% slower. If you want that, you can have it right now without adding support to the driver.

But there are rumors that those graphics chips used in the pandora are (on the hardware side!) identical to the chips used by intel and loved under the name "pulsbo". So for netbooks those do feature "full" OpenGL. So yeah, it all comes down to a "software only" limitation, which is enforced by the proprietary driver.

Indeed, but the driver support for those was/is a big fiasco, and it's unclear to me that there is actually a reasonably working OpenGL driver for that hardware on Windows or Linux. See for example complaints like this, this, and this. Even if such support were possible, it wouldn't provide any acceleration features that aren't already usable via OpenGL ES.

Well, that's a hell amount of engines. There is also GLES driver for pcsx_rearmed, gles2n64 plugin for mupen64plus ( which is awesome ! looks good with Turok 2 ) and few others I don't know about.


Most of the new games that are built with GLES2 support in mind are for Android and have nothing to do with us. ( Now, don't even start a thread about "Android = Linux". An OS with games that can't be used on "standard" linux is not linux. Unlike Android, you can take Ubuntu binary and most likely it will run on Fedora for e.g. So there is no point talking about Android, and especially iOS, since it doesn't matter to us anyhow. Maemo on the other hand does - if I am correct we can use more or less any of its software. )


Maybe it would take a manageable amount of effort to port an engine to GLES, but don't you think it would be better for Devs to spend time on updating the engine, getting rid of bugs, optimising, etc with standard OpenGL in mind ?


Besides, who on earth would want 100% software 3d ? What the Devs want is Gallium driver accelerated by SGX. This is what we want.


But still this has nothing to do with OP statement. Another DSS layer wouldn't do the magic

 

[fusion_power]

Which games do already use GLES2 on the Pandora? I read alot about GLES1 in the Forums but TI advertises their OMAP with usualy mentioning "GLES2" so I want to see some GLES2 beauty on my Pandora.

 

[sebt3]

Which games do already use GLES2 on the Pandora? I read alot about GLES1 in the Forums but TI advertises their OMAP with usualy mentioning "GLES2" so I want to see some GLES2 beauty on my Pandora.

I'm aware of a lot's of developpement for GLES2 in this community (since a while btw) but nothing got delivered that I know.


You need to understand that until you realy need new features provided by GLES2, GLES1.1 will probably be faster

 

[Exophase]

glESn64 (packaged with Mupen64plus) uses it.. hence its namesake. Similarly anyone using Adventus' wrapper is ultimately using ES2.


ES1.x being faster is one of those mysterious things since the hardware probably doesn't have any special fixed function ES1 blocks and hence emulates it using the same shaders you'd get in ES2. But this is supported by real evidence and is probably due to the driver writers having much better access to the hardware than OGL ES2 gives you, allowing for more special tricks.. Maybe even shaders hand-written in SGX assembly..

 

[notaz]

There are some games using GLES, Briquolo, Frogatto and even Angry Birds, not sure what GLES versions though. Maybe somebody could make a list on the wiki.

 

[Linopoly]

Well, that's a hell amount of engines. There is also GLES driver for pcsx_rearmed, gles2n64 plugin for mupen64plus ( which is awesome ! looks good with Turok 2 ) and few others I don't know about.


Most of the new games that are built with GLES2 support in mind are for Android and have nothing to do with us. ( Now, don't even start a thread about "Android = Linux". An OS with games that can't be used on "standard" linux is not linux. Unlike Android, you can take Ubuntu binary and most likely it will run on Fedora for e.g. So there is no point talking about Android, and especially iOS, since it doesn't matter to us anyhow. Maemo on the other hand does - if I am correct we can use more or less any of its software. )


Maybe it would take a manageable amount of effort to port an engine to GLES, but don't you think it would be better for Devs to spend time on updating the engine, getting rid of bugs, optimising, etc with standard OpenGL in mind ?


Besides, who on earth would want 100% software 3d ? What the Devs want is Gallium driver accelerated by SGX. This is what we want.


But still this has nothing to do with OP statement. Another DSS layer wouldn't do the magic

Android actually has an "NDK" that lets developers port and deploy native apps. It's how all the existing FOSS games would get ported, and it's how Angry Birds works, for example. This is also possible on WebOS, which is why I mentioned both of those platforms in the first place. However, whether these platforms are Linux or not is actually not relevant to my point, since what I'm trying to say is that chances are that any video game engine you want to run on the Pandora has already been ported to OpenGL ES by someone else, just for kicks even. Which of the platforms I mentioned above is mostly irrelevant, since the OpenGL ES related stuff will work almost the same way on each platform.