Can’t hurt to try. @bigretrofan when did the issue present itself for you, might be easier to track down a working driver. Unless a Windows update caused the issue as you alluded to.
Already tried linux and the shader works perfectly. Didn’t try the proprietary AMD driver though
Update: and to reiterate; this is a vulkan/opengl issue. No problems with dx11/12
In recent times I’ve actually been using DX11/12 in RetroArch you know due to the ability to enable Hard GPU Sync via Waitable Swapchain and setting Max Frame Latency to 1.
I don’t get these options when using Vulkan. Instead the lowest I’m able to set Max Swapchain Images to is 2, so unless I’m missing something, DX11/12 is currently able to achieve lower latency than the generally regarded as superior Vulkan?
I don’t seem to notice a difference switching back and forth between video driver APIs though. Some have stated that it’s possible to switch Hard GPU Sync On manually for Vulkan.
Well I haven’t seen that option in the RetroArch menu in many years but it can be added to the config file. Not sure if it actually still works. I tried adding it but the menu options never changed to what was available in DX11/12.
Hopefully someone more knowledgeable about this can confirm or deny whether or not there exists a potential 1 frame latency advantage by using DX11/12 over Vulkan in RetroArch currently.
So what I’m saying in a nutshell is that there may be some positive side effects if you have to settle for DX11/12 in the meantime as a workaround.
One con that I could remember was that Mega Bezel took much longer to load using either DX11/12 vs Vulkan. I’m can’t remember if that was ever resolved.
I thought vulkan already benefited from Hard GPU Sync hence the setting wasn’t required, but it’s been a few years since I looked into it.
I’d be interested to know about any frame latency differences.
I’m not averse to DX. I did see a delay in loading heavy shaders when I used them, but not with megatron. But some cores force a specific video drivers e.g scummvm forces opengl so I wouldn’t be able to use aperture there. I’m not really averse to using dot/slot mask with certain cores either, but I’d like to see ths issue fixed, as niche as it is.
UPDATE: I’ve found an amd driver which works: 24.5.1 with vulkan 2.0.299 from May 2024, although I might just live with the compromises rather than running an older driver…
This is great and the first step towards resolving the issue permanently. The next might be to try to find the specific driver in which the problem started.
You can probably report it to AMD as well as the RetroArch dev team.
I’m not sure if you already did but can you restate the exact “Display’s Resolution”, “Display’s Subpixel Layout” and “CRT Resolution (TVL)” settings where the issue is occurring?
From this, I can look at the Subpixel Mask Layout to confirm if it is correct and we can also use this information to try the same Subpixel Mask Layout in another shader like CRT-Guest-Advanced to help eliminate the shader as also having an issue which might be contributing to the problem.
By the way, are you the same @Wilch who used to post here in the early days of Sony Megatron Colour Video Monitor when it was now getting proper WOLED support?
Looks like 24.5.1 was the last good driver then 24.6.1 introduced the regression. It was the first driver to include vulkan version 2.0.302.
Exact display res: 3840x2160.
Display’s Subpixel Layout: RWBG (not RGBW which I mistakenly said above).
CRT Resolution (TVL): Issue occurs in all with differences (300 & 600 tvl show a red image, 800 tvl shows blue and 900 tvl shows magenta).
RGB and RWBG mask subpixels tested with no difference.
Which mask in guest advanced would be the most similar?
Yep, same Wilch. I used to sign in using my github account, but lost access!
Usually those kind of issues are due to gray documented areas, where the driver can act as it pleases.
And even if it isn’t, Retroarch is not that important to make amd invest resources to fix specific (like to be) bugs.
The best bet is to try to fix it by modifying the shader bits triggering it.
These are the Subpixel Layouts of the Sony Megatron Colour Video Monitor 4K Masks. I can get CRT-Guest-Advance’s Mask Layouts but at a later time. Maybe @nesguy or someone else’ who knows can follow up in the meantime.
Off the bat I can tell you that RRGGBBX is Mask 12, RGBX is Mask 10 and RGB is Mask 6.
4K
300TVL
RRGGBBX
RRBBGGX
BBGGRRX
600TVL
RGBX
RBGX
BGRX
800TVL
RGB
GBR
BGR
1000TVL
MG
YB
GM
Update: Here are CRT-Guest-Advanced’s Mask Layouts:
@Wilch1 Remember, to reverse the Mask Layout for WOLED and BGR Displays you can use Mask Layout 1 (BGR) in CRT-Guest-Advanced. The particular starting subpixel or subpixel offset is what allows CRT-Guest-Advanced’s Mask Layout 1 to be compatible with both BGR and WOLED Displays.
So far it’s one mask within one shader within RA while using vulkan/opengl. Very niche indeed.
I tried every mask in guest-advanced at full strength, each with various mask sizes and with both mask layouts. No issues.
Perhaps @bigretrofan can try?
Did you try with HDR On as well as Off in RetroArch? Also have you tested the Sony Megatron Colour Video Monitor masks showing the issue with the Shader Parameters set to SDR Mode and HDR turned Off in the RetroArch Menu?
Lastly have you tested my latest CyberLab Megatron miniLED Epic Preset Pack or @Azurfel’s, Azmods shader and presets to see if you’re also experiencing the issue there?
Mega Bezel also has Sony Megatron Colour Video Monitor base presets you could test.
I tried guest advanced mask mask 10 and it is working properly on latest driver while Megatron is broken. I then downgraded AMD drivers 23.9.1 to check and there is is working as intended. So it is not Windows 24h2 upgrade as I originally was thinking ( my win10 other partition is using older driver so no wonder it was working there) but it fits timeline if drivers got broken in mid 2024 timeline as Wilch1 rightfully discovered.
We could still make the bug report to AMD and see what happens. It could be a genuine bug/mistake on their part and who knows what else could be affected by it?
I’ve tried with HDR on/off in Windows, in RA and within the shader params. No combination of settings helps. I’ve tested cyberlabs miniLED Epic pack and Azmods and all presets using aperture are bugged.
I couldn’t get megatron working in mega bezel, it caused RA to close
By the way, have you tried enabling and disabling display scaling?
When I get a chance, I’m going to share an alternative sonymegatron.slang with reversed X (Dark subpixel) placement. In Sony Megatron Colour Video Monitor the X is after the RGB subpixels but at least for some of CRT-Guest-Advanced’s masks, the X is at the beginning.
Have you used a test pattern to 100% verify that the problematic AMD driver is correctly outputting 444 chroma? (Tho i highly doubt it’s chroma subsampling, that presents quite differently from what you describe.)
Also, for trouble shooting purposes, check if the masks are visible at 1920x1080.
@Wilch1, @bigretrofan you can try this version of crt-sony-megatron.slang which has the Black subpixel in front of the RGB subpixels instead of after. Just be sure to backup your original crt-sony-megatron.slang before trying. Only the 4K, Aperture Grille masks have been modified.
Update:
Just did some testing with an AMD Radeon RX 6600 using Driver 25.12.1 and was able to replicate the behavior, even on a 1080p BGR SDR display. D3D11 is completely fine though.
I tested the above crt-sony-megatron.slang and the problem was still there.
Does the mask bug occur with both Retroarch and Megatron in SDR mode?
Yes, SDR/HDR mode doesn’t seem to matter.
I tried switching between 8 bit, 10 bit and 12bit modes as well as between 8 bit and 10 bit Open GL mode in my Adrenalin Driver Contro Panel. I tried setting Integer Scaling On/Off, Enabled/Disabled GPU Scaling and set scaling mode to center. None of that helped.
Yeh I tried with scaling disabled straight away, forgot to mention it