Main Menu —> Logging —> Enable Verbose Logging On, Save Log to File On.
Thx, here is my full log and steps I took to reproduce and fix the issue:
-Loaded retroarch -Loaded up MegaManX with vulkan driver -Selected my HDR shader -Picture was washed out -Disabled HDR with vulkan still as the driver and re-enabled (did not fix) -Selected DX12 -Disabled HDR and re-enabled (fixed the issue and correcly displays the shader)
Edit - In looking at the log closely, Retroarch sees a second GPU when you select DX12 instead of Vulkan, perhaps this is why HDR works with DX12 and not Vulkan? 1. [INFO] [D3D12]: Found GPU at index 1: “Microsoft Basic Render Driver”.
Weird this would show up under DX12, especially since I don’t have onboard graphics.
2 Likes
Excellent thanks! So there is some interesting stuff in here on the first Vulkan try it selects a RGB565 format:
[INFO] [Vulkan]: Using RGB565 format.
Which is wrong as thats a 16bit format and it should be using R10G10B10A2 or R16G16B16A16 which are 32bit and 64bit respectively. Interestingly earlier on in the log you have a line:
[INFO] [Environ]: SET_PIXEL_FORMAT: RGB565.
Im guessing its this line which is key to why HDR is intermittently working. What could be setting this? My guess is a shader preset explicitly setting the format? Do you have a default shader set? Other guesses are settings that indirectly set the output format to a compressed format. Its all a bit odd to be honest. You definitely dont want to use this format regardless of hdr as youll probably get banding in sdr too.
EDIT: can you look through these configs:
[INFO] [Overrides]: Core-specific overrides found at "E:\retroarch\config\Snes9x\Snes9x.cfg".
[INFO] [Config]: Loading config: "E:\retroarch\retroarch.cfg".
[INFO] [Config]: Appending override config: "E:\retroarch\config\Snes9x\Snes9x.cfg".
This line in particular is of interest:
[DEBUG] [Environ]: GET_VARIABLE: snes9x_blargg = "rgb"
Can you turn off this blargg variable and see if vulkan starts to pick up hdr for you?
EDIT 2: Looking at dx12 something is very ill as it shouldnt be choosing the Microsoft Basic Renderer as far as Im aware - that should be an Nvidia driver. If you reboot with DX12 does it select the right driver instead. Im guessing this might be to do with the rgb565 output format selected and only the basic renderer supporting it - total guess though Id need to check my log and compare.
2 Likes
Could all of this be due to Mega Bezel not fully unloading or possibly parts of it being attempted to be reloaded in between Game loads or Shader Loads?
Remember I saw the reflection shader appear briefly even after I had manually loaded a Sony Megatron Preset during the process of switching HDR On when using Vulkan.
I’ve also been having issues taking screenshots using any other shader I’ve tried except Mega Bezel.
Also of note is that Mega Bezel Reflection Shader is really intertwoven into my setup. Lots of Game, Core and Global Presets which would force Mega Bezel to be loaded or reloaded. Some functions cause a Shader Reload in RetroArch for example Blargg Video Filters in the Video Filters Menu.
Similarly I have many Core Overrides saved which have HDR set to Off. So if an event causes a change in Core or an override to load or be reloaded, HDR could be getting switched off by the particular Override kicking in at some point.
I know RetroArch has a lot of fallbacks. Could something happening in between be throwing a wrench into things?
Also, does Mega Bezel Reflection Shader free up all resources and revert it’s special settings in RetroArch when it unloads or when another Shader attempts to load?
I don’t know, just a hunch maybe?
1 Like
I doubt it in @rancid’s case as the mega bezel isn’t being used as far as I can see from the logs. Could be wrong.
1 Like
Ok so looking at my logs - it does look like RGB565 gets selected at first and then RGBA8888 is selected which is interesting. My version of RetroArch is 1.12 so quite old - I’ll try to upgrade and see whether I can repro what youre seeing @rancid . Anyway here’s my Vulkan log for comparison (I use bsnes mercury accuracy):
EDIT: I think you want to be seeing these two lines:
[INFO] [Environ]: SET_PIXEL_FORMAT: XRGB8888.
and
[INFO] [Vulkan]: Using BGRA8888 format.
1 Like
Here’s my DX12 log - its selecting the right driver and the right format - again using bsnes mercury accuracy:
Both logs are from a fresh boot of RetroArch and just loading Super Mario World from my history - so defaulting to load via bsnes mercury accuracy in my case.
1 Like
Could it also be Run-Ahead or Preemptive Frames related possibly due to the use of a second instance in some cases?
1 Like
I’ll disable the snes filter, but that is just setting it to RGB rather than composite. It honestly has no impact on anything and set in the core options. I do agree on the Nvidia driver part, I don’t understand why DX12 tries to use a default MS renderer and Vulkan does not UNLESS it is picking up HDR as a separate renderer for some reason since HDR is integrated into Windows.
2 Likes
No I dont think so as I dont have those things on as far as Im aware I just think there is a two stage setup - possibly one for menu and then one for core not sure though.
1 Like
Ok great so we can rule that out - could you try using bsnes mercury accuracte as well? My best guess right now is that a bug has been introduced between 1.12 and 1.15. I need to download 1.15 and see if I can repro your log.
2 Likes
Same behavior, here you go my friend this was in Mercury Accuracy no config overrides in place same behavior - Loaded Mega ManX with Mercury Accuracy, selected HD HDR shader - picture washed out. Went into drivers and switched to DX12, turned off HDR, turned it back on and image was 100% fixed and correct.
2 Likes
Great stuff thanks for this. So it looks like the main point that our logs differ (that look related to this problem) is that after the line:
[INFO] [Shaders]: Specific shader preset found at "C:\RetroArch-Win64\config\bsnes-mercury\bsnes-mercury.slangp".
Yours looks as if it loads a different shader - Im wondering whether its this shader that is throwing a wrench in the works? If you set the megatron as the default shader for bsnes does it fix it?
Obviously we need to fix whatever is causing this be that a bug introduced or a different default shader but itd be good to know what is at issue. I still need to upgrade - Ill try and do that tonight.
1 Like
This is definitely along the lines of my original suspicions and observations. We might also have to lookout for the retroarch.slangp file and any global presets.
1 Like
I just tried setting several HDR shaders as the core preset default and it does not make any difference, have to switch to DX12 and turn HDR off and then back on.
2 Likes
Thanks for spending the time investigating. Ill update and see if I can repro it.
1 Like
Yes OK so HDR for native HDR shaders (i.e ones that do the inverse tonemapping etc themselves) has been broken in the Vulkan driver between 1.14 and 1.15. There’s been a major refactor of the Vulkan driver and I suspect things happen in different orders now as the code that deals with this is still there its just in different places. The D3D11 and D3D12 drivers are unaffected. When I have time I’ll go and have a look as to what’s got broken and fix it up but this could be a while. In the mean time I’d recommend using the DX11 or DX12 drivers for HDR.
2 Likes
Is the issue not the same as the one we discussed here?
I just checked and the behaviour remains the same. Removing those 4 lines from the .slangp file after saving your preset will fix that preset in vulkan. So load a megatron preset, save it then remove those lines from your new .slangp file then use that preset as your base for tweaking further until this issue is fixed. I discovered those 4 lines when comparing to an old preset I had from before this issue happened and the lines weren’t there.
scale_type_x2 = “viewport”
scale_x2 = “1.000000”
scale_type_y2 = “viewport”
scale_y2 = “1.000000”
Apologies if I’ve misunderstood and this is something completely different!
2 Likes
Thanks for everything that you do for the community, look forward to the update! 
3 Likes
Ooo very interesting! Thanks for reminding me of this issue! I’ll give this a whirl and see if it makes things work. If it works for me I wonder what might be causing this to brake HDR - very odd indeed.
1 Like