Beta Latest Sgx Driver


notaz

Certified Guru
Joined
Aug 23, 2005
Messages
4,913
Location
Lithuania
Website
notaz.gp2x.de
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.
 
notaz said:
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
 
Last edited by a moderator:
Added instructions for reverting to HF5 driver to first post.

God Ginrai said:
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.

paeryn said:
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.
 
Last edited by a moderator:
thanks notaz, i'm going to try this when i get home or latest at this weekend. bit busy lately :)
 
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?
 
mhadf said:
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.
 
Last edited by a moderator:
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)
 
bzfrank said:
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
 
Last edited by a moderator:
bzfrank said:
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..
 
Last edited by a moderator:
BTW Does TI provide any information on implementation limits of their driver?
 
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:
 
bzfrank said:
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".

fusion_power said:
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.
 
Last edited by a moderator:
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.
 
bzfrank said:
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.
 
Last edited by a moderator:
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!
 
bzfrank said:
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?
 
Last edited by a moderator:
crow_riot said:
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
 
Last edited by a moderator:
Back
Top