SGX driver outdated

[Alemarius Nexus]

Hi,

Yes, it's about the SGX driver again. This GPU and its driver are really screwed up I think. I keep having countless problems on them. It's been a while since I first asked about the driver quality here. Back then I hadn't had my Pandora and tested on another OMAP device, but now I have it, and it's even worse than I expected.

I mean, was anybody ever able to use GLESv2 on the Pandora for a bigger application (ignoring performance for now)? I've had problems rendering to depth textures, then problems rendering to non-square textures at all, and finally, it throws GL_OUT_OF_MEMORY although there is plenty of system RAM left, but only in some situations.

Concerning the last of these problems, I have asked in the Imgtec forum, and they told me that the driver used on the Pandora is extremely outdated, so maybe the problems are solved in newer versions? This leads me to my actual question: Why do we have such old SGX drivers on the Pandora? I'm not experienced with anything driver-related (or kernel-related at all) if it doesn't have a simple installer, so I'm a bit afraid of fiddling around with the Graphics SDK from TI, which should have newer drivers. Also, I don't get how these drivers work. There seems to be a small kernel module that is open source, which is the thing I have been compiling several times to get GLESv2 working on my Pandora. The main driver is a proprietary BLOB as I understand, but where is it? Is it a dynamic kernel module, or is it compiled in statically? We have quite a recent kernel (3.2) on the Pandora by now, so shouldn't it be possible to include newer versions of the BLOB?

Maybe I am just too used to the big drivers for Desktop OpenGL which are relatively unproblematic most of the time, but the current state of the SGX driver renders the GPU absolutely unusable for me, so I really hope that it's possible to switch to some non-ancient version.

 

[Exophase]

Drivers are so old because the original OMAP3530 revisions on the Pandora don't support the newer drivers.

The (bulk of the) driver isn't a kernel module, it's a user space library. libGLESv2.so should be it.

 

[Alemarius Nexus]

And the driver we have on the Pandora right now is really the most recent one where the old GPU is still supported? Imgtec told me the current drivers are 1.8/1.9, and Pandora has 1.4 drivers. I mean, the 1GHz GPU can't differ so much from the old one when the SoCs are said to be compatible, can it? If so, I can't imagine that they dropped support for the old one after 1.4, but still support the new one in the current versions.

 

[Askarus]

Maybe some PND would be the solution.

It could update the driver but warns the user that it will damage old boards.

 

[Alemarius Nexus]

Yes, if this is the only way...

I don't like the idea of creating a game that will run only on the newer Pandoras, though. If there's no more recent driver that works on the old boards, I'll try to ask TI about this first. Maybe they have at least a workaround for the GL_OUT_OF_MEMORY bug.

 

[ShleeDragon]

Speak to the powers that be! I'm under the impression there are more recent releases for the SOCs we use with hardfloat support and all that jazz.... but it would require wayyyyyy too much work to get them working with the current firmware. because the Kernel would need patches, kernel modules need tweaking, the Xorg version needs to be updated... with the userspace redone.

After that. there is testing and months of bugs that might result in an unstable and broken environment... also forget about backwards compatibility.

Feel free to try

http://processors.wiki.ti.com/index.php/RN_4_08_00_01

http://processors.wiki.ti.com/index.php/RN_4_08_00_02

 

[Askarus]

Of course I fully agree with you.

It's bad to have games/programs that only run on the 1 GHz Pandoras.

That's what we don't want.

If you can find a solution and ask TI it'd be great.

But there's an other point of view, too:

Some People paid a very high price to get the 1 GHz Pandora.

It'd be also bad to limit those units because of the older models.

There IS already stuff that's much more playable on the Giga Pandora (for example N64 or some Android Games, maybe some Win 95 games as well).

No one complains about that.

I'm very sure Developers will do their best to get their programs running on old Pandoras as well.

If it's not possible I don't see any reason why the new Pandoras should be limited as well.

It won't split community. Neither rebirth nor GHz Pandoras did and a driver won't.

 

[Cloudef]

The newer drivers need newer kernel with the drm omap driver, and dri2 for X acceleration.

Also like said, the newer drivers won't work in the original pandoras.

It's possible to use the newer drivers right now, if you don't plan to have X acceleration (only framebuffer).

 

[Exophase]

Speak to the powers that be! I'm under the impression there are more recent releases for the SOCs we use with hardfloat support and all that jazz.... but it would require wayyyyyy too much work to get them working with the current firmware. because the Kernel would need patches, kernel modules need tweaking, the Xorg version needs to be updated... with the userspace redone.

After that. there is testing and months of bugs that might result in an unstable and broken environment... also forget about backwards compatibility.

Feel free to try

http://processors.wiki.ti.com/index.php/RN_4_08_00_01

http://processors.wiki.ti.com/index.php/RN_4_08_00_02

We made it to the 3.2 kernel all the way from something years older, so at least that rough order of magnitude of work is feasible. I think.

But if switching to hard float causes PND incompatibility then we have much bigger problems :/ If all that other stuff could be done while sticking with softfp it could be worth it.

 

[notaz]

And the driver we have on the Pandora right now is really the most recent one where the old GPU is still supported?

Yes, that's the last driver where original pandoras work (SGX530 v1.0.3), any newer ones will lock up the unit hard.

 

[Linux-SWAT]

Using the secret CPU detection, wouldn't it be good to load a newer module, using insmod in a special separate /lib/modules ?

 

[notaz]

It's not a matter of kernel module, almost everything is in userspace blobs.

And the CPU detection is not secret, search the old threads.

 

[Linux-SWAT]

Found it back, indeed it's far from being hidden ^^.

 

[lunixbochs]

It's pretty easy to switch user-space libs based on hardware. Any chance we can work with IMG to get a newer userspace that supports both the old and newer SoCs?

 

[Alemarius Nexus]

the Kernel would need patches, kernel modules need tweaking, the Xorg version needs to be updated

(...)

Feel free to try

No, thanks. I don't have any idea how kernel-space development works. I just want to program my user-space applications and forget about everything else. ^_^

There IS already stuff that's much more playable on the Giga Pandora

Yes, but that is only limited by the hardware speed, I guess, which means the programs are just too heavy to run flawlessly on the older hardware at all, unless low-level optimizations are done. In my case, it would be impossible to run the game on the old units at all, and not because the hardware is not capable of running it, but only because of some stupid driver bug.

But if there is no way around this error (particularly the OUT_OF_MEMORY thing. The rest is something I can live with), I will have to drop support for older Pandoras. That is, if there are not many more severe bugs I am not aware of yet, which would not surprise me anymore. Another possibility would be to write a GLESv1 renderer, because I expect that to be far more usable, but I'm so used to the programmable pipeline by now that I do not really want to go back to this ancient technology. We'll see...

It's possible to use the newer drivers right now, if you don't plan to have X acceleration (only framebuffer).

I don't know what you mean by "X acceleration". I have never used X11 directly, always EGL and SDL. I need GLESv2 hardware acceleration for the main framebuffer as well as FBOs. 2D graphics acceleration will not be needed right now, if you mean this. And even if so, I could do the 2D stuff in GLESv2, I guess.

Any chance we can work with IMG to get a newer userspace that supports both the old and newer SoCs?

I don't have any hope there. I guess they had a reason for dropping support in the first place, so I doubt they will change their mind if we ask them nicely.

I have asked in the TI forums for a workaround. We'll see how this works out...

 

[Cloudef]

I don't know what you mean by "X acceleration". I have never used X11 directly, always EGL and SDL. I need GLESv2 hardware acceleration for the main framebuffer as well as FBOs. 2D graphics acceleration will not be needed right now, if you mean this. And even if so, I could do the 2D stuff in GLESv2, I guess.

It means both, X driver that can provide some sort of acceleration through SGX libraries, and OpenGL ES under X session through DRI2 that is provided by the same X driver.

This driver also needs the omap-drm kernel driver, which has kms and what not...

Omapfb which is currently used is basically dead. Not that it ever provided much over plain fbdev.

The old SGX drivers don't need dri2 for ES under X either.

 

[EvilDragon]

Well, I'm happy to try and contact any company behind it for a driver update - but I'm no coder, so I don't need what's needed and who would be responsible for that.

I know we tried that a while ago with TI, but never really got any help, but maybe IMGTec can help here?

No idea.

If anyone could tell me what updates we need from whom, I'll try to talk to them...

 

[notaz]

If anyone could tell me what updates we need from whom, I'll try to talk to them...

Any driver newer than 1.4.14.2616 for SGX530 core version 1.0.3 .Normally TI is providing the drivers, and last time I posted in their forums they responded with "your chip is not supported".

 

[lunixbochs]

Why aren't we using 1.9 for our other SGX cores?

 

[notaz]

One problem is that you end up with feature disparity between pandoras, another is that newer drivers need DRI stuff that nobody has been able (or tried hard enough) to get working. Cloudef claims that newer kernel is required with omapdrm driver, meanwhile I'm not sure about all that (the driver DRI dependency appeared before omapdrm appeared in kernel).