Yeah its no doubt linux not having HDR done as a post process
2 Likes
Sorry what platform is this? Linux?
2 Likes
Yes, it’s Debian Linux with Gnome, but it was also reported to happen in KDE in the issue I submitted previously: https://github.com/libretro/RetroArch/issues/18186
I brought up this yesterday when I saw the issue about the wrong colors/tonemapping, which I previously thought was the same issue, but Azurfel demonstrated above that it’s a different one.
2 Likes
Great stuff I just had a poke around and the quick hack I thought might work didnt or at least it fixed this issue but caused ten others. I’ll have to do a bit of work in each driver.
3 Likes
As it turns out, this is partially related the UI tonemapping bug.
When an SDR preset doesn’t include a “scale_type” line ???in the final shader of the chain???, the content is tonemapped identically to the UI.
HDR in SDR screenshots again, so these don’t look like they actually do, but it gets the idea across somewhat.
Megatron v2 active, screenshot popup presents the tonemapping bug:
A shader preset with no “scale_type” line, both content and popup present the tonemapping bug.
3 Likes
This doesn’t appear to be working correctly for me. It looks like it might be compressing the entire Rec2020 range down to Rec709 or some other smaller gamut, and then displaying the selected gamut within that range.
I’ll dig into it a bit and see if i can figure out what is going on.
(Megatron v2 is still working as expected.)
2 Likes
Unfortunately unrelated, but i found a single typo in crt-sony-megatron-hdr-pass-v2-config.slang that renders crt-sony-megatron-v2-default-config.slangp non-functional:
#define HCRT_HDR gloabl.EnableHDR
where it should be
#define HCRT_HDR global.EnableHDR
I replaced one of the transformation matrices with Rec2020’s, and this is indeed the case, at least approximately:
I haven’t been able to figure out why so far tho.
Edit 2: Oh, that may be related. The menu level HDR settings are still active:
2 Likes
Ah I think I know what this is about: I limit the scanlines to being on only on resolutions above 4x240p. I think this scale_type is messing around with that size and so the scanlines kick in or not which is what your screenshots seem to show.
2 Likes
Damn thats a nasty typo, great catch. I didnt test switching HDR on/off as much as the other settings. Ill fix it tomorrow. Ill hopefully fix at least one of the drivers menus tomorrow as well - its Vulkan thats the problem though.
2 Likes
Hey y’all, are there any updates on when we might see a LG G5 compatible settings? We used to have a CX and loved using this shader, and would love to get it up and running again on the G5 
Thanks for all you do!!
2 Likes
Fixed D3D11, D3D12 and Vulkan driver’s HDR menus. Whenever it gets merged, it will be in the nightly build there after.
5 Likes
Hi what settings are incompatible with a LG G5? I presume it looks broken and youre using the original shader? (rather than the recently updated v2 that is). In my head it should still work on a LG G5 just fine if you got it working on a LG CX. You might need to tweak the peak and paper white luminance for your new TV though.
2 Likes
LG changed the subpixel layout from RWBG to BWRG for the G5 (the C5 was still RWBG tho).
Another variation on the current WOLED setting would presumably work.
4 Likes
I don’t see why they can’t just try the 3 Layouts the shader has already and take some macro photos and get back to us.
It’s just the red and the blue subpixel swapped so that’s BRG. Don’t we already have a BRG layout? Who knows, maybe the existing RGB might work.
3 Likes
I thought there was some weird layout shenanigans factoring in the white subpixel spacing that made the “WOLED” layout work as well as it does, actually.
If it’s just RBG under the hood, then yeah, i would think the BRG layout would work just as well for the G5 as the “WOLED” layout does for the previous LG panels.
3 Likes
I would be happy to do so, but won’t be able to until I actually have the TV set up which is going to be tomorrow!
2 Likes
Just a (maybe dumb) question, but I’m not finding an answer in online searches. I’m aware that for HDR to work on Windows with D3D11/12 I need to enable HDR on the system and then in RetroArch. Is this also true for Linux with Vulkan?
The question arose because, reading the Arch Linux Wiki page about HDR, for all the applications listed there, including RetroArch, the information is that it is only necessary to enable it in the application itself.
And despite those bugs I mentioned in the comments above, I can use the Sony Megatron just by enabling HDR in RetroArch, also enabling it on the system does not fix the bugs, but in fact, it makes them worse.
So I’m unsure how is the correct way to use it on Linux systems.
1 Like
I don’t think anyone has thourougly tested it but I have always suspected that RGB phosphor triads on WOLED RWBG displays always use subpixels from at least 2 adjacent pixels in order to emulate 1 rgb phosphor triad. The white subpixel being off just creates the “X” or gap or darkened subpixel between triads.
1 Like
On Android at least there is no HDR switch - the app just asks for a HDR buffer and then tells the vulkan driver via meta data that its a HDR app. I think Windows should do the same but I vaguely remember people saying to avoid using metadata and just let the display decide which makes sense for some things max nits etc but maybe not for others. 
2 Likes
I can’t get Megatron v2 to load on my installations; I’ve got the Retrodeck and Flatpack versions of Retroarch running on Bazzite (Fedora) and they just fail to load. Doesn’t load on iOS either. All versions 1.22.2. Am I missing something? I’ve read the thread since my last post and can’t see any bugs mentioned.
Does it only work on Nightly Retroarch builds at the moment?
1 Like