Newer generations of DRAM (both GDDRx and the DDRx used in desktops and servers) are dense enough that they need on-die ECC. But that only offers some protection for data at rest, while the traditional kind of ECC involves also transmitting extra bits in order to also protect against transmission errors, providing end-to-end data protection. I don't think Nvidia has started allowing the latter kind of ECC to be enabled on consumer products.
That surprises me because memory corruption in something like texture-memory for game world rendering is far-less important than memory corruption in shader program memory. GPU memory needs to be fast, and ECC can slow it down - and add cost. So if they were going to use ECC in gaming GPUs I’d expect it to be limited to areas reserved for shader programs and “program state” rather than output texture memory. If all of VRAM is ECC backed then I’m wowed and kudos to NVIDIA for doing that.
ECC slows down RAM however RAM speeds are starting to become bounded by error rates. To push into the faster timings ECC actually becomes essential to keep the system from becoming unstable.
This is the reason why DDR5 is so much faster despite using ECC effectively by default.
For GPUs, it's not just the RAM timings and clock speeds that matter. The way they implement ECC also directly subtracts from the effective memory bus width and therefore the total bandwidth.
This is true for off-die ECC (i.e the kind that computes ECC between chips using a separate chip) however on-die ECC (the ECC logic and parity memory being included in the memory chip itself) like what DDR5 will have doesn't have this bandwidth issue. It causes the dies to cost slightly more but otherwise largely results in the same performance as non-ECC memory.
In the GPU space, this is why HBM2 memory doesn't really have a performance difference between ECC and non-ECC memory.
