Jason Z

It totally depends on what you want to do with your rendering code.  The best way to structure your code is to make it flexible so you can choose the right tool for the job at hand.  My engine allows for both of the mechanisms that you mentioned, but in my case each object carries around its own material information.  The 'state manager' then ensures that there aren't multiple API calls made to set the same data more than once.

 

The latter of your two ideas is usually called an immediate renderer or something similar.  It is generally a higher level object that simplifies the usage of the graphics hardware at the cost of performance.

The random number can be obtained by having a 'random' texture and applying an offset to the texture coordinates used to look it up based on time.  So over time the random value supplied to each pixel will change.  You can then determine what size of texture works best for you, and how fast the offset should wrap around.

 

As long as you are capable to get a draw call that can be used to select the appropriate pixels to get executed in the pixel shader, you should be able to use this technique to add or reinitialize particles.

Hi Tiago,

 

I found out that it is indeed not possible to do the pixel history when a pipeline configuration uses SV_InstanceID, SV_PrimitiveID, or SV_VertexID.  This is due to the fact that these are generated on the GPU rather than by the driver, complicating the ability to recreate the pixel history.  Apparently PIX had the same issue, although nobody was sure if it has been documented prior to this.

 

That's probably not the answer you wanted to hear, but at least you know what to expect in these three cases now.  I hope that helps...

That is typically only needed for objects which have transparency (or use blending in your case).

 

EDIT: There is actually an algorithm called "Order Independent Transparency", but it is a very heavyweight algorithm for doing simple sprite rendering.  Still, it might give some insight into the problem if you read up about on the topic.

If you are fixed on OpenGL, you can safely disregard this option

 

Hieroglyph 3 is an open source engine that makes it possible to add new effects / rendering techniques relatively easily - but it uses Direct3D 11.  There is a number of different effects already available (deferred rendering, light prepass, tessellated terrain surface, water rendering, voxel texture rendering, etc...), which can be used as a guide for implementing something totally new.  There is a small community and moderately active discussions, so if you have questions there is help not too far away.

 

In full disclosure, it is my library... but I still think it may be able to help you with your testing.

Are you sure that this isn't how it's supposed to look?

Are you asking a question, or telling us that your implementation is correct?  It isn't clear to me (or anyone else I think) what your motive is for writing this thread.  If there is something about your results that seem wrong to you, then please ask about it.  If this is a thread for you to demonstrate your implementation, then put that in the description.

 

So far, I haven't seen you really ask any substantive questions - please help us to understand what you want.

One difference between structured and non-structured is that you can use some of the additional features on structured buffers, such as the structure count for append/consume buffers.  Otherwise I don't think is much performance difference between the two if you use them in the same manner.

 

In the case where you listed two separate buffers to replace a structured buffer, I would expect worse performance with two separate buffers due to cache misses.  However, things like that are so variable that it could easily be the opposite case, depending on the GPU and driver and usage conditions and...

You're probably thrashing the texture cache. Texture samples close to each other (in the texture) in adjacent pixels will be much cheaper than texture samples far away from each other.

 

Ok, so I'm going to try to convert the random texture to DXT-format. Still, after what you explained about the one is cheaper than the other distance, why could this huge hit then happen at the random noise texture, thats always getting sampled the same, regardeless of distance?

That is the real question here, and I doubt that you will find an answer using nSight (although I could be wrong - its been known to happen from time to time ;) ).  Your shader has been run in another engine, with the same results - a slowdown when close to the scene and speeds up when farther away.  So one part of your SSAO shader is behaving differently when the position is close up - we need to find out which part is doing it.  And as far as I know, nSight won't help us find the performance issue within the shader itself...  Again, I might be wrong, but if it is that simple, I would love to hear from someone with some experience using it (and if you could plop the original posted shader in and try it out).

 

The SSAO shader is more or less split into a couple of small parts that get executed several times with some jitter applied to randomize the results.  Start taking away portions of the shader until you either get your performance to be stable or there is nothing left.  It is only in an exploratory manner, so make sure you keep some backup copy of the file.  I still would like to know if you tried eliminating the randomization - either use fixed offsets, or make your random function return a constant.

 

Also, I just wanted to make sure about one thing - when you are running your shader, are you running on a release build outside of the visual studio IDE?

This is an interesting problem - I don't see any dependency on the depth in your shader that would trigger significantly different sampling patterns (or calculation patterns) based solely on the depth of the current pixel.  Maybe there is something to do with the way you calculate your random vector?  Can you try to fake out your random function to just return a constant instead of sampling a texture?  I'm really shooting from the hip here though - I just don't see anything obvious to try to hammer down...

The most likely reason that performance changes in SSAO when objects are close in view is due to texture cache thrashing.  That would come from the sample offsets being effectively larger in texture space since it is closer to the camera location.  However, it looks like you are using a texture space sampling offset, so that probably isn't your problem.

 

Since you are using a texture space offsets, there should be no difference in the time needed for SSAO before and after the scene is filled.  You are most likely running into a bottleneck with your other code running sequentially with the SSAO pass.  Can you try to render your input data to the SSAO algorithm, then keep those buffers unmodified and see what the performance is like?

 

My guess would be that you are texture bandwidth bound, due to the gbuffer generation, sampling, and the SSAO sampling process.  That's lots of reads and writes... especially at high resolutions, so if you can cut down on the GBuffer size or otherwise save some bandwidth, that will probably help out.

 

Also, there was a few presentations (from NVidia I think) about rendering the occlusion buffer at a 1/4 scale, then doing a bilateral up-sample pass to scale it up to the full resolution size.  So that is an option, but I'm pretty sure you can improve things without having to resort to something like that.

It looks to me like the texcoords are stuck at a particular value, causing it to look like the texture is stretched across the whole model.  Have you tried loading a simpler model yet?  I would start out with something like a square or cube, where you can assign known values to each vertex.  Then when you load the model through AssImp, you can inspect the results and ensure that everything was properly read in and interpreted.

In case you are interested in more details about how the technique works, you can take a look here.  There is descriptions for sphere mapping, cube mapping, and dual paraboloid mapping too, all of them as single pass techniques.

Do you have specific questions about how it works?

That's why I'm asking you if you have any specific questions about how it works!  That is also why I listed the process in steps, so that you can direct questions about a particular portion of the process.  You need to think about each step, and ask us a question about it - there are many people here willing to help, but I doubt anyone is going to just write the shader for you and say here is your solution.

 

If you have absolutely no idea what those process steps mean, then ask a question about them, don't ask for a code example showing it.

With even, the higher tesselation starts only with factors > 2 it seems. So for your plateaus a odd makes more sense. Shouldn't make a difference with very high tesselation, though.

That's actually the definition of the even/odd partitioning modes.  Even rounds to even factors while odd rounds to odd factors.  So for even, you end up with a factor in the 2, 4, 6, 8, ..., 64 range, while for odd you get 1, 3, 5, ..., 63.  If you take this into account when designing the algorithm that produces the tessellation factors, then you will be in good shape and can set the minimums accordingly to ensure you get at least a little bit of tessellation.

 

The same can be said for the other two types (integer and pow2) as they just define the "steps" in your tessellation factors.

Ok, I have that squared away and I'm back in business! My algorithm works great, I just have to tweak it so that both low detail and high detail aren't so quick to appear. I can handle that.

 

After this I'll need to see some performance info of some kind, so I need to print text. I'll open a new thread for that. My research on that topic has given me some conflicting info.

Nice job sticking to it - so where is the obligatory screen shot showing us the low and high res triangles all at once???