Good catch. OP should probably update the article
Fantastic seeing the author lay out all the steps involved in getting a renderdoc capture of a browser and what's involved in debugging shader issues in a webpage.
It's interesting that the issue only manifested on the geforce 40xx if it was an fxc issue though... wonder if it's fxc combined with a driver issue and not just one or the other?
TL;DR: don't expect that floating point operations on GPUs are strictly IEEE-754 compatible
Historically graphics programming has been more concerned with looking good rather than being accurate, and behavior is likely different on each GPU. It's a "hop into the water and learn to swim" kind of thing as far as I'm concerned. You will find errors for things you'll never have thought about and there is hardly any way to brace for it except trying on the go.
It looks like the LLM hallucinated a diagnosis of a miscompilation based on which fix worked. I would not treat its claim as accurate without further investigation.
Edit: Read the rest of the article and it looks like further investigation was performed, and it had nothing to do with the GPU driver after all. Good stuff.
On the contrary, WebGL2 is probably the only 3D API that comes even close to the idea of "write once, run everywhere".
I haven't worked with opengl/shaders in a while, but was thinking about some algorithm I wrote a few years ago, while in shower yesterday. It brought back the memories of how difficult it was for me to first understand the whole concept of shaders. There's basically no main function, no for loops etc. Your shader is called for each pixel, for every frame. I was wondering how easy it would have been in today's world. I spent like 2 months on something that is just a prompt now.
And there are for loops- and if statements, and function declarations, etc. It's very c-like without dynamic memory allocation and executed in a highly parallel context.
Your shader is also not necessarily called every frame, you control this. It could be called multiple times per frame or only at certain times.
Fragment shaders (one type of shader) is called for each fragment of the rendered geometry - in 2D or in screen space this is just a quad so effectively a panel of pixels.
You get to know your own location with something like UV or a pixel coordinate if you pass it from a vertex shader, so that you can sample input textures as needed to build whatever it is you're building.
If you're not doing multiple render targets, your only responsibility is setting to the fragment color variable which will be the final color of that pixel for the output texture.
And that could in turn be the input to another shader etc.
I usually recommend https://thebookofshaders.com/
It's very sad this was never completed. It's so good.
To be honest, there have always been copy-paste programmers, LLMs just reduced the friction.
[1] Better than me anyway.
E.g. floating point behaviour is only the tip of the iceberg. Every GPU vendor also does mipmapping differently (to balance image quality versus required memory bandwidth).