Source

Branch

1/ @AgileJebrim

@NOTimothyLottes

Humor me… have you tried entering in atomicAdd(adr,lane==0?v:0)? How bad is it relative to the rest?

2/ @NOTimothyLottes

@AgileJebrim

You cannot get that behavior because the driver will “fix” it for you. There had been so many bad programmers not predicating atomics that the IHVs had been forced to workaround (too the expense of everyone who had optimized correctly)

3/ @AgileJebrim

@NOTimothyLottes

The driver is going to replace my code to what?

4/ @AgileJebrim

@NOTimothyLottes

This is why I said humor me. I’m frankly curious to see what performance it’ll get on your test suite. Just try it.

5/ @NOTimothyLottes

@AgileJebrim

110% if dividing by the type of the prior worst. So it’s a bunch slower than the prior worst case. But I don’t have NV’s disassembly, so not sure exactly what it did under the hood.

6/ @NOTimothyLottes

@AgileJebrim

If we look at AMD disassembly for atomicAdd’ing “gl_LocalInvocationID.x==0?256:0” you will see the AMD driver do a wave-op ADD reduction (highlighted) and I’d suspect the same from NVIDIA. Note the atomic at the end of the shader uses my trick (and sums the runtime).

7/ @AgileJebrim

@NOTimothyLottes

Even though it knows it’s 0 it’ll still waste time reducing? Lame.

8/ @NOTimothyLottes

@AgileJebrim

There have traditionally been a lot of driver workarounds in this area (like using ballot and bitcount if the adder is 1, etc). And I remember as far back as being at NV (so more than a decade ago) and having this same problem of NV drivers breaking perf of pre-optimized shaders.

9/ @NOTimothyLottes

@AgileJebrim

I do find it interesting that it took me a decade to figure out a proper good workaround. So yeah, I’m the “idiot” too. But I’m one workaround less of an idiot this week, which is progress.

10/ @AgileJebrim

@NOTimothyLottes

It’d be nice if there were a way to configure the optimizer settings like you can do with many compilers.