Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (497)
Games in Android Showcase (114)
games submitted by our members
Games in WIP (563)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2
  ignore  |  Print  
  Android threading vagaries  (Read 4912 times)
0 Members and 1 Guest are viewing this topic.
Offline princec

JGO Kernel


Medals: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Posted 2011-10-17 08:12:21 »

So, I've got a dual-core phone and because of the way Android works I'm also, it seems, forced to use two threads to run my game in. For the moment. I might figure out some way around that.

My problem is that the producer-consumer relationship between the logic thread and the rendering thread seems to be very vague. I don't know if it's the Android thread scheduler (which should be just plain ol' Linux thread sheduling) or what, but the actual length of time spent in the meat of the logic thread and the rendering thread can vary by a factor of up to 3 on the same data each frame. The only thing that can slow it down is a synchronized block waiting for a render queue to become available to write to or read from, and thusly I surmise that the way that the thread scheduler wakes up from this is what's causing the latency (after all it only takes a 30ms delay to effectively double the time any particular unit of work is going to take!).

Has anybody got any ideas as to how I can get this idea of writing to one queue and reading from another queue to work without the random latencies?

Shall I just give up on dual-core efficiency and do the logic in the rendering thread? (After all there's not that many phones with dual cores)

Cas Smiley

Offline princec

JGO Kernel


Medals: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #1 - Posted 2011-10-17 10:40:10 »

Actually it turns out there's not a lot of latency in the synchronized wait()/notify() render queues :/ Sometimes it's just taking bizarrely long to update or render. How infuriating.

Cas Smiley

Offline theagentd
« Reply #2 - Posted 2011-10-17 10:41:50 »

Isn't it just the OS or some other program that hogs CPU time, and the thread scheduler isn't smart enough to handle it effectively? =S

Myomyomyo.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline princec

JGO Kernel


Medals: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #3 - Posted 2011-10-17 11:15:39 »

It most likely is ... I've tried setting the GL rendering thread and the logic thread to Thread.MAX_PRIORITY but there still seem to be other things pre-empting it. My suspicions currently fall on the display event loop, sorta like your AWT event thread of old. I was calling display.requestRender() from my logic thread when it was expedient to render a new frame; using RENDERMODE_CONTINUOUSLY the frame rate appears to be more stable. Investigation continues.

Cas Smiley

Offline theagentd
« Reply #4 - Posted 2011-10-17 11:25:24 »

I'm a complete Android n00b as I've said, but you should just let other programs and the AWT-like thread use the second core and settle for the increased stability? xD It's difficult enough getting good scaling on a quad core PC!

Myomyomyo.
Offline princec

JGO Kernel


Medals: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #5 - Posted 2011-10-17 14:19:33 »

Right, I have shamefully admitted defeat and moved to a single-threaded rendering and logic game loop using continuous rendering. Apart from being vastly less complex, it maintains a far more consistent rendering rate, it also means that my Galaxy 2 is no longer ridiculously fast compared to all the other phones out there, which is probably a good thing when you're a developer Wink I'm still getting about 2000 sprites before the game drops noticeably below about 28fps so that'll probably do. I'll aim for 1000 sprites max, more likely about 500, and that should be enough to do some nice games with.

Cas Smiley


Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #6 - Posted 2011-11-20 19:16:37 »

it seems, forced to use two threads to run my game in.

Out of interest (I haven't bothered doing multi-core optimizations for Android yet) ... what were you expecting?

Quote
if it's the Android thread scheduler (which should be just plain ol' Linux thread sheduling)

IME: it's the Android thread scheduler, at least pre-3.0 (I vaguely remember that 2.3 or 3.0 upgraded the scheduler?)

It's massively undefined (one of the many glaring holes in the OS docs for Android).

My impression is that it's a fairly naive scheduler, and on any thread context switch(es) it says to itself:

"Hey! You finished! Cool. I'll go do lots and lots and LOTS of OS-stuff now. I don't know much there is to do - I haven't actually been tracking it! HaHa! It'll only take me a few hundred milliseconds to check everything ... just in case... Bye now!"

...anyway, my early experiences were: go single-threaded, don't look back. I got fed up having the OS treat me so unpredictably Sad.

malloc will be first against the wall when the revolution comes...
Online Catharsis

Senior Member


Medals: 5
Exp: 18 years


TyphonRT rocks!


« Reply #7 - Posted 2011-11-20 21:49:42 »

Yeah.. I've stuck single threaded this whole time, but use the java concurrent executor API to kick off longer running tasks. I have a little framework built up around the executor API to get callbacks and such. IE more powerful than asynctask and cross-platform. It seems a single threaded approach works best for the time being and I easily get 60FPS+ for Q3 levels on Galaxy S2 / Tegra2+. Cas, it also seems that you may be playing around with the stock GLSurfaceView.  I wrote my own "GLSurfaceView" that works with my clock/timing thread and handle GLES context creation and use eglSwapBuffers directly. It works well.

Offline princec

JGO Kernel


Medals: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #8 - Posted 2011-11-20 23:06:47 »

Allegedly 3.0 or 3.1 or something has a new thread scheduler that significantly improves multicore scheduling, but whether that improves on the scheduling with single cores I don't know.

Cas Smiley

Online Catharsis

Senior Member


Medals: 5
Exp: 18 years


TyphonRT rocks!


« Reply #9 - Posted 2011-11-20 23:55:12 »

Yeah.. I'm still on the fence with multiple threads. I know I got to get there, but for now it seems like a specialized case. For instance in the NVidia glow ball demo which looks great they are spawning separate threads to deal with the cloth / physics simulation, but that is possible because in the demo each tapestry / cloth does not interact with each other. http://www.youtube.com/watch?v=eBvaDtshLY8 I'm first going to take a look at Scala, actors, message passing in Scala and evaluate on how to proceed. Haven't had a chance to dig into Scala yet, but I'm gathering the favor of immutable message passing won't be efficient per se on Android. So I foresee some sort of generalized COP (component oriented) message system similar to how I handle input events.

That being said I don't know how much one can get out of basic / general logic + render threads separated. It doesn't help much since in the general case as unless the rendering thread gets updates it's just duplicate frames being rendered. There is much to do in this area especially for Java oriented frameworks.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline theagentd
« Reply #10 - Posted 2011-11-21 01:43:58 »

Yeah.. I'm still on the fence with multiple threads. I know I got to get there, but for now it seems like a specialized case. For instance in the NVidia glow ball demo which looks great they are spawning separate threads to deal with the cloth / physics simulation, but that is possible because in the demo each tapestry / cloth does not interact with each other. http://www.youtube.com/watch?v=eBvaDtshLY8 I'm first going to take a look at Scala, actors, message passing in Scala and evaluate on how to proceed. Haven't had a chance to dig into Scala yet, but I'm gathering the favor of immutable message passing won't be efficient per se on Android. So I foresee some sort of generalized COP (component oriented) message system similar to how I handle input events.

That being said I don't know how much one can get out of basic / general logic + render threads separated. It doesn't help much since in the general case as unless the rendering thread gets updates it's just duplicate frames being rendered. There is much to do in this area especially for Java oriented frameworks.

Why do people have so much trouble with multithreading? It's not hard to implement at all.

Myomyomyo.
Offline delt0r

JGO Knight


Medals: 27
Exp: 18 years


Computers can do that?


« Reply #11 - Posted 2011-11-21 09:14:53 »

What about network threads? So right now i am doing a game mockup/prototype. I use a thread for rendering (awt right now, but lwjgl later), a thread for the "game engine" and threads for reading data from socket connections as its multiplayer.

Will this not work on Android? Do i need to consider full single threaded flow with non blocking IO? That would be a PITA.

I have no special talents. I am only passionately curious.--Albert Einstein
Offline princec

JGO Kernel


Medals: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #12 - Posted 2011-11-21 09:24:41 »

My experiments with threading were only concerned with visible jitter - I was rendering things, and the eye is adept at picking up tiny discrepancies in movement that are caused by the frame rate varying. You have to use threads for asynchronous IO, end of story. That is, in fact, the very thing they were designed to do.

Cas Smiley

Offline Nate

JGO Kernel


Medals: 147
Projects: 4
Exp: 14 years


Esoteric Software


« Reply #13 - Posted 2011-11-21 09:56:31 »

You could take your own advice and use libgdx so you can focus on actually making a game. Wink

Offline princec

JGO Kernel


Medals: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #14 - Posted 2011-11-21 10:10:32 »

Libgdx is massive and fancy pants. I'd use my own SPGL library but it too is massive and fancy pants. However: I think it is time for another rant.
<edit>Doh wrong thread, completely got wired crossed. My SPGL library predates libgdx by years, and is vastly better for my purposes Smiley Not to mention it only took about 2 weeks to wrangle it on to Android. The process of wrangling it also made it so much nicer I'm going to backport it back to J2SE.

Cas Smiley

Online Catharsis

Senior Member


Medals: 5
Exp: 18 years


TyphonRT rocks!


« Reply #15 - Posted 2011-11-22 07:24:03 »

Why do people have so much trouble with multithreading? It's not hard to implement at all.

Uh, I highly doubt you have an efficient and general purpose framework for separating various logic oriented sub systems from rendering. Working with threads is not difficult on the surface and of course is the essential approach with networking, I/O, or long running processes that can easily be separated from the main update / render loop.

As I mentioned in the particular example case of glow ball NVidia has great multithreading here because the separate cloth / tapestries _do not_ interact with each other. I just recently attended an NVidia presentation at AnDevCon where they showed some very fancy tools for debugging GLES on Android and such; I do believe they will be public soon and are amazing for seeing thread / core utilization and debugging shaders and frame by frame rendering by each step / GL call.

What this example translates too is that it's easy to implement a trivial example in a multithreaded context if you know exactly how things will interact and they don't overlap. It's much harder to create a general purpose framework where there isn't advance knowledge of the task at hand which can scale from one to X processors.

There is absolutely a reason why Carmack stuck with the single threaded approach until Rage. Even at that if wikipedia is to be believed it only was likely in the last ~3-4 years that the switch got traction w/ id tech 5 given the WWDC '07 anecdote. http://en.wikipedia.org/wiki/Id_Tech_5 Even with all the neat potential cool stuff id Tech 5 does it still is a relatively closed system with 100% known sub systems thus the multithreading could be relatively baked in a specialized manner into the engine.


Offline Nate

JGO Kernel


Medals: 147
Projects: 4
Exp: 14 years


Esoteric Software


« Reply #16 - Posted 2011-11-22 11:08:14 »

Massive yes, but it is only as fancy pants as you want. If you only want to use the OpenGL abstraction and game loop, you can do that. You are going to run into issue after issue on your own (Android is a f**king minefield), and it is all time wasted not working on your game.

Offline princec

JGO Kernel


Medals: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #17 - Posted 2011-11-22 11:53:58 »

... that may have been the case but it turns out I've solved them all on my own in 3 weeks, and in the bargain I got to learn about android, and keep all my existing tooling and workflow Wink The only thing stopping me from writing some games now is the fact that I've only got two hands and have a shedload of Steam stuff to do.

Cas Smiley

Online Catharsis

Senior Member


Medals: 5
Exp: 18 years


TyphonRT rocks!


« Reply #18 - Posted 2011-11-22 16:26:59 »

... that may have been the case but it turns out I've solved them all on my own in 3 weeks

Or so you may think until you run your code on a different device / API level than the one you have in your hands...  Wink

Offline princec

JGO Kernel


Medals: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #19 - Posted 2011-11-22 16:40:50 »

I'm pretty sure it'll misbehave on a couple of devices out there but it's really so brain dead simple, this code, it really shouldn't misbehave. The code itself is near as dammit identical to the code I've used for the last however many years on the desktop too - it's had a lot of lovely testing.

As it happens it's been tested on a pretty wide variety of devices and basically it seems to function fine on all of them, just with rather varying performance depending on the phone in question (obviously!). I'm aiming at sort of mid-range phones available right now, and hoping that by the time I actually release something most people will own such a phone, and get me about 500 sprites a frame to play with.

Cas Smiley

Offline Nate

JGO Kernel


Medals: 147
Projects: 4
Exp: 14 years


Esoteric Software


« Reply #20 - Posted 2011-11-22 17:16:01 »

Any which way you need to justify it, suit yourself. Wink
* Nate goes back to developing on the desktop and deploying to Android...

Online Catharsis

Senior Member


Medals: 5
Exp: 18 years


TyphonRT rocks!


« Reply #21 - Posted 2011-11-23 07:22:39 »

I'm pretty sure it'll misbehave on a couple of devices out there but it's really so brain dead simple, this code, it really shouldn't misbehave. The code itself is near as dammit identical to the code I've used for the last however many years on the desktop too - it's had a lot of lovely testing.

Very cool. Android caused me to step up my game as things go too. Testing never hurts.

Some of the silliness on Android is well just blatant lack of testing on big G's part. I'll throw out some stuff starting with Froyo though it goes back to the beginning; the "official" Java GL/ES 2.0 bindings in API level 8 are incomplete as code gen was used to create it, but it was never tested thus wrong signatures on some methods preventing some VBO usage. Gingerbread for the most part had no new problems as far as I'm aware for game dev. Honeycomb (3.0 / 3.1) had a major Java NIO regression where calling duplicate on a non ByteBuffer caused an _immutable_ endian swap on the buffer! Way non-kosher there and it broke all my GL code as I have a little extended NIO API that used duplicate on a FloatBuffer; that took me 45 hours of debugging to find and then provide big G a test case; I bitched them out over that though. ;P Only time I've seen the Android team fix a major regression in ~3 hours after test case was provided. Most items in the bug tracker languish forever. Last big thing to cause a ~4 day workaround in my efforts, IE 2 to fix, 2 to make clean, is the piss poor annotation support in Class likely taken from Harmony; horrible GC triggering code. All API levels affected up to Ice Cream Sandwich; had to implement caching myself. MotionEvent and such is an abortion of a proper API. So yeah.. There is always another big bomb shell awaiting around the corner.  Not exactly an exhaustive list and of course off topic.    

You should be able to get far more than 500 sprites on screen w/ mid level hardware. I'm sure the OG droid can pull that off. Fill rate / overdraw is the biggest issue, etc. Err.. this is not about threading anymore.. ;P

@Nate libgdx still require ~6 lines of code changes to configure between desktop & Android usage?  I'm aiming at no code changes.

Offline princec

JGO Kernel


Medals: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #22 - Posted 2011-11-23 12:30:27 »

Don't worry, it's still on topic! Indeed on the Galaxy 2 I managed some daft figure like 2000 sprites @ 60fps but the problem was that to do it reliably everywhere I had to return to single threaded code and the lowest common denominator that I wanted to support. 500 sprites is still quite a lot!

Cas Smiley

Offline delt0r

JGO Knight


Medals: 27
Exp: 18 years


Computers can do that?


« Reply #23 - Posted 2011-11-23 12:33:17 »

how does sprite count reflect say, poly count for "3d"? not at all, or just a little etc..

I have no special talents. I am only passionately curious.--Albert Einstein
Offline princec

JGO Kernel


Medals: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #24 - Posted 2011-11-23 12:36:49 »

Sprites and 3d polys are very much like comparing apples to oranges. Sprites are the worst possible case for 3d cards to render, generally. GPUs are designed to render models super-fast by virtue of shared vertices already being transformed. Furthermore they rarely have to worry about transparency. And of course each sprite needs rotating and scaling individually, probably on the CPU. And so on.

Cas Smiley

Offline delt0r

JGO Knight


Medals: 27
Exp: 18 years


Computers can do that?


« Reply #25 - Posted 2011-11-23 13:00:18 »

A little OT, but did you make any progress on doing the rotating and transforming on the GPU with shaders? I assume this is all ES 2.0?

I have no special talents. I am only passionately curious.--Albert Einstein
Offline princec

JGO Kernel


Medals: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #26 - Posted 2011-11-23 13:13:21 »

No that requires geometry shaders basically, trying anything else is just like gnawing your own legs off to gain a 5fps gain = #FAIL.

Cas Smiley

Offline theagentd
« Reply #27 - Posted 2011-11-23 14:03:22 »

What's wrong with geometry shaders?

Myomyomyo.
Offline delt0r

JGO Knight


Medals: 27
Exp: 18 years


Computers can do that?


« Reply #28 - Posted 2011-11-23 14:07:34 »

ES 2.0 does not have them.

I have no special talents. I am only passionately curious.--Albert Einstein
Offline tberthel
« Reply #29 - Posted 2011-11-23 20:45:41 »

I use lots of threads, but for Android I found the same issue and just use a custom GLSurfaceView with a single rendering thread.

My multi-player games have 2 constantly running threads and even that is a bitch on Android even though they don't synchronize.

So it is not just a rendering issue, but a scheduling issue on Android.

Pages: [1] 2
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

BurntPizza (22 views)
2014-09-19 03:14:18

Dwinin (35 views)
2014-09-12 09:08:26

Norakomi (63 views)
2014-09-10 13:57:51

TehJavaDev (90 views)
2014-09-10 06:39:09

Tekkerue (44 views)
2014-09-09 02:24:56

mitcheeb (65 views)
2014-09-08 06:06:29

BurntPizza (48 views)
2014-09-07 01:13:42

Longarmx (35 views)
2014-09-07 01:12:14

Longarmx (40 views)
2014-09-07 01:11:22

Longarmx (37 views)
2014-09-07 01:10:19
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!