Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (494)
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]
  ignore  |  Print  
  Normal for glClearColor and glClear to be slower than the actual rendering?  (Read 1044 times)
0 Members and 1 Guest are viewing this topic.
Offline Dxu1994
« Posted 2014-01-10 14:32:24 »

I recently profiled my game (using LWJGL) using the NetBeans profiler and to my surprise, the initial pixel clear function was taking LONGER to execute than rendering 10 thousand sprites a frame.

This really baffles me and I wanted to ask if anyone has any idea why?



Its not just a slight difference either, the glClear and glClearColor methods are taking over 2x the time that doRender() is, and doRender actually renders about 10k-20k sprites per frame, setting up buffers, binding shaders, calculating tex coords and finally calling glDrawElements.

Now i'm just super confused and I'd like to see if anyone has any clues as to why this is.

The function looks like this:

1  
2  
3  
4  
5  
6  
7  
@Override
    public void begin() {
        GL11.glClearColor(0, 0, 0, 1);
        GL11.glClear(GL11.GL_COLOR_BUFFER_BIT);
        a = r = g = b = (byte)0xff;
        scissorRect = null;
    }

Offline StrideColossus
« Reply #1 - Posted 2014-01-10 14:44:53 »

Couple of possibilities spring to mind:

1. It's possible that GL is queuing the commands and only flushing when glClear() gets called - unlikely, though I have seen other odd 'bottle-necks' when profiling before.  Might be worth adding glFlush() at the end of the rendering code?  (or would swapping the buffers force the flush anyway?)

2. Are you using vsync?  It might just be waiting for the sync before starting the clear?

- stride

Offline Dxu1994
« Reply #2 - Posted 2014-01-10 14:58:58 »

Couple of possibilities spring to mind:

1. It's possible that GL is queuing the commands and only flushing when glClear() gets called - unlikely, though I have seen other odd 'bottle-necks' when profiling before.  Might be worth adding glFlush() at the end of the rendering code?  (or would swapping the buffers force the flush anyway?)

2. Are you using vsync?  It might just be waiting for the sync before starting the clear?

- stride



1. Tried that, it makes no difference, and yes I do call Display.update() every single time after I'm done rendering. (Buffer swap)

2. No, I'm not using vsync. I still get over 200 FPS with this code but I just thought this anomaly was kind of strange, like it shouldn't be happening.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline StrideColossus
« Reply #3 - Posted 2014-01-10 15:23:16 »

2. No, I'm not using vsync. I still get over 200 FPS with this code but I just thought this anomaly was kind of strange, like it shouldn't be happening.

Agreed it's very odd, bit of googling reveals a few other people have had vaguely similar issues but there doesn't appear to be any consensus.
Maybe some other forumistas can suggest why this is happening?
Offline davedes
« Reply #4 - Posted 2014-01-10 15:50:56 »

Throw a glFinish in to see if that does anything to your profiling.

Chances are it's just queueing commands, and only executing them on glClear. Nothing to worry about if you're getting 200 FPS.

Also; you don't need to set the clear color every frame. Since GL is state-based, you can just set it once during initialization.

Offline Dxu1994
« Reply #5 - Posted 2014-01-10 16:29:09 »

Throw a glFinish in to see if that does anything to your profiling.

Chances are it's just queueing commands, and only executing them on glClear. Nothing to worry about if you're getting 200 FPS.

Also; you don't need to set the clear color every frame. Since GL is state-based, you can just set it once during initialization.

Thanks for the tip.

Surprisingly, I changed my glClearColor function to this:

1  
2  
3  
4  
5  
6  
7  
8  
9  
public static void glClearColor(float cA, float cR, float cG, float cB) {
        if (clearA != cA || clearR != cR || cG != clearG || cB != clearB) {
            clearA = cA;
            clearR = cR;
            clearG = cG;
            clearB = cB;
            GL11.glClearColor(cA, cR, cG, cB);
        }
    }


And now the glClear() function is taking about as long to execute as the rendering step,

I still don't understand how glClearColor() could be such a bottleneck though? Seems super strange to me.

Offline theagentd
« Reply #6 - Posted 2014-01-10 17:46:06 »

Surprisingly, I changed my glClearColor function to this:

...

And now the glClear() function is taking about as long to execute as the rendering step,
Did your actual FPS change?


Measuring GPU performance using CPU benchmarking won't give accurate results. I've chased ghosts quite a few times simply because the driver's command queue got full causing a random OpenGL command to block. You're calling glClear() right after Display.update(), so it's very possible that the driver simply blocks on the first OpenGL call(s) because it has buffered enough commands (1-3 frames ahead usually). There's actually no way to know for sure what's happening, since it's completely up to the driver.

You could try to measure the actual GPU time it takes to clear the screen using

1  
2  
3  
4  
5  
6  
7  
int myQuery = glGenQueries();

...

glBeginQuery(GL_TIME_ELAPSED, myQuery);
//Clear screen
glEndQuery(GL_TIME_ELAPSED);


Then you can get the time it took to clear the screen in nano seconds using
glGetQueryObjecti(myQuery, GL_QUERY_RESULT)
. Note that getting the results right after calling glEndQuery() may cause performance problems since the CPU has to wait until the result is ready. I recommend that you get the results with a whole frame's delay, meaning you'll need two sets of query objects.

1. use query object 1 when rendering frame 1
2. use query object 2 when rendering frame 2
3. get result from frame 1
4. use query object 1 when rendering frame 3
5. get result from frame 2
and so on.

Myomyomyo.
Offline davedes
« Reply #7 - Posted 2014-01-10 17:48:14 »

Gxu1994 - Well, it's not a "bottleneck" since you're at 200 FPS. It might just be slower in comparison to everything else (especially if the other stuff is working on the GPU).

Offline Danny02
« Reply #8 - Posted 2014-01-10 18:07:02 »

As others have already hinted, all OpenGL calls are asynchronous at first. Some calls may block under certain circumstances which may also differ from implementation to implementation.
Offline Dxu1994
« Reply #9 - Posted 2014-01-10 18:25:01 »

Ah yeah, I'll give all that a try.

Thanks everyone! Smiley

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.

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

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

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

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

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

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

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

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

Longarmx (30 views)
2014-09-07 01:10:19

mitcheeb (37 views)
2014-09-04 23:08:59
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!