[android-developers] Re: OpenGL lockups in 2.2
We just did a big profiling, optimizing and tuning session on our engine and found that we had LOTS of redundant Shader and Geometry binds and unbinds. We found that we never need to unbind from shaders or disable vertex attributes because they are automatically all disabled when switching shaders - then we made it so that glGetError is only called when we have our debugging flags on... Result? The game that was crashing instantly on the EVO now runs without any problems until the battery dies. So - just another thing to look into. Run your code in the Adreno profiler with glFinish() on, remove all the redundant state changes and unnecessary unbinds like texture, shader or vbo binds to 0 or anything like that and see how it goes. This worked for us. On Apr 12, 10:59 am, cybice wrote: > Please look > athttps://developer.qualcomm.com/forum/qdevnet-forums/mobile-gaming-gra... > > i have no rooted phone, > so please anybody who affected this bug, send to Qualcomm a stack trace > (using gdb) of all the threads of the system_server process -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: OpenGL lockups in 2.2
Please look at https://developer.qualcomm.com/forum/qdevnet-forums/mobile-gaming-graphics-optimization-adreno/11525#comment-6928 i have no rooted phone, so please anybody who affected this bug, send to Qualcomm a stack trace (using gdb) of all the threads of the system_server process -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: OpenGL lockups in 2.2
It looks like i found workaround. In all my apps error "
waitForCondition(LockCondition) timed
out " disappeared.
The workaround is next.
I preload two copy of each texture into GPU - texture1 and texture1copy,
and in onDrawFrame one call i use first texture copy, next call i use
second texture copy and so on
code sample:
int _seed=0;
public void onDrawFrame(GL10 gl) {
if(_seed%2==0)
{
GLES20.glBindTexture(GLES20.GL_TEXTURE_2D, texture1 );
}else
{
GLES20.glBindTexture(GLES20.GL_TEXTURE_2D, texture1copy);
}
_seed++;
}
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: OpenGL lockups in 2.2
Hey I am new to the android game development please reply with some get started tips as I am very much new bee here for graphics and gaming physics theory . Kindly help me to get some basic kick start. I shall be thankful to you . On Tue, Oct 11, 2011 at 9:32 PM, calderwa wrote: > Nope, 'fraid not. That code seems if anything to makes things a little > worse for me = intermittent screen glitches, with rectangular areas > garbled, and the less frequesnt hangup for a second or so, with the > even less frequent reboot. I am using Samsung Galaxy S, 2.3.3, so > clearly not restricted to HTC. All hangs seem to be locking problems > in SharedBufferStack. > glFlush calls have no effect on my problem. Switching from > glDrawArrays to VBOs and glDrawElements had no effect. > > This bug is SO bad and i have spent SO long on it now that I am pretty > much at the stage of junking many months of work and not publishing > the openGL version of my app. > > This comes on top of unacknowledged problems in java 2d drawing > routines, the ridiculous DirectBuffer problem in 3.0+ where it > allocates 4* as much memory as you ask for. The list is nearly > endless. > > Apple, here I come? > > > On Aug 13, 8:18 am, Herko Lategan wrote: > > Guys! *SOLUTION* > > > > I finally *found the solution* while watching one of the Google IO talks! > I > > have been struggling with this problem for over 2 months now, while > > developing on my HTC Desire, and it made me so demotivated knowing my > > application will freeze randomly for some users! But after hours of > > searching I found a solution done by a Google Developer! > > > > *solution*: > > > > Here is the link to the solution for GLSurfaceView, > http://replicaisland.googlecode.com/svn/trunk/src/com/replica/replica... > > Search for *mSafeMode, **check all the results*, he gives a description > as > > to why the error occurs (it is because of broken drivers for certain > > chipsets). > > > > I have downloaded the source for this game, so if the links disappear you > > can email me and I'll be happy to share. > > > > Good luck to everyone! > > -- > You received this message because you are subscribed to the Google > Groups "Android Developers" group. > To post to this group, send email to android-developers@googlegroups.com > To unsubscribe from this group, send email to > android-developers+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: OpenGL lockups in 2.2
"Difficulties with one device" I have no way of knowing how many makes/models of device this problem is on. I know that it happens all the time on my Samsung Galaxy (I9000). Others report exactly the same thing as being a feature of a number of HTC devices - these two make up a major part of the market I believe. I think I may well have two faults - one is the "standard" eglSwapBuffers hang, which none of the suggested fixes have had any effect on -square textures, different GLSurfaceView, wait, flush, finish etc. The second one, which I think be related, is my intermittent framebuffer corruption, I am willing to accept this may be my fault in some way I have been unable to pinpoint. http://www.fordartworks.co.uk/dodgyS.png - the ractilinear dodgy area just above the left and right arrow buttons. "smacks of throwing the baby out..." At the moment, I am just hugely frustrated by the long list of problems I have faced with Android - halts on writing to SD card, gradients that don't work at one particular angle and so on. I have been a software designer and developer for over 25 years - parallel architecture research, trading room systems, real time etc (assembler, Fortran, Prolog, Occam, C, C++, Java) and I have never been so frustrated by any system - there has always been a different way of doing things, getting round problems. With this /these? OpenGL problem(s) it appears to be a black box. Without a genuine understanding of what is wrong, any "fix" is pure conjecture. "should just be ignored" I am extremely reluctant to put out an App that looks flakey or, much worse, shuts down people's phones. "Ignoring" a problem that I can't get round is not a viable solution I feel. "plugging and unplugging the USB cable" The USB cable stuff was a problem I had with very jerky OpenGL performance when the rendering load was heavy - this was caused by the CPU clock reducing when the GPU was active, I believe. "seeing the behavior elsewhere" I haven't experienced this problem with other programs on this phone. (I have not detected the problem on my Asus Transformer either, but I have tested that far less. It will also have very different performance characteristics.) I don't play games, 2D or 3D. Many of the openGL demonstrators, testers or benchmarkers don't stress the system sufficiently - i can get 50 or 60 fps. The problem is very timing dependent- i have one picture definition for my App that fails vaguely regularly - i have 2 or 3 others that do very occasionally, and I have 100+ that i haven't seen go wrong yet. I simply haven't the time to sit and fiddle about with a 3rd party app on the off-chance of catching a glitch. If I did - that would prove relatively little. I could sit there till doomsday with my own app under the right conditions and never see anything untoward. I'll maybe just take a break from this (go and paint a few pictures :-) ) - i've been on this problem 7 days a week for nearly 3 weeks now. I might even go get a real job again, lol. "It's insane" Thank you for your concerns over my mental health :-) On Oct 11, 7:28 pm, Christopher Van Kirk wrote: > It's insane to throw away months of work. > > Are you seeing this behavior in other 2 or 3d games running on that > device? If so, it's probably a device fault that you simply can't get > around, and should just be ignored. There are other devices in the world > that, in theory, it should work on. In your market publish, just mention > that you had problems with that device and that it's not recommended to > be run there, then move on. > > If you aren't seeing the behavior elsewhere, then what you have is an > application problem. Have you considered that plugging and unplugging > the USB cable is introducing thread locking that is absent in your code? > When you connect the USB cable, if you have development enabled, you > instantly start reading out logging info, which may have locking in > there that's fixing some problem you have. > > Anyway, giving up smacks of throwing the baby out with the bath water > because of difficulties with one device. I wouldn't do it. > > On 10/12/2011 12:02 AM, calderwa wrote: > > > > > Nope, 'fraid not. That code seems if anything to makes things a little > > worse for me = intermittent screen glitches, with rectangular areas > > garbled, and the less frequesnt hangup for a second or so, with the > > even less frequent reboot. I am using Samsung Galaxy S, 2.3.3, so > > clearly not restricted to HTC. All hangs seem to be locking problems > > in SharedBufferStack. > > glFlush calls have no effect on my problem. Switching from > > glDrawArrays to VBOs and glDrawElements had no effect. > > > This bug is SO bad and i have spent SO long on it now that I am pretty > > much at the stage of junking many months of work and not publishing > > the openGL version of my app. > > > This comes on top of unacknowledged problems in java 2d drawing > > routines, the ridiculous DirectBuffer problem in 3.0+ where it > > al
[android-developers] Re: OpenGL lockups in 2.2
"Difficulties with one device" I have no way of knowing how many makes/models of device this problem is on. I know that it happens all the time on my Samsung Galaxy (I9000). Others report exactly the same thing as being a feature of a number of HTC devices - these two make up a major part of the market I believe. I think I may well have two faults - one is the "standard" eglSwapBuffers hang, which none of the suggested fixes have had any effect on -square textures, different GLSurfaceView, wait, flush, finish etc. The second one, which I think be related, is my intermittent framebuffer corruption, I am willing to accept this may be my fault in some way I have been unable to pinpoint. http://www.fordartworks.co.uk/dodgyS.png - the ractilinear dodgy area just above the left and right arrow buttons. "smacks of throwing the baby out..." At the moment, I am just hugely frustrated by the long list of problems I have faced with Android - halts on writing to SD card, gradients that don't work at one particular angle and so on. I have been a software designer and developer for over 25 years - parallel architecture research, trading room systems, real time etc (assembler, Fortran, Prolog, Occam, C, C++, Java) and I have never been so frustrated by any system - there has always been a different way of doing things, getting round problems. With this /these? OpenGL problem(s) it appears to be a black box. Without a genuine understanding of what is wrong, any "fix" is pure conjecture. "should just be ignored" I am extremely reluctant to put out an App that looks flakey or, much worse, shuts down people's phones. "Ignoring" a problem that I can't get round is not a viable solution I feel. "plugging and unplugging the USB cable" The USB cable stuff was a problem I had with very jerky OpenGL performance when the rendering load was heavy - this was caused by the CPU clock reducing when the GPU was active, I believe. "seeing the behavior elsewhere" I haven't experienced this problem with other programs on this phone. (I have not detected the problem on my Asus Transformer either, but I have tested that far less. It will also have very different performance characteristics.) I don't play games, 2D or 3D. Many of the openGL demonstrators, testers or benchmarkers don't stress the system sufficiently - i can get 50 or 60 fps. The problem is very timing dependent- i have one picture definition for my App that fails vaguely regularly - i have 2 or 3 others that do very occasionally, and I have 100+ that i haven't seen go wrong yet. I simply haven't the time to sit and fiddle about with a 3rd party app on the off-chance of catching a glitch. If I did - that would prove relatively little. I could sit there till doomsday with my own app under the right conditions and never see anything untoward. I'll maybe just take a break from this (go and paint a few pictures :-) ) - i've been on this problem 7 days a week for nearly 3 weeks now. I might even go get a real job again, lol. "It's insane" Thank you for your concerns over my mental health :-) On Oct 11, 7:28 pm, Christopher Van Kirk wrote: > It's insane to throw away months of work. > > Are you seeing this behavior in other 2 or 3d games running on that > device? If so, it's probably a device fault that you simply can't get > around, and should just be ignored. There are other devices in the world > that, in theory, it should work on. In your market publish, just mention > that you had problems with that device and that it's not recommended to > be run there, then move on. > > If you aren't seeing the behavior elsewhere, then what you have is an > application problem. Have you considered that plugging and unplugging > the USB cable is introducing thread locking that is absent in your code? > When you connect the USB cable, if you have development enabled, you > instantly start reading out logging info, which may have locking in > there that's fixing some problem you have. > > Anyway, giving up smacks of throwing the baby out with the bath water > because of difficulties with one device. I wouldn't do it. > > On 10/12/2011 12:02 AM, calderwa wrote: > > > > > Nope, 'fraid not. That code seems if anything to makes things a little > > worse for me = intermittent screen glitches, with rectangular areas > > garbled, and the less frequesnt hangup for a second or so, with the > > even less frequent reboot. I am using Samsung Galaxy S, 2.3.3, so > > clearly not restricted to HTC. All hangs seem to be locking problems > > in SharedBufferStack. > > glFlush calls have no effect on my problem. Switching from > > glDrawArrays to VBOs and glDrawElements had no effect. > > > This bug is SO bad and i have spent SO long on it now that I am pretty > > much at the stage of junking many months of work and not publishing > > the openGL version of my app. > > > This comes on top of unacknowledged problems in java 2d drawing > > routines, the ridiculous DirectBuffer problem in 3.0+ where it > > al
Re: [android-developers] Re: OpenGL lockups in 2.2
It's insane to throw away months of work. Are you seeing this behavior in other 2 or 3d games running on that device? If so, it's probably a device fault that you simply can't get around, and should just be ignored. There are other devices in the world that, in theory, it should work on. In your market publish, just mention that you had problems with that device and that it's not recommended to be run there, then move on. If you aren't seeing the behavior elsewhere, then what you have is an application problem. Have you considered that plugging and unplugging the USB cable is introducing thread locking that is absent in your code? When you connect the USB cable, if you have development enabled, you instantly start reading out logging info, which may have locking in there that's fixing some problem you have. Anyway, giving up smacks of throwing the baby out with the bath water because of difficulties with one device. I wouldn't do it. On 10/12/2011 12:02 AM, calderwa wrote: Nope, 'fraid not. That code seems if anything to makes things a little worse for me = intermittent screen glitches, with rectangular areas garbled, and the less frequesnt hangup for a second or so, with the even less frequent reboot. I am using Samsung Galaxy S, 2.3.3, so clearly not restricted to HTC. All hangs seem to be locking problems in SharedBufferStack. glFlush calls have no effect on my problem. Switching from glDrawArrays to VBOs and glDrawElements had no effect. This bug is SO bad and i have spent SO long on it now that I am pretty much at the stage of junking many months of work and not publishing the openGL version of my app. This comes on top of unacknowledged problems in java 2d drawing routines, the ridiculous DirectBuffer problem in 3.0+ where it allocates 4* as much memory as you ask for. The list is nearly endless. Apple, here I come? On Aug 13, 8:18 am, Herko Lategan wrote: Guys! *SOLUTION* I finally *found the solution* while watching one of the Google IO talks! I have been struggling with this problem for over 2 months now, while developing on my HTC Desire, and it made me so demotivated knowing my application will freeze randomly for some users! But after hours of searching I found a solution done by a Google Developer! *solution*: Here is the link to the solution for GLSurfaceView,http://replicaisland.googlecode.com/svn/trunk/src/com/replica/replica... Search for *mSafeMode, **check all the results*, he gives a description as to why the error occurs (it is because of broken drivers for certain chipsets). I have downloaded the source for this game, so if the links disappear you can email me and I'll be happy to share. Good luck to everyone! -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: OpenGL lockups in 2.2
Nope, 'fraid not. That code seems if anything to makes things a little worse for me = intermittent screen glitches, with rectangular areas garbled, and the less frequesnt hangup for a second or so, with the even less frequent reboot. I am using Samsung Galaxy S, 2.3.3, so clearly not restricted to HTC. All hangs seem to be locking problems in SharedBufferStack. glFlush calls have no effect on my problem. Switching from glDrawArrays to VBOs and glDrawElements had no effect. This bug is SO bad and i have spent SO long on it now that I am pretty much at the stage of junking many months of work and not publishing the openGL version of my app. This comes on top of unacknowledged problems in java 2d drawing routines, the ridiculous DirectBuffer problem in 3.0+ where it allocates 4* as much memory as you ask for. The list is nearly endless. Apple, here I come? On Aug 13, 8:18 am, Herko Lategan wrote: > Guys! *SOLUTION* > > I finally *found the solution* while watching one of the Google IO talks! I > have been struggling with this problem for over 2 months now, while > developing on my HTC Desire, and it made me so demotivated knowing my > application will freeze randomly for some users! But after hours of > searching I found a solution done by a Google Developer! > > *solution*: > > Here is the link to the solution for > GLSurfaceView,http://replicaisland.googlecode.com/svn/trunk/src/com/replica/replica... > Search for *mSafeMode, **check all the results*, he gives a description as > to why the error occurs (it is because of broken drivers for certain > chipsets). > > I have downloaded the source for this game, so if the links disappear you > can email me and I'll be happy to share. > > Good luck to everyone! -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: OpenGL lockups in 2.2
Guys! *SOLUTION* I finally *found the solution* while watching one of the Google IO talks! I have been struggling with this problem for over 2 months now, while developing on my HTC Desire, and it made me so demotivated knowing my application will freeze randomly for some users! But after hours of searching I found a solution done by a Google Developer! *solution*: Here is the link to the solution for GLSurfaceView, http://replicaisland.googlecode.com/svn/trunk/src/com/replica/replicaisland/GLSurfaceView.java Search for *mSafeMode, **check all the results*, he gives a description as to why the error occurs (it is because of broken drivers for certain chipsets). I have downloaded the source for this game, so if the links disappear you can email me and I'll be happy to share. Good luck to everyone! -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: OpenGL lockups in 2.2
I have the same f** problem on my HTC Desire 2.2 . Everytime i start it on my device it crashs at the beginning. On my emulator 2.2 it works fine. Set an glFinish() on the end of the OnDrawFrame don't work. Any new information about the bug ? Im not so hard in these scene. On 2 Okt., 23:42, Jeremy Statz wrote: > Sorry to spam so many replies into this thread here... > > I just went and tested a couple of my wallpapers on the G2, since I've > been getting new and strange reports about them. One that was NOT > using glFinish seemed to behave okay, but the other that was using it > was locking up every single time upon switching from portrait to > landscape. I used aLogCat to view the log and this is what was going > on: > > W/SharedBufferStack(21310): waitForCondition(LockCondition) timed out > (identity=2376, status=0). CPU may be pegged. trying again. > W/SharedBufferStack(21310): waitForCondition(LockCondition) timed out > (identity=2376, status=0). CPU may be pegged. trying again. > W/SharedBufferStack(21310): waitForCondition(LockCondition) timed out > (identity=2376, status=0). CPU may be pegged. trying again. > > So, maybe starting with the G2 HTC's made this non-fatal? This > happened consistently upon switching from portrait to landscape. Why > the one that wasn't using glFinish is immune I'm not sure, maybe they > fixed things for the common case (of glFinish not being called) so now > glFinish causes problems? > > On Oct 2, 12:25 pm, Jeremy Statz wrote: > > > > > I'm not mixing Native in with anything either, straight Java is enough > > trouble as is. :P > > > I noticed a definitely framerate hit with glFinish as well, but I'd > > rather suffer through that than have it forcibly lock up and reboot > > people's phones. The worst thing is everybody but HTC seems just fine > > either way. I really don't want to end up with a setting that says > > "Check this if you have an HTC handset". > > > After updating a few things I'm less sold on glFinish actually fixing > > the problem. In particular I'm starting to get e-mails from people > > who just bought a G2, and those seem to be a whole new raft of random > > stuff happening. The most recent EVO update introduced flickering on > > the bottom half of the screen, which I thought glFinish fixed, but it > > doesn't sound like it was a 100% fix. It might just come down to the > > framerate being slower in that case. > > > That said, maybe it means SwapInterval is a sensible thing to try, so > > I'll give it a shot. > > > On Oct 2, 12:04 pm, Leigh McRae > > wrote: > > > > Maybe set swap interval. I have to say I feel your pain as Android is > > > starting to feel like PC when it comes to graphics drivers. > > > > On 10/1/2010 9:03 PM, Robert Green wrote: > > > > > Update - I just tested with eglWaitGL right before swapBuffers and I > > > > got the same nasty performance hit as glFinish. > > > > > Any other ideas? > > > > > On Oct 1, 7:43 pm, Robert Green wrote: > > > >> I'm not mixing native with my context, but I get lots of reports of > > > >> freezing and have seen it on my Nexus One running both 2.1 and 2.2. > > > >> I'm just trying to find a solution to it. > > > > >> On Oct 1, 7:04 pm, Leigh McRae wrote: > > > > >>> I would never call glFinish unless I was reading a buffer back. I > > > >>> would also never call glFlush. Swapping the buffers will do this. > > > >>> When > > > >>> I was writing drivers it was common for glFlush to be a NOP. > > > >>> With that said, if you're mixing native with your context use the > > > >>> eglWait functions. I know eglWaitGL says it's the same as glFinish > > > >>> but > > > >>> I think the driver has a more clearer picture as to what is going on. > > > >>> On 10/1/2010 7:43 PM, Robert Green wrote: > > > After more testing it's apparent that glFinish is causing nearly > > > double the frame time and it's not my code causing the issue. > > > Do you think adding glFlush() will do anything useful? I did that on > > > my first 3D game and no one's ever complained about it freezing. > > > On Oct 1, 6:12 pm, Robert Green wrote: > > > > Bad news... My testing shows a very significant performance hit from > > > > doing this. > > > > Nexus One went from 40fps without ending on glFinish down to 20-27. > > > > G1 went from 30fps down to about 5-10. > > > > This is not good. I can't just put that in and call it fixed or > > > > it'll > > > > make the game unplayable on low end phones. I'll do some more > > > > testing > > > > and see if it's my threading causing problems but I have a bad > > > > feeling > > > > that it's not. > > > > On Sep 30, 3:30 pm, timedilation wrote: > > > >> Jeremy, Glad to note that is has so far worked out for you. > > > >> Leigh, to your point, I also tested this with an explicit call to > > > >> eglWaitGL() function in my own version of GLSurfaceView (basically > > > >> t
[android-developers] Re: OpenGL lockups in 2.2
Sorry to spam so many replies into this thread here... I just went and tested a couple of my wallpapers on the G2, since I've been getting new and strange reports about them. One that was NOT using glFinish seemed to behave okay, but the other that was using it was locking up every single time upon switching from portrait to landscape. I used aLogCat to view the log and this is what was going on: W/SharedBufferStack(21310): waitForCondition(LockCondition) timed out (identity=2376, status=0). CPU may be pegged. trying again. W/SharedBufferStack(21310): waitForCondition(LockCondition) timed out (identity=2376, status=0). CPU may be pegged. trying again. W/SharedBufferStack(21310): waitForCondition(LockCondition) timed out (identity=2376, status=0). CPU may be pegged. trying again. So, maybe starting with the G2 HTC's made this non-fatal? This happened consistently upon switching from portrait to landscape. Why the one that wasn't using glFinish is immune I'm not sure, maybe they fixed things for the common case (of glFinish not being called) so now glFinish causes problems? On Oct 2, 12:25 pm, Jeremy Statz wrote: > I'm not mixing Native in with anything either, straight Java is enough > trouble as is. :P > > I noticed a definitely framerate hit with glFinish as well, but I'd > rather suffer through that than have it forcibly lock up and reboot > people's phones. The worst thing is everybody but HTC seems just fine > either way. I really don't want to end up with a setting that says > "Check this if you have an HTC handset". > > After updating a few things I'm less sold on glFinish actually fixing > the problem. In particular I'm starting to get e-mails from people > who just bought a G2, and those seem to be a whole new raft of random > stuff happening. The most recent EVO update introduced flickering on > the bottom half of the screen, which I thought glFinish fixed, but it > doesn't sound like it was a 100% fix. It might just come down to the > framerate being slower in that case. > > That said, maybe it means SwapInterval is a sensible thing to try, so > I'll give it a shot. > > On Oct 2, 12:04 pm, Leigh McRae > wrote: > > > > > > > > > Maybe set swap interval. I have to say I feel your pain as Android is > > starting to feel like PC when it comes to graphics drivers. > > > On 10/1/2010 9:03 PM, Robert Green wrote: > > > > Update - I just tested with eglWaitGL right before swapBuffers and I > > > got the same nasty performance hit as glFinish. > > > > Any other ideas? > > > > On Oct 1, 7:43 pm, Robert Green wrote: > > >> I'm not mixing native with my context, but I get lots of reports of > > >> freezing and have seen it on my Nexus One running both 2.1 and 2.2. > > >> I'm just trying to find a solution to it. > > > >> On Oct 1, 7:04 pm, Leigh McRae wrote: > > > >>> I would never call glFinish unless I was reading a buffer back. I > > >>> would also never call glFlush. Swapping the buffers will do this. When > > >>> I was writing drivers it was common for glFlush to be a NOP. > > >>> With that said, if you're mixing native with your context use the > > >>> eglWait functions. I know eglWaitGL says it's the same as glFinish but > > >>> I think the driver has a more clearer picture as to what is going on. > > >>> On 10/1/2010 7:43 PM, Robert Green wrote: > > After more testing it's apparent that glFinish is causing nearly > > double the frame time and it's not my code causing the issue. > > Do you think adding glFlush() will do anything useful? I did that on > > my first 3D game and no one's ever complained about it freezing. > > On Oct 1, 6:12 pm, Robert Green wrote: > > > Bad news... My testing shows a very significant performance hit from > > > doing this. > > > Nexus One went from 40fps without ending on glFinish down to 20-27. > > > G1 went from 30fps down to about 5-10. > > > This is not good. I can't just put that in and call it fixed or it'll > > > make the game unplayable on low end phones. I'll do some more testing > > > and see if it's my threading causing problems but I have a bad feeling > > > that it's not. > > > On Sep 30, 3:30 pm, timedilation wrote: > > >> Jeremy, Glad to note that is has so far worked out for you. > > >> Leigh, to your point, I also tested this with an explicit call to > > >> eglWaitGL() function in my own version of GLSurfaceView (basically > > >> this call was added just before the eglSwapBuffer() call). This also > > >> fixed thefreezingin my case. I just resorted to using glFinish() > > >> because that way I didn't have to use my own version of > > >> GLSurfaceView. > > >> So if Google changed their GLSurfaceView in the next release, my code > > >> will not be affected much. > > >> When I mentioned this to a Google developer advocate and he said that > > >> this still needs to be fixed in the OS since it is an OS level bug. > > >
[android-developers] Re: OpenGL lockups in 2.2
That said, I just sat down to test that, and eglSwapInterval doesn't appear to be supported on Android, at least I don't see it in either EGL10 or EGL11. On Oct 2, 3:06 pm, Jeremy Statz wrote: > Back in the day glSwapInterval is what you'd use to synchronize with a > CRT's refresh rate. Setting it to one basically means that > swapBuffers wouldn't happen until the next display refresh. I'd > thought it was dead and buried, but this appears to indicate > otherwise:http://www.khronos.org/opengles/sdk/1.1/docs/man/eglSwapInterval.xml > > On a LCD screen presumably this means it'll clamp to 60Hz intervals > when swapping the buffers, so you don't get a buffer being swapped > halfway through a screen refresh. > > On Oct 2, 2:50 pm, Robert Green wrote: > > > > > > > > > I actually am adding a "safe mode" setting to the game that people can > > use if it's freezing on their device. I can't have it on all the time > > or the game really is unplayably slow on the first gen phones and it > > never seems to lock up on those - just snapdragons. > > > What are you guys talking about with the swap interval? Is that a > > framebuffer thing and if so, where do you handle it? > > > Thanks > > > On Oct 2, 12:25 pm, Jeremy Statz wrote: > > > > I'm not mixing Native in with anything either, straight Java is enough > > > trouble as is. :P > > > > I noticed a definitely framerate hit with glFinish as well, but I'd > > > rather suffer through that than have it forcibly lock up and reboot > > > people's phones. The worst thing is everybody but HTC seems just fine > > > either way. I really don't want to end up with a setting that says > > > "Check this if you have an HTC handset". > > > > After updating a few things I'm less sold on glFinish actually fixing > > > the problem. In particular I'm starting to get e-mails from people > > > who just bought a G2, and those seem to be a whole new raft of random > > > stuff happening. The most recent EVO update introduced flickering on > > > the bottom half of the screen, which I thought glFinish fixed, but it > > > doesn't sound like it was a 100% fix. It might just come down to the > > > framerate being slower in that case. > > > > That said, maybe it means SwapInterval is a sensible thing to try, so > > > I'll give it a shot. > > > > On Oct 2, 12:04 pm, Leigh McRae > > > wrote: > > > > > Maybe set swap interval. I have to say I feel your pain as Android is > > > > starting to feel like PC when it comes to graphics drivers. > > > > > On 10/1/2010 9:03 PM, Robert Green wrote: > > > > > > Update - I just tested with eglWaitGL right before swapBuffers and I > > > > > got the same nasty performance hit as glFinish. > > > > > > Any other ideas? > > > > > > On Oct 1, 7:43 pm, Robert Green wrote: > > > > >> I'm not mixing native with my context, but I get lots of reports of > > > > >> freezing and have seen it on my Nexus One running both 2.1 and 2.2. > > > > >> I'm just trying to find a solution to it. > > > > > >> On Oct 1, 7:04 pm, Leigh McRae > > > > >> wrote: > > > > > >>> I would never call glFinish unless I was reading a buffer back. > > > > >>> I > > > > >>> would also never call glFlush. Swapping the buffers will do this. > > > > >>> When > > > > >>> I was writing drivers it was common for glFlush to be a NOP. > > > > >>> With that said, if you're mixing native with your context use the > > > > >>> eglWait functions. I know eglWaitGL says it's the same as glFinish > > > > >>> but > > > > >>> I think the driver has a more clearer picture as to what is going > > > > >>> on. > > > > >>> On 10/1/2010 7:43 PM, Robert Green wrote: > > > > After more testing it's apparent that glFinish is causing nearly > > > > double the frame time and it's not my code causing the issue. > > > > Do you think adding glFlush() will do anything useful? I did that > > > > on > > > > my first 3D game and no one's ever complained about it freezing. > > > > On Oct 1, 6:12 pm, Robert Green wrote: > > > > > Bad news... My testing shows a very significant performance hit > > > > > from > > > > > doing this. > > > > > Nexus One went from 40fps without ending on glFinish down to > > > > > 20-27. > > > > > G1 went from 30fps down to about 5-10. > > > > > This is not good. I can't just put that in and call it fixed or > > > > > it'll > > > > > make the game unplayable on low end phones. I'll do some more > > > > > testing > > > > > and see if it's my threading causing problems but I have a bad > > > > > feeling > > > > > that it's not. > > > > > On Sep 30, 3:30 pm, timedilation wrote: > > > > >> Jeremy, Glad to note that is has so far worked out for you. > > > > >> Leigh, to your point, I also tested this with an explicit call to > > > > >> eglWaitGL() function in my own version of GLSurfaceView > > > > >> (basically > > > > >> this call was added just before the eglSw
[android-developers] Re: OpenGL lockups in 2.2
Back in the day glSwapInterval is what you'd use to synchronize with a CRT's refresh rate. Setting it to one basically means that swapBuffers wouldn't happen until the next display refresh. I'd thought it was dead and buried, but this appears to indicate otherwise: http://www.khronos.org/opengles/sdk/1.1/docs/man/eglSwapInterval.xml On a LCD screen presumably this means it'll clamp to 60Hz intervals when swapping the buffers, so you don't get a buffer being swapped halfway through a screen refresh. On Oct 2, 2:50 pm, Robert Green wrote: > I actually am adding a "safe mode" setting to the game that people can > use if it's freezing on their device. I can't have it on all the time > or the game really is unplayably slow on the first gen phones and it > never seems to lock up on those - just snapdragons. > > What are you guys talking about with the swap interval? Is that a > framebuffer thing and if so, where do you handle it? > > Thanks > > On Oct 2, 12:25 pm, Jeremy Statz wrote: > > > > > > > > > I'm not mixing Native in with anything either, straight Java is enough > > trouble as is. :P > > > I noticed a definitely framerate hit with glFinish as well, but I'd > > rather suffer through that than have it forcibly lock up and reboot > > people's phones. The worst thing is everybody but HTC seems just fine > > either way. I really don't want to end up with a setting that says > > "Check this if you have an HTC handset". > > > After updating a few things I'm less sold on glFinish actually fixing > > the problem. In particular I'm starting to get e-mails from people > > who just bought a G2, and those seem to be a whole new raft of random > > stuff happening. The most recent EVO update introduced flickering on > > the bottom half of the screen, which I thought glFinish fixed, but it > > doesn't sound like it was a 100% fix. It might just come down to the > > framerate being slower in that case. > > > That said, maybe it means SwapInterval is a sensible thing to try, so > > I'll give it a shot. > > > On Oct 2, 12:04 pm, Leigh McRae > > wrote: > > > > Maybe set swap interval. I have to say I feel your pain as Android is > > > starting to feel like PC when it comes to graphics drivers. > > > > On 10/1/2010 9:03 PM, Robert Green wrote: > > > > > Update - I just tested with eglWaitGL right before swapBuffers and I > > > > got the same nasty performance hit as glFinish. > > > > > Any other ideas? > > > > > On Oct 1, 7:43 pm, Robert Green wrote: > > > >> I'm not mixing native with my context, but I get lots of reports of > > > >> freezing and have seen it on my Nexus One running both 2.1 and 2.2. > > > >> I'm just trying to find a solution to it. > > > > >> On Oct 1, 7:04 pm, Leigh McRae wrote: > > > > >>> I would never call glFinish unless I was reading a buffer back. I > > > >>> would also never call glFlush. Swapping the buffers will do this. > > > >>> When > > > >>> I was writing drivers it was common for glFlush to be a NOP. > > > >>> With that said, if you're mixing native with your context use the > > > >>> eglWait functions. I know eglWaitGL says it's the same as glFinish > > > >>> but > > > >>> I think the driver has a more clearer picture as to what is going on. > > > >>> On 10/1/2010 7:43 PM, Robert Green wrote: > > > After more testing it's apparent that glFinish is causing nearly > > > double the frame time and it's not my code causing the issue. > > > Do you think adding glFlush() will do anything useful? I did that on > > > my first 3D game and no one's ever complained about it freezing. > > > On Oct 1, 6:12 pm, Robert Green wrote: > > > > Bad news... My testing shows a very significant performance hit from > > > > doing this. > > > > Nexus One went from 40fps without ending on glFinish down to 20-27. > > > > G1 went from 30fps down to about 5-10. > > > > This is not good. I can't just put that in and call it fixed or > > > > it'll > > > > make the game unplayable on low end phones. I'll do some more > > > > testing > > > > and see if it's my threading causing problems but I have a bad > > > > feeling > > > > that it's not. > > > > On Sep 30, 3:30 pm, timedilation wrote: > > > >> Jeremy, Glad to note that is has so far worked out for you. > > > >> Leigh, to your point, I also tested this with an explicit call to > > > >> eglWaitGL() function in my own version of GLSurfaceView (basically > > > >> this call was added just before the eglSwapBuffer() call). This > > > >> also > > > >> fixed thefreezingin my case. I just resorted to using glFinish() > > > >> because that way I didn't have to use my own version of > > > >> GLSurfaceView. > > > >> So if Google changed their GLSurfaceView in the next release, my > > > >> code > > > >> will not be affected much. > > > >> When I mentioned this to a Google developer advocate and he said > > > >> th
[android-developers] Re: OpenGL lockups in 2.2
I actually am adding a "safe mode" setting to the game that people can use if it's freezing on their device. I can't have it on all the time or the game really is unplayably slow on the first gen phones and it never seems to lock up on those - just snapdragons. What are you guys talking about with the swap interval? Is that a framebuffer thing and if so, where do you handle it? Thanks On Oct 2, 12:25 pm, Jeremy Statz wrote: > I'm not mixing Native in with anything either, straight Java is enough > trouble as is. :P > > I noticed a definitely framerate hit with glFinish as well, but I'd > rather suffer through that than have it forcibly lock up and reboot > people's phones. The worst thing is everybody but HTC seems just fine > either way. I really don't want to end up with a setting that says > "Check this if you have an HTC handset". > > After updating a few things I'm less sold on glFinish actually fixing > the problem. In particular I'm starting to get e-mails from people > who just bought a G2, and those seem to be a whole new raft of random > stuff happening. The most recent EVO update introduced flickering on > the bottom half of the screen, which I thought glFinish fixed, but it > doesn't sound like it was a 100% fix. It might just come down to the > framerate being slower in that case. > > That said, maybe it means SwapInterval is a sensible thing to try, so > I'll give it a shot. > > On Oct 2, 12:04 pm, Leigh McRae > wrote: > > > > > > > > > Maybe set swap interval. I have to say I feel your pain as Android is > > starting to feel like PC when it comes to graphics drivers. > > > On 10/1/2010 9:03 PM, Robert Green wrote: > > > > Update - I just tested with eglWaitGL right before swapBuffers and I > > > got the same nasty performance hit as glFinish. > > > > Any other ideas? > > > > On Oct 1, 7:43 pm, Robert Green wrote: > > >> I'm not mixing native with my context, but I get lots of reports of > > >> freezing and have seen it on my Nexus One running both 2.1 and 2.2. > > >> I'm just trying to find a solution to it. > > > >> On Oct 1, 7:04 pm, Leigh McRae wrote: > > > >>> I would never call glFinish unless I was reading a buffer back. I > > >>> would also never call glFlush. Swapping the buffers will do this. When > > >>> I was writing drivers it was common for glFlush to be a NOP. > > >>> With that said, if you're mixing native with your context use the > > >>> eglWait functions. I know eglWaitGL says it's the same as glFinish but > > >>> I think the driver has a more clearer picture as to what is going on. > > >>> On 10/1/2010 7:43 PM, Robert Green wrote: > > After more testing it's apparent that glFinish is causing nearly > > double the frame time and it's not my code causing the issue. > > Do you think adding glFlush() will do anything useful? I did that on > > my first 3D game and no one's ever complained about it freezing. > > On Oct 1, 6:12 pm, Robert Green wrote: > > > Bad news... My testing shows a very significant performance hit from > > > doing this. > > > Nexus One went from 40fps without ending on glFinish down to 20-27. > > > G1 went from 30fps down to about 5-10. > > > This is not good. I can't just put that in and call it fixed or it'll > > > make the game unplayable on low end phones. I'll do some more testing > > > and see if it's my threading causing problems but I have a bad feeling > > > that it's not. > > > On Sep 30, 3:30 pm, timedilation wrote: > > >> Jeremy, Glad to note that is has so far worked out for you. > > >> Leigh, to your point, I also tested this with an explicit call to > > >> eglWaitGL() function in my own version of GLSurfaceView (basically > > >> this call was added just before the eglSwapBuffer() call). This also > > >> fixed thefreezingin my case. I just resorted to using glFinish() > > >> because that way I didn't have to use my own version of > > >> GLSurfaceView. > > >> So if Google changed their GLSurfaceView in the next release, my code > > >> will not be affected much. > > >> When I mentioned this to a Google developer advocate and he said that > > >> this still needs to be fixed in the OS since it is an OS level bug. > > >> eglSwapBuffers() called glFlush() internally anyways but it ends up > > >> getting deadlocked once in a while on some of these devices we have > > >> seen. Explicitly calling eglWaitGL() or glFinish() in the renderloop > > >> *before* the eglSwapBuffers() appears to have fixed this issue in > > >> many > > >> (if not all) cases. I still have users reporting to me that their > > >> phonesfreezingeven with the latest update, albeit much less > > >> frequently. > > >> Let's hope for Google to fix this once and for all in their next > > >> release. > > >> On Sep 30, 2:26 pm, Leigh McRae > > >> wrote: > > >>> You might want to look into the eg
[android-developers] Re: OpenGL lockups in 2.2
I'm not mixing Native in with anything either, straight Java is enough trouble as is. :P I noticed a definitely framerate hit with glFinish as well, but I'd rather suffer through that than have it forcibly lock up and reboot people's phones. The worst thing is everybody but HTC seems just fine either way. I really don't want to end up with a setting that says "Check this if you have an HTC handset". After updating a few things I'm less sold on glFinish actually fixing the problem. In particular I'm starting to get e-mails from people who just bought a G2, and those seem to be a whole new raft of random stuff happening. The most recent EVO update introduced flickering on the bottom half of the screen, which I thought glFinish fixed, but it doesn't sound like it was a 100% fix. It might just come down to the framerate being slower in that case. That said, maybe it means SwapInterval is a sensible thing to try, so I'll give it a shot. On Oct 2, 12:04 pm, Leigh McRae wrote: > Maybe set swap interval. I have to say I feel your pain as Android is > starting to feel like PC when it comes to graphics drivers. > > On 10/1/2010 9:03 PM, Robert Green wrote: > > > > > > > > > Update - I just tested with eglWaitGL right before swapBuffers and I > > got the same nasty performance hit as glFinish. > > > Any other ideas? > > > On Oct 1, 7:43 pm, Robert Green wrote: > >> I'm not mixing native with my context, but I get lots of reports of > >> freezing and have seen it on my Nexus One running both 2.1 and 2.2. > >> I'm just trying to find a solution to it. > > >> On Oct 1, 7:04 pm, Leigh McRae wrote: > > >>> I would never call glFinish unless I was reading a buffer back. I > >>> would also never call glFlush. Swapping the buffers will do this. When > >>> I was writing drivers it was common for glFlush to be a NOP. > >>> With that said, if you're mixing native with your context use the > >>> eglWait functions. I know eglWaitGL says it's the same as glFinish but > >>> I think the driver has a more clearer picture as to what is going on. > >>> On 10/1/2010 7:43 PM, Robert Green wrote: > After more testing it's apparent that glFinish is causing nearly > double the frame time and it's not my code causing the issue. > Do you think adding glFlush() will do anything useful? I did that on > my first 3D game and no one's ever complained about it freezing. > On Oct 1, 6:12 pm, Robert Green wrote: > > Bad news... My testing shows a very significant performance hit from > > doing this. > > Nexus One went from 40fps without ending on glFinish down to 20-27. > > G1 went from 30fps down to about 5-10. > > This is not good. I can't just put that in and call it fixed or it'll > > make the game unplayable on low end phones. I'll do some more testing > > and see if it's my threading causing problems but I have a bad feeling > > that it's not. > > On Sep 30, 3:30 pm, timedilation wrote: > >> Jeremy, Glad to note that is has so far worked out for you. > >> Leigh, to your point, I also tested this with an explicit call to > >> eglWaitGL() function in my own version of GLSurfaceView (basically > >> this call was added just before the eglSwapBuffer() call). This also > >> fixed thefreezingin my case. I just resorted to using glFinish() > >> because that way I didn't have to use my own version of GLSurfaceView. > >> So if Google changed their GLSurfaceView in the next release, my code > >> will not be affected much. > >> When I mentioned this to a Google developer advocate and he said that > >> this still needs to be fixed in the OS since it is an OS level bug. > >> eglSwapBuffers() called glFlush() internally anyways but it ends up > >> getting deadlocked once in a while on some of these devices we have > >> seen. Explicitly calling eglWaitGL() or glFinish() in the renderloop > >> *before* the eglSwapBuffers() appears to have fixed this issue in many > >> (if not all) cases. I still have users reporting to me that their > >> phonesfreezingeven with the latest update, albeit much less > >> frequently. > >> Let's hope for Google to fix this once and for all in their next > >> release. > >> On Sep 30, 2:26 pm, Leigh McRae > >> wrote: > >>> You might want to look into the eglWait functions that are used to > >>> synchronize with the native rendering system. > >>> On 9/30/2010 2:07 PM, Jeremy Statz wrote: > I've tested this extensively at this point (including a 20-hour run > on > an Incredible) and I think you're right, calling glFinish() seems > like > it largely fixes the problem. Wow, I'd really thought that one was > outmoded. > Related to this, the most recent EVO update was causing the > framebuffer to flicker with black squares sometimes on my wallpapers, > and calling g
Re: [android-developers] Re: OpenGL lockups in 2.2
Maybe set swap interval. I have to say I feel your pain as Android is starting to feel like PC when it comes to graphics drivers. On 10/1/2010 9:03 PM, Robert Green wrote: Update - I just tested with eglWaitGL right before swapBuffers and I got the same nasty performance hit as glFinish. Any other ideas? On Oct 1, 7:43 pm, Robert Green wrote: I'm not mixing native with my context, but I get lots of reports of freezing and have seen it on my Nexus One running both 2.1 and 2.2. I'm just trying to find a solution to it. On Oct 1, 7:04 pm, Leigh McRae wrote: I would never call glFinish unless I was reading a buffer back. I would also never call glFlush. Swapping the buffers will do this. When I was writing drivers it was common for glFlush to be a NOP. With that said, if you're mixing native with your context use the eglWait functions. I know eglWaitGL says it's the same as glFinish but I think the driver has a more clearer picture as to what is going on. On 10/1/2010 7:43 PM, Robert Green wrote: After more testing it's apparent that glFinish is causing nearly double the frame time and it's not my code causing the issue. Do you think adding glFlush() will do anything useful? I did that on my first 3D game and no one's ever complained about it freezing. On Oct 1, 6:12 pm, Robert Greenwrote: Bad news... My testing shows a very significant performance hit from doing this. Nexus One went from 40fps without ending on glFinish down to 20-27. G1 went from 30fps down to about 5-10. This is not good. I can't just put that in and call it fixed or it'll make the game unplayable on low end phones. I'll do some more testing and see if it's my threading causing problems but I have a bad feeling that it's not. On Sep 30, 3:30 pm, timedilationwrote: Jeremy, Glad to note that is has so far worked out for you. Leigh, to your point, I also tested this with an explicit call to eglWaitGL() function in my own version of GLSurfaceView (basically this call was added just before the eglSwapBuffer() call). This also fixed thefreezingin my case. I just resorted to using glFinish() because that way I didn't have to use my own version of GLSurfaceView. So if Google changed their GLSurfaceView in the next release, my code will not be affected much. When I mentioned this to a Google developer advocate and he said that this still needs to be fixed in the OS since it is an OS level bug. eglSwapBuffers() called glFlush() internally anyways but it ends up getting deadlocked once in a while on some of these devices we have seen. Explicitly calling eglWaitGL() or glFinish() in the renderloop *before* the eglSwapBuffers() appears to have fixed this issue in many (if not all) cases. I still have users reporting to me that their phonesfreezingeven with the latest update, albeit much less frequently. Let's hope for Google to fix this once and for all in their next release. On Sep 30, 2:26 pm, Leigh McRae wrote: You might want to look into the eglWait functions that are used to synchronize with the native rendering system. On 9/30/2010 2:07 PM, Jeremy Statz wrote: I've tested this extensively at this point (including a 20-hour run on an Incredible) and I think you're right, calling glFinish() seems like it largely fixes the problem. Wow, I'd really thought that one was outmoded. Related to this, the most recent EVO update was causing the framebuffer to flicker with black squares sometimes on my wallpapers, and calling glFinish() fixed that too. And it fixed a similar corruption I had reported a few days ago on the Nexus one. It's the magic HTC fixer-upper! TimeDilation, you're my hero. On Sep 21, 3:26 pm, timedilation wrote: It was happening between 1 - 45 minutes into the app. Every single time. Maybe this is not a permanent fix and maybe it has just reduced the frequency of freezings. But as I mentioned before, so far I have not seen a single freeze since I made that change 2 days ago. On Sep 21, 4:05 pm, Robert Green wrote: And it was happening reliably before? On Sep 21, 12:48 pm, timedilation wrote: I haven't seen any freeze since making that change (I am only testing this on the HTC Desire running 2.2) On Sep 21, 1:32 pm, Robert Green wrote: So after finishing with glFinish(), you haven't seen a freeze at all or you just saw one now? I'm not sure what to make of the "until now" part :) If you really think that's making a difference, I'll try it out and see if it makes a difference for my games as well, though I have to play for about an hour to see it happen. On Sep 21, 12:10 pm, timedilation wrote: Not sure if the following will fix thefreezingin all cases but it appears to have fixed it in my app. I still have my fingers crossed about it although my app hasn't frozen for a while now - even when I let it run overnight on an HTC Desire 2.2. I first took the source code of GLSurfaceView into my custom class and added this line immediately before the eglSwapBuffer()
[android-developers] Re: OpenGL lockups in 2.2
Update - I just tested with eglWaitGL right before swapBuffers and I got the same nasty performance hit as glFinish. Any other ideas? On Oct 1, 7:43 pm, Robert Green wrote: > I'm not mixing native with my context, but I get lots of reports of > freezing and have seen it on my Nexus One running both 2.1 and 2.2. > I'm just trying to find a solution to it. > > On Oct 1, 7:04 pm, Leigh McRae wrote: > > > > > > > > > I would never call glFinish unless I was reading a buffer back. I > > would also never call glFlush. Swapping the buffers will do this. When > > I was writing drivers it was common for glFlush to be a NOP. > > > With that said, if you're mixing native with your context use the > > eglWait functions. I know eglWaitGL says it's the same as glFinish but > > I think the driver has a more clearer picture as to what is going on. > > > On 10/1/2010 7:43 PM, Robert Green wrote: > > > > After more testing it's apparent that glFinish is causing nearly > > > double the frame time and it's not my code causing the issue. > > > > Do you think adding glFlush() will do anything useful? I did that on > > > my first 3D game and no one's ever complained about it freezing. > > > > On Oct 1, 6:12 pm, Robert Green wrote: > > >> Bad news... My testing shows a very significant performance hit from > > >> doing this. > > > >> Nexus One went from 40fps without ending on glFinish down to 20-27. > > >> G1 went from 30fps down to about 5-10. > > > >> This is not good. I can't just put that in and call it fixed or it'll > > >> make the game unplayable on low end phones. I'll do some more testing > > >> and see if it's my threading causing problems but I have a bad feeling > > >> that it's not. > > > >> On Sep 30, 3:30 pm, timedilation wrote: > > > >>> Jeremy, Glad to note that is has so far worked out for you. > > >>> Leigh, to your point, I also tested this with an explicit call to > > >>> eglWaitGL() function in my own version of GLSurfaceView (basically > > >>> this call was added just before the eglSwapBuffer() call). This also > > >>> fixed thefreezingin my case. I just resorted to using glFinish() > > >>> because that way I didn't have to use my own version of GLSurfaceView. > > >>> So if Google changed their GLSurfaceView in the next release, my code > > >>> will not be affected much. > > >>> When I mentioned this to a Google developer advocate and he said that > > >>> this still needs to be fixed in the OS since it is an OS level bug. > > >>> eglSwapBuffers() called glFlush() internally anyways but it ends up > > >>> getting deadlocked once in a while on some of these devices we have > > >>> seen. Explicitly calling eglWaitGL() or glFinish() in the renderloop > > >>> *before* the eglSwapBuffers() appears to have fixed this issue in many > > >>> (if not all) cases. I still have users reporting to me that their > > >>> phonesfreezingeven with the latest update, albeit much less > > >>> frequently. > > >>> Let's hope for Google to fix this once and for all in their next > > >>> release. > > >>> On Sep 30, 2:26 pm, Leigh McRae > > >>> wrote: > > You might want to look into the eglWait functions that are used to > > synchronize with the native rendering system. > > On 9/30/2010 2:07 PM, Jeremy Statz wrote: > > > I've tested this extensively at this point (including a 20-hour run on > > > an Incredible) and I think you're right, calling glFinish() seems like > > > it largely fixes the problem. Wow, I'd really thought that one was > > > outmoded. > > > Related to this, the most recent EVO update was causing the > > > framebuffer to flicker with black squares sometimes on my wallpapers, > > > and calling glFinish() fixed that too. And it fixed a similar > > > corruption I had reported a few days ago on the Nexus one. It's the > > > magic HTC fixer-upper! > > > TimeDilation, you're my hero. > > > On Sep 21, 3:26 pm, timedilation wrote: > > >> It was happening between 1 - 45 minutes into the app. Every single > > >> time. > > >> Maybe this is not a permanent fix and maybe it has just reduced the > > >> frequency of freezings. But as I mentioned before, so far I have not > > >> seen a single freeze since I made that change 2 days ago. > > >> On Sep 21, 4:05 pm, Robert Green wrote: > > >>> And it was happening reliably before? > > >>> On Sep 21, 12:48 pm, timedilation wrote: > > I haven't seen any freeze since making that change (I am only > > testing > > this on the HTC Desire running 2.2) > > On Sep 21, 1:32 pm, Robert Green wrote: > > > So after finishing with glFinish(), you haven't seen a freeze at > > > all > > > or you just saw one now? I'm not sure what to make of the "until > > > now" > > > part :) > > > If you really think that's making a difference, I'll try it out > > > and > > > see if it make
[android-developers] Re: OpenGL lockups in 2.2
I'm not mixing native with my context, but I get lots of reports of freezing and have seen it on my Nexus One running both 2.1 and 2.2. I'm just trying to find a solution to it. On Oct 1, 7:04 pm, Leigh McRae wrote: > I would never call glFinish unless I was reading a buffer back. I > would also never call glFlush. Swapping the buffers will do this. When > I was writing drivers it was common for glFlush to be a NOP. > > With that said, if you're mixing native with your context use the > eglWait functions. I know eglWaitGL says it's the same as glFinish but > I think the driver has a more clearer picture as to what is going on. > > On 10/1/2010 7:43 PM, Robert Green wrote: > > > > > > > > > After more testing it's apparent that glFinish is causing nearly > > double the frame time and it's not my code causing the issue. > > > Do you think adding glFlush() will do anything useful? I did that on > > my first 3D game and no one's ever complained about it freezing. > > > On Oct 1, 6:12 pm, Robert Green wrote: > >> Bad news... My testing shows a very significant performance hit from > >> doing this. > > >> Nexus One went from 40fps without ending on glFinish down to 20-27. > >> G1 went from 30fps down to about 5-10. > > >> This is not good. I can't just put that in and call it fixed or it'll > >> make the game unplayable on low end phones. I'll do some more testing > >> and see if it's my threading causing problems but I have a bad feeling > >> that it's not. > > >> On Sep 30, 3:30 pm, timedilation wrote: > > >>> Jeremy, Glad to note that is has so far worked out for you. > >>> Leigh, to your point, I also tested this with an explicit call to > >>> eglWaitGL() function in my own version of GLSurfaceView (basically > >>> this call was added just before the eglSwapBuffer() call). This also > >>> fixed thefreezingin my case. I just resorted to using glFinish() > >>> because that way I didn't have to use my own version of GLSurfaceView. > >>> So if Google changed their GLSurfaceView in the next release, my code > >>> will not be affected much. > >>> When I mentioned this to a Google developer advocate and he said that > >>> this still needs to be fixed in the OS since it is an OS level bug. > >>> eglSwapBuffers() called glFlush() internally anyways but it ends up > >>> getting deadlocked once in a while on some of these devices we have > >>> seen. Explicitly calling eglWaitGL() or glFinish() in the renderloop > >>> *before* the eglSwapBuffers() appears to have fixed this issue in many > >>> (if not all) cases. I still have users reporting to me that their > >>> phonesfreezingeven with the latest update, albeit much less > >>> frequently. > >>> Let's hope for Google to fix this once and for all in their next > >>> release. > >>> On Sep 30, 2:26 pm, Leigh McRae > >>> wrote: > You might want to look into the eglWait functions that are used to > synchronize with the native rendering system. > On 9/30/2010 2:07 PM, Jeremy Statz wrote: > > I've tested this extensively at this point (including a 20-hour run on > > an Incredible) and I think you're right, calling glFinish() seems like > > it largely fixes the problem. Wow, I'd really thought that one was > > outmoded. > > Related to this, the most recent EVO update was causing the > > framebuffer to flicker with black squares sometimes on my wallpapers, > > and calling glFinish() fixed that too. And it fixed a similar > > corruption I had reported a few days ago on the Nexus one. It's the > > magic HTC fixer-upper! > > TimeDilation, you're my hero. > > On Sep 21, 3:26 pm, timedilation wrote: > >> It was happening between 1 - 45 minutes into the app. Every single > >> time. > >> Maybe this is not a permanent fix and maybe it has just reduced the > >> frequency of freezings. But as I mentioned before, so far I have not > >> seen a single freeze since I made that change 2 days ago. > >> On Sep 21, 4:05 pm, Robert Green wrote: > >>> And it was happening reliably before? > >>> On Sep 21, 12:48 pm, timedilation wrote: > I haven't seen any freeze since making that change (I am only testing > this on the HTC Desire running 2.2) > On Sep 21, 1:32 pm, Robert Green wrote: > > So after finishing with glFinish(), you haven't seen a freeze at all > > or you just saw one now? I'm not sure what to make of the "until > > now" > > part :) > > If you really think that's making a difference, I'll try it out and > > see if it makes a difference for my games as well, though I have to > > play for about an hour to see it happen. > > On Sep 21, 12:10 pm, timedilation wrote: > >> Not sure if the following will fix thefreezingin all cases but it > >> appears to have fixed it in my app. I still have my fingers crossed > >> about it although my app hasn't frozen fo
Re: [android-developers] Re: OpenGL lockups in 2.2
I would never call glFinish unless I was reading a buffer back. I would also never call glFlush. Swapping the buffers will do this. When I was writing drivers it was common for glFlush to be a NOP. With that said, if you're mixing native with your context use the eglWait functions. I know eglWaitGL says it's the same as glFinish but I think the driver has a more clearer picture as to what is going on. On 10/1/2010 7:43 PM, Robert Green wrote: After more testing it's apparent that glFinish is causing nearly double the frame time and it's not my code causing the issue. Do you think adding glFlush() will do anything useful? I did that on my first 3D game and no one's ever complained about it freezing. On Oct 1, 6:12 pm, Robert Green wrote: Bad news... My testing shows a very significant performance hit from doing this. Nexus One went from 40fps without ending on glFinish down to 20-27. G1 went from 30fps down to about 5-10. This is not good. I can't just put that in and call it fixed or it'll make the game unplayable on low end phones. I'll do some more testing and see if it's my threading causing problems but I have a bad feeling that it's not. On Sep 30, 3:30 pm, timedilation wrote: Jeremy, Glad to note that is has so far worked out for you. Leigh, to your point, I also tested this with an explicit call to eglWaitGL() function in my own version of GLSurfaceView (basically this call was added just before the eglSwapBuffer() call). This also fixed thefreezingin my case. I just resorted to using glFinish() because that way I didn't have to use my own version of GLSurfaceView. So if Google changed their GLSurfaceView in the next release, my code will not be affected much. When I mentioned this to a Google developer advocate and he said that this still needs to be fixed in the OS since it is an OS level bug. eglSwapBuffers() called glFlush() internally anyways but it ends up getting deadlocked once in a while on some of these devices we have seen. Explicitly calling eglWaitGL() or glFinish() in the renderloop *before* the eglSwapBuffers() appears to have fixed this issue in many (if not all) cases. I still have users reporting to me that their phonesfreezingeven with the latest update, albeit much less frequently. Let's hope for Google to fix this once and for all in their next release. On Sep 30, 2:26 pm, Leigh McRae wrote: You might want to look into the eglWait functions that are used to synchronize with the native rendering system. On 9/30/2010 2:07 PM, Jeremy Statz wrote: I've tested this extensively at this point (including a 20-hour run on an Incredible) and I think you're right, calling glFinish() seems like it largely fixes the problem. Wow, I'd really thought that one was outmoded. Related to this, the most recent EVO update was causing the framebuffer to flicker with black squares sometimes on my wallpapers, and calling glFinish() fixed that too. And it fixed a similar corruption I had reported a few days ago on the Nexus one. It's the magic HTC fixer-upper! TimeDilation, you're my hero. On Sep 21, 3:26 pm, timedilationwrote: It was happening between 1 - 45 minutes into the app. Every single time. Maybe this is not a permanent fix and maybe it has just reduced the frequency of freezings. But as I mentioned before, so far I have not seen a single freeze since I made that change 2 days ago. On Sep 21, 4:05 pm, Robert Greenwrote: And it was happening reliably before? On Sep 21, 12:48 pm, timedilationwrote: I haven't seen any freeze since making that change (I am only testing this on the HTC Desire running 2.2) On Sep 21, 1:32 pm, Robert Greenwrote: So after finishing with glFinish(), you haven't seen a freeze at all or you just saw one now? I'm not sure what to make of the "until now" part :) If you really think that's making a difference, I'll try it out and see if it makes a difference for my games as well, though I have to play for about an hour to see it happen. On Sep 21, 12:10 pm, timedilationwrote: Not sure if the following will fix thefreezingin all cases but it appears to have fixed it in my app. I still have my fingers crossed about it although my app hasn't frozen for a while now - even when I let it run overnight on an HTC Desire 2.2. I first took the source code of GLSurfaceView into my custom class and added this line immediately before the eglSwapBuffer() call in the EGLHelper class function: mEgl.glWaitGL(); This is a blocking call that waits for all existing GL commands to be processed before returning. With this line, thefreezingseems to have stopped. I then realized that the glFinish() function does the same thing. So I went back to using the built-in GLSurfaceView and added the glFinish() call at the very end of my renderer.onDrawFrame() function. This had the same effect and I haven't seen a freeze until now. I suspect this call is just making the loop wait explicitly for all GL commands to be processed before render
[android-developers] Re: OpenGL lockups in 2.2
After more testing it's apparent that glFinish is causing nearly double the frame time and it's not my code causing the issue. Do you think adding glFlush() will do anything useful? I did that on my first 3D game and no one's ever complained about it freezing. On Oct 1, 6:12 pm, Robert Green wrote: > Bad news... My testing shows a very significant performance hit from > doing this. > > Nexus One went from 40fps without ending on glFinish down to 20-27. > G1 went from 30fps down to about 5-10. > > This is not good. I can't just put that in and call it fixed or it'll > make the game unplayable on low end phones. I'll do some more testing > and see if it's my threading causing problems but I have a bad feeling > that it's not. > > On Sep 30, 3:30 pm, timedilation wrote: > > > > > > > > > Jeremy, Glad to note that is has so far worked out for you. > > > Leigh, to your point, I also tested this with an explicit call to > > eglWaitGL() function in my own version of GLSurfaceView (basically > > this call was added just before the eglSwapBuffer() call). This also > > fixed thefreezingin my case. I just resorted to using glFinish() > > because that way I didn't have to use my own version of GLSurfaceView. > > So if Google changed their GLSurfaceView in the next release, my code > > will not be affected much. > > > When I mentioned this to a Google developer advocate and he said that > > this still needs to be fixed in the OS since it is an OS level bug. > > eglSwapBuffers() called glFlush() internally anyways but it ends up > > getting deadlocked once in a while on some of these devices we have > > seen. Explicitly calling eglWaitGL() or glFinish() in the renderloop > > *before* the eglSwapBuffers() appears to have fixed this issue in many > > (if not all) cases. I still have users reporting to me that their > > phonesfreezingeven with the latest update, albeit much less > > frequently. > > > Let's hope for Google to fix this once and for all in their next > > release. > > > On Sep 30, 2:26 pm, Leigh McRae > > wrote: > > > > You might want to look into the eglWait functions that are used to > > > synchronize with the native rendering system. > > > > On 9/30/2010 2:07 PM, Jeremy Statz wrote: > > > > > I've tested this extensively at this point (including a 20-hour run on > > > > an Incredible) and I think you're right, calling glFinish() seems like > > > > it largely fixes the problem. Wow, I'd really thought that one was > > > > outmoded. > > > > > Related to this, the most recent EVO update was causing the > > > > framebuffer to flicker with black squares sometimes on my wallpapers, > > > > and calling glFinish() fixed that too. And it fixed a similar > > > > corruption I had reported a few days ago on the Nexus one. It's the > > > > magic HTC fixer-upper! > > > > > TimeDilation, you're my hero. > > > > > On Sep 21, 3:26 pm, timedilation wrote: > > > >> It was happening between 1 - 45 minutes into the app. Every single > > > >> time. > > > >> Maybe this is not a permanent fix and maybe it has just reduced the > > > >> frequency of freezings. But as I mentioned before, so far I have not > > > >> seen a single freeze since I made that change 2 days ago. > > > > >> On Sep 21, 4:05 pm, Robert Green wrote: > > > > >>> And it was happening reliably before? > > > >>> On Sep 21, 12:48 pm, timedilation wrote: > > > I haven't seen any freeze since making that change (I am only testing > > > this on the HTC Desire running 2.2) > > > On Sep 21, 1:32 pm, Robert Green wrote: > > > > So after finishing with glFinish(), you haven't seen a freeze at all > > > > or you just saw one now? I'm not sure what to make of the "until > > > > now" > > > > part :) > > > > If you really think that's making a difference, I'll try it out and > > > > see if it makes a difference for my games as well, though I have to > > > > play for about an hour to see it happen. > > > > On Sep 21, 12:10 pm, timedilation wrote: > > > >> Not sure if the following will fix thefreezingin all cases but it > > > >> appears to have fixed it in my app. I still have my fingers crossed > > > >> about it although my app hasn't frozen for a while now - even when > > > >> I > > > >> let it run overnight on an HTC Desire 2.2. > > > >> I first took the source code of GLSurfaceView into my custom class > > > >> and > > > >> added this line immediately before the eglSwapBuffer() call in the > > > >> EGLHelper class function: > > > >> mEgl.glWaitGL(); > > > >> This is a blocking call that waits for all existing GL commands to > > > >> be > > > >> processed before returning. With this line, thefreezingseems to > > > >> have > > > >> stopped. > > > >> I then realized that the glFinish() function does the same thing. > > > >> So I > > > >> went back to using the built-in GLSurfaceView and added the > > > >> glFinish() > > > >> ca
[android-developers] Re: OpenGL lockups in 2.2
Bad news... My testing shows a very significant performance hit from doing this. Nexus One went from 40fps without ending on glFinish down to 20-27. G1 went from 30fps down to about 5-10. This is not good. I can't just put that in and call it fixed or it'll make the game unplayable on low end phones. I'll do some more testing and see if it's my threading causing problems but I have a bad feeling that it's not. On Sep 30, 3:30 pm, timedilation wrote: > Jeremy, Glad to note that is has so far worked out for you. > > Leigh, to your point, I also tested this with an explicit call to > eglWaitGL() function in my own version of GLSurfaceView (basically > this call was added just before the eglSwapBuffer() call). This also > fixed thefreezingin my case. I just resorted to using glFinish() > because that way I didn't have to use my own version of GLSurfaceView. > So if Google changed their GLSurfaceView in the next release, my code > will not be affected much. > > When I mentioned this to a Google developer advocate and he said that > this still needs to be fixed in the OS since it is an OS level bug. > eglSwapBuffers() called glFlush() internally anyways but it ends up > getting deadlocked once in a while on some of these devices we have > seen. Explicitly calling eglWaitGL() or glFinish() in the renderloop > *before* the eglSwapBuffers() appears to have fixed this issue in many > (if not all) cases. I still have users reporting to me that their > phonesfreezingeven with the latest update, albeit much less > frequently. > > Let's hope for Google to fix this once and for all in their next > release. > > On Sep 30, 2:26 pm, Leigh McRae > wrote: > > > > > > > > > You might want to look into the eglWait functions that are used to > > synchronize with the native rendering system. > > > On 9/30/2010 2:07 PM, Jeremy Statz wrote: > > > > I've tested this extensively at this point (including a 20-hour run on > > > an Incredible) and I think you're right, calling glFinish() seems like > > > it largely fixes the problem. Wow, I'd really thought that one was > > > outmoded. > > > > Related to this, the most recent EVO update was causing the > > > framebuffer to flicker with black squares sometimes on my wallpapers, > > > and calling glFinish() fixed that too. And it fixed a similar > > > corruption I had reported a few days ago on the Nexus one. It's the > > > magic HTC fixer-upper! > > > > TimeDilation, you're my hero. > > > > On Sep 21, 3:26 pm, timedilation wrote: > > >> It was happening between 1 - 45 minutes into the app. Every single > > >> time. > > >> Maybe this is not a permanent fix and maybe it has just reduced the > > >> frequency of freezings. But as I mentioned before, so far I have not > > >> seen a single freeze since I made that change 2 days ago. > > > >> On Sep 21, 4:05 pm, Robert Green wrote: > > > >>> And it was happening reliably before? > > >>> On Sep 21, 12:48 pm, timedilation wrote: > > I haven't seen any freeze since making that change (I am only testing > > this on the HTC Desire running 2.2) > > On Sep 21, 1:32 pm, Robert Green wrote: > > > So after finishing with glFinish(), you haven't seen a freeze at all > > > or you just saw one now? I'm not sure what to make of the "until now" > > > part :) > > > If you really think that's making a difference, I'll try it out and > > > see if it makes a difference for my games as well, though I have to > > > play for about an hour to see it happen. > > > On Sep 21, 12:10 pm, timedilation wrote: > > >> Not sure if the following will fix thefreezingin all cases but it > > >> appears to have fixed it in my app. I still have my fingers crossed > > >> about it although my app hasn't frozen for a while now - even when I > > >> let it run overnight on an HTC Desire 2.2. > > >> I first took the source code of GLSurfaceView into my custom class > > >> and > > >> added this line immediately before the eglSwapBuffer() call in the > > >> EGLHelper class function: > > >> mEgl.glWaitGL(); > > >> This is a blocking call that waits for all existing GL commands to be > > >> processed before returning. With this line, thefreezingseems to have > > >> stopped. > > >> I then realized that the glFinish() function does the same thing. So > > >> I > > >> went back to using the built-in GLSurfaceView and added the > > >> glFinish() > > >> call at the very end of my renderer.onDrawFrame() function. This had > > >> the same effect and I haven't seen a freeze until now. I suspect this > > >> call is just making the loop wait explicitly for all GL commands to > > >> be > > >> processed before rendering again. I took a look in the profiler and > > >> this call did not add any extra overhead (likely because the > > >> eglSwapBuffers() is also a blocking call and does the same thing - > > >> except that it freezes randomly). > > >>
[android-developers] Re: OpenGL lockups in 2.2
Hi , I'm facing the same issue in Android 2.1. Is there any updates on why these timed out messages come. I tried putting glFinish() call in SurfaceFlinger.cpp before calling eglSwapBuffer. But this isn't helping much. Regards, Manjunath On Sep 22, 1:26 am, timedilation wrote: > It was happening between 1 - 45 minutes into the app. Every single > time. > Maybe this is not a permanent fix and maybe it has just reduced the > frequency of freezings. But as I mentioned before, so far I have not > seen a single freeze since I made that change 2 days ago. > > On Sep 21, 4:05 pm, Robert Green wrote: > > > And it was happening reliably before? > > > On Sep 21, 12:48 pm, timedilation wrote: > > > > I haven't seen any freeze since making that change (I am only testing > > > this on the HTC Desire running 2.2) > > > > On Sep 21, 1:32 pm, Robert Green wrote: > > > > > So after finishing with glFinish(), you haven't seen a freeze at all > > > > or you just saw one now? I'm not sure what to make of the "until now" > > > > part :) > > > > > If you really think that's making a difference, I'll try it out and > > > > see if it makes a difference for my games as well, though I have to > > > > play for about an hour to see it happen. > > > > > On Sep 21, 12:10 pm, timedilation wrote: > > > > > > Not sure if the following will fix the freezing in all cases but it > > > > > appears to have fixed it in my app. I still have my fingers crossed > > > > > about it although my app hasn't frozen for a while now - even when I > > > > > let it run overnight on an HTC Desire 2.2. > > > > > > I first took the source code of GLSurfaceView into my custom class and > > > > > added this line immediately before the eglSwapBuffer() call in the > > > > > EGLHelper class function: > > > > > > mEgl.glWaitGL(); > > > > > > This is a blocking call that waits for all existing GL commands to be > > > > > processed before returning. With this line, the freezing seems to have > > > > > stopped. > > > > > > I then realized that the glFinish() function does the same thing. So I > > > > > went back to using the built-in GLSurfaceView and added the glFinish() > > > > > call at the very end of my renderer.onDrawFrame() function. This had > > > > > the same effect and I haven't seen a freeze until now. I suspect this > > > > > call is just making the loop wait explicitly for all GL commands to be > > > > > processed before rendering again. I took a look in the profiler and > > > > > this call did not add any extra overhead (likely because the > > > > > eglSwapBuffers() is also a blocking call and does the same thing - > > > > > except that it freezes randomly). > > > > > > If the freezing starts again, I will update this post. > > > > > Hope this works for you all out there too. > > > > > > On Sep 17, 7:46 am, String wrote: > > > > > > > It's not all OpenGL implementations, that's for sure. I have 2 apps > > > > > > with OpenGL live wallpapers; one has had the lockup problem, the > > > > > > other > > > > > > hasn't. Architecturally, they're very similar - I based the later > > > > > > one > > > > > > off the earlier. It was by pursuing the differences (like changing > > > > > > textures mid-stream, as I discussed in an earlier post) that I've > > > > > > been > > > > > > able to stop the lockups so far. > > > > > > > String > > > > > > > On Sep 17, 4:26 am, timedilation wrote: > > > > > > > > I have played games like Winds of Steel for hours on my HTC > > > > > > > desire. > > > > > > > Surely they must be using opengl as well (I think). And the FPS is > > > > > > > also pretty good. How's it that those games do not freeze at all? > > > > > > > I > > > > > > > need to dissect those and see what calls they are making. > > > > > > > > On Sep 15, 12:17 pm, Jeremy Statz wrote: > > > > > > > > > I just let the same wallpaper run uninterrupted on a Motorola > > > > > > > > Droid > > > > > > > > for something like 16 hours and it's still fine. I would've > > > > > > > > expected > > > > > > > > my Incredible to have hit the problem by then. I also haven't > > > > > > > > heard > > > > > > > > any reports of this from folks with a Galaxy S variant. > > > > > > > > > On Sep 14, 7:38 pm, timedilation wrote: > > > > > > > > > > This appears to be an HTC specific bug. My app never freezes > > > > > > > > > on the > > > > > > > > > Motorla Droid. EVER. It is very stable on the Droid and I > > > > > > > > > have tested > > > > > > > > > it for about 4months without a single freeze. Interestingly > > > > > > > > > though it > > > > > > > > > never froze on my G1 either. The G1 I have is the ADP1 phone > > > > > > > > > I bought > > > > > > > > > directly from Google. > > > > > > > > > > All other HTC phones that I have exhibit the freezing - Evo, > > > > > > > > > Desire > > > > > > > > > and Nexus One (which is also from HTC I believe). > > > > > > > > > > Apart from that I tested it for a month on Samsung Moment. > > > > > > > > > There
[android-developers] Re: OpenGL lockups in 2.2
Jeremy, Glad to note that is has so far worked out for you. Leigh, to your point, I also tested this with an explicit call to eglWaitGL() function in my own version of GLSurfaceView (basically this call was added just before the eglSwapBuffer() call). This also fixed the freezing in my case. I just resorted to using glFinish() because that way I didn't have to use my own version of GLSurfaceView. So if Google changed their GLSurfaceView in the next release, my code will not be affected much. When I mentioned this to a Google developer advocate and he said that this still needs to be fixed in the OS since it is an OS level bug. eglSwapBuffers() called glFlush() internally anyways but it ends up getting deadlocked once in a while on some of these devices we have seen. Explicitly calling eglWaitGL() or glFinish() in the renderloop *before* the eglSwapBuffers() appears to have fixed this issue in many (if not all) cases. I still have users reporting to me that their phones freezing even with the latest update, albeit much less frequently. Let's hope for Google to fix this once and for all in their next release. On Sep 30, 2:26 pm, Leigh McRae wrote: > You might want to look into the eglWait functions that are used to > synchronize with the native rendering system. > > On 9/30/2010 2:07 PM, Jeremy Statz wrote: > > > > > > > I've tested this extensively at this point (including a 20-hour run on > > an Incredible) and I think you're right, calling glFinish() seems like > > it largely fixes the problem. Wow, I'd really thought that one was > > outmoded. > > > Related to this, the most recent EVO update was causing the > > framebuffer to flicker with black squares sometimes on my wallpapers, > > and calling glFinish() fixed that too. And it fixed a similar > > corruption I had reported a few days ago on the Nexus one. It's the > > magic HTC fixer-upper! > > > TimeDilation, you're my hero. > > > On Sep 21, 3:26 pm, timedilation wrote: > >> It was happening between 1 - 45 minutes into the app. Every single > >> time. > >> Maybe this is not a permanent fix and maybe it has just reduced the > >> frequency of freezings. But as I mentioned before, so far I have not > >> seen a single freeze since I made that change 2 days ago. > > >> On Sep 21, 4:05 pm, Robert Green wrote: > > >>> And it was happening reliably before? > >>> On Sep 21, 12:48 pm, timedilation wrote: > I haven't seen any freeze since making that change (I am only testing > this on the HTC Desire running 2.2) > On Sep 21, 1:32 pm, Robert Green wrote: > > So after finishing with glFinish(), you haven't seen a freeze at all > > or you just saw one now? I'm not sure what to make of the "until now" > > part :) > > If you really think that's making a difference, I'll try it out and > > see if it makes a difference for my games as well, though I have to > > play for about an hour to see it happen. > > On Sep 21, 12:10 pm, timedilation wrote: > >> Not sure if the following will fix the freezing in all cases but it > >> appears to have fixed it in my app. I still have my fingers crossed > >> about it although my app hasn't frozen for a while now - even when I > >> let it run overnight on an HTC Desire 2.2. > >> I first took the source code of GLSurfaceView into my custom class and > >> added this line immediately before the eglSwapBuffer() call in the > >> EGLHelper class function: > >> mEgl.glWaitGL(); > >> This is a blocking call that waits for all existing GL commands to be > >> processed before returning. With this line, the freezing seems to have > >> stopped. > >> I then realized that the glFinish() function does the same thing. So I > >> went back to using the built-in GLSurfaceView and added the glFinish() > >> call at the very end of my renderer.onDrawFrame() function. This had > >> the same effect and I haven't seen a freeze until now. I suspect this > >> call is just making the loop wait explicitly for all GL commands to be > >> processed before rendering again. I took a look in the profiler and > >> this call did not add any extra overhead (likely because the > >> eglSwapBuffers() is also a blocking call and does the same thing - > >> except that it freezes randomly). > >> If the freezing starts again, I will update this post. > >> Hope this works for you all out there too. > >> On Sep 17, 7:46 am, String wrote: > >>> It's not all OpenGL implementations, that's for sure. I have 2 apps > >>> with OpenGL live wallpapers; one has had the lockup problem, the other > >>> hasn't. Architecturally, they're very similar - I based the later one > >>> off the earlier. It was by pursuing the differences (like changing > >>> textures mid-stream, as I discussed in an earlier post) that I've been > >>> able to stop the lockups so far. > >>> String > >>> On Sep 17, 4:26 am, timedilation
Re: [android-developers] Re: OpenGL lockups in 2.2
You might want to look into the eglWait functions that are used to synchronize with the native rendering system. On 9/30/2010 2:07 PM, Jeremy Statz wrote: I've tested this extensively at this point (including a 20-hour run on an Incredible) and I think you're right, calling glFinish() seems like it largely fixes the problem. Wow, I'd really thought that one was outmoded. Related to this, the most recent EVO update was causing the framebuffer to flicker with black squares sometimes on my wallpapers, and calling glFinish() fixed that too. And it fixed a similar corruption I had reported a few days ago on the Nexus one. It's the magic HTC fixer-upper! TimeDilation, you're my hero. On Sep 21, 3:26 pm, timedilation wrote: It was happening between 1 - 45 minutes into the app. Every single time. Maybe this is not a permanent fix and maybe it has just reduced the frequency of freezings. But as I mentioned before, so far I have not seen a single freeze since I made that change 2 days ago. On Sep 21, 4:05 pm, Robert Green wrote: And it was happening reliably before? On Sep 21, 12:48 pm, timedilation wrote: I haven't seen any freeze since making that change (I am only testing this on the HTC Desire running 2.2) On Sep 21, 1:32 pm, Robert Green wrote: So after finishing with glFinish(), you haven't seen a freeze at all or you just saw one now? I'm not sure what to make of the "until now" part :) If you really think that's making a difference, I'll try it out and see if it makes a difference for my games as well, though I have to play for about an hour to see it happen. On Sep 21, 12:10 pm, timedilation wrote: Not sure if the following will fix the freezing in all cases but it appears to have fixed it in my app. I still have my fingers crossed about it although my app hasn't frozen for a while now - even when I let it run overnight on an HTC Desire 2.2. I first took the source code of GLSurfaceView into my custom class and added this line immediately before the eglSwapBuffer() call in the EGLHelper class function: mEgl.glWaitGL(); This is a blocking call that waits for all existing GL commands to be processed before returning. With this line, the freezing seems to have stopped. I then realized that the glFinish() function does the same thing. So I went back to using the built-in GLSurfaceView and added the glFinish() call at the very end of my renderer.onDrawFrame() function. This had the same effect and I haven't seen a freeze until now. I suspect this call is just making the loop wait explicitly for all GL commands to be processed before rendering again. I took a look in the profiler and this call did not add any extra overhead (likely because the eglSwapBuffers() is also a blocking call and does the same thing - except that it freezes randomly). If the freezing starts again, I will update this post. Hope this works for you all out there too. On Sep 17, 7:46 am, String wrote: It's not all OpenGL implementations, that's for sure. I have 2 apps with OpenGL live wallpapers; one has had the lockup problem, the other hasn't. Architecturally, they're very similar - I based the later one off the earlier. It was by pursuing the differences (like changing textures mid-stream, as I discussed in an earlier post) that I've been able to stop the lockups so far. String On Sep 17, 4:26 am, timedilation wrote: I have played games like Winds of Steel for hours on my HTC desire. Surely they must be using opengl as well (I think). And the FPS is also pretty good. How's it that those games do not freeze at all? I need to dissect those and see what calls they are making. On Sep 15, 12:17 pm, Jeremy Statz wrote: I just let the same wallpaper run uninterrupted on a Motorola Droid for something like 16 hours and it's still fine. I would've expected my Incredible to have hit the problem by then. I also haven't heard any reports of this from folks with a Galaxy S variant. On Sep 14, 7:38 pm, timedilation wrote: This appears to be an HTC specific bug. My app never freezes on the Motorla Droid. EVER. It is very stable on the Droid and I have tested it for about 4months without a single freeze. Interestingly though it never froze on my G1 either. The G1 I have is the ADP1 phone I bought directly from Google. All other HTC phones that I have exhibit the freezing - Evo, Desire and Nexus One (which is also from HTC I believe). Apart from that I tested it for a month on Samsung Moment. There was NO freezing there either. I have been in touch with a Google developer advocate and I have submitted the bug report to his team. They are looking into this as well. On Sep 14, 8:23 pm, Jeremy Statz wrote: That's my experience as well. All my log results say that there's no loading or anything necessary -- the frame it dies on is bog standard, with drawFrame going from beginning to end. Any loading is long since done. I'm currently wondering if this is an HTC driver bug. I'm going to let this run on a Motorola Dr
[android-developers] Re: OpenGL lockups in 2.2
I've tested this extensively at this point (including a 20-hour run on an Incredible) and I think you're right, calling glFinish() seems like it largely fixes the problem. Wow, I'd really thought that one was outmoded. Related to this, the most recent EVO update was causing the framebuffer to flicker with black squares sometimes on my wallpapers, and calling glFinish() fixed that too. And it fixed a similar corruption I had reported a few days ago on the Nexus one. It's the magic HTC fixer-upper! TimeDilation, you're my hero. On Sep 21, 3:26 pm, timedilation wrote: > It was happening between 1 - 45 minutes into the app. Every single > time. > Maybe this is not a permanent fix and maybe it has just reduced the > frequency of freezings. But as I mentioned before, so far I have not > seen a single freeze since I made that change 2 days ago. > > On Sep 21, 4:05 pm, Robert Green wrote: > > > > > > > > > And it was happening reliably before? > > > On Sep 21, 12:48 pm, timedilation wrote: > > > > I haven't seen any freeze since making that change (I am only testing > > > this on the HTC Desire running 2.2) > > > > On Sep 21, 1:32 pm, Robert Green wrote: > > > > > So after finishing with glFinish(), you haven't seen a freeze at all > > > > or you just saw one now? I'm not sure what to make of the "until now" > > > > part :) > > > > > If you really think that's making a difference, I'll try it out and > > > > see if it makes a difference for my games as well, though I have to > > > > play for about an hour to see it happen. > > > > > On Sep 21, 12:10 pm, timedilation wrote: > > > > > > Not sure if the following will fix the freezing in all cases but it > > > > > appears to have fixed it in my app. I still have my fingers crossed > > > > > about it although my app hasn't frozen for a while now - even when I > > > > > let it run overnight on an HTC Desire 2.2. > > > > > > I first took the source code of GLSurfaceView into my custom class and > > > > > added this line immediately before the eglSwapBuffer() call in the > > > > > EGLHelper class function: > > > > > > mEgl.glWaitGL(); > > > > > > This is a blocking call that waits for all existing GL commands to be > > > > > processed before returning. With this line, the freezing seems to have > > > > > stopped. > > > > > > I then realized that the glFinish() function does the same thing. So I > > > > > went back to using the built-in GLSurfaceView and added the glFinish() > > > > > call at the very end of my renderer.onDrawFrame() function. This had > > > > > the same effect and I haven't seen a freeze until now. I suspect this > > > > > call is just making the loop wait explicitly for all GL commands to be > > > > > processed before rendering again. I took a look in the profiler and > > > > > this call did not add any extra overhead (likely because the > > > > > eglSwapBuffers() is also a blocking call and does the same thing - > > > > > except that it freezes randomly). > > > > > > If the freezing starts again, I will update this post. > > > > > Hope this works for you all out there too. > > > > > > On Sep 17, 7:46 am, String wrote: > > > > > > > It's not all OpenGL implementations, that's for sure. I have 2 apps > > > > > > with OpenGL live wallpapers; one has had the lockup problem, the > > > > > > other > > > > > > hasn't. Architecturally, they're very similar - I based the later > > > > > > one > > > > > > off the earlier. It was by pursuing the differences (like changing > > > > > > textures mid-stream, as I discussed in an earlier post) that I've > > > > > > been > > > > > > able to stop the lockups so far. > > > > > > > String > > > > > > > On Sep 17, 4:26 am, timedilation wrote: > > > > > > > > I have played games like Winds of Steel for hours on my HTC > > > > > > > desire. > > > > > > > Surely they must be using opengl as well (I think). And the FPS is > > > > > > > also pretty good. How's it that those games do not freeze at all? > > > > > > > I > > > > > > > need to dissect those and see what calls they are making. > > > > > > > > On Sep 15, 12:17 pm, Jeremy Statz wrote: > > > > > > > > > I just let the same wallpaper run uninterrupted on a Motorola > > > > > > > > Droid > > > > > > > > for something like 16 hours and it's still fine. I would've > > > > > > > > expected > > > > > > > > my Incredible to have hit the problem by then. I also haven't > > > > > > > > heard > > > > > > > > any reports of this from folks with a Galaxy S variant. > > > > > > > > > On Sep 14, 7:38 pm, timedilation wrote: > > > > > > > > > > This appears to be an HTC specific bug. My app never freezes > > > > > > > > > on the > > > > > > > > > Motorla Droid. EVER. It is very stable on the Droid and I > > > > > > > > > have tested > > > > > > > > > it for about 4months without a single freeze. Interestingly > > > > > > > > > though it > > > > > > > > > never froze on my G1 either. The G1 I have is the ADP1 phone > > > > > > > > > I bought > > > > > >
[android-developers] Re: OpenGL lockups in 2.2
It was happening between 1 - 45 minutes into the app. Every single time. Maybe this is not a permanent fix and maybe it has just reduced the frequency of freezings. But as I mentioned before, so far I have not seen a single freeze since I made that change 2 days ago. On Sep 21, 4:05 pm, Robert Green wrote: > And it was happening reliably before? > > On Sep 21, 12:48 pm, timedilation wrote: > > > > > I haven't seen any freeze since making that change (I am only testing > > this on the HTC Desire running 2.2) > > > On Sep 21, 1:32 pm, Robert Green wrote: > > > > So after finishing with glFinish(), you haven't seen a freeze at all > > > or you just saw one now? I'm not sure what to make of the "until now" > > > part :) > > > > If you really think that's making a difference, I'll try it out and > > > see if it makes a difference for my games as well, though I have to > > > play for about an hour to see it happen. > > > > On Sep 21, 12:10 pm, timedilation wrote: > > > > > Not sure if the following will fix the freezing in all cases but it > > > > appears to have fixed it in my app. I still have my fingers crossed > > > > about it although my app hasn't frozen for a while now - even when I > > > > let it run overnight on an HTC Desire 2.2. > > > > > I first took the source code of GLSurfaceView into my custom class and > > > > added this line immediately before the eglSwapBuffer() call in the > > > > EGLHelper class function: > > > > > mEgl.glWaitGL(); > > > > > This is a blocking call that waits for all existing GL commands to be > > > > processed before returning. With this line, the freezing seems to have > > > > stopped. > > > > > I then realized that the glFinish() function does the same thing. So I > > > > went back to using the built-in GLSurfaceView and added the glFinish() > > > > call at the very end of my renderer.onDrawFrame() function. This had > > > > the same effect and I haven't seen a freeze until now. I suspect this > > > > call is just making the loop wait explicitly for all GL commands to be > > > > processed before rendering again. I took a look in the profiler and > > > > this call did not add any extra overhead (likely because the > > > > eglSwapBuffers() is also a blocking call and does the same thing - > > > > except that it freezes randomly). > > > > > If the freezing starts again, I will update this post. > > > > Hope this works for you all out there too. > > > > > On Sep 17, 7:46 am, String wrote: > > > > > > It's not all OpenGL implementations, that's for sure. I have 2 apps > > > > > with OpenGL live wallpapers; one has had the lockup problem, the other > > > > > hasn't. Architecturally, they're very similar - I based the later one > > > > > off the earlier. It was by pursuing the differences (like changing > > > > > textures mid-stream, as I discussed in an earlier post) that I've been > > > > > able to stop the lockups so far. > > > > > > String > > > > > > On Sep 17, 4:26 am, timedilation wrote: > > > > > > > I have played games like Winds of Steel for hours on my HTC desire. > > > > > > Surely they must be using opengl as well (I think). And the FPS is > > > > > > also pretty good. How's it that those games do not freeze at all? I > > > > > > need to dissect those and see what calls they are making. > > > > > > > On Sep 15, 12:17 pm, Jeremy Statz wrote: > > > > > > > > I just let the same wallpaper run uninterrupted on a Motorola > > > > > > > Droid > > > > > > > for something like 16 hours and it's still fine. I would've > > > > > > > expected > > > > > > > my Incredible to have hit the problem by then. I also haven't > > > > > > > heard > > > > > > > any reports of this from folks with a Galaxy S variant. > > > > > > > > On Sep 14, 7:38 pm, timedilation wrote: > > > > > > > > > This appears to be an HTC specific bug. My app never freezes on > > > > > > > > the > > > > > > > > Motorla Droid. EVER. It is very stable on the Droid and I have > > > > > > > > tested > > > > > > > > it for about 4months without a single freeze. Interestingly > > > > > > > > though it > > > > > > > > never froze on my G1 either. The G1 I have is the ADP1 phone I > > > > > > > > bought > > > > > > > > directly from Google. > > > > > > > > > All other HTC phones that I have exhibit the freezing - Evo, > > > > > > > > Desire > > > > > > > > and Nexus One (which is also from HTC I believe). > > > > > > > > > Apart from that I tested it for a month on Samsung Moment. > > > > > > > > There was > > > > > > > > NO freezing there either. > > > > > > > > I have been in touch with a Google developer advocate and I have > > > > > > > > submitted the bug report to his team. They are looking into > > > > > > > > this as > > > > > > > > well. > > > > > > > > > On Sep 14, 8:23 pm, Jeremy Statz wrote: > > > > > > > > > > That's my experience as well. All my log results say that > > > > > > > > > there's no > > > > > > > > > loading or anything necessary -- the frame it dies on is bog > > >
[android-developers] Re: OpenGL lockups in 2.2
And it was happening reliably before? On Sep 21, 12:48 pm, timedilation wrote: > I haven't seen any freeze since making that change (I am only testing > this on the HTC Desire running 2.2) > > On Sep 21, 1:32 pm, Robert Green wrote: > > > > > So after finishing with glFinish(), you haven't seen a freeze at all > > or you just saw one now? I'm not sure what to make of the "until now" > > part :) > > > If you really think that's making a difference, I'll try it out and > > see if it makes a difference for my games as well, though I have to > > play for about an hour to see it happen. > > > On Sep 21, 12:10 pm, timedilation wrote: > > > > Not sure if the following will fix the freezing in all cases but it > > > appears to have fixed it in my app. I still have my fingers crossed > > > about it although my app hasn't frozen for a while now - even when I > > > let it run overnight on an HTC Desire 2.2. > > > > I first took the source code of GLSurfaceView into my custom class and > > > added this line immediately before the eglSwapBuffer() call in the > > > EGLHelper class function: > > > > mEgl.glWaitGL(); > > > > This is a blocking call that waits for all existing GL commands to be > > > processed before returning. With this line, the freezing seems to have > > > stopped. > > > > I then realized that the glFinish() function does the same thing. So I > > > went back to using the built-in GLSurfaceView and added the glFinish() > > > call at the very end of my renderer.onDrawFrame() function. This had > > > the same effect and I haven't seen a freeze until now. I suspect this > > > call is just making the loop wait explicitly for all GL commands to be > > > processed before rendering again. I took a look in the profiler and > > > this call did not add any extra overhead (likely because the > > > eglSwapBuffers() is also a blocking call and does the same thing - > > > except that it freezes randomly). > > > > If the freezing starts again, I will update this post. > > > Hope this works for you all out there too. > > > > On Sep 17, 7:46 am, String wrote: > > > > > It's not all OpenGL implementations, that's for sure. I have 2 apps > > > > with OpenGL live wallpapers; one has had the lockup problem, the other > > > > hasn't. Architecturally, they're very similar - I based the later one > > > > off the earlier. It was by pursuing the differences (like changing > > > > textures mid-stream, as I discussed in an earlier post) that I've been > > > > able to stop the lockups so far. > > > > > String > > > > > On Sep 17, 4:26 am, timedilation wrote: > > > > > > I have played games like Winds of Steel for hours on my HTC desire. > > > > > Surely they must be using opengl as well (I think). And the FPS is > > > > > also pretty good. How's it that those games do not freeze at all? I > > > > > need to dissect those and see what calls they are making. > > > > > > On Sep 15, 12:17 pm, Jeremy Statz wrote: > > > > > > > I just let the same wallpaper run uninterrupted on a Motorola Droid > > > > > > for something like 16 hours and it's still fine. I would've > > > > > > expected > > > > > > my Incredible to have hit the problem by then. I also haven't heard > > > > > > any reports of this from folks with a Galaxy S variant. > > > > > > > On Sep 14, 7:38 pm, timedilation wrote: > > > > > > > > This appears to be an HTC specific bug. My app never freezes on > > > > > > > the > > > > > > > Motorla Droid. EVER. It is very stable on the Droid and I have > > > > > > > tested > > > > > > > it for about 4months without a single freeze. Interestingly > > > > > > > though it > > > > > > > never froze on my G1 either. The G1 I have is the ADP1 phone I > > > > > > > bought > > > > > > > directly from Google. > > > > > > > > All other HTC phones that I have exhibit the freezing - Evo, > > > > > > > Desire > > > > > > > and Nexus One (which is also from HTC I believe). > > > > > > > > Apart from that I tested it for a month on Samsung Moment. There > > > > > > > was > > > > > > > NO freezing there either. > > > > > > > I have been in touch with a Google developer advocate and I have > > > > > > > submitted the bug report to his team. They are looking into this > > > > > > > as > > > > > > > well. > > > > > > > > On Sep 14, 8:23 pm, Jeremy Statz wrote: > > > > > > > > > That's my experience as well. All my log results say that > > > > > > > > there's no > > > > > > > > loading or anything necessary -- the frame it dies on is bog > > > > > > > > standard, > > > > > > > > with drawFrame going from beginning to end. Any loading is > > > > > > > > long since > > > > > > > > done. > > > > > > > > > I'm currently wondering if this is an HTC driver bug. I'm > > > > > > > > going to > > > > > > > > let this run on a Motorola Droid all night and see if it > > > > > > > > crashes. Not > > > > > > > > sure I'm expecting it to, as my fiance has been using my > > > > > > > > wallpapers on > > > > > > > > her Droid since forever a
[android-developers] Re: OpenGL lockups in 2.2
I haven't seen any freeze since making that change (I am only testing this on the HTC Desire running 2.2) On Sep 21, 1:32 pm, Robert Green wrote: > So after finishing with glFinish(), you haven't seen a freeze at all > or you just saw one now? I'm not sure what to make of the "until now" > part :) > > If you really think that's making a difference, I'll try it out and > see if it makes a difference for my games as well, though I have to > play for about an hour to see it happen. > > On Sep 21, 12:10 pm, timedilation wrote: > > > > > Not sure if the following will fix the freezing in all cases but it > > appears to have fixed it in my app. I still have my fingers crossed > > about it although my app hasn't frozen for a while now - even when I > > let it run overnight on an HTC Desire 2.2. > > > I first took the source code of GLSurfaceView into my custom class and > > added this line immediately before the eglSwapBuffer() call in the > > EGLHelper class function: > > > mEgl.glWaitGL(); > > > This is a blocking call that waits for all existing GL commands to be > > processed before returning. With this line, the freezing seems to have > > stopped. > > > I then realized that the glFinish() function does the same thing. So I > > went back to using the built-in GLSurfaceView and added the glFinish() > > call at the very end of my renderer.onDrawFrame() function. This had > > the same effect and I haven't seen a freeze until now. I suspect this > > call is just making the loop wait explicitly for all GL commands to be > > processed before rendering again. I took a look in the profiler and > > this call did not add any extra overhead (likely because the > > eglSwapBuffers() is also a blocking call and does the same thing - > > except that it freezes randomly). > > > If the freezing starts again, I will update this post. > > Hope this works for you all out there too. > > > On Sep 17, 7:46 am, String wrote: > > > > It's not all OpenGL implementations, that's for sure. I have 2 apps > > > with OpenGL live wallpapers; one has had the lockup problem, the other > > > hasn't. Architecturally, they're very similar - I based the later one > > > off the earlier. It was by pursuing the differences (like changing > > > textures mid-stream, as I discussed in an earlier post) that I've been > > > able to stop the lockups so far. > > > > String > > > > On Sep 17, 4:26 am, timedilation wrote: > > > > > I have played games like Winds of Steel for hours on my HTC desire. > > > > Surely they must be using opengl as well (I think). And the FPS is > > > > also pretty good. How's it that those games do not freeze at all? I > > > > need to dissect those and see what calls they are making. > > > > > On Sep 15, 12:17 pm, Jeremy Statz wrote: > > > > > > I just let the same wallpaper run uninterrupted on a Motorola Droid > > > > > for something like 16 hours and it's still fine. I would've expected > > > > > my Incredible to have hit the problem by then. I also haven't heard > > > > > any reports of this from folks with a Galaxy S variant. > > > > > > On Sep 14, 7:38 pm, timedilation wrote: > > > > > > > This appears to be an HTC specific bug. My app never freezes on the > > > > > > Motorla Droid. EVER. It is very stable on the Droid and I have > > > > > > tested > > > > > > it for about 4months without a single freeze. Interestingly though > > > > > > it > > > > > > never froze on my G1 either. The G1 I have is the ADP1 phone I > > > > > > bought > > > > > > directly from Google. > > > > > > > All other HTC phones that I have exhibit the freezing - Evo, Desire > > > > > > and Nexus One (which is also from HTC I believe). > > > > > > > Apart from that I tested it for a month on Samsung Moment. There was > > > > > > NO freezing there either. > > > > > > I have been in touch with a Google developer advocate and I have > > > > > > submitted the bug report to his team. They are looking into this as > > > > > > well. > > > > > > > On Sep 14, 8:23 pm, Jeremy Statz wrote: > > > > > > > > That's my experience as well. All my log results say that > > > > > > > there's no > > > > > > > loading or anything necessary -- the frame it dies on is bog > > > > > > > standard, > > > > > > > with drawFrame going from beginning to end. Any loading is long > > > > > > > since > > > > > > > done. > > > > > > > > I'm currently wondering if this is an HTC driver bug. I'm going > > > > > > > to > > > > > > > let this run on a Motorola Droid all night and see if it crashes. > > > > > > > Not > > > > > > > sure I'm expecting it to, as my fiance has been using my > > > > > > > wallpapers on > > > > > > > her Droid since forever and says she's never seen it lock and > > > > > > > reboot > > > > > > > like we're describing. Is there anyone at HTC to take something > > > > > > > like > > > > > > > that to, if I gather some evidence? > > > > > > > > On Sep 14, 3:32 pm, timedilation wrote: > > > > > > > > > That's interesting.. > > > > > > >
[android-developers] Re: OpenGL lockups in 2.2
So after finishing with glFinish(), you haven't seen a freeze at all or you just saw one now? I'm not sure what to make of the "until now" part :) If you really think that's making a difference, I'll try it out and see if it makes a difference for my games as well, though I have to play for about an hour to see it happen. On Sep 21, 12:10 pm, timedilation wrote: > Not sure if the following will fix the freezing in all cases but it > appears to have fixed it in my app. I still have my fingers crossed > about it although my app hasn't frozen for a while now - even when I > let it run overnight on an HTC Desire 2.2. > > I first took the source code of GLSurfaceView into my custom class and > added this line immediately before the eglSwapBuffer() call in the > EGLHelper class function: > > mEgl.glWaitGL(); > > This is a blocking call that waits for all existing GL commands to be > processed before returning. With this line, the freezing seems to have > stopped. > > I then realized that the glFinish() function does the same thing. So I > went back to using the built-in GLSurfaceView and added the glFinish() > call at the very end of my renderer.onDrawFrame() function. This had > the same effect and I haven't seen a freeze until now. I suspect this > call is just making the loop wait explicitly for all GL commands to be > processed before rendering again. I took a look in the profiler and > this call did not add any extra overhead (likely because the > eglSwapBuffers() is also a blocking call and does the same thing - > except that it freezes randomly). > > If the freezing starts again, I will update this post. > Hope this works for you all out there too. > > On Sep 17, 7:46 am, String wrote: > > > > > It's not all OpenGL implementations, that's for sure. I have 2 apps > > with OpenGL live wallpapers; one has had the lockup problem, the other > > hasn't. Architecturally, they're very similar - I based the later one > > off the earlier. It was by pursuing the differences (like changing > > textures mid-stream, as I discussed in an earlier post) that I've been > > able to stop the lockups so far. > > > String > > > On Sep 17, 4:26 am, timedilation wrote: > > > > I have played games like Winds of Steel for hours on my HTC desire. > > > Surely they must be using opengl as well (I think). And the FPS is > > > also pretty good. How's it that those games do not freeze at all? I > > > need to dissect those and see what calls they are making. > > > > On Sep 15, 12:17 pm, Jeremy Statz wrote: > > > > > I just let the same wallpaper run uninterrupted on a Motorola Droid > > > > for something like 16 hours and it's still fine. I would've expected > > > > my Incredible to have hit the problem by then. I also haven't heard > > > > any reports of this from folks with a Galaxy S variant. > > > > > On Sep 14, 7:38 pm, timedilation wrote: > > > > > > This appears to be an HTC specific bug. My app never freezes on the > > > > > Motorla Droid. EVER. It is very stable on the Droid and I have tested > > > > > it for about 4months without a single freeze. Interestingly though it > > > > > never froze on my G1 either. The G1 I have is the ADP1 phone I bought > > > > > directly from Google. > > > > > > All other HTC phones that I have exhibit the freezing - Evo, Desire > > > > > and Nexus One (which is also from HTC I believe). > > > > > > Apart from that I tested it for a month on Samsung Moment. There was > > > > > NO freezing there either. > > > > > I have been in touch with a Google developer advocate and I have > > > > > submitted the bug report to his team. They are looking into this as > > > > > well. > > > > > > On Sep 14, 8:23 pm, Jeremy Statz wrote: > > > > > > > That's my experience as well. All my log results say that there's > > > > > > no > > > > > > loading or anything necessary -- the frame it dies on is bog > > > > > > standard, > > > > > > with drawFrame going from beginning to end. Any loading is long > > > > > > since > > > > > > done. > > > > > > > I'm currently wondering if this is an HTC driver bug. I'm going to > > > > > > let this run on a Motorola Droid all night and see if it crashes. > > > > > > Not > > > > > > sure I'm expecting it to, as my fiance has been using my wallpapers > > > > > > on > > > > > > her Droid since forever and says she's never seen it lock and reboot > > > > > > like we're describing. Is there anyone at HTC to take something > > > > > > like > > > > > > that to, if I gather some evidence? > > > > > > > On Sep 14, 3:32 pm, timedilation wrote: > > > > > > > > That's interesting.. > > > > > > > Although I know for sure that all my gl* calls are happening only > > > > > > > in > > > > > > > the GL thread. And this freezing happens even when I simply leave > > > > > > > the > > > > > > > device (HTC Desire) running my app with zero user interaction > > > > > > > whatsoever. All the app renders is a scenery with a single > > > > > > > animation. > > > > > > > No textu
[android-developers] Re: OpenGL lockups in 2.2
Not sure if the following will fix the freezing in all cases but it appears to have fixed it in my app. I still have my fingers crossed about it although my app hasn't frozen for a while now - even when I let it run overnight on an HTC Desire 2.2. I first took the source code of GLSurfaceView into my custom class and added this line immediately before the eglSwapBuffer() call in the EGLHelper class function: mEgl.glWaitGL(); This is a blocking call that waits for all existing GL commands to be processed before returning. With this line, the freezing seems to have stopped. I then realized that the glFinish() function does the same thing. So I went back to using the built-in GLSurfaceView and added the glFinish() call at the very end of my renderer.onDrawFrame() function. This had the same effect and I haven't seen a freeze until now. I suspect this call is just making the loop wait explicitly for all GL commands to be processed before rendering again. I took a look in the profiler and this call did not add any extra overhead (likely because the eglSwapBuffers() is also a blocking call and does the same thing - except that it freezes randomly). If the freezing starts again, I will update this post. Hope this works for you all out there too. On Sep 17, 7:46 am, String wrote: > It's not all OpenGL implementations, that's for sure. I have 2 apps > with OpenGL live wallpapers; one has had the lockup problem, the other > hasn't. Architecturally, they're very similar - I based the later one > off the earlier. It was by pursuing the differences (like changing > textures mid-stream, as I discussed in an earlier post) that I've been > able to stop the lockups so far. > > String > > On Sep 17, 4:26 am, timedilation wrote: > > > > > I have played games like Winds of Steel for hours on my HTC desire. > > Surely they must be using opengl as well (I think). And the FPS is > > also pretty good. How's it that those games do not freeze at all? I > > need to dissect those and see what calls they are making. > > > On Sep 15, 12:17 pm, Jeremy Statz wrote: > > > > I just let the same wallpaper run uninterrupted on a Motorola Droid > > > for something like 16 hours and it's still fine. I would've expected > > > my Incredible to have hit the problem by then. I also haven't heard > > > any reports of this from folks with a Galaxy S variant. > > > > On Sep 14, 7:38 pm, timedilation wrote: > > > > > This appears to be an HTC specific bug. My app never freezes on the > > > > Motorla Droid. EVER. It is very stable on the Droid and I have tested > > > > it for about 4months without a single freeze. Interestingly though it > > > > never froze on my G1 either. The G1 I have is the ADP1 phone I bought > > > > directly from Google. > > > > > All other HTC phones that I have exhibit the freezing - Evo, Desire > > > > and Nexus One (which is also from HTC I believe). > > > > > Apart from that I tested it for a month on Samsung Moment. There was > > > > NO freezing there either. > > > > I have been in touch with a Google developer advocate and I have > > > > submitted the bug report to his team. They are looking into this as > > > > well. > > > > > On Sep 14, 8:23 pm, Jeremy Statz wrote: > > > > > > That's my experience as well. All my log results say that there's no > > > > > loading or anything necessary -- the frame it dies on is bog standard, > > > > > with drawFrame going from beginning to end. Any loading is long since > > > > > done. > > > > > > I'm currently wondering if this is an HTC driver bug. I'm going to > > > > > let this run on a Motorola Droid all night and see if it crashes. Not > > > > > sure I'm expecting it to, as my fiance has been using my wallpapers on > > > > > her Droid since forever and says she's never seen it lock and reboot > > > > > like we're describing. Is there anyone at HTC to take something like > > > > > that to, if I gather some evidence? > > > > > > On Sep 14, 3:32 pm, timedilation wrote: > > > > > > > That's interesting.. > > > > > > Although I know for sure that all my gl* calls are happening only in > > > > > > the GL thread. And this freezing happens even when I simply leave > > > > > > the > > > > > > device (HTC Desire) running my app with zero user interaction > > > > > > whatsoever. All the app renders is a scenery with a single > > > > > > animation. > > > > > > No texture changes or geometry changes are taking place in this > > > > > > scenario. But because of the animation, I have to render > > > > > > continuously > > > > > > and this is why I have not used the Render_when_dirty approach. > > > > > > > I did notice that when the app freezes, my main UI thread as well > > > > > > as a > > > > > > secondary thread (that talks to a game server) are still running and > > > > > > alive. The main UI thread does register touches until a point and > > > > > > then > > > > > > hangs while the secondary thread stays alive. I tried to send an > > > > > > interrupt() to the GLThr
[android-developers] Re: OpenGL lockups in 2.2
It's not all OpenGL implementations, that's for sure. I have 2 apps with OpenGL live wallpapers; one has had the lockup problem, the other hasn't. Architecturally, they're very similar - I based the later one off the earlier. It was by pursuing the differences (like changing textures mid-stream, as I discussed in an earlier post) that I've been able to stop the lockups so far. String On Sep 17, 4:26 am, timedilation wrote: > I have played games like Winds of Steel for hours on my HTC desire. > Surely they must be using opengl as well (I think). And the FPS is > also pretty good. How's it that those games do not freeze at all? I > need to dissect those and see what calls they are making. > > On Sep 15, 12:17 pm, Jeremy Statz wrote: > > > > > I just let the same wallpaper run uninterrupted on a Motorola Droid > > for something like 16 hours and it's still fine. I would've expected > > my Incredible to have hit the problem by then. I also haven't heard > > any reports of this from folks with a Galaxy S variant. > > > On Sep 14, 7:38 pm, timedilation wrote: > > > > This appears to be an HTC specific bug. My app never freezes on the > > > Motorla Droid. EVER. It is very stable on the Droid and I have tested > > > it for about 4months without a single freeze. Interestingly though it > > > never froze on my G1 either. The G1 I have is the ADP1 phone I bought > > > directly from Google. > > > > All other HTC phones that I have exhibit the freezing - Evo, Desire > > > and Nexus One (which is also from HTC I believe). > > > > Apart from that I tested it for a month on Samsung Moment. There was > > > NO freezing there either. > > > I have been in touch with a Google developer advocate and I have > > > submitted the bug report to his team. They are looking into this as > > > well. > > > > On Sep 14, 8:23 pm, Jeremy Statz wrote: > > > > > That's my experience as well. All my log results say that there's no > > > > loading or anything necessary -- the frame it dies on is bog standard, > > > > with drawFrame going from beginning to end. Any loading is long since > > > > done. > > > > > I'm currently wondering if this is an HTC driver bug. I'm going to > > > > let this run on a Motorola Droid all night and see if it crashes. Not > > > > sure I'm expecting it to, as my fiance has been using my wallpapers on > > > > her Droid since forever and says she's never seen it lock and reboot > > > > like we're describing. Is there anyone at HTC to take something like > > > > that to, if I gather some evidence? > > > > > On Sep 14, 3:32 pm, timedilation wrote: > > > > > > That's interesting.. > > > > > Although I know for sure that all my gl* calls are happening only in > > > > > the GL thread. And this freezing happens even when I simply leave the > > > > > device (HTC Desire) running my app with zero user interaction > > > > > whatsoever. All the app renders is a scenery with a single animation. > > > > > No texture changes or geometry changes are taking place in this > > > > > scenario. But because of the animation, I have to render continuously > > > > > and this is why I have not used the Render_when_dirty approach. > > > > > > I did notice that when the app freezes, my main UI thread as well as a > > > > > secondary thread (that talks to a game server) are still running and > > > > > alive. The main UI thread does register touches until a point and then > > > > > hangs while the secondary thread stays alive. I tried to send an > > > > > interrupt() to the GLThread from this secondary thread but that did > > > > > not help. The GLThread remained stuck in eglSwapBuffer(); > > > > > > On Sep 14, 3:42 pm, String wrote: > > > > > > > On Sep 13, 11:24 pm, Jeremy Statz wrote: > > > > > > > > The big problem here, in my eyes, is that this appears to > > > > > > > affect any OpenGL using application, and is tremendously > > > > > > > discouraging, > > > > > > > to the point that people pull things off the market and avoid > > > > > > > using > > > > > > > OpenGL. > > > > > > > I've been chasing this in a couple of my own OpenGL apps for a > > > > > > couple > > > > > > of months as well. It's summed up well in this thread - extremely > > > > > > intermittent, but extremely serious when it does happen. And I'm one > > > > > > of the devs who has pulled an app from the Market as a result. > > > > > > > At the moment, I'm provisionally optimistic that I've worked around > > > > > > the issue in my case. Given it's a race condition, I took the > > > > > > approach > > > > > > of maximum thread-safety: I put a whole load of semaphores into my > > > > > > code, added "synchronized" and "volatile" modifiers all over the > > > > > > place, that sort of thing. And it seems to have been successful... I > > > > > > can't be sure (because of the intermittency), but I haven't seen it > > > > > > happen for a couple of weeks now. > > > > > > > If I had to speculate, I'd say that the problem finally went when I > > > > > > synchr
[android-developers] Re: OpenGL lockups in 2.2
I have played games like Winds of Steel for hours on my HTC desire. Surely they must be using opengl as well (I think). And the FPS is also pretty good. How's it that those games do not freeze at all? I need to dissect those and see what calls they are making. On Sep 15, 12:17 pm, Jeremy Statz wrote: > I just let the same wallpaper run uninterrupted on a Motorola Droid > for something like 16 hours and it's still fine. I would've expected > my Incredible to have hit the problem by then. I also haven't heard > any reports of this from folks with a Galaxy S variant. > > On Sep 14, 7:38 pm, timedilation wrote: > > > > > This appears to be an HTC specific bug. My app never freezes on the > > Motorla Droid. EVER. It is very stable on the Droid and I have tested > > it for about 4months without a single freeze. Interestingly though it > > never froze on my G1 either. The G1 I have is the ADP1 phone I bought > > directly from Google. > > > All other HTC phones that I have exhibit the freezing - Evo, Desire > > and Nexus One (which is also from HTC I believe). > > > Apart from that I tested it for a month on Samsung Moment. There was > > NO freezing there either. > > I have been in touch with a Google developer advocate and I have > > submitted the bug report to his team. They are looking into this as > > well. > > > On Sep 14, 8:23 pm, Jeremy Statz wrote: > > > > That's my experience as well. All my log results say that there's no > > > loading or anything necessary -- the frame it dies on is bog standard, > > > with drawFrame going from beginning to end. Any loading is long since > > > done. > > > > I'm currently wondering if this is an HTC driver bug. I'm going to > > > let this run on a Motorola Droid all night and see if it crashes. Not > > > sure I'm expecting it to, as my fiance has been using my wallpapers on > > > her Droid since forever and says she's never seen it lock and reboot > > > like we're describing. Is there anyone at HTC to take something like > > > that to, if I gather some evidence? > > > > On Sep 14, 3:32 pm, timedilation wrote: > > > > > That's interesting.. > > > > Although I know for sure that all my gl* calls are happening only in > > > > the GL thread. And this freezing happens even when I simply leave the > > > > device (HTC Desire) running my app with zero user interaction > > > > whatsoever. All the app renders is a scenery with a single animation. > > > > No texture changes or geometry changes are taking place in this > > > > scenario. But because of the animation, I have to render continuously > > > > and this is why I have not used the Render_when_dirty approach. > > > > > I did notice that when the app freezes, my main UI thread as well as a > > > > secondary thread (that talks to a game server) are still running and > > > > alive. The main UI thread does register touches until a point and then > > > > hangs while the secondary thread stays alive. I tried to send an > > > > interrupt() to the GLThread from this secondary thread but that did > > > > not help. The GLThread remained stuck in eglSwapBuffer(); > > > > > On Sep 14, 3:42 pm, String wrote: > > > > > > On Sep 13, 11:24 pm, Jeremy Statz wrote: > > > > > > > The big problem here, in my eyes, is that this appears to > > > > > > affect any OpenGL using application, and is tremendously > > > > > > discouraging, > > > > > > to the point that people pull things off the market and avoid using > > > > > > OpenGL. > > > > > > I've been chasing this in a couple of my own OpenGL apps for a couple > > > > > of months as well. It's summed up well in this thread - extremely > > > > > intermittent, but extremely serious when it does happen. And I'm one > > > > > of the devs who has pulled an app from the Market as a result. > > > > > > At the moment, I'm provisionally optimistic that I've worked around > > > > > the issue in my case. Given it's a race condition, I took the approach > > > > > of maximum thread-safety: I put a whole load of semaphores into my > > > > > code, added "synchronized" and "volatile" modifiers all over the > > > > > place, that sort of thing. And it seems to have been successful... I > > > > > can't be sure (because of the intermittency), but I haven't seen it > > > > > happen for a couple of weeks now. > > > > > > If I had to speculate, I'd say that the problem finally went when I > > > > > synchronized some code which re-generates geometry within my OpenGL > > > > > model. I added semaphores to ensure that textures, geometry, and > > > > > rendering never happened concurrently. There's no way to know that was > > > > > the end problem, but that SEEMED to be it. If that helps anyone. > > > > > > Just to reiterate, I agree that this is a serious platform-level bug > > > > > that needs to be fixed by Google. And it has gotten worse since 2.2, > > > > > although I have (rarely) seen it happen on my G1 running 1.6. > > > > > > String -- You received this message because you are subscribed to the
[android-developers] Re: OpenGL lockups in 2.2
You say you don't see why anyone would use it, but then your own words give a pretty good description of when to use GLSurfaceView: when you don't care about making your code less portable, and don't need the "control taken away from you". And by "less portable" you must mean having in mind to port to non- Android platforms. But if your application is Android specific anyway, then this is not a consideration. There will be lots of OpenGL applications out there. Just give it time to develop. GLSurfaceView is a HUGE improvement over the JME way of supporting OpenGL. On Sep 15, 5:25 pm, Leigh McRae wrote: > I don't use GLSurfaceView and I am not really sure why anyone would > use it for anything other than a demo. It makes your code less portable > and takes control away from you. > > With that said, I do get people with HTC complaining about freezes. So > it would seem that it's not a GLSurfaceView problem. > > On 9/14/2010 8:38 PM, timedilation wrote: > > > This appears to be an HTC specific bug. My app never freezes on the > > Motorla Droid. EVER. It is very stable on the Droid and I have tested > > it for about 4months without a single freeze. Interestingly though it > > never froze on my G1 either. The G1 I have is the ADP1 phone I bought > > directly from Google. > > > All other HTC phones that I have exhibit the freezing - Evo, Desire > > and Nexus One (which is also from HTC I believe). > > > Apart from that I tested it for a month on Samsung Moment. There was > > NO freezing there either. > > I have been in touch with a Google developer advocate and I have > > submitted the bug report to his team. They are looking into this as > > well. > > > On Sep 14, 8:23 pm, Jeremy Statz wrote: > >> That's my experience as well. All my log results say that there's no > >> loading or anything necessary -- the frame it dies on is bog standard, > >> with drawFrame going from beginning to end. Any loading is long since > >> done. > > >> I'm currently wondering if this is an HTC driver bug. I'm going to > >> let this run on a Motorola Droid all night and see if it crashes. Not > >> sure I'm expecting it to, as my fiance has been using my wallpapers on > >> her Droid since forever and says she's never seen it lock and reboot > >> like we're describing. Is there anyone at HTC to take something like > >> that to, if I gather some evidence? > > >> On Sep 14, 3:32 pm, timedilation wrote: > > >>> That's interesting.. > >>> Although I know for sure that all my gl* calls are happening only in > >>> the GL thread. And this freezing happens even when I simply leave the > >>> device (HTC Desire) running my app with zero user interaction > >>> whatsoever. All the app renders is a scenery with a single animation. > >>> No texture changes or geometry changes are taking place in this > >>> scenario. But because of the animation, I have to render continuously > >>> and this is why I have not used the Render_when_dirty approach. > >>> I did notice that when the app freezes, my main UI thread as well as a > >>> secondary thread (that talks to a game server) are still running and > >>> alive. The main UI thread does register touches until a point and then > >>> hangs while the secondary thread stays alive. I tried to send an > >>> interrupt() to the GLThread from this secondary thread but that did > >>> not help. The GLThread remained stuck in eglSwapBuffer(); > >>> On Sep 14, 3:42 pm, String wrote: > On Sep 13, 11:24 pm, Jeremy Statz wrote: > > The big problem here, in my eyes, is that this appears to > > affect any OpenGL using application, and is tremendously discouraging, > > to the point that people pull things off the market and avoid using > > OpenGL. > I've been chasing this in a couple of my own OpenGL apps for a couple > of months as well. It's summed up well in this thread - extremely > intermittent, but extremely serious when it does happen. And I'm one > of the devs who has pulled an app from the Market as a result. > At the moment, I'm provisionally optimistic that I've worked around > the issue in my case. Given it's a race condition, I took the approach > of maximum thread-safety: I put a whole load of semaphores into my > code, added "synchronized" and "volatile" modifiers all over the > place, that sort of thing. And it seems to have been successful... I > can't be sure (because of the intermittency), but I haven't seen it > happen for a couple of weeks now. > If I had to speculate, I'd say that the problem finally went when I > synchronized some code which re-generates geometry within my OpenGL > model. I added semaphores to ensure that textures, geometry, and > rendering never happened concurrently. There's no way to know that was > the end problem, but that SEEMED to be it. If that helps anyone. > Just to reiterate, I agree that this is a serious platform-level bug > that needs to be fixed
Re: [android-developers] Re: OpenGL lockups in 2.2
I don't use GLSurfaceView and I am not really sure why anyone would use it for anything other than a demo. It makes your code less portable and takes control away from you. With that said, I do get people with HTC complaining about freezes. So it would seem that it's not a GLSurfaceView problem. On 9/14/2010 8:38 PM, timedilation wrote: This appears to be an HTC specific bug. My app never freezes on the Motorla Droid. EVER. It is very stable on the Droid and I have tested it for about 4months without a single freeze. Interestingly though it never froze on my G1 either. The G1 I have is the ADP1 phone I bought directly from Google. All other HTC phones that I have exhibit the freezing - Evo, Desire and Nexus One (which is also from HTC I believe). Apart from that I tested it for a month on Samsung Moment. There was NO freezing there either. I have been in touch with a Google developer advocate and I have submitted the bug report to his team. They are looking into this as well. On Sep 14, 8:23 pm, Jeremy Statz wrote: That's my experience as well. All my log results say that there's no loading or anything necessary -- the frame it dies on is bog standard, with drawFrame going from beginning to end. Any loading is long since done. I'm currently wondering if this is an HTC driver bug. I'm going to let this run on a Motorola Droid all night and see if it crashes. Not sure I'm expecting it to, as my fiance has been using my wallpapers on her Droid since forever and says she's never seen it lock and reboot like we're describing. Is there anyone at HTC to take something like that to, if I gather some evidence? On Sep 14, 3:32 pm, timedilation wrote: That's interesting.. Although I know for sure that all my gl* calls are happening only in the GL thread. And this freezing happens even when I simply leave the device (HTC Desire) running my app with zero user interaction whatsoever. All the app renders is a scenery with a single animation. No texture changes or geometry changes are taking place in this scenario. But because of the animation, I have to render continuously and this is why I have not used the Render_when_dirty approach. I did notice that when the app freezes, my main UI thread as well as a secondary thread (that talks to a game server) are still running and alive. The main UI thread does register touches until a point and then hangs while the secondary thread stays alive. I tried to send an interrupt() to the GLThread from this secondary thread but that did not help. The GLThread remained stuck in eglSwapBuffer(); On Sep 14, 3:42 pm, String wrote: On Sep 13, 11:24 pm, Jeremy Statz wrote: The big problem here, in my eyes, is that this appears to affect any OpenGL using application, and is tremendously discouraging, to the point that people pull things off the market and avoid using OpenGL. I've been chasing this in a couple of my own OpenGL apps for a couple of months as well. It's summed up well in this thread - extremely intermittent, but extremely serious when it does happen. And I'm one of the devs who has pulled an app from the Market as a result. At the moment, I'm provisionally optimistic that I've worked around the issue in my case. Given it's a race condition, I took the approach of maximum thread-safety: I put a whole load of semaphores into my code, added "synchronized" and "volatile" modifiers all over the place, that sort of thing. And it seems to have been successful... I can't be sure (because of the intermittency), but I haven't seen it happen for a couple of weeks now. If I had to speculate, I'd say that the problem finally went when I synchronized some code which re-generates geometry within my OpenGL model. I added semaphores to ensure that textures, geometry, and rendering never happened concurrently. There's no way to know that was the end problem, but that SEEMED to be it. If that helps anyone. Just to reiterate, I agree that this is a serious platform-level bug that needs to be fixed by Google. And it has gotten worse since 2.2, although I have (rarely) seen it happen on my G1 running 1.6. String -- Leigh McRae www.lonedwarfgames.com -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: OpenGL lockups in 2.2
I just let the same wallpaper run uninterrupted on a Motorola Droid for something like 16 hours and it's still fine. I would've expected my Incredible to have hit the problem by then. I also haven't heard any reports of this from folks with a Galaxy S variant. On Sep 14, 7:38 pm, timedilation wrote: > This appears to be an HTC specific bug. My app never freezes on the > Motorla Droid. EVER. It is very stable on the Droid and I have tested > it for about 4months without a single freeze. Interestingly though it > never froze on my G1 either. The G1 I have is the ADP1 phone I bought > directly from Google. > > All other HTC phones that I have exhibit the freezing - Evo, Desire > and Nexus One (which is also from HTC I believe). > > Apart from that I tested it for a month on Samsung Moment. There was > NO freezing there either. > I have been in touch with a Google developer advocate and I have > submitted the bug report to his team. They are looking into this as > well. > > On Sep 14, 8:23 pm, Jeremy Statz wrote: > > > > > > > > > That's my experience as well. All my log results say that there's no > > loading or anything necessary -- the frame it dies on is bog standard, > > with drawFrame going from beginning to end. Any loading is long since > > done. > > > I'm currently wondering if this is an HTC driver bug. I'm going to > > let this run on a Motorola Droid all night and see if it crashes. Not > > sure I'm expecting it to, as my fiance has been using my wallpapers on > > her Droid since forever and says she's never seen it lock and reboot > > like we're describing. Is there anyone at HTC to take something like > > that to, if I gather some evidence? > > > On Sep 14, 3:32 pm, timedilation wrote: > > > > That's interesting.. > > > Although I know for sure that all my gl* calls are happening only in > > > the GL thread. And this freezing happens even when I simply leave the > > > device (HTC Desire) running my app with zero user interaction > > > whatsoever. All the app renders is a scenery with a single animation. > > > No texture changes or geometry changes are taking place in this > > > scenario. But because of the animation, I have to render continuously > > > and this is why I have not used the Render_when_dirty approach. > > > > I did notice that when the app freezes, my main UI thread as well as a > > > secondary thread (that talks to a game server) are still running and > > > alive. The main UI thread does register touches until a point and then > > > hangs while the secondary thread stays alive. I tried to send an > > > interrupt() to the GLThread from this secondary thread but that did > > > not help. The GLThread remained stuck in eglSwapBuffer(); > > > > On Sep 14, 3:42 pm, String wrote: > > > > > On Sep 13, 11:24 pm, Jeremy Statz wrote: > > > > > > The big problem here, in my eyes, is that this appears to > > > > > affect any OpenGL using application, and is tremendously discouraging, > > > > > to the point that people pull things off the market and avoid using > > > > > OpenGL. > > > > > I've been chasing this in a couple of my own OpenGL apps for a couple > > > > of months as well. It's summed up well in this thread - extremely > > > > intermittent, but extremely serious when it does happen. And I'm one > > > > of the devs who has pulled an app from the Market as a result. > > > > > At the moment, I'm provisionally optimistic that I've worked around > > > > the issue in my case. Given it's a race condition, I took the approach > > > > of maximum thread-safety: I put a whole load of semaphores into my > > > > code, added "synchronized" and "volatile" modifiers all over the > > > > place, that sort of thing. And it seems to have been successful... I > > > > can't be sure (because of the intermittency), but I haven't seen it > > > > happen for a couple of weeks now. > > > > > If I had to speculate, I'd say that the problem finally went when I > > > > synchronized some code which re-generates geometry within my OpenGL > > > > model. I added semaphores to ensure that textures, geometry, and > > > > rendering never happened concurrently. There's no way to know that was > > > > the end problem, but that SEEMED to be it. If that helps anyone. > > > > > Just to reiterate, I agree that this is a serious platform-level bug > > > > that needs to be fixed by Google. And it has gotten worse since 2.2, > > > > although I have (rarely) seen it happen on my G1 running 1.6. > > > > > String -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: OpenGL lockups in 2.2
This appears to be an HTC specific bug. My app never freezes on the Motorla Droid. EVER. It is very stable on the Droid and I have tested it for about 4months without a single freeze. Interestingly though it never froze on my G1 either. The G1 I have is the ADP1 phone I bought directly from Google. All other HTC phones that I have exhibit the freezing - Evo, Desire and Nexus One (which is also from HTC I believe). Apart from that I tested it for a month on Samsung Moment. There was NO freezing there either. I have been in touch with a Google developer advocate and I have submitted the bug report to his team. They are looking into this as well. On Sep 14, 8:23 pm, Jeremy Statz wrote: > That's my experience as well. All my log results say that there's no > loading or anything necessary -- the frame it dies on is bog standard, > with drawFrame going from beginning to end. Any loading is long since > done. > > I'm currently wondering if this is an HTC driver bug. I'm going to > let this run on a Motorola Droid all night and see if it crashes. Not > sure I'm expecting it to, as my fiance has been using my wallpapers on > her Droid since forever and says she's never seen it lock and reboot > like we're describing. Is there anyone at HTC to take something like > that to, if I gather some evidence? > > On Sep 14, 3:32 pm, timedilation wrote: > > > > > That's interesting.. > > Although I know for sure that all my gl* calls are happening only in > > the GL thread. And this freezing happens even when I simply leave the > > device (HTC Desire) running my app with zero user interaction > > whatsoever. All the app renders is a scenery with a single animation. > > No texture changes or geometry changes are taking place in this > > scenario. But because of the animation, I have to render continuously > > and this is why I have not used the Render_when_dirty approach. > > > I did notice that when the app freezes, my main UI thread as well as a > > secondary thread (that talks to a game server) are still running and > > alive. The main UI thread does register touches until a point and then > > hangs while the secondary thread stays alive. I tried to send an > > interrupt() to the GLThread from this secondary thread but that did > > not help. The GLThread remained stuck in eglSwapBuffer(); > > > On Sep 14, 3:42 pm, String wrote: > > > > On Sep 13, 11:24 pm, Jeremy Statz wrote: > > > > > The big problem here, in my eyes, is that this appears to > > > > affect any OpenGL using application, and is tremendously discouraging, > > > > to the point that people pull things off the market and avoid using > > > > OpenGL. > > > > I've been chasing this in a couple of my own OpenGL apps for a couple > > > of months as well. It's summed up well in this thread - extremely > > > intermittent, but extremely serious when it does happen. And I'm one > > > of the devs who has pulled an app from the Market as a result. > > > > At the moment, I'm provisionally optimistic that I've worked around > > > the issue in my case. Given it's a race condition, I took the approach > > > of maximum thread-safety: I put a whole load of semaphores into my > > > code, added "synchronized" and "volatile" modifiers all over the > > > place, that sort of thing. And it seems to have been successful... I > > > can't be sure (because of the intermittency), but I haven't seen it > > > happen for a couple of weeks now. > > > > If I had to speculate, I'd say that the problem finally went when I > > > synchronized some code which re-generates geometry within my OpenGL > > > model. I added semaphores to ensure that textures, geometry, and > > > rendering never happened concurrently. There's no way to know that was > > > the end problem, but that SEEMED to be it. If that helps anyone. > > > > Just to reiterate, I agree that this is a serious platform-level bug > > > that needs to be fixed by Google. And it has gotten worse since 2.2, > > > although I have (rarely) seen it happen on my G1 running 1.6. > > > > String -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: OpenGL lockups in 2.2
That's my experience as well. All my log results say that there's no loading or anything necessary -- the frame it dies on is bog standard, with drawFrame going from beginning to end. Any loading is long since done. I'm currently wondering if this is an HTC driver bug. I'm going to let this run on a Motorola Droid all night and see if it crashes. Not sure I'm expecting it to, as my fiance has been using my wallpapers on her Droid since forever and says she's never seen it lock and reboot like we're describing. Is there anyone at HTC to take something like that to, if I gather some evidence? On Sep 14, 3:32 pm, timedilation wrote: > That's interesting.. > Although I know for sure that all my gl* calls are happening only in > the GL thread. And this freezing happens even when I simply leave the > device (HTC Desire) running my app with zero user interaction > whatsoever. All the app renders is a scenery with a single animation. > No texture changes or geometry changes are taking place in this > scenario. But because of the animation, I have to render continuously > and this is why I have not used the Render_when_dirty approach. > > I did notice that when the app freezes, my main UI thread as well as a > secondary thread (that talks to a game server) are still running and > alive. The main UI thread does register touches until a point and then > hangs while the secondary thread stays alive. I tried to send an > interrupt() to the GLThread from this secondary thread but that did > not help. The GLThread remained stuck in eglSwapBuffer(); > > On Sep 14, 3:42 pm, String wrote: > > > > > > > > > On Sep 13, 11:24 pm, Jeremy Statz wrote: > > > > The big problem here, in my eyes, is that this appears to > > > affect any OpenGL using application, and is tremendously discouraging, > > > to the point that people pull things off the market and avoid using > > > OpenGL. > > > I've been chasing this in a couple of my own OpenGL apps for a couple > > of months as well. It's summed up well in this thread - extremely > > intermittent, but extremely serious when it does happen. And I'm one > > of the devs who has pulled an app from the Market as a result. > > > At the moment, I'm provisionally optimistic that I've worked around > > the issue in my case. Given it's a race condition, I took the approach > > of maximum thread-safety: I put a whole load of semaphores into my > > code, added "synchronized" and "volatile" modifiers all over the > > place, that sort of thing. And it seems to have been successful... I > > can't be sure (because of the intermittency), but I haven't seen it > > happen for a couple of weeks now. > > > If I had to speculate, I'd say that the problem finally went when I > > synchronized some code which re-generates geometry within my OpenGL > > model. I added semaphores to ensure that textures, geometry, and > > rendering never happened concurrently. There's no way to know that was > > the end problem, but that SEEMED to be it. If that helps anyone. > > > Just to reiterate, I agree that this is a serious platform-level bug > > that needs to be fixed by Google. And it has gotten worse since 2.2, > > although I have (rarely) seen it happen on my G1 running 1.6. > > > String -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: OpenGL lockups in 2.2
That's interesting.. Although I know for sure that all my gl* calls are happening only in the GL thread. And this freezing happens even when I simply leave the device (HTC Desire) running my app with zero user interaction whatsoever. All the app renders is a scenery with a single animation. No texture changes or geometry changes are taking place in this scenario. But because of the animation, I have to render continuously and this is why I have not used the Render_when_dirty approach. I did notice that when the app freezes, my main UI thread as well as a secondary thread (that talks to a game server) are still running and alive. The main UI thread does register touches until a point and then hangs while the secondary thread stays alive. I tried to send an interrupt() to the GLThread from this secondary thread but that did not help. The GLThread remained stuck in eglSwapBuffer(); On Sep 14, 3:42 pm, String wrote: > On Sep 13, 11:24 pm, Jeremy Statz wrote: > > > The big problem here, in my eyes, is that this appears to > > affect any OpenGL using application, and is tremendously discouraging, > > to the point that people pull things off the market and avoid using > > OpenGL. > > I've been chasing this in a couple of my own OpenGL apps for a couple > of months as well. It's summed up well in this thread - extremely > intermittent, but extremely serious when it does happen. And I'm one > of the devs who has pulled an app from the Market as a result. > > At the moment, I'm provisionally optimistic that I've worked around > the issue in my case. Given it's a race condition, I took the approach > of maximum thread-safety: I put a whole load of semaphores into my > code, added "synchronized" and "volatile" modifiers all over the > place, that sort of thing. And it seems to have been successful... I > can't be sure (because of the intermittency), but I haven't seen it > happen for a couple of weeks now. > > If I had to speculate, I'd say that the problem finally went when I > synchronized some code which re-generates geometry within my OpenGL > model. I added semaphores to ensure that textures, geometry, and > rendering never happened concurrently. There's no way to know that was > the end problem, but that SEEMED to be it. If that helps anyone. > > Just to reiterate, I agree that this is a serious platform-level bug > that needs to be fixed by Google. And it has gotten worse since 2.2, > although I have (rarely) seen it happen on my G1 running 1.6. > > String -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: OpenGL lockups in 2.2
On Sep 13, 11:24 pm, Jeremy Statz wrote: > The big problem here, in my eyes, is that this appears to > affect any OpenGL using application, and is tremendously discouraging, > to the point that people pull things off the market and avoid using > OpenGL. I've been chasing this in a couple of my own OpenGL apps for a couple of months as well. It's summed up well in this thread - extremely intermittent, but extremely serious when it does happen. And I'm one of the devs who has pulled an app from the Market as a result. At the moment, I'm provisionally optimistic that I've worked around the issue in my case. Given it's a race condition, I took the approach of maximum thread-safety: I put a whole load of semaphores into my code, added "synchronized" and "volatile" modifiers all over the place, that sort of thing. And it seems to have been successful... I can't be sure (because of the intermittency), but I haven't seen it happen for a couple of weeks now. If I had to speculate, I'd say that the problem finally went when I synchronized some code which re-generates geometry within my OpenGL model. I added semaphores to ensure that textures, geometry, and rendering never happened concurrently. There's no way to know that was the end problem, but that SEEMED to be it. If that helps anyone. Just to reiterate, I agree that this is a serious platform-level bug that needs to be fixed by Google. And it has gotten worse since 2.2, although I have (rarely) seen it happen on my G1 running 1.6. String -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: OpenGL lockups in 2.2
That GLSurfaceView did not fix the issue. The freezing is still
happening. I even tried to interrupt() the GLThread from a second
thread - no success so far.
On Sep 14, 1:46 pm, Robert Green wrote:
> Social Hub,
>
> That's not it. That was just a workaround for 2 sequential
> activities. This problem is deeper than GLSurfaceView. IMO there is
> a race condition between some code system_server calls and the
> userland app which results in mutual freeze. It is up to the platform
> developers to solve, but our job should be to try to isolate some use
> cases that really show it well so they can fix it.
>
> On Sep 14, 10:40 am, social hub wrote:
>
>
>
> >http://code.google.com/p/andengine/source/browse/src/org/anddev/anden...
>
> > I am not the expert but
> > I was looking at andengine they have their modified glsurfaceview and they
> > say something about lockup. I am not sure that's what is happening here. my
> > 2 cents
>
> > Thanks
>
> > On Tue, Sep 14, 2010 at 10:22 AM, timedilation wrote:
>
> > > Any resolutions or workarounds so far on the freezing issue? I am
> > > seeing the same with my opengl app - mainly on HTC phones. I have
> > > never seen this happen on my G1 though and also never on the Motorola
> > > Droid. I am using Google recommended GLSurfaceView and all the
> > > standard stuff but the game itself is graphically fairly intensive.
>
> > > In my case too I get the same messages in logcat:
> > > WARN/SharedBufferStack(3878): waitForCondition(LockCondition) timed
> > > out .. CPU may be pegged. trying again.
>
> > > This is what I have found from my own analysis thus far:
> > > Apparently the following code from SharedBufferStack.h must be causing
> > > these messages to be logged:
> > > //
> > > template
> > > status_t SharedBufferBase::waitForCondition(T condition)
> > > {
> > > const SharedBufferStack& stack( *mSharedStack );
> > > SharedClient& client( *mSharedClient );
> > > const nsecs_t TIMEOUT = s2ns(1);
> > > Mutex::Autolock _l(client.lock);
> > > while ((condition()==false) &&
> > > (stack.identity == mIdentity) &&
> > > (stack.status == NO_ERROR))
> > > {
> > > status_t err = client.cv.waitRelative(client.lock, TIMEOUT);
>
> > > // handle errors and timeouts
> > > if (CC_UNLIKELY(err != NO_ERROR)) {
> > > if (err == TIMED_OUT) {
> > > if (condition()) {
> > > LOGE("waitForCondition(%s) timed out (identity=
> > > %d), "
> > > "but condition is true! We recovered but it "
> > > "shouldn't happen." , T::name(),
> > > stack.identity);
> > > break;
> > > } else {
> > > LOGW("waitForCondition(%s) timed out "
> > > "(identity=%d, status=%d). "
> > > "CPU may be pegged. trying again.", T::name(),
> > > stack.identity, stack.status);
> > > }
> > > } else {
> > > LOGE("waitForCondition(%s) error (%s) ",
> > > T::name(), strerror(-err));
> > > return err;
> > > }
> > > }
> > > }
> > > return (stack.identity != mIdentity) ? status_t(BAD_INDEX) :
> > > stack.status;
> > > }
> > > //
>
> > > The GL thread hangs indefinitely while doing the eglSwapBuffer() call.
> > > This java call maps to a JNI C++ call via the function below:
> > > (taken from this link:
>
> > >http://www.netmite.com/android/mydroid/frameworks/base/opengl/libGLES...
> > > )
>
> > > //-
> > > EGLBoolean eglSwapBuffers(EGLDisplay dpy, EGLSurface draw)
> > > {
> > > if (!validate_display_surface(dpy, draw))
> > > return EGL_FALSE;
> > > egl_display_t const * const dp = get_display(dpy);
> > > egl_surface_t const * const s = get_surface(draw);
> > > return s->cnx->hooks->egl.eglSwapBuffers(dp->dpys[s->impl], s-
> > > >surface);
> > > }
> > > //-
> > > The last line of this function I believe hooks into and makes a low
> > > level call into the GL driver library on the device. Somewhere in
> > > there might be a call that locks up and causes the main thread of my
> > > game to start spitting out those timeout (LockCondition) messages to
> > > logcat.
>
> > > On Sep 13, 6:24 pm, Jeremy Statz wrote:
> > > > What I did to log this is to create a special logging class that can
> > > > output to SD card, then put a print at the top and bottom of every
> > > > function call in my wallpaper, with a fluch() after every line being
> > > > written. This wrecks the framerate and results in a several hundred
> > > > meg log after a few hours, but means I have a reliable log of all
> > > > activity throughout the application. Consistently, the crash occurs
> >
[android-developers] Re: OpenGL lockups in 2.2
Social Hub,
That's not it. That was just a workaround for 2 sequential
activities. This problem is deeper than GLSurfaceView. IMO there is
a race condition between some code system_server calls and the
userland app which results in mutual freeze. It is up to the platform
developers to solve, but our job should be to try to isolate some use
cases that really show it well so they can fix it.
On Sep 14, 10:40 am, social hub wrote:
> http://code.google.com/p/andengine/source/browse/src/org/anddev/anden...
>
> I am not the expert but
> I was looking at andengine they have their modified glsurfaceview and they
> say something about lockup. I am not sure that's what is happening here. my
> 2 cents
>
> Thanks
>
> On Tue, Sep 14, 2010 at 10:22 AM, timedilation wrote:
>
>
>
> > Any resolutions or workarounds so far on the freezing issue? I am
> > seeing the same with my opengl app - mainly on HTC phones. I have
> > never seen this happen on my G1 though and also never on the Motorola
> > Droid. I am using Google recommended GLSurfaceView and all the
> > standard stuff but the game itself is graphically fairly intensive.
>
> > In my case too I get the same messages in logcat:
> > WARN/SharedBufferStack(3878): waitForCondition(LockCondition) timed
> > out .. CPU may be pegged. trying again.
>
> > This is what I have found from my own analysis thus far:
> > Apparently the following code from SharedBufferStack.h must be causing
> > these messages to be logged:
> > //
> > template
> > status_t SharedBufferBase::waitForCondition(T condition)
> > {
> > const SharedBufferStack& stack( *mSharedStack );
> > SharedClient& client( *mSharedClient );
> > const nsecs_t TIMEOUT = s2ns(1);
> > Mutex::Autolock _l(client.lock);
> > while ((condition()==false) &&
> > (stack.identity == mIdentity) &&
> > (stack.status == NO_ERROR))
> > {
> > status_t err = client.cv.waitRelative(client.lock, TIMEOUT);
>
> > // handle errors and timeouts
> > if (CC_UNLIKELY(err != NO_ERROR)) {
> > if (err == TIMED_OUT) {
> > if (condition()) {
> > LOGE("waitForCondition(%s) timed out (identity=
> > %d), "
> > "but condition is true! We recovered but it "
> > "shouldn't happen." , T::name(),
> > stack.identity);
> > break;
> > } else {
> > LOGW("waitForCondition(%s) timed out "
> > "(identity=%d, status=%d). "
> > "CPU may be pegged. trying again.", T::name(),
> > stack.identity, stack.status);
> > }
> > } else {
> > LOGE("waitForCondition(%s) error (%s) ",
> > T::name(), strerror(-err));
> > return err;
> > }
> > }
> > }
> > return (stack.identity != mIdentity) ? status_t(BAD_INDEX) :
> > stack.status;
> > }
> > //
>
> > The GL thread hangs indefinitely while doing the eglSwapBuffer() call.
> > This java call maps to a JNI C++ call via the function below:
> > (taken from this link:
>
> >http://www.netmite.com/android/mydroid/frameworks/base/opengl/libGLES...
> > )
>
> > //-
> > EGLBoolean eglSwapBuffers(EGLDisplay dpy, EGLSurface draw)
> > {
> > if (!validate_display_surface(dpy, draw))
> > return EGL_FALSE;
> > egl_display_t const * const dp = get_display(dpy);
> > egl_surface_t const * const s = get_surface(draw);
> > return s->cnx->hooks->egl.eglSwapBuffers(dp->dpys[s->impl], s-
> > >surface);
> > }
> > //-
> > The last line of this function I believe hooks into and makes a low
> > level call into the GL driver library on the device. Somewhere in
> > there might be a call that locks up and causes the main thread of my
> > game to start spitting out those timeout (LockCondition) messages to
> > logcat.
>
> > On Sep 13, 6:24 pm, Jeremy Statz wrote:
> > > What I did to log this is to create a special logging class that can
> > > output to SD card, then put a print at the top and bottom of every
> > > function call in my wallpaper, with a fluch() after every line being
> > > written. This wrecks the framerate and results in a several hundred
> > > meg log after a few hours, but means I have a reliable log of all
> > > activity throughout the application. Consistently, the crash occurs
> > > in-between frames, and requires no special stimulation -- the phone
> > > can just be sitting there running, then will suddenly die without
> > > warning. I'm confident saying that.
>
> > > I've actually been using your GLWallpaperService code as a base,
> > > though I've made a couple minor changes. It's been quite stable
> > > overall. The big problem here, in my eyes, is that this
[android-developers] Re: OpenGL lockups in 2.2
Thx for sharing the link. I will try this to see if it fixes the
issue.
On Sep 14, 11:40 am, social hub wrote:
> http://code.google.com/p/andengine/source/browse/src/org/anddev/anden...
>
> I am not the expert but
> I was looking at andengine they have their modified glsurfaceview and they
> say something about lockup. I am not sure that's what is happening here. my
> 2 cents
>
> Thanks
>
> On Tue, Sep 14, 2010 at 10:22 AM, timedilation wrote:
>
>
>
> > Any resolutions or workarounds so far on the freezing issue? I am
> > seeing the same with my opengl app - mainly on HTC phones. I have
> > never seen this happen on my G1 though and also never on the Motorola
> > Droid. I am using Google recommended GLSurfaceView and all the
> > standard stuff but the game itself is graphically fairly intensive.
>
> > In my case too I get the same messages in logcat:
> > WARN/SharedBufferStack(3878): waitForCondition(LockCondition) timed
> > out .. CPU may be pegged. trying again.
>
> > This is what I have found from my own analysis thus far:
> > Apparently the following code from SharedBufferStack.h must be causing
> > these messages to be logged:
> > //
> > template
> > status_t SharedBufferBase::waitForCondition(T condition)
> > {
> > const SharedBufferStack& stack( *mSharedStack );
> > SharedClient& client( *mSharedClient );
> > const nsecs_t TIMEOUT = s2ns(1);
> > Mutex::Autolock _l(client.lock);
> > while ((condition()==false) &&
> > (stack.identity == mIdentity) &&
> > (stack.status == NO_ERROR))
> > {
> > status_t err = client.cv.waitRelative(client.lock, TIMEOUT);
>
> > // handle errors and timeouts
> > if (CC_UNLIKELY(err != NO_ERROR)) {
> > if (err == TIMED_OUT) {
> > if (condition()) {
> > LOGE("waitForCondition(%s) timed out (identity=
> > %d), "
> > "but condition is true! We recovered but it "
> > "shouldn't happen." , T::name(),
> > stack.identity);
> > break;
> > } else {
> > LOGW("waitForCondition(%s) timed out "
> > "(identity=%d, status=%d). "
> > "CPU may be pegged. trying again.", T::name(),
> > stack.identity, stack.status);
> > }
> > } else {
> > LOGE("waitForCondition(%s) error (%s) ",
> > T::name(), strerror(-err));
> > return err;
> > }
> > }
> > }
> > return (stack.identity != mIdentity) ? status_t(BAD_INDEX) :
> > stack.status;
> > }
> > //
>
> > The GL thread hangs indefinitely while doing the eglSwapBuffer() call.
> > This java call maps to a JNI C++ call via the function below:
> > (taken from this link:
>
> >http://www.netmite.com/android/mydroid/frameworks/base/opengl/libGLES...
> > )
>
> > //-
> > EGLBoolean eglSwapBuffers(EGLDisplay dpy, EGLSurface draw)
> > {
> > if (!validate_display_surface(dpy, draw))
> > return EGL_FALSE;
> > egl_display_t const * const dp = get_display(dpy);
> > egl_surface_t const * const s = get_surface(draw);
> > return s->cnx->hooks->egl.eglSwapBuffers(dp->dpys[s->impl], s-
> > >surface);
> > }
> > //-
> > The last line of this function I believe hooks into and makes a low
> > level call into the GL driver library on the device. Somewhere in
> > there might be a call that locks up and causes the main thread of my
> > game to start spitting out those timeout (LockCondition) messages to
> > logcat.
>
> > On Sep 13, 6:24 pm, Jeremy Statz wrote:
> > > What I did to log this is to create a special logging class that can
> > > output to SD card, then put a print at the top and bottom of every
> > > function call in my wallpaper, with a fluch() after every line being
> > > written. This wrecks the framerate and results in a several hundred
> > > meg log after a few hours, but means I have a reliable log of all
> > > activity throughout the application. Consistently, the crash occurs
> > > in-between frames, and requires no special stimulation -- the phone
> > > can just be sitting there running, then will suddenly die without
> > > warning. I'm confident saying that.
>
> > > I've actually been using your GLWallpaperService code as a base,
> > > though I've made a couple minor changes. It's been quite stable
> > > overall. The big problem here, in my eyes, is that this appears to
> > > affect any OpenGL using application, and is tremendously discouraging,
> > > to the point that people pull things off the market and avoid using
> > > OpenGL. This hurts the platform as a whole, especially when comparing
> > > its game library to the iPhone.
>
> > > On top of that, while this seemed excee
Re: [android-developers] Re: OpenGL lockups in 2.2
http://code.google.com/p/andengine/source/browse/src/org/anddev/andengine/opengl/view/GLSurfaceView.java
I am not the expert but
I was looking at andengine they have their modified glsurfaceview and they
say something about lockup. I am not sure that's what is happening here. my
2 cents
Thanks
On Tue, Sep 14, 2010 at 10:22 AM, timedilation wrote:
> Any resolutions or workarounds so far on the freezing issue? I am
> seeing the same with my opengl app - mainly on HTC phones. I have
> never seen this happen on my G1 though and also never on the Motorola
> Droid. I am using Google recommended GLSurfaceView and all the
> standard stuff but the game itself is graphically fairly intensive.
>
> In my case too I get the same messages in logcat:
> WARN/SharedBufferStack(3878): waitForCondition(LockCondition) timed
> out .. CPU may be pegged. trying again.
>
> This is what I have found from my own analysis thus far:
> Apparently the following code from SharedBufferStack.h must be causing
> these messages to be logged:
> //
> template
> status_t SharedBufferBase::waitForCondition(T condition)
> {
>const SharedBufferStack& stack( *mSharedStack );
>SharedClient& client( *mSharedClient );
>const nsecs_t TIMEOUT = s2ns(1);
>Mutex::Autolock _l(client.lock);
>while ((condition()==false) &&
>(stack.identity == mIdentity) &&
>(stack.status == NO_ERROR))
>{
>status_t err = client.cv.waitRelative(client.lock, TIMEOUT);
>
>// handle errors and timeouts
>if (CC_UNLIKELY(err != NO_ERROR)) {
>if (err == TIMED_OUT) {
>if (condition()) {
>LOGE("waitForCondition(%s) timed out (identity=
> %d), "
>"but condition is true! We recovered but it "
>"shouldn't happen." , T::name(),
>stack.identity);
>break;
>} else {
>LOGW("waitForCondition(%s) timed out "
>"(identity=%d, status=%d). "
>"CPU may be pegged. trying again.", T::name(),
>stack.identity, stack.status);
>}
>} else {
>LOGE("waitForCondition(%s) error (%s) ",
>T::name(), strerror(-err));
>return err;
>}
>}
>}
>return (stack.identity != mIdentity) ? status_t(BAD_INDEX) :
> stack.status;
> }
> //
>
> The GL thread hangs indefinitely while doing the eglSwapBuffer() call.
> This java call maps to a JNI C++ call via the function below:
> (taken from this link:
>
> http://www.netmite.com/android/mydroid/frameworks/base/opengl/libGLES_CM/gl_wrapper.cpp
> )
>
> //-
> EGLBoolean eglSwapBuffers(EGLDisplay dpy, EGLSurface draw)
> {
>if (!validate_display_surface(dpy, draw))
>return EGL_FALSE;
>egl_display_t const * const dp = get_display(dpy);
>egl_surface_t const * const s = get_surface(draw);
>return s->cnx->hooks->egl.eglSwapBuffers(dp->dpys[s->impl], s-
> >surface);
> }
> //-
> The last line of this function I believe hooks into and makes a low
> level call into the GL driver library on the device. Somewhere in
> there might be a call that locks up and causes the main thread of my
> game to start spitting out those timeout (LockCondition) messages to
> logcat.
>
>
>
>
> On Sep 13, 6:24 pm, Jeremy Statz wrote:
> > What I did to log this is to create a special logging class that can
> > output to SD card, then put a print at the top and bottom of every
> > function call in my wallpaper, with a fluch() after every line being
> > written. This wrecks the framerate and results in a several hundred
> > meg log after a few hours, but means I have a reliable log of all
> > activity throughout the application. Consistently, the crash occurs
> > in-between frames, and requires no special stimulation -- the phone
> > can just be sitting there running, then will suddenly die without
> > warning. I'm confident saying that.
> >
> > I've actually been using your GLWallpaperService code as a base,
> > though I've made a couple minor changes. It's been quite stable
> > overall. The big problem here, in my eyes, is that this appears to
> > affect any OpenGL using application, and is tremendously discouraging,
> > to the point that people pull things off the market and avoid using
> > OpenGL. This hurts the platform as a whole, especially when comparing
> > its game library to the iPhone.
> >
> > On top of that, while this seemed exceedingly uncommon on 2.1, I feel
> > like I've seen a whole lot more of it with 2.2 on my HTC Incredible.
> > Considering the free versions of my wallpapers have something like
> > three or four million downloads between them, that scares me a great
> > deal.
[android-developers] Re: OpenGL lockups in 2.2
Forgot to mention that the SharedBufferStack code was found at the
following links:
http://www.netmite.com/android/mydroid/2.0/frameworks/base/libs/ui/SharedBufferStack.cpp
http://www.netmite.com/android/mydroid/2.0/frameworks/base/include/private/ui/SharedBufferStack.h
On Sep 14, 11:22 am, timedilation wrote:
> Any resolutions or workarounds so far on the freezing issue? I am
> seeing the same with my opengl app - mainly on HTC phones. I have
> never seen this happen on my G1 though and also never on the Motorola
> Droid. I am using Google recommended GLSurfaceView and all the
> standard stuff but the game itself is graphically fairly intensive.
>
> In my case too I get the same messages in logcat:
> WARN/SharedBufferStack(3878): waitForCondition(LockCondition) timed
> out .. CPU may be pegged. trying again.
>
> This is what I have found from my own analysis thus far:
> Apparently the following code from SharedBufferStack.h must be causing
> these messages to be logged:
> //
> template
> status_t SharedBufferBase::waitForCondition(T condition)
> {
> const SharedBufferStack& stack( *mSharedStack );
> SharedClient& client( *mSharedClient );
> const nsecs_t TIMEOUT = s2ns(1);
> Mutex::Autolock _l(client.lock);
> while ((condition()==false) &&
> (stack.identity == mIdentity) &&
> (stack.status == NO_ERROR))
> {
> status_t err = client.cv.waitRelative(client.lock, TIMEOUT);
>
> // handle errors and timeouts
> if (CC_UNLIKELY(err != NO_ERROR)) {
> if (err == TIMED_OUT) {
> if (condition()) {
> LOGE("waitForCondition(%s) timed out (identity=
> %d), "
> "but condition is true! We recovered but it "
> "shouldn't happen." , T::name(),
> stack.identity);
> break;
> } else {
> LOGW("waitForCondition(%s) timed out "
> "(identity=%d, status=%d). "
> "CPU may be pegged. trying again.", T::name(),
> stack.identity, stack.status);
> }
> } else {
> LOGE("waitForCondition(%s) error (%s) ",
> T::name(), strerror(-err));
> return err;
> }
> }
> }
> return (stack.identity != mIdentity) ? status_t(BAD_INDEX) :
> stack.status;}
>
> //
>
> The GL thread hangs indefinitely while doing the eglSwapBuffer() call.
> This java call maps to a JNI C++ call via the function below:
> (taken from this
> link:http://www.netmite.com/android/mydroid/frameworks/base/opengl/libGLES...)
>
> //-
> EGLBoolean eglSwapBuffers(EGLDisplay dpy, EGLSurface draw)
> {
> if (!validate_display_surface(dpy, draw))
> return EGL_FALSE;
> egl_display_t const * const dp = get_display(dpy);
> egl_surface_t const * const s = get_surface(draw);
> return s->cnx->hooks->egl.eglSwapBuffers(dp->dpys[s->impl], s->surface);
> }
>
> //-
> The last line of this function I believe hooks into and makes a low
> level call into the GL driver library on the device. Somewhere in
> there might be a call that locks up and causes the main thread of my
> game to start spitting out those timeout (LockCondition) messages to
> logcat.
>
> On Sep 13, 6:24 pm, Jeremy Statz wrote:
>
>
>
> > What I did to log this is to create a special logging class that can
> > output to SD card, then put a print at the top and bottom of every
> > function call in my wallpaper, with a fluch() after every line being
> > written. This wrecks the framerate and results in a several hundred
> > meg log after a few hours, but means I have a reliable log of all
> > activity throughout the application. Consistently, the crash occurs
> > in-between frames, and requires no special stimulation -- the phone
> > can just be sitting there running, then will suddenly die without
> > warning. I'm confident saying that.
>
> > I've actually been using your GLWallpaperService code as a base,
> > though I've made a couple minor changes. It's been quite stable
> > overall. The big problem here, in my eyes, is that this appears to
> > affect any OpenGL using application, and is tremendously discouraging,
> > to the point that people pull things off the market and avoid using
> > OpenGL. This hurts the platform as a whole, especially when comparing
> > its game library to the iPhone.
>
> > On top of that, while this seemed exceedingly uncommon on 2.1, I feel
> > like I've seen a whole lot more of it with 2.2 on my HTC Incredible.
> > Considering the free versions of my wallpapers have something like
> > three or four million downloads between them, that scares me a great
> > deal. That's a lot of potential
[android-developers] Re: OpenGL lockups in 2.2
Any resolutions or workarounds so far on the freezing issue? I am
seeing the same with my opengl app - mainly on HTC phones. I have
never seen this happen on my G1 though and also never on the Motorola
Droid. I am using Google recommended GLSurfaceView and all the
standard stuff but the game itself is graphically fairly intensive.
In my case too I get the same messages in logcat:
WARN/SharedBufferStack(3878): waitForCondition(LockCondition) timed
out .. CPU may be pegged. trying again.
This is what I have found from my own analysis thus far:
Apparently the following code from SharedBufferStack.h must be causing
these messages to be logged:
//
template
status_t SharedBufferBase::waitForCondition(T condition)
{
const SharedBufferStack& stack( *mSharedStack );
SharedClient& client( *mSharedClient );
const nsecs_t TIMEOUT = s2ns(1);
Mutex::Autolock _l(client.lock);
while ((condition()==false) &&
(stack.identity == mIdentity) &&
(stack.status == NO_ERROR))
{
status_t err = client.cv.waitRelative(client.lock, TIMEOUT);
// handle errors and timeouts
if (CC_UNLIKELY(err != NO_ERROR)) {
if (err == TIMED_OUT) {
if (condition()) {
LOGE("waitForCondition(%s) timed out (identity=
%d), "
"but condition is true! We recovered but it "
"shouldn't happen." , T::name(),
stack.identity);
break;
} else {
LOGW("waitForCondition(%s) timed out "
"(identity=%d, status=%d). "
"CPU may be pegged. trying again.", T::name(),
stack.identity, stack.status);
}
} else {
LOGE("waitForCondition(%s) error (%s) ",
T::name(), strerror(-err));
return err;
}
}
}
return (stack.identity != mIdentity) ? status_t(BAD_INDEX) :
stack.status;
}
//
The GL thread hangs indefinitely while doing the eglSwapBuffer() call.
This java call maps to a JNI C++ call via the function below:
(taken from this link:
http://www.netmite.com/android/mydroid/frameworks/base/opengl/libGLES_CM/gl_wrapper.cpp)
//-
EGLBoolean eglSwapBuffers(EGLDisplay dpy, EGLSurface draw)
{
if (!validate_display_surface(dpy, draw))
return EGL_FALSE;
egl_display_t const * const dp = get_display(dpy);
egl_surface_t const * const s = get_surface(draw);
return s->cnx->hooks->egl.eglSwapBuffers(dp->dpys[s->impl], s-
>surface);
}
//-
The last line of this function I believe hooks into and makes a low
level call into the GL driver library on the device. Somewhere in
there might be a call that locks up and causes the main thread of my
game to start spitting out those timeout (LockCondition) messages to
logcat.
On Sep 13, 6:24 pm, Jeremy Statz wrote:
> What I did to log this is to create a special logging class that can
> output to SD card, then put a print at the top and bottom of every
> function call in my wallpaper, with a fluch() after every line being
> written. This wrecks the framerate and results in a several hundred
> meg log after a few hours, but means I have a reliable log of all
> activity throughout the application. Consistently, the crash occurs
> in-between frames, and requires no special stimulation -- the phone
> can just be sitting there running, then will suddenly die without
> warning. I'm confident saying that.
>
> I've actually been using your GLWallpaperService code as a base,
> though I've made a couple minor changes. It's been quite stable
> overall. The big problem here, in my eyes, is that this appears to
> affect any OpenGL using application, and is tremendously discouraging,
> to the point that people pull things off the market and avoid using
> OpenGL. This hurts the platform as a whole, especially when comparing
> its game library to the iPhone.
>
> On top of that, while this seemed exceedingly uncommon on 2.1, I feel
> like I've seen a whole lot more of it with 2.2 on my HTC Incredible.
> Considering the free versions of my wallpapers have something like
> three or four million downloads between them, that scares me a great
> deal. That's a lot of potentially affected users.
>
> On Sep 13, 3:22 am, Robert Green wrote:
>
>
>
> > Jeremy,
>
> > It happened to me quite a bit on both 2.1 and 2.2 on every device.
> > It's surely a defect of Android but so far no one has been able to
> > track it down. It's a tough one, very difficult to reproduce
> > reliably. It tends to happen more often in certain cases for reasons
> > unknown to me right now, such as on an EVO running 2.1 on the third
> > level of Deadly Chambers if you play it straight thr
[android-developers] Re: OpenGL lockups in 2.2
What I did to log this is to create a special logging class that can output to SD card, then put a print at the top and bottom of every function call in my wallpaper, with a fluch() after every line being written. This wrecks the framerate and results in a several hundred meg log after a few hours, but means I have a reliable log of all activity throughout the application. Consistently, the crash occurs in-between frames, and requires no special stimulation -- the phone can just be sitting there running, then will suddenly die without warning. I'm confident saying that. I've actually been using your GLWallpaperService code as a base, though I've made a couple minor changes. It's been quite stable overall. The big problem here, in my eyes, is that this appears to affect any OpenGL using application, and is tremendously discouraging, to the point that people pull things off the market and avoid using OpenGL. This hurts the platform as a whole, especially when comparing its game library to the iPhone. On top of that, while this seemed exceedingly uncommon on 2.1, I feel like I've seen a whole lot more of it with 2.2 on my HTC Incredible. Considering the free versions of my wallpapers have something like three or four million downloads between them, that scares me a great deal. That's a lot of potentially affected users. On Sep 13, 3:22 am, Robert Green wrote: > Jeremy, > > It happened to me quite a bit on both 2.1 and 2.2 on every device. > It's surely a defect of Android but so far no one has been able to > track it down. It's a tough one, very difficult to reproduce > reliably. It tends to happen more often in certain cases for reasons > unknown to me right now, such as on an EVO running 2.1 on the third > level of Deadly Chambers if you play it straight through. Since that > takes 20 minutes, it's impossible to figure out by logging because > it's just way too much. Breakpoints don't work because the game > doesn't run fast enough in debug mode and debugging doesn't work > anyways once the lockup has happened. > > It's pretty much a worse case scenario - a very fatal, very > intermittent bug that breaks debugging and is nearly impossible to > isolate. > > I hope some genius out there can figure this one out. I couldn't even > get close. > > On Sep 12, 10:34 pm, Jeremy Statz wrote: > > > > > > > > > There's been a couple threads about this in the last year or so, but I > > wanted to draw attention to it again, as I've spent most of the last > > couple of days trying to confirm it wasn't anything I'm doing. > > > The short story is, I'm pretty sure there's a very serious lock-up-the- > > phone level bug that happens when using OpenGL applications. When it > > occurs the phone will freeze for at least two minutes before rebooting > > itself, sometimes requiring that the battery be pulled. This didn't > > seem to happen often on 2.1, but I'm seeing it with a lot more > > regularity on 2.2 (particularly on HTC phones, though that may be a > > coincidence) and am really hoping to draw some attention from someone > > in a position to fix it. Typically, you'll end up seeing hundreds of > > lines of this in the LogCat log: > > > WARN/SharedBufferStack(2005): waitForCondition(LockCondition) timed > > out (identity=9, status=0). CPU may be pegged. trying again. > > WARN/SharedBufferStack(71): waitForCondition(LockCondition) timed out > > (identity=9, status=0). CPU may be pegged. trying again. > > > There won't be any callstack or error of any kind preceding this. In > > this case 2005 is my app (a live wallpaper), and 71 appears to be the > > UI/system process. I'm assuming this is a race condition within > > SharedBufferStack. I've seen cases where four or five process IDs > > were all printing the message, all OpenGL apps of some kind. > > > Replicating the problem is very, very difficult and seems very > > random... in the last case I had to leave the wallpaper running and > > active on the home screen for about seven hours before it occurred. > > Sometimes I've had it go days, other times it'll happen within a few > > minutes. My log output demonstrates no unusual activity at all before > > the crash, loading/unloading/visibility/etc doesn't seem to be a > > factor. It's very rare. > > > I kind of feel like this got glossed over the last couple times people > > have reported it here, but based on my reading it's a long-standing > > problem with Android and OpenGL and is having a chilling effect on its > > usage. Is there anyone who can explain if there's anything I can do > > to discourage problems here? This is beyond my ken honestly, does > > anyone know this part of the system well? -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this
[android-developers] Re: OpenGL lockups in 2.2
I'm sorry - let me clarify something. When I said, "quite a bit," I mean that it happened to me on both versions at least once on every device I tested on. To quantify better, it happened maybe a total of 20 times in about 400 hours of play testing. It happens more often to others according to support emails I've received. On Sep 13, 3:22 am, Robert Green wrote: > Jeremy, > > It happened to me quite a bit on both 2.1 and 2.2 on every device. > It's surely a defect of Android but so far no one has been able to > track it down. It's a tough one, very difficult to reproduce > reliably. It tends to happen more often in certain cases for reasons > unknown to me right now, such as on an EVO running 2.1 on the third > level of Deadly Chambers if you play it straight through. Since that > takes 20 minutes, it's impossible to figure out by logging because > it's just way too much. Breakpoints don't work because the game > doesn't run fast enough in debug mode and debugging doesn't work > anyways once the lockup has happened. > > It's pretty much a worse case scenario - a very fatal, very > intermittent bug that breaks debugging and is nearly impossible to > isolate. > > I hope some genius out there can figure this one out. I couldn't even > get close. > > On Sep 12, 10:34 pm, Jeremy Statz wrote: > > > > > There's been a couple threads about this in the last year or so, but I > > wanted to draw attention to it again, as I've spent most of the last > > couple of days trying to confirm it wasn't anything I'm doing. > > > The short story is, I'm pretty sure there's a very serious lock-up-the- > > phone level bug that happens when using OpenGL applications. When it > > occurs the phone will freeze for at least two minutes before rebooting > > itself, sometimes requiring that the battery be pulled. This didn't > > seem to happen often on 2.1, but I'm seeing it with a lot more > > regularity on 2.2 (particularly on HTC phones, though that may be a > > coincidence) and am really hoping to draw some attention from someone > > in a position to fix it. Typically, you'll end up seeing hundreds of > > lines of this in the LogCat log: > > > WARN/SharedBufferStack(2005): waitForCondition(LockCondition) timed > > out (identity=9, status=0). CPU may be pegged. trying again. > > WARN/SharedBufferStack(71): waitForCondition(LockCondition) timed out > > (identity=9, status=0). CPU may be pegged. trying again. > > > There won't be any callstack or error of any kind preceding this. In > > this case 2005 is my app (a live wallpaper), and 71 appears to be the > > UI/system process. I'm assuming this is a race condition within > > SharedBufferStack. I've seen cases where four or five process IDs > > were all printing the message, all OpenGL apps of some kind. > > > Replicating the problem is very, very difficult and seems very > > random... in the last case I had to leave the wallpaper running and > > active on the home screen for about seven hours before it occurred. > > Sometimes I've had it go days, other times it'll happen within a few > > minutes. My log output demonstrates no unusual activity at all before > > the crash, loading/unloading/visibility/etc doesn't seem to be a > > factor. It's very rare. > > > I kind of feel like this got glossed over the last couple times people > > have reported it here, but based on my reading it's a long-standing > > problem with Android and OpenGL and is having a chilling effect on its > > usage. Is there anyone who can explain if there's anything I can do > > to discourage problems here? This is beyond my ken honestly, does > > anyone know this part of the system well? -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: OpenGL lockups in 2.2
Jeremy, It happened to me quite a bit on both 2.1 and 2.2 on every device. It's surely a defect of Android but so far no one has been able to track it down. It's a tough one, very difficult to reproduce reliably. It tends to happen more often in certain cases for reasons unknown to me right now, such as on an EVO running 2.1 on the third level of Deadly Chambers if you play it straight through. Since that takes 20 minutes, it's impossible to figure out by logging because it's just way too much. Breakpoints don't work because the game doesn't run fast enough in debug mode and debugging doesn't work anyways once the lockup has happened. It's pretty much a worse case scenario - a very fatal, very intermittent bug that breaks debugging and is nearly impossible to isolate. I hope some genius out there can figure this one out. I couldn't even get close. On Sep 12, 10:34 pm, Jeremy Statz wrote: > There's been a couple threads about this in the last year or so, but I > wanted to draw attention to it again, as I've spent most of the last > couple of days trying to confirm it wasn't anything I'm doing. > > The short story is, I'm pretty sure there's a very serious lock-up-the- > phone level bug that happens when using OpenGL applications. When it > occurs the phone will freeze for at least two minutes before rebooting > itself, sometimes requiring that the battery be pulled. This didn't > seem to happen often on 2.1, but I'm seeing it with a lot more > regularity on 2.2 (particularly on HTC phones, though that may be a > coincidence) and am really hoping to draw some attention from someone > in a position to fix it. Typically, you'll end up seeing hundreds of > lines of this in the LogCat log: > > WARN/SharedBufferStack(2005): waitForCondition(LockCondition) timed > out (identity=9, status=0). CPU may be pegged. trying again. > WARN/SharedBufferStack(71): waitForCondition(LockCondition) timed out > (identity=9, status=0). CPU may be pegged. trying again. > > There won't be any callstack or error of any kind preceding this. In > this case 2005 is my app (a live wallpaper), and 71 appears to be the > UI/system process. I'm assuming this is a race condition within > SharedBufferStack. I've seen cases where four or five process IDs > were all printing the message, all OpenGL apps of some kind. > > Replicating the problem is very, very difficult and seems very > random... in the last case I had to leave the wallpaper running and > active on the home screen for about seven hours before it occurred. > Sometimes I've had it go days, other times it'll happen within a few > minutes. My log output demonstrates no unusual activity at all before > the crash, loading/unloading/visibility/etc doesn't seem to be a > factor. It's very rare. > > I kind of feel like this got glossed over the last couple times people > have reported it here, but based on my reading it's a long-standing > problem with Android and OpenGL and is having a chilling effect on its > usage. Is there anyone who can explain if there's anything I can do > to discourage problems here? This is beyond my ken honestly, does > anyone know this part of the system well? -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
