Compute shaders and arbitrary writes to texture memory

Is this possible? I can reference HLSL documentation where the RSFX documentation is lacking, though I'd need to know which version. If RSFX has custom syntax for this kind of shader work, I can't seem to find documentation for it.

Short Version

I need to know if ReShade FX supports the ability to write to an arbitrary texture location within a shader (I'm guessing, a compute shader).
Ideally, an interlocked add operation would be required, as multiple threads would write to the texture in parallel.
For example, imagine you wanted a shader that counts the number of pixels colored red, green or blue. For each pixel in the source texture: read its color, if it's red, increment the pixel in the destination 2x2 texture at position (0,0) by 1. If it's green, increment at (1,0). If its blue, increment at (0,1). Otherwise, increment at (1,1).
Multiple threads would be doing this, one thread per N pixels. The "read, increment, write" operation would need to be interlocked (meaning, one thread at a time) to prevent increments from being missed due to race conditions.

If interlocked operations are not possible, or are too slow, I can work around that.

Long Version

I'm writing a shader that creates a tiny light probe for each NxN block of the screen. For a given block, for each pixel in that block, the shader would look at the color and normal. It'd convert the normal direction to a write coordinate on the destination block of pixels (XYZ -> UV using some form of spherical projection). It'd then read the RGB values on the source color texture and increment the pixel values on the destination texture at the location UV by that amount.

To filter the probe values on the destination texture, I'd use mipmapping and use the alpha channel to determine the sample density. (I'm being breif about details.)

This requires being able to write to a given texture at arbitrary coordinates. If interlocked increment operations are not available or are not performant, I can write the compute shader so that 1 thread is assigned per block (this may be the faster way anyway).

The approach I'm taking assumes that the RGB and normal values contain information about lighting. Even though it also contains information about albedo, by averaging out samples taken from a large enough block of the screen, the texture information can be filtered out. Lighting tends to corelate more with normal direction, whereas albedo tends to corelate more with position.

Using the light probes, I can estimate lighting and albedo and separate them into two separate textures. This will help with implementing some physically based lighting techniques.

I'm not personally familiar with compute shaders, however I believe the answer to your question is that it's supported under graphics APIs that inherently support compute shaders (ie. won't work on DX9 or OpenGL). See here:

github.com/crosire/reshade-shaders/blob/slim/REFERENCE.md

Ah, I just had to read it a little more closely.

The bits of interest in there for your case are `storage` objects (equivalent to UAVs in HLSL), the `tex2Dstore` intrinsic and compute shader syntax/pass states.
Btw. compute shaders work just fine in OpenGL, only D3D9 and D3D10 are not supported.

Cool, didn't know compute shaders worked on OpenGL. Learn something new every day.

You can always use point-primitive vertex shader to write to a specific pixel. I have some shaders that implement that, but are commercial, like vectorscope monitor.