It was. M16 mode also allows for a color overlay with 255 color palette entries in addition to the 16 bit grayscale/luminance. This is what displays the blue text, colorful words and drifting red gradient.
Sound like alpha-blending works fine, and rendering in general. Probably some problem on the display hw side.
Yes you need the update-grub before the reboot for changes to take effect. Indeed you will need this both for testing if that artifact goes away, and to make your new RX 6600 work at all. The old display path no longer exists for anything more modern than Polaris, so all you’d get with your new cards would be a black screen.
After a couple of hours of detective work and combing through kernel code, I have tracked down the change in Linux 5.14 and later that causes the problem. Ironically it was a change I made myself early 2021, to appear first in Linux 5.14, when implementing the new 16 bit high color precision framebuffer support for AMD graphics cards that allows PTB up to 12 bpc per color channel color output on regular 8 bit (dithered over DP, HDMI, DVI), 10 bit (dithered over DP, HDMI) and 12 bit (native over DP, HDMI) displays without the need for more expensive stimulators from CRS or VPixx. While the change causes no problems for the DCN-1 display engine, and hopefully also not for all later DCN’s (RX 6600 has a DCN-3), It seems to trigger some hardware design flaw on Polaris DCE-11.2. We had also problems with older AMD’s DCE-11.0, DCE-8.x which we fixed, but Polaris seemed to have no problem. I assume now that the change affects all DCE engines, also Vega graphics cards, although this is untested. I guess i missed this one during my testing, which was impaired and difficult due to Covid related lab lockdowns and lack of access to some equipment and severe lack of time due to lack of proper funding.
Anyway, I developed a one-line fix and tested it yesterday over 6 hours with a CRS Bits# and a ColorCal-2, which seems to successfully fix identity pixel passthrough for CRS and VPixx devices, while retaining the 12 bpc color precision, as tested on a consumer HDR monitor with 10 bit native + 2 bit dithered ~ 12 bpc precision, as the ColorCal-2 confirms. Ofc. i can’t test the full intensity range as that would need a more controlled environment and dozens of hours for a single photometer run, but spot-testing a representative small fraction showed linear response and 12 bpc precision, so this is as good as it gets.
Next step is cleaning up and submitting that fix to upstream for inclusion into a future Linux kernel. If all goes well then the bug fix should bubble back within a few weeks to months of time delay into a bug fix release of the Linux 5.15-LTS kernel of Ubuntu 22.04-LTS and the problem should go away, hopefully without causing new problems.
Ofc. that means we are out another 10 hours of work for the benefit of CRS and VPixx customers, almost all of which do not support us financially at all.
So from my perspective it wouldn’t hurt to know from you as an independent source if a kernel downgrade to Linux 5.13 solves your problem, but i’m pretty confident it should according to my own testing on Linux 5.13 + Polaris - unless there are other weird problems related to your specific model of Polaris. But the long-term solution for users of Vega, Polaris and older AMD gpu’s in combination with CRS or VPixx visual stimulators on Ubuntu 22.04-LTS will be that proper bug fix – fingers crossed.
If you would run into problems with your new RX6600’s there would be little i could do. I assume they are as well behaved as my DCN-1 RavenRidge wrt. CRS/VPixx equipment, but if not, i’d have to buy such a card myself, and new 1000 Euro class PC, as my current machine would be unable to use such a card, and we’d be talking about thousands of euros having to be paid for material costs and setup time in addition to actual troubleshooting.
-mario