Unless the kernel is misconfiguring hardware, I’m really unsure how corrupted memory transactions can be a software problem, especially when it happens with two completely different userspace driver stacks.
(In terms of glmark2-es2 scores, I have gotten as high as 2958 with Wayland compositors, it is less a benchmark of performance than of the per-frame compositor overhead.)
Here is a “screenshot” of a corrupted FBO rescued using the kernel debugger, with a 32x32 grid overlaid:
So although the MMU table corruption does not appear in RAM, this does, suggesting that the problem can happen with both read and write transfers. However, it could just be that the corruption happens when reading the source texture for the blit into GPU memory, so I am not absolutely sure about this yet.
I wonder if the problem only happens with one of the two DRAM chips, that could explain why (in this case) only the green and alpha bytes are affected, and red and blue are correct.
I hypothesise that the problem can only result in bits being set to zero when they shouldn’t be, this would explain why the kernel (which lives at the bottom of phsyical memory) is so often corrupted.