The thing that caused me to ragequit the AMD ecosystem was when I took an OpenCL program I had been fighting for two days straight and ran it on my buddy's Nvidia system in hopes of getting an error message that might point me in the right direction. Instead, the program just ran, and it ran much faster, even though the nvidia card was theoretically slower.
In terms of quality, I expect the competition to catch up in a generation or two, but then there is still the decade+ of legacy code to consider. Hopefully with how fast AI/ML churns that isn't actually an insurmountable obstacle.
>>> struct.pack('f',math.nan)
b'\x00\x00\xc0\x7f'
maybe that becomes green if you composite over white or something? Or maybe there is a common type of NaN that fills some of the unspecified bits? ("Just use the particular NaN that makes it green" is cheating unless you have an excuse)It was a nice way to debug tensors: render them to the screen, the green sticks out.
https://encycolorpedia.com/76b900 says Nvidia green #76b900.
[Edit] Could not find it under the name, but it shows how color blind users perceive it. And it loads much faster.
https://www.colorhexa.com/76b900
[Edit] Encycolorpedia has a color blindness simulator too. Have to check on desktop.
Where both the sign (s) and the x bits can be anything and it will still be treated as a NaN.
There are lots of ways to encode colour, but there would be too much red with RGBA, and ARGB could be almost any opaque colour, but the red channel has to be at least 0x80, which is still too much red.
So NaNs are too red to encode nvidia green.
Wonder what caused the difference in the latter bits being all 1 or 0 together.