Beta Latest Sgx Driver

[crow_riot]

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

and look for OGL.framebuffer.enable

wait, what? you're creating a framebuffer object and the freeze is gone?
well ... this is not the way i meant it, just create the GLES context ontop of the framebuffer (eglGetDisplay(0) ...);
but again this is really strange then if your freeze went away then.

notaz, the best way to reproduce a freeze of gles rendering is sending SIGSTOP and SIGCONT.
i'm really busy at the moment, so i cant help with writing a test app, sorry
maybe paeryn had success already?

this problem is pretty much related, there's also a small test app inside which may help! *keeping fingers crossed*
http://www.gp32x.de/board/index.php?/topic/59034-system-lockup-with-render-to-texture/

 

[notaz]

gles2n64 consistently crashes 4.03 driver so I've started ripping out it's code in attempt to make a testcase for TI, but I had no luck (the result won't crash)

 

[bzfrank]

gles2n64 consistently crashes 4.03 driver so I've started ripping out it's code in attempt to make a testcase for TI, but I had no luck (the result won't crash)

Same here (otherwise I would have sent you my results). It only crashes when used in mupen. Guess the only way is to 'record' what calls the emulator makes and replay it 1:1 in the testcase.

 

[chris_c]

Just a thought, I made my self a cheap and nasty opengl debugger once (years ago) by linking to a library I created with the same functions as the actual opengl library, it logged the call, synced the file system, then executed the actual opengl call, sloooow as hell but it did let me catch problems...

Of course slowing things down like this may just "solve" a race condition so YMMV .....

 

[paeryn]

Just a thought, I made my self a cheap and nasty opengl debugger once (years ago) by linking to a library I created with the same functions as the actual opengl library, it logged the call, synced the file system, then executed the actual opengl call, sloooow as hell but it did let me catch problems...

Of course slowing things down like this may just "solve" a race condition so YMMV .....

ImgTec have finally released a new version of PVRTrace that works on the Pandora (only gles2 & egl). Running mupen with it resulted in a slideshow of 1-2 spf (secs per frame) alternating between a black screen and the screen of a previously run gl program. I killed it after 66 frames, system was fine - no lock-up.

There are only two errors showing, the first at the end of OGL_InitStates - glUniform1i() is called before glUseProgram(), AFAIK it should be after.
And in OGL_Start there is a call glGetFloatv(GL_MAX_TEXTURE_MAX_ANISOTROPY_EXT, &f) - it fails because we don't have that extension.

I've not had any luck in writing test code that crashes the driver yet.