5

After more analysis, the TL;DR here is that, yes, the slowdown is due to memory locality, and yes the pixel order is to blame. More interestingly, by writing the shader differently, we can greatly surpass the fragment shader's performance—though we obviously shouldn't rely on being able to do that regularly. First, to expand on the analysis: the best way ...


4

In general, you should not see significant performance differences running identical compute shaders via one API vs. another; in the end they’re running the same instructions on the same hardware. It’s possible for vendor-provided toolkits like CUDA or MetalPerformanceShaders to have more efficient implementations of a given algorithm on that vendor’s ...


3

well, if anyone is stumbling across this and needs to know what solved it for me: We can bind a compute buffer to global shader memory if we just know what exactly we need to do within the Compute shader the RWstructuredBuffer is declared as (without the "\" infront of float): uniform RWStructuredBuffer<\float3> buffer : register(u1); (not certain ...


3

GLSL has no mechanism to change the "size" of shared memory. Indeed, GLSL is structurally incapable of such a thing. You can't get a pointer to shared memory. Indeed, "shared memory" doesn't really exist in GLSL; there are only shared variables. And variables have a compile-time fixed size. So GLSL wouldn't even have a good way of ...


2

Broadly speaking, no, these won't really matter. In specific cases, it could, but only because it might influence the order in which work groups are processed. And that would mean that it might influence cache behavior and the like, which could matter if neighboring work groups access related memories. But even in such a case, which one is better would ...


2

If you could use imageLoad/Store to do atomic operations, there would be no need for atomic operations as a distinct class of operations. So no, you can't. There is no correct set of barriers or other properties that will allow this to work generally the way atomic operations do.


1

If there is no such function, why have noone made an extension for this yet? Just because something might be "useful" doesn't mean it would be possible or cheap. GPU hardware achieves blending by using an entirely separate piece of hardware, one that preserves the order of the fragment values generated by unordered fragment shader executions. ...


1

It appears that this is indeed a bug within renderdoc. I have encountered the bug I was debugging for in only 1 model, while all the others work fine. In every instance of using the renderdoc debugger, I get the same problem though.


1

Do I could get event better perf by making it a compile-time constant ? You'll have to profile it. That being said, "a few hundreds mat4" is not "small". I have trouble understanding what could be the best value for the 'usage' parameters of the buffer. All buffers being written to and read several time, I'm not sure what to put here. ...


1

My question is, though i am aware cos() and sin() is fast, how do they compare to simply getting the value precomputed in a buffer instead? This will depend on your shader code and GPU model. GPUs utilize latency hiding by executing independent ALU instructions while waiting for data to arrive from memory. Accessing memory is usually the slowest operation ...


Only top voted, non community-wiki answers of a minimum length are eligible