Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (109)
games submitted by our members
Games in WIP (536)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Can eglSwapBuffers be parallellized?  (Read 6793 times)
0 Members and 1 Guest are viewing this topic.
Offline lsgames

Senior Newbie





« Posted 2010-06-10 15:30:19 »

Hi All,

I learned from Chris Pruett/ Replica Island that it should be possible to parallelize the eglSwapBuffers call. So if eglSwapBuffers is running in one thread other threads can run while eglSwapBuffers is completing. Reason for this should be that eglSwapBuffers is running on the GPU - not CPU.

I thus coded a game using two threads - a Render thread and a Physics thread. However I experienced none or very little performance gain. Very little if the thread priorities where calibrated. The eglSwapBuffers call takes 10-20 ms so if it was possible for other threads to run parallel with it it should result in 20% more frames.

Anyone has an opinion on 2-threaded GL games like this or even experience on Android or other platforms?

Thanks,

Martin
Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #1 - Posted 2010-06-10 16:01:54 »

Well, my opinion on this is that the actual call to eglSwapBuffers should internally be asyncrhonous; that is, it should return immediately, which it does on some modern desktop drivers. Trying to work around it yourself on Android might not really be worth the effort.

Cas Smiley

Offline lsgames

Senior Newbie





« Reply #2 - Posted 2010-06-10 17:06:41 »

Hehe, tell me about it... Definitely not worth the effort so far.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline lsgames

Senior Newbie





« Reply #3 - Posted 2010-06-10 17:07:44 »

I agree that it would be nice if it was asynchronous - that would fit better into my idea about how things should work.
Offline lsgames

Senior Newbie





« Reply #4 - Posted 2010-06-21 13:00:47 »

A little follow-up: After testing in depth we actually found that on Droid and Nexus One eglSwapbuffers returns before all the work is done. So it allows for paralellism in the way we hoped. The G1 however appears to block on the eglSwapbuffers call until all work is done. If running multithreaded however it is still possible to gain a performance increase of up to 20% on the G1 by parallelizing work.
Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #5 - Posted 2010-06-21 13:55:55 »

Nice findings. Good thing the G1 is quite a rare phone.

Cas Smiley

Offline VeaR

Junior Member





« Reply #6 - Posted 2010-06-21 14:39:29 »

Don't know if the 'roid has it, but in normal OpenGL, there is glFlush, which forces a flush on the OGL pipeline. If it is not used, (on some cards) it is possible to be 2.5 frames in advance to what is seen on the screen. You could emulate the G1 behavior with adding glFlush after SwapBuffers.
Offline lsgames

Senior Newbie





« Reply #7 - Posted 2010-06-21 20:24:18 »

They have glFlush - it is part of OpenGL 1.0 I believe. Read a bit about it. My impression so far was that it could be done before glSwapBuffers and also that glSwapBuffers can be expected to do a glFlush as the first thing it does. Will flush the pipeline but NOT wait for swap to complete. Was my impression. Curiously on G1 glFlush seems to return immidiatly and not wait for work to be done. 
Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #8 - Posted 2010-06-21 22:36:39 »

glFlush() has no place outside of an actual distributed client/server graphics system (eg. remote X). Its presence is really a bit of an anachronism - not even sure why it's in OpenGL-ES at all, as any gl* methods that actually require a flush (eg. picking, reads) perform an implicit flush anyway.

Cas Smiley

Offline Spasi
« Reply #9 - Posted 2010-06-21 23:32:34 »

glFlush can be useful in ES when interacting with other APIs (OpenCL/VG/MAX etc). It doesn't help with SwapBuffers parallelism though, the driver has to be multi-thread aware to see any gains (which I don't think will be very common on current ES implementations).
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline VeaR

Junior Member





« Reply #10 - Posted 2010-06-27 09:49:18 »

glFlush() has no place outside of an actual distributed client/server graphics system (eg. remote X). Its presence is really a bit of an anachronism - not even sure why it's in OpenGL-ES at all, as any gl* methods that actually require a flush (eg. picking, reads) perform an implicit flush anyway.

Cas Smiley

I think that glFlush is useful when you only want to update the screen in specific situations only, eg when the program keeps track of the changes to the scene, and only updates the display when necessary. I think that such a scenario is valid for Android, since the display complexity is probably simple, and updating the screen only when necessary would save processor and thus battery power. But i'm not into Android coding (yet), so i don't know how important that is.
Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #11 - Posted 2010-06-27 10:13:03 »

That'd be valid in a single-buffered context but... nobody uses single buffering Smiley

Cas Smiley

Offline VeaR

Junior Member





« Reply #12 - Posted 2010-06-27 13:09:17 »

That'd be valid in a single-buffered context but... nobody uses single buffering Smiley

Cas Smiley

Not so. It has nothing to do with double or single buffering. Its just that the display is not updated in the render loop at 30 or whatever frames per second, but only when something changes on the screen. glFlush works perfectly with double-buffered display.
Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #13 - Posted 2010-06-27 22:02:57 »

I still don't follow :/ I can't see any need whatsoever for glFlush in a double-buffered display.... any command requiring that the buffers are flushed, flushes it. That includes swapBuffers of course, too... so I must be being dim. What am I missing?

Cas Smiley

Offline VeaR

Junior Member





« Reply #14 - Posted 2010-06-28 08:31:12 »

I still don't follow :/ I can't see any need whatsoever for glFlush in a double-buffered display.... any command requiring that the buffers are flushed, flushes it. That includes swapBuffers of course, too... so I must be being dim. What am I missing?

Cas Smiley

SwapBuffers does no flush the command queue. I assume that no other commands are used which would flush it. That's why it is possible for display to lags behind in addition to double-buffering. When updating the screen in ad-hoc manner (not regularily), then it is unwanted that OGL buffers multiple frames, since we want the new display to be seen as soon as possible, since the screen update was probably initiated as a reaction to user input. In a normal render loop glFlush is bad, and causes lower frame-rate.

EDIT: Actually i'm somewhere mistaking in this, since swapbuffers does do the actual rendering, but my tests showed that glFlush did reduce framerate.
Pages: [1]
  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.

CogWheelz (15 views)
2014-08-01 22:53:16

CogWheelz (15 views)
2014-08-01 22:51:43

CopyableCougar4 (15 views)
2014-08-01 19:37:19

CogWheelz (19 views)
2014-07-30 21:08:39

Riven (27 views)
2014-07-29 18:09:19

Riven (16 views)
2014-07-29 18:08:52

Dwinin (14 views)
2014-07-29 10:59:34

E.R. Fleming (35 views)
2014-07-29 03:07:13

E.R. Fleming (13 views)
2014-07-29 03:06:25

pw (44 views)
2014-07-24 01:59:36
Resources for WIP games
by CogWheelz
2014-08-01 18:20:17

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

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

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

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

HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22
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!