Regarding GL profiling

Sage
Posts: 1,199
Joined: 2004.10
Post: #31
DoG Wrote:I find it a bit odd that the performance on the X1600 and GF8600 is about the same. I have the impression that you are doing something very wonky syncing drawing to your physics simulation.

I'll post my update loop, but it's pretty much a bog-standard update loop :/

Quote:Also, GL Profiler shows you seem to have too many state changes, and a lot of glVertex calls which you should also get rid off.

I will have to look into the state changes; but I can say right now that I only call glVertex in my UI drawing. Everything else in the scene ( terrain, rubble, car, skydome, foliage ) are drawn via VBOs.
Quote this message in a reply
Sage
Posts: 1,199
Joined: 2004.10
Post: #32
Fenris Wrote:Looks like you've got an interesting crash here... 15" MBP, standard setup... :/

Well, that stinks. It's clearly crashing in DDHidLib -- the super-nice ObjC wrapper to Apple's totally impossible to use USB HID IOKit APIs. I've never seen DDHidLib die before, so this is new to me Sad
Quote this message in a reply
Sage
Posts: 1,199
Joined: 2004.10
Post: #33
aBabyRabbit Wrote:Interesting demo, lots of "how does he do it questions", but first I have a more important dumb user question: how to change the two toggles at the top of the screen? When I mouse over I see a darker bar temporarily under the options, but no amount of mouse clicking or dragging lets me actually change them....

For me, and for the few computers I've tried this on, clicking on the text toggles them. The only thing I can imagine that's wrong is that for some reason the mouse position isn't being read correctly. The underline bar shows up when you mouse-over the text, right? And goes away when you mouse out? But nothing happens when you click? I've never seen that...
Quote this message in a reply
Sage
Posts: 1,199
Joined: 2004.10
Post: #34
Frogblast Wrote:More tests to run:

1) How much does performance improve when alpha test is disabled?

I thought alpha test was a given for performance speedup. Well, I turned it off and performance went up from 20's to solid 30. But the rendering output is not acceptable.
[Image: Terrain-2009-06-30-00.png]

I tried throwing `discard` into the GLSL, but not surprisingly the performance tanked.

Quote:2) Can you use occlusion queries to count the total number of your pixels covered by the foilage? (disable alpha test and depth testing when performing this test). How does this compare to the number of pixels in the whole framebuffer?

It's worth a look.
Quote this message in a reply
Sage
Posts: 1,199
Joined: 2004.10
Post: #35
DoG Wrote:I find it a bit odd that the performance on the X1600 and GF8600 is about the same. I have the impression that you are doing something very wonky syncing drawing to your physics simulation.

Here's my game loop.

Code:
void
DisplayDelegate::update( void )
{
    if ( _animating )
    {
        //
        //    Update time and find out how much time
        //    has elapsed since last call to ::update
        //    
        //    Then add whatever was left over from last iteration.
        //

        _currentTime = realtime::now();
        
        float dt = _currentTime - _lastTime;
        _lastTime = _currentTime;

        float availableTime = dt + _timeRemainder;
        
        if ( availableTime < _time.interval )
        {
            _timeRemainder += dt;
        }
        else
        {
            float steps = availableTime / _time.interval;
            int numSteps = lrintf( steps );
            
            for ( int i=0; i < numSteps; i++ )
            {
                dispatchStep();
            }

            //
            //    Increment remainder
            //

            _timeRemainder = (steps - float( numSteps )) * _time.interval;
        }
        
        dispatchDisplay();
    }
    else
    {
        lerr << "DisplayDelegate::update - update shouldn't ever be called on a non-animating DisplayDelegate" << std::endl;
    }
}

void
DisplayDelegate::dispatchStep( void )
{
    _time.now += _time.interval;

    preStep( _time );
    step( _time );
    postStep( _time );
    
    _time.stepsExecuted++;        
}

void
DisplayDelegate::dispatchDisplay( void )
{
    glViewport( 0, 0, _contextSize.x, _contextSize.y );

    preDisplay( _time );
    display( _time );
    postDisplay( _time );
    
    _time.framesRendered++;
}

It's being called from an NSView subclass with a VBL-synced opengl view. I'm using an NSTimer set to (1/1000) time interval.

EDIT: I switched to a 0.0 time interval for giggles, since 1/1000 seemed arbitrary and dumb.
Quote this message in a reply
Moderator
Posts: 1,560
Joined: 2003.10
Post: #36
TomorrowPlusX Wrote:For me, and for the few computers I've tried this on, clicking on the text toggles them. The only thing I can imagine that's wrong is that for some reason the mouse position isn't being read correctly. The underline bar shows up when you mouse-over the text, right? And goes away when you mouse out? But nothing happens when you click? I've never seen that...

Same problem here. It underlines when I roll onto it, but doesn't respond to clicks. I tried clicking around the bottom part of the window in case the coordinates were vertically flipped, but no luck there (and it wouldn't even make sense, since it's detecting the bounds on mouseOver). MacBook Pro (early 2008), 10.5.7, GeForce 8600M GT
Quote this message in a reply
Sage
Posts: 1,199
Joined: 2004.10
Post: #37
What a shame. My GUI's no good at all!
Quote this message in a reply
Moderator
Posts: 3,579
Joined: 2003.06
Post: #38
TomorrowPlusX Wrote:EDIT: I switched to a 0.0 time interval for giggles, since 1/1000 seemed arbitrary and dumb.

Not to stray off-topic, because I know you're focusing on the issue at hand, but: According to Apple docs 1/1000 is one of the techniques recommended for that purpose. Also, after my own testing, switching to 0.0 yields 1 kHz regardless, so apparently that's what the timers are capped at. So yeah, I guess 0.0 makes no difference anyway. The only thing I'd stick to 1/1000 for is that if Apple for whatever reason decided to raise their internal cap to something higher, then 1 kHz works fine so why waste even more? (yeah, I know, like as if that's ever going to happen, but still, it's the thought that counts I guess...)

Don't forget to give displaylink a try instead, if the 1 kHz timer trick bugs you. displaylink seems to give me the same performance.
Quote this message in a reply
Sage
Posts: 1,199
Joined: 2004.10
Post: #39
ThemsAllTook Wrote:Same problem here. It underlines when I roll onto it, but doesn't respond to clicks. I tried clicking around the bottom part of the window in case the coordinates were vertically flipped, but no luck there (and it wouldn't even make sense, since it's detecting the bounds on mouseOver). MacBook Pro (early 2008), 10.5.7, GeForce 8600M GT

I was just at the gym, thinking about this and it occurred to me that you might be using an external mouse connected to your MBP? Is this the case?

I switched from normal NSEvent filtering for input a while back to DDHIDLib; but and large it's been a real boon, but I only handle the zeroth input device of each type. E.g., the first mouse of N mice. The first keyboard of N keyboards, etc.

It occurrs to me that that might be what's going on here. The external mouse is moving the single global mouse cursor -- so I get the mouse over effects correctly -- but the button events are keyed to mouse #1, not zero, so I never catch them.

EDIT: I was -- sort of -- able to reproduce by plugging in an external mouse. In my case, however, the external mouse works correctly but the trackpad's motion is processed but not the clicks. So, I'm guessing you can unplug the external mouse to make the buttons work correctly. Meanwhile, I'll experiment with a best way to handle this situation.

@AnotherJake -- I recall now that that's why I was using 1/1000 -- I generally comment my code well, but I really should mark the reasoning behind magic numbers. Also, I've considered displaylink, but I'm concerned that it's running in its own thread. I don't want to have to worry about synchronizing between a render thread and the general game loop.

(Of course, I might be wrong about display link being threaded, but that's what I gathered from examination of the docs )
Quote this message in a reply
Moderator
Posts: 3,579
Joined: 2003.06
Post: #40
TomorrowPlusX Wrote:Also, I've considered displaylink, but I'm concerned that it's running in its own thread. I don't want to have to worry about synchronizing between a render thread and the general game loop.

(Of course, I might be wrong about display link being threaded, but that's what I gathered from examination of the docs )

You might be right about displaylink being on another thread. My game update is usually completely separate so I didn't have issues while testing, and it's been so long since I tested it that I don't recall... and too lazy to check the docs right now Rasp
Quote this message in a reply
Sage
Posts: 1,199
Joined: 2004.10
Post: #41
Technically, rendering should be non-mutating so rendering in a dedicated thread should be fine.

But the trouble is that changes to game state -- such as a moving camera or moving entities -- would mutate the visibility set possibly while it's being iterated to render. And a million other things. So I've stayed shy of it...
Quote this message in a reply
Moderator
Posts: 3,579
Joined: 2003.06
Post: #42
That is very true. Definitely not a trivial task to keep everything synchronized correctly, and the stuff you've built up over the years is far more complex than what I've been doing graphically. There are only a few times when I've really seen multiple threads help anyway - physics being a good example (specifically the collision detection). But that's another subject for another day. Wink
Quote this message in a reply
Sage
Posts: 1,199
Joined: 2004.10
Post: #43
An interesting note -- per frogblast's suggestion to disable alpha testing. Obviously, I'd need to depth sort the foliage, if I wanted to draw this way. But, I'm still curious.

In the old days glAlphaTest sped things up since it meant fewer pixels were being touched. So why's it a big speedup now?
Quote this message in a reply
Sage
Posts: 1,199
Joined: 2004.10
Post: #44
An interesting performance detail I just noticed. It's not disabling alpha test specifically, but rather, commenting out setting of the glAlphaFunc per draw-call that's the culprit.

EDIT:
I take it back, it's having a non-zero test which causes the performance hit.

So, per draw call I set the alpha func threshold as such:

Code:
glAlphaFunc( GL_GREATER, lrp( _visibility, 1.0f, AlphaFuncMin ));

This ramps from 1.0 to 0.8 as visibility goes from 0->1 -- allowing for slightly smooth transition from as foliage enters the visibility radius. I noticed that setting the func to (GL_GREATER, 0) gives me a rock solid 30fps! Setting it to (GL_GREATER, 0.5) gives me performance like what I'm seeing.

Out of curiosity, I tried dropping GL_ALPHA_TEST for calling 'discard' in GLSL, but as expected, the performance was terrible.

So, what are my options? I don't know that I want to depth sort my foliage...
Quote this message in a reply
Member
Posts: 87
Joined: 2006.08
Post: #45
I'd be interested in seeing the Occlusion Query results. It might be possible to use discard/alpha test, but if you're just drawing Too Many Pixels, then you're next course of action is probably to try to coalesce far-away pieces of grass into a single quad, so you can draw multiple neighboring pieces of grass with as little overdraw as possible.
Quote this message in a reply
Post Reply