Beta Latest Sgx Driver

[notaz]

This is latest TI 4.03.00.02 SGX driver.
Warning: it seems to be unstable and occasionally crashing the system; you may have to reflash if you try this.
HF5 is required to install this.

Install these in order (sudo opkg install <file>):
http://notaz.gp2x.de/misc/pnd/sgx/hf5/omap3-sgx-modules_1.6.16.3977-r24i.5_omap3-pandora.ipk
http://notaz.gp2x.de/misc/pnd/sgx/hf5/libgles-omap3_4.03.00.02-r0.5_armv7a.ipk
reboot when done.

To install the HF5 driver (4.00.00.01) back, install these in order
(sudo opkg --force-downgrade install <file>):
http://notaz.gp2x.de/misc/pnd/sgx/hf5/omap3-sgx-modules_1.4.14.2616-r24i.5_omap3-pandora.ipk
http://notaz.gp2x.de/misc/pnd/sgx/hf5/libgles-omap3_4.00.00.01-r0.5_armv7a.ipk
reboot when done.

I've also built pre-HF5 driver (3.01.00.02) to be compatible with HF5
(install with sudo opkg --force-downgrade install <file>):
http://notaz.gp2x.de/misc/pnd/sgx/hf5/omap3-sgx-modules_1.4.14.2514-r24a.5_omap3-pandora.ipk
http://notaz.gp2x.de/misc/pnd/sgx/hf5/libgles-omap3_3.01.00.02-r7.5_armv7a.ipk
reboot when done.

I've been trying to get TI support for the stability issue (see here), but they want an isolated testcase that would reproduce the problem. However I'm unable to figure out what's causing it (it looks random to me) and probably would not be able to write correct GLES app anyway, so if someone knows GLES and wants to do some debugging, any help would be appreciated.

 

[God Ginrai]

This is latest TI 4.03.00.02 SGX driver.
Warning: it seems to be unstable and occasionally crashing the system, be prepared to reflash if you try this.
HF5 is required to install this.

Install these in order (sudo opkg install <file>):
http://notaz.gp2x.de/misc/pnd/sgx/omap3-sgx-modules_1.6.16.3977-r24i.5_omap3-pandora.ipk
http://notaz.gp2x.de/misc/pnd/sgx/libgles-omap3_4.03.00.02-r0.5_armv7a.ipk
reboot when done.

I've been trying to get TI support for the stability issue (see here), but they want an isolated testcase that would reproduce the problem. However I'm unable to figure out what's causing it (it looks random to me) and probably would not be able to write correct GLES app anyway, so if someone knows GLES and wants to do some debugging, any help would be appreciated.

Aside from the stability issue, what does this driver offer in terms of performance? Is it a good improvement?

-God Ginrai

 

[paeryn]

Got your PM after I'd already read & downloaded Is this the debug driver?

I'll install it later and see if I can write a reliable crash scenario.

Paeryn.

 

[notaz]

Added instructions for reverting to HF5 driver to first post.

Aside from the stability issue, what does this driver offer in terms of performance? Is it a good improvement?

You can try and tell, TI logs don't provide much info.

Is this the debug driver?

No it's release one. The debug one only spits useful info to dmesg as it brings the system down, so without serial you might have hard time getting that info anyway.

 

[crow_riot]

thanks notaz, i'm going to try this when i get home or latest at this weekend. bit busy lately

 

[notaz]

Also added pre-HF5 driver built for HF5 firmware (on bzfrank's request).

 

[mhadf]

From what I can gather in the release notes it has been tested on 2.6.32 and 2.6.37. Is this another reason to start the push towards a more recent kernel?

 

[notaz]

From what I can gather in the release notes it has been tested on 2.6.32 and 2.6.37. Is this another reason to start the push towards a more recent kernel?

I don't think kernel has much impact, I've also tested on 2.6.37 and result is more or less the same.

 

[bzfrank]

4.03 not seem to work with Mupen, locks up as soon as a game is started (black screen). E.g. LOZ:OOT immediately locks up, does not even show the startup logo. No such problem when using 4.00 (and 3.01, however it still has the hard freeze on the Triforce cutscene)

 

[God Ginrai]

4.03 not seem to work with Mupen, locks up as soon as a game is started (black screen). E.g. LOZ:OOT immediately locks up, does not even show the startup logo. No such problem when using 4.00 (and 3.01, however it still has the hard freeze on the Triforce cutscene)

:/ That doesn't sound promising...

-God Ginrai

 

[notaz]

4.03 not seem to work with Mupen, locks up as soon as a game is started (black screen). E.g. LOZ:OOT immediately locks up, does not even show the startup logo. No such problem when using 4.00 (and 3.01, however it still has the hard freeze on the Triforce cutscene)

I saw that too.. Someone familiar with gles2n64 code needs to make a stand-alone testcase for TI, I can't just ask them to run some n64 emu..

 

[God Ginrai]

I can't just ask them to run some n64 emu..

Yea, I cold see how that might not turn out to well.

-God Ginrai

 

[bzfrank]

BTW Does TI provide any information on implementation limits of their driver?

 

[fusion_power]

If this driver is bugy or has no benefits, what was the reason for TI to release it? Just for supporting new SGX hardware (and do forgetting older SGX Chips we still use for example)? :unsure:

 

[notaz]

BTW Does TI provide any information on implementation limits of their driver?

There is some info in release notes, however crashing the kernel shouldn't be the way to say "you've gone too far".

If this driver is bugy or has no benefits, what was the reason for TI to release it? Just for supporting new SGX hardware (and do forgetting older SGX Chips we still use for example)? :unsure:

They claim it is not buggy, also SGX demos work.

 

[bzfrank]

Well, there seems to be a bit work to do for them...

After several days of searching for the 'hard freeze' bug I firmly believe now that its a race condition in the driver, also earlier versions. Regardless of what parameters I changed the result (freeze / not freeze) was like throwing a dice, only that in 1 of 10 it works, in the other 9 it locked up. May be worth an article in the journal of irreproducable results.

I'll see if I can hack something together that triggers the 4.03 bug.

 

[crow_riot]

Well, there seems to be a bit work to do for them...

After several days of searching for the 'hard freeze' bug I firmly believe now that its a race condition in the driver, also earlier versions. Regardless of what parameters I changed the result (freeze / not freeze) was like throwing a dice, only that in 1 of 10 it works, in the other 9 it locked up. May be worth an article in the journal of irreproducable results.

I'll see if I can hack something together that triggers the 4.03 bug.

i also think so, the problem i have with the previous version seems something like that. did you create your GLES context on an x11 window or plain framebuffer? from what my research gave me, the framebuffer version doesnt have this issue.

 

[bzfrank]

Holy moly! Changing the rendering of gles2n64 to framebuffer resolved the hard freeze! I just tried it three times in a row (remember that the spider must be slain for each test, so it takes a bit) and it worked.

Thanks a bunch for the tip!

 

[crow_riot]

Holy moly! Changing the rendering of gles2n64 to framebuffer resolved the hard freeze! I just tried it three times in a row (remember that the spider must be slain for each test, so it takes a bit) and it worked.

Thanks a bunch for the tip!

so the locking issue has something todo with the windowing system; i've no idea about the underlying architecture, where's the reason - is this still a sgx driver issue or has it something todo with the x11 driver(?!) itself?

 

[bzfrank]

so the locking issue has something todo with the windowing system; i've no idea about the underlying architecture, where's the reason - is this still a sgx driver issue or has it something todo with the x11 driver(?!) itself?

Since the freezes were such that the system was knocked out cold, could only be revived by a hard reset and nothing was ever written to a log its hard to deduce whats going on.

If you like to see what makes the difference check

http://code.google.com/p/gles2n64/source/browse/trunk/OpenGL.cpp

and look for OGL.framebuffer.enable