Jump to content

  • Log In with Google      Sign In   
  • Create Account

jujumbura

Member Since 08 Aug 2005
Offline Last Active Oct 27 2015 10:02 PM

Posts I've Made

In Topic: Data Flow Between Systems

02 September 2015 - 07:01 AM

Thanks guys,

 

I am going with the assumption that I should duplicate the data, for the reasons you describe Sean.  But my problem is the data needs to be in different orders for different systems, so when I duplicate it I end up having to jump all over memory to reorder it ( it's never a linear memcpy ).  I think that's probably inevitable, and I am trying to consider the best way to do it.

 

@Waterlimon - That's an interesting thought, regarding keeping it sorted over multiple frames.  However, although it's true that the order is unlikely to change, the data itself almost certainly will ( assuming these are all dynamic objects ), so I still need to re-write data into the sorted "slots" each frame.  I can cache the sorted index to avoid running the algorithm, but that's almost identical to the second method I was discussing ( which never actually entails a sort ).  Unless I am misunderstanding your suggestion?


In Topic: Display Loop with Win32

01 December 2013 - 12:39 PM

Think I found my problem!

 

In my display() function, I was calling glGetUniformLocation() for the projection, world and texture locations.  That seems to be what blocks, not glBindBuffers() ( I had been overlooking that in the profile region ).

 

If I instead cache the uniform locations on init after linking the shader, I no longer stall in my display() function.  Now SwapBuffers() is what takes the 16.6 ms as expected.

 

I am a little surprised that getting the uniform location would block like that, but maybe it's documented somewhere...?


In Topic: Display Loop with Win32

01 December 2013 - 10:21 AM

Thank you Spiro, that clarification helps a lot.

 

The only thing that doesn't make sense then is the profiling I am doing.  I built a little profiling class using QueryPerformanceCounter(), and I am using it to record time taken for blocks of code.  My loop looks like this:

while(!done)									
{
    if (PeekMessage(&msg,NULL,0,0,PM_REMOVE))
    {
        if (msg.message==WM_QUIT)
        {
            done=TRUE;							
        }
        else									
        {
            TranslateMessage(&msg);	
	    DispatchMessage(&msg);		
        }
    }
    else
    {
			
        display();

        SwapBuffers(hDC);
			
    }
}

Now I have a start/stop timer block around the display() function and the SwapBuffers() function.  If the main thread wait occurs inside SwapBuffers(), I would expect that the SwapBuffers() timer would take around 16 ms ( as my scene is very light, just two quads being drawn ).  But from my numbers, the SwapBuffers() call takes almost no time and the display() call takes around 16.6 ms.  That's why it seemed like something in my display() function was blocking, which lead me to glBindBuffers().

 

But maybe I have an error in my timer class, or I am making an invalid assumption here?


In Topic: Display Loop with Win32

01 December 2013 - 12:18 AM

Alright, dug a little deeper:

 

I did some more timing to see where the block occurs in my display function.  It's not in glClear(), glUseProgram(), or any glUniform...() calls.  It appears that the wait happens when I call glBindBuffer() to activate my vertex data.

 

This to me sounds like the buffer resource is being locked internally while the GPU is using it to render.  This is actually undesirable for me, as I definitely want to be able to start writing draw commands for my current frame while the GPU is working on the last frame.  If I'm right about this, is there any way to avoid the stall?  Since I don't need to modify that data, it seems like there ought to be a way to use it for rendering without trying to lock it...


In Topic: Display Loop with Win32

30 November 2013 - 07:38 PM

Well, it's not that I want to control the VSYNC itself, its that I want to control when my thread is blocked by it ( or at least know exactly when it is going to occur ).  And that's the funny thing; I assumed it would occur on SwapBuffers, but it seems like it's actually happening somewhere in the OpenGL calls based on my profiling.  Really I just need to know what function is going to block as that will affect how I synchronize with other systems in the simulation.


PARTNERS