Jump to content

  • Log In with Google      Sign In   
  • Create Account


noodleBowl

Member Since 08 Sep 2013
Offline Last Active Dec 24 2013 02:16 PM

Posts I've Made

In Topic: ActionScript 3, Timesteps, and the fixed time step

22 December 2013 - 09:58 PM

I just tried removing the interpolation, but unfortunatly while it stops the jittering when standing still. It does not solve the spikes of jitters while moving :(


In Topic: Good Performance test?

13 December 2013 - 08:51 PM

 

There are certain flush points that cause the GPU to perform all queued render commands. Clearing the bound buffer. Changing render targets. Presenting to the screen.
When these flushes are complete, any resources sent to the GPU until that point are no longer in use by the GPU.
If you are so worried about it, use triple-buffering or quadruple-buffering.
 

 

I was thinking that this would be the solution, also I assume the growable buffers would prevent this as well

 

Speaking of which, how do these work on a technical level? I understand you said they should grow when you run out of room.

But if I release it and then create a new one of the appropriate size I would assume its content is just gone. So then I guess this check has to be made from the start of a draw call right? So something like this

void SpriteBatcher::drawCall()
{
	//If the buffer is full
	if(currentBufferPosition + vertexperQuad > maxBufferSize)
	{
		unmapCurrentBuffers(); //Unmaps the buffers
		drawContent(); //Draws the data in the buffer [ DrawIndexed Call]
		
		releaseBufferAB(); //Releases buffer A and B
		
		constructBufferAB(currentSize + quadIncreaseAmount); //Recreate the vertex buffers A and B; With there new sizes
		switchBuffer(); //Changes the current buffer to the next Buffer that should be used
		
                currentBufferPosition = 0; //Reset the buffer position
		mapCurrentBuffer(); //maps the current buffer; Uses NO OVERWRiTE FLAG
                

	}
	
	/* Code to place the data into the Current Buffer; Increase the current buffer position*/
}

Also when using Dynamic buffers the map flag must be DISCARD or NO OVERWRITE. If I choose to use double buffers and with that in mind I should (or will have to) always use the NO OVERWRITE flag right? Seeing as using DISCARD would defeat the purpose of the double buffer technique


In Topic: Good Performance test?

12 December 2013 - 11:00 PM

 

If so how does this not create the issue where I'm writing to the buffer, send it to the GPU, and then I start writing to the buffer again before it is ready?

I don’t know how else I can explain what I have already explained before.
You aren’t writing to it while it is in use by the GPU. You are writing to the other buffer while it is in use by the GPU. Hence the term: Double Buffer.
If you have further questions on what double-buffering is and how it works there are plenty of resources on Google (rather on the Internet; Google just helps you find them).

 

I should explain myself a little better. I understand that the double buffer is supposed to mitigate the GPU stalls, but I guess what I'm trying to get at is. Since the GPU and CPU are asynchronous, how well does double buffering essentially guarantee that the GPU won’t stall?

 

Let just say that my CPU is going so fast around that the GPU just cannot keep up. Even when using double buffers.

The CPU will keep going, where I assume the GPU will start using ‘invalid’ data at some point right?

 

So I'm assuming, because the chance is so small that the above will happen and the fact that you will already have an exact needed size

(The buffers will always have enough room to hold everything) those are the major benefits over the DISCARD / OVERWRITE method.

 

Although that maybe the case, is the DISCARD/OVERWRITE method not safer or is it that safety does not come at a great price?


In Topic: Good Performance test?

11 December 2013 - 10:09 PM

 

Does the DISCARD flag not give me a new location in memory to use or am I thinking of this wrong?

Even if so, that means an extra allocation and free by the driver, which is a costly operation.

 

Even though that might be and I'm sure it is, because it makes tons of sense that the GPU would need to allocate more memory. But isn't that what the DISCARD flag and the use of Dynamic buffer is designed for?

 

 

 

But what I am a little confused about is, are you saying to only use the DISCARD flag. Does this not defeat the purpose of using a dynamic buffer and reusing buffer slots with NO OVERWRITE?

You still need the buffers to be D3D11_USAGE_DYNAMIC and update with D3D11_MAP_WRITE on the buffer that is not being used by the GPU.

 

 

I assume I need to be at the beginning of my buffer in order to use D3D11_MAP_WRITE correctly, also that this will always no matter what, overwrite the content in the buffers. Right?
 

If so how does this not create the issue where I'm writing to the buffer, send it to the GPU, and then I start writing to the buffer again before it is ready? Or does calling DrawIndexed send everything off to the GPU and the buffers get "flushed" in the sense that it does not matter if I overwrite the content because the GPU gets a copy or etc to use

 


In Topic: Good Performance test?

09 December 2013 - 10:43 PM

I got so many questions

 

 

For on you are potentially updating a vertex buffer/index buffer while still in use by the GPU (if the buffer is full).

 

Can you explain this a little more? I don't understand how I can potentially be updating while the GPU is still in use.

Does the DISCARD flag not give me a new location in memory to use or am I thinking of this wrong?

 

 

Use double-buffering and growable vertex buffers. Do work on buffer A, present, next frame work on buffer B, present, back to A. If you run out of room in the vertex buffer, just grow it. It will only be slow for a little bit at the start, if even that (perhaps growing once is enough).

 

What exactly do you mean by a growable vertex buffer? Also does this mean you are saying to DISCARD on every frame?

 

Also I only half understand the A then B buffer update. How does this exactly save bandwidth, how does it work?

It seems like I would stall on the GPU somewhere

 

 


Secondly, avoid all that memory-copying.
First you generate data, copy it into a vector, then map the vertex buffers and copy from the vector into there.
The routine should be:

batcher->beginBatch(); // Calls Map() internally.
for(int i = 0; i < 10000; i++)
{
     // Places a quad directly into the mapped pointer.
     batcher->draw((rand()%700) + 10, (rand()%500) + 10, 32.0f, 32.0f);
}
batcher->endBatch(); // Unmaps.
batcher->draw(); // Draws.
Thirdly, if you use double-buffering and start from the beginning of the buffer on each frame, you no longer need to update your index buffer at all, as each time it would be writing the same values into itself.

 

 

This part definitely needs to happen, this is my main bottleneck for sure.

 

But what I am a little confused about is, are you saying to only use the DISCARD flag. Does this not defeat the purpose of using a dynamic buffer and reusing buffer slots with NO OVERWRITE? I also assume, I do not need to check if I hit my MaxBufferSize because this is where the growable buffer would fall in right?


PARTNERS