1
$\begingroup$

What I want is a function like imageStore, but instead of replacing a value - applying a blend operation to it, e.g. addition. It is not possible to do something like this with atomics due to them only operating on 32bit integers.

If there is no such function, why have noone made an extension for this yet? It seems rather useful for compute shader lighting, and some post-processing effects.

$\endgroup$

2 Answers 2

1
$\begingroup$

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. These execution units, commonly called "ROPs", are distinct hardware from fragment shaders.

CS's can't just do that. They have a fundamentally unordered execution model, and what you're talking about requires at least some ordering between them. That's not simple or cheap to implement, even if it's possible at all.

The closest you can get to that is fragment_shader_interlock, which can force parts of FS execution to be ordered by primitive order and to execute critical sections that prevent overlapping executions. But as the name suggests, that's a feature of fragment shaders (and not one universally supported), not a feature of compute shaders.

Also, it doesn't really make sense to use a compute shader for post-processing effects, since FS's are perfectly capable of dealing with that sort of thing, and actually have access to ROPs.

$\endgroup$
1
  • 2
    $\begingroup$ BTW, it can make sense to use a compute shader for postprocessing in some cases, e.g. if it's an algorithm that can take advantage of threadgroup shared memory, or if it's beneficial to use async compute to overlap postprocessing work with something else. $\endgroup$ Mar 14, 2021 at 18:41
0
$\begingroup$

You can always just do an image load, apply whatever math you want to the value, and then store it back out. This only works if you can ensure multiple CS invocations aren't trying to modify the same pixel—otherwise you get a race condition—but that limitation is fine for most lighting and postprocessing applications, where you're running a single CS dispatch across a whole framebuffer (or some tiles within a framebuffer), with one invocation per pixel.

$\endgroup$
1
  • $\begingroup$ "This only works if you can ensure multiple CS invocations aren't trying to modify the same pixel" It's not just modifying the same pixel; you can't read any pixel that another invocation writes to. So you'd have to write to a different image or different region of the image. $\endgroup$ Mar 14, 2021 at 18:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.