Could you please verify this works with hdr?
I made a second preset named adaptive_strobe-koko-hdr_blasckscreen_workaround.slangp and inside it I appended a stock pass with the same metadata as the hdr-config.slangp
1 Like
It doesn’t solve the issue.
@kokoko3k I think this is the real fix here. No workaround is necessary. I would add that you don’t need to apppend the hdr-config.slangp. Instead you could append the hdr.slangp.
The hdr-config.slangp is used if you want to add the old style Sony Megatron HDR Peak and Paper White Brightness overrides to the Shader Parameters, while the hdr.slangp is used if you want to add HDR compatibility to any shader but use the settings in Settings–>Video–>HDR to control HDR output, including HDR Brightness, which is what @MajorPainTheCactus had in mind when he updated RetroArch and Sony Megatron Colour Video Monitor’s HDR implementation not too long ago.
Guess what? I’m able to double stack adaptive_strobe-koko with my display’s strobing BFI! so far I haven’t done any real objective testing except but the only downside I can see if the normal lower brightness I get when using the hardware based solution.
This is the issue:
These show the output after appending hdr-config.slangp or hdr.slangp. The darker shots are the dark frames being output from the adaptive-strobe-koko shader:
1 Like
I was trying to append an hdr.slangp with the intent to export it as a full preset to understand if it would work, but faced a blocking issue:
[ERROR] [Slang] Failed to open shader file: "/home/koko/.config/retroarch/shaders/shaders_slang/hdr/shaders/include\hdr10.h"
there are some backslashes:
grep -R include /home/koko/.config/retroarch/shaders/shaders_slang/ | grep \\\\
/home/koko/.config/retroarch/shaders/shaders_slang/bezel/Mega_Bezel/shaders/megatron/inverse_tonemap.slang:#include "include\inverse_tonemap.h"
/home/koko/.config/retroarch/shaders/shaders_slang/bezel/Mega_Bezel/shaders/megatron/hdr10.slang:#include "include\hdr10.h"
/home/koko/.config/retroarch/shaders/shaders_slang/hdr/shaders/hdr_inverse_tonemap_config.slang:#include "include\inverse_tonemap.h"
/home/koko/.config/retroarch/shaders/shaders_slang/hdr/shaders/hdr_inverse_tonemap_config.slang:#include "include\hdr10.h"
/home/koko/.config/retroarch/shaders/shaders_slang/hdr/shaders/hdr10_v2_config.slang:#include "include\hdr10.h"
/home/koko/.config/retroarch/shaders/shaders_slang/hdr/shaders/inverse_tonemap_v2.slang:#include "include\inverse_tonemap.h"
/home/koko/.config/retroarch/shaders/shaders_slang/hdr/shaders/hdr.slang:#include "include\hdr10.h"
/home/koko/.config/retroarch/shaders/shaders_slang/hdr/shaders/inverse_tonemap.slang:#include "include\inverse_tonemap.h"
/home/koko/.config/retroarch/shaders/shaders_slang/hdr/shaders/hdr10_v2.slang:#include "include\hdr10.h"
/home/koko/.config/retroarch/shaders/shaders_slang/hdr/shaders/hdr_config.slang:#include "include\hdr10.h"
/home/koko/.config/retroarch/shaders/shaders_slang/hdr/shaders/hdr_inverse_tonemap.slang:#include "include\inverse_tonemap.h"
/home/koko/.config/retroarch/shaders/shaders_slang/hdr/shaders/hdr_inverse_tonemap.slang:#include "include\hdr10.h"
/home/koko/.config/retroarch/shaders/shaders_slang/hdr/shaders/hdr10.slang:#include "include\hdr10.h"
/home/koko/.config/retroarch/shaders/shaders_slang/hdr/shaders/inverse_tonemap_v2_config.slang:#include "include\inverse_tonemap.h"
/home/koko/.config/retroarch/shaders/shaders_slang/shader_deploy.py:INCLUDE_RE = re.compile(r'^\s*#include\s+"([^"]+)"')
…I think those will only compile under Windows.
1 Like
Any reason why I’m seeing these shaders in the Mega Bezel folder in the path?
The Mega Bezel version of Sony Megatron Colour Video Monitor is way behind the current version. How is it relevant?
Are you using a nightly build? Or stable?
MajorPainTheCactus made the “v2” HDR shaders such that they pull some of their settings from RetroArch’s settings, rather than making them entirely self contained, so they require a nightly build that includes those settings.
This does not work. Outputs a screen with scattered corrupted flickering artifacts.
1 Like
I don’t think it matters, problem is that those shaders (updated) use a backslash instead of a slash.
So what’s the long term solution to the use of the backslash issue?
At least in the short term you can append the hdr.slangp to the adaptive_strobe-koko.slangp and include a preset in RetroArch.
Is just a syntax problem, I’ll make a PR today with the fix for linux,android,mac.
(done)
2 Likes
I hooked my laptop to an LG oled C1 and loaded the preset you pointed out @cyber, this time with vulkan, hdr enabled under ArchLinux (Kde plasma with HDR enabled), and HDR enabled under retroarch; then appended my bfi shader and everything worked flawlessly, so I really don’t know 
I tried with the latest stable release of retroarch; maybe the issue is tied to the nightly builds? Maybe it’s Windows only? It should be reported upstream so that it can be fixed before release.
The latest stable release is “old”. There have been significant updates to RetroArch’s HDR implementation since then.
Yeah, but it is the stable one, and indeed it works (at least here); that’s because I think the issue should be reported before the current development version becomes “stable”.
I’m assuming the issue is tied to the nightly one. Could you please check if appending AtaptiveStrobe bfi alone to your preset in the stable 1.22.2 works ok for you? (without hdr.slangp)
1 Like
Sure, I could try. Hopefully it won’t break any of my settings files.
Do note that @MajorPainTheCactus only drops by once in a while.
Coming to think of it, I’m not sure if it’s an issue or if it might actually be by design because I remember reading a conversation between @MajorPainTheCactus and @anikom15 concerning changes in tonemapping and @MajorPainTheCactus said something like it was up to the Shader devs to do their own tonemapping or something like that. Which is something that didn’t need to be done in the old HDR implementation.
You should really go over to the Sony Megatron Colour Video Monitor thread and get up to speed on what was changed and how the new HDR Implementation works differently before thinking that this might be an “issue”.
It might actually be a feature.
You can go to the thread then filter @MajorPainTheCactus’ posts and read all of them from this year.
In the end he left everything modular so shader developer had the option to append his tonemapper and have things back the legacy way as well.
1 Like
Rather than missing tonemapping, it sounds more like a bug, since the screen is completely black (?)
Differently, any appending operation in hdr environment would require appending another full viewport shader to the chain, which is very heavy on the gpu; either way, I hope it is not the intended workflow.
I can drop a note in my bfi shader and anyone using any bfi or whatever other shader should do, then) saying: If you’ve issue, append hdr.slangp, but this sounds unoptimal to me.
1 Like
I think you should read up rather than rely on my 3rd party accounts. It’s not that many posts so not a long read and I think the enlightenment might help eliminate at least some speculation as to what might be going on and why.
1 Like
There were a bunch of shader black screen bugs that got fixed across the various renderers (mostly vulkan), so this is likely.
1.22.2 stable doesn’t have the HDR “v2” updates, or a bunch of vulkan fixes, so i imagine it’s a conflict with of those updates or fixes.
2 Likes
I’ve noticed the dips more frequently now since trying the appended version. It’s actually pretty bad because every few seconds there’s a flash/flicker of a brighter frame that you can see and it shows up as a dip in the framerate in RTSS.
The severity and frequency varies depending on the game and the Core though.
On another note, as a new user of Sub-Frames, can I also enable Sync to Content Refresh Rate? If not, can I safely enable Automatic Frame Delay?
For the former, I don’t know, but the latter should not pose any problem.
…indeed, at 4k is overkill, expecially since it seems the way hdr will be implemented requires another full viewport pass (hdr-xxx.slangp)
1 Like
Okay, let me rephrase my statement. Instead of “It’s actually pretty bad.”, it’s more like sometimes it can get pretty bad or even occasionally. Depending on the load it can be regular but not necessarily frequent. The real issue is its noticeable and so breaks immersion. I don’t think I had seen this happening with the Adaptive-Strobe-Koko shader prepended.
Yes, I use the defaults on an LCD so image anti-image-retention is active.
I understood, it’ìs clear, the gpu can’t keep up, and misses a frame here and there; expecially considering that subframes are rendered as normal frames if the shader doesn’t optimize that somehow by showing the previous frame instead of calculating it from scratch.
Since adaptive-strobe is very simple, if you’re interested, maybe @guest.r could incorporate it into the last .slang used so that at least you don’t have to waste viewport passes.
koko-aio optionally supports that via plugins (yet to be released as stable, but it’s on dev version, and can additionally optimize subframes by skipping redundant calculations on subframes).
1 Like
Hmmm…currently I’m appending Phosphor Persistence after CRT-Guest-Advanced-NTSC, then Adaptive-Strobe-Koko, then hdr.slangp.
Is there another way that this could you done seeing that there’s a shader between Adaptive-Strobe-Koko and CRT-Guest-Advanced-NTSC?
At some point, I would like to learn how to incorporate/integrate shaders into less passes as well as remove already integrated shaders which might have redundant features.