Hi folks,

Maybe you can help me understand how the GPU works a little better? I'm drawing a few million points in a 2d app (no perspective or z-buffer).

When rendering point primitives from a vertex buffer, somehow the points get drawn in the exact order they are in the VB? So if some points overlap, you are still guaranteed the same output every time?

If instead I render the points from a vertex texture, i.e. the vertex shader fetches from a uv coord that's some function of the SV_VERTEXID, are they still in guaranteed order?

But if I use a compute shader, loading points from a StructuredBuffer and writing manually to an output UAV, I assume all bets are off?

Any thoughts on why one of these 3 techniques should be fastest?

Thank you!

Glen.Able said:
somehow the points get drawn in the exact order they are in the VB?

yes, vb is an ordered stream sequence of verts

Glen.Able said:
So if some points overlap, you are still guaranteed the same output every time?

correct, if point P which is at vbuffer position7 and transformed by matrix M is repeated at position 50 in the same vbuffer and transformed by the same M, then yes it will have the same output; (that's why, for example, in OGL, if its internals can detect that some input is going to be the same output, it reuses the previous result instead of wasting time by running the same vshader on the same input)

Glen.Able said:
. the vertex shader fetches from a uv coord that's some function of the SV_VERTEXID, are they still in guaranteed order?

that's a good question actually… i don't know if u can use SVVERTEXID with VTFs (vertex texture fetches). Also, using SV_VERTEXID is not what guarantees order (this System Value only tells the IA stage to generate an ID for each vert). I don't know if vt fetches define a fetching order or if those fetches are ordered in the same way that are similar to the TIU (Texture Input Units) or Pixel Shader (texture fetches).

My guess would be that the fetching order here is guided by the texture coord generator (by the interpolator)…there's more to be said here…

Glen.Able said:
…I assume all bets are off?

-lol- well really it depends on various factors, if for example, you're really using the UAV for RW by multiple threads etc… then…

Glen.Able said:
Any thoughts on why one of these 3 techniques should be fastest?

(respectfully) i think that's not the right question to ask, they all have their use AND pros and cons. The worst u can do is to use anyone of them the “unrecommended” way, right?

Good questions !

A+ ?

Thanks for your thoughts!

The only implementation I've tried so far used the vertex id + vertex texture fetches approach like this…it worked fine:

VS_TO_PS VS(uint vid : SV_VERTEXID) {

// generate tex coords from vertex index

float u = (vid & 2047) / 2048.0f + 0.5f / 2048.0f;

float v = (vid >> 11) / 2048.0f + 0.5f / 2048.0f;

float4 pointPos = texSrc.SampleLevel(samp0, float2(u, v), 0);

…

}

I never noticed any of the flickering you might expect if it's not running deterministically (i.e. sometimes at some output pixel, point A gets rendered before point B, sometimes vice-versa) But once I started thinking about a compute shader implementation, that possibility occurred to me.

As you said, maybe not the right question, not least because rendering the points probably isn't the slow bit, and you can measure speed easily enough anyway!

ok, however with compute shaders, u could group-synch threads with barrier to synch vtf calculation outputs, it's a cheap op, but adds constraints to the warp scheduler (and could cause stalls) ; so then again back again to those pros and cons and trade-offs ?

anyway thanks for sharing ?

@mjp

well that's odd, in that link it states:

“This enables Order Independent Transparency (OIT) algorithms to work, which give much better rendering results when multiple transparent objects are in line with each other in a view.”

OIT works well and gives good transparency results without ROVs, so this statement is unclear… in other words, the authors of OIT did not need a ROV when they had a breakthrough… so why did anyone think that ROV was needed for OIT??

what am I missing ?

aaaah right ok, @mjp makes perfect sense now;

thanks for enlightning ?