Oolite on HDR Displays

[another_commander]

I found out the reason for the color distortion - the game did not work in true HDR mode. If you switch to windowed mode and change the value of the SDR content brightness slider in the windows settings, it will affect the image in the game window. Fortunately, I was able to force true HDR mode: I installed ReShade with the AutoHDR plugin.

I don't understand this. The game window is most definitely true and proper HDR both when fullscreen and windowed. Just tested it right now on my laptop to be sure. Launched the game in windowed mode and changed the value of the HDR content slider (on laptops it is the opposite of desktops with external displays, the slider refers to HDR content instead of SDR) and by moving the slider I could see the brightness in the game window changing, whcih means it was 100% HDR. No external utilities are required to achieve HDR signal.

Can I ask for the contents of your Latest.log please? Just want to confirm that the game recognizes and sets HDR properly when launching.

[Simba]

It might have something to do with my AMD graphics card - it has some issues with enabling Auto HDR in games running OpenGL. I think it might also affect native HDR.

Can I ask for the contents of your Latest.log please? Just want to confirm that the game recognizes and sets HDR properly when launching.

https://paste.ofcode.org/ZN5vEsmqjb6v3p6Gjcj4JT

[another_commander]

I was about to ask if you would be willing to install SpecialK and try to help finding out what's going on, but I see you were already on the SpecialK discord and even SK couldn't trigger HDR properly. Looking at this screenshot

I can see that even though the presentation model is Hardware Composed: Independent Flip (which is good, this is needed for HDR presentation), the graphics API is reported as OpenGL when it really should be OpenGL-IK. OpenGL-IK means that SK has effectively created a bridge between OpenGL and DX11/12 and is using DirectX for the final presentation step on the screen, while the rest of the rendering is done normally via OpenGL. This is what is called a DXGI interop. The guys helping you out on Discord also mentioned interop quite a bit, that's basically what they are referring to.

Oolite is making use of an automatic DXGI driver interop on NVidia cards, activated whenever an application requests a render backbuffer which is implicitly HDR-only (there are other uses of this interop, like on Optimus laptops where this is used for communication between the discreet and the internal GPUs, but that's a story for another time ). Oolite requests a 16-bit RGBA float backbuffer when it starts up in HDR and that is basically an scRGB HDR setup. The NVidia driver sets up the app's window as HDR just by seeing this request.

Now, we know that AMD used to do exactly the same at least until about one year ago. Check out this SK discord discussion, where a very advanced AMD user, Lilium (you probably know them, they are the creator of most of the Reshade HDR analysis and black floor fix shaders), is running a quick analysis on Oolite and confirms that it's working fine in HDR. Scroll down a bit on the discussion and you will find the confirmation there. So we know that with the AMD drivers of that time it worked as we'd expect. Not sure if and when they changed that, but the fact that you can't get HDR neither with Oolite nor with SpecialK could be pointing to a driver bug or maybe a driver setting that's switched the wrong way.

After briefly looking around for information, I found this in the AMD reddit: https://www.reddit.com/r/Amd/comments/1 ... r_latency/ You basically need to turn on OpenGL triple buffering in the Adrenaline control panel so that the interop gets enabled. Have you tried that? Worth a shot I guess.

The alternative, if you are willing to go that far, would be to try with a driver from around November 2023.

I understand if you are happy with the Reshade AutoHDR you got working now and don't feel like messing around anymore with all this, but normally native HDR is a better experience than external inverse-tone mapping solutions like AutoHDR (be it Windows or Reshade).

[Simba]

You basically need to turn on OpenGL triple buffering in the Adrenaline control panel so that the interop gets enabled. Have you tried that? Worth a shot I guess.

This setting was initially enabled - switching it does not do anything.

I understand if you are happy with the Reshade AutoHDR you got working now and don't feel like messing around anymore with all this, but normally native HDR is a better experience than external inverse-tone mapping solutions like AutoHDR (be it Windows or Reshade).

In fact, the situation is different - the addon does not work, this is indicated by a message "HDR support is not enabled. If hardware can support it please go to Windows 'Display Settings' and then turn on 'Use HDR'". If I understood the code correctly, then it is compatible only with dx11 or dx12. I did a little research: in the addon itself, hdr is enabled on the line
https://github.com/EndlesslyFlowering/A ... n.cpp#L582
The code in the on_create_swapchain function doesn't matter - it just has to return true.

In the end, it all comes down to the line https://github.com/crosire/reshade/blob ... l.cpp#L502. Without it, hdr doesn't work.

Unfortunately, I'm bad at C-like languages ​​and it takes a lot of time.

[another_commander]

I am now starting to wonder if you happen to have one of those wide color gamut monitors that have a hardware or firmware switch to change modes from wcg (sdr) to HDR and vice versa. Would you mind sharing your monitor specs?

Just to be sure that I understand, can you please confirm the following:
- All the tests you did with Oolite were conducted with HDR turned on in Windows->Settings ->Display? Based on your posted log Oolite thinks HDR was on, specialk also seemed to think it was on (but failed to do anything with it), but reshade autohdr seems to disagree. So was it on in windows settings or not?

-Go to https://www.wide-gamut.com/test while in HDR mode and check the tests. Do you see any warnings on any of the tabs? Do the tests produce what their descriptions indicate they should? This could tell us if you are truly in HDR or in wcg mode.

If you are indeed in HDR in windows and various apps don't recognize it, maybe a driver reinstall could be a last resort option. But let's try to find out what is going on first if we can.

[Simba]

- All the tests you did with Oolite were conducted with HDR turned on in Windows->Settings ->Display? Based on your posted log Oolite thinks HDR was on, specialk also seemed to think it was on (but failed to do anything with it), but reshade autohdr seems to disagree. So was it on in windows settings or not?

The addon checks the API in the line https://github.com/EndlesslyFlowering/A ... n.cpp#L350, and only then will it be possible to update the value of the g_hdr_support variable. In my case, the API check is negative, so the g_hdr_support variable is always false. I tried to get rid of this check by actually forcing the code execution inside the if block, but this led to an error, so I did not deal with it further.
Of course, I have HDR enabled everywhere and it works fine in other games/applications with native support (at least if there is directX).

-Go to https://www.wide-gamut.com/test while in HDR mode and check the tests. Do you see any warnings on any of the tabs? Do the tests produce what their descriptions indicate they should? This could tell us if you are truly in HDR or in wcg mode.

Everything is OK here too. By the way, web tests suck because they depend primarily on the technology support in the browser itself. For example, Firefox does not support HDR or even 10-bit images. That's why when I first bought the monitor, I also looked at these tests:
https://github.com/jursonovicst/gradien ... /3120x1440
https://drive.usercontent.google.com/do ... authuser=0
https://drive.google.com/drive/folders/ ... 8_5nLcRwHA
https://4kmedia.org/samsung-hdr-picture ... d-4k-demo/

The only thing worth mentioning is that my monitor has a color gamut close to standard, but not to dci-p3. In any case, it doesn't matter, because we have a 100% method for determining whether an application works in hdr mode - changing the brightness slider of sdr content in the Windows display settings. And in my case, Oolite works correctly only when reshade is connected with the AutoHDR addon (which does not actually perform its function).

If you are indeed in HDR in windows and various apps don't recognize it, maybe a driver reinstall could be a last resort option. But let's try to find out what is going on first if we can.

I'm avoiding reinstalling the driver for now, because so far everything points to the fact that the problem can be solved programmatically. Actually, it really can be solved - just need to understand what reshade does differently than it is implemented in Oolite.

[another_commander]

I'm avoiding reinstalling the driver for now, because so far everything points to the fact that the problem can be solved programmatically. Actually, it really can be solved - just need to understand what reshade does differently than it is implemented in Oolite.

We know exactly what reshade does differently since we have the source for both available. Reshade is using the dxgi factory api to detect hdr, while Oolite uses the DisplayConfig api. Two completely different methods and it is not possible to apply the dxgi factory one in Oolite for various technical reasons.

It seems that in your case the dxgi interop OpenGL rendering -> DX11/12 presentation is not working as we would have hoped. This can be confirmed by running Oolite on top of the Intel Presentmon app.

Edit: For reference, this is what it looks like for me when presentmon runs. Note that oolite.exe is reported as running under DXGI despite it being OpenGL. This demonstrates that the dxgi driver interop functions correctly and the game goes straight to hdr mode with Hardware Composed: Independent Flip presentation model and stays there until exit.


If you decide to use it, make sure the account you are running it from is a member of the Performance Log Users group or, alternatively, is an admin account.

Edit #2: One more easy thing you could try is to open oolite.app/Resources/Config/logcontrol.plist, and edit the display.initGL line thus:

Code: Select all

display.initGL	= yes;

Then run the game with the -hdr parameter and post the log, it will contain some additional info about the status of the swap chain it sets up.

[Simba]

Presentmon app

I got lines similar to these:

Application,ProcessID,SwapChainAddress,PresentRuntime,SyncInterval,PresentFlags,AllowsTearing,PresentMode,CPUStartTime,FrameTime,CPUBusy,CPUWait,GPULatency,GPUTime,GPUBusy,GPUWait,DisplayLatency,DisplayedTime,AnimationError,ClickToPhotonLatency
oolite.exe,4368,0x1F02A390,DXGI,1,0,0,Composed: Flip,23120.9930,4.8911,4.7755,0.1156,1.3679,29.4203,2.5853,26.8350,35.4083,753.3505,0.0000,NA
oolite.exe,4368,0x1F02A390,DXGI,1,0,0,Composed: Flip,23125.8841,773.3906,773.2291,0.1615,25.8971,749.5856,3.7621,745.8235,783.8677,1.0915,-748.4594,2498.9158
oolite.exe,4368,0x1F02A390,DXGI,1,0,0,Hardware Composed: Independent Flip,23899.2747,8.5512,3.1102,5.4410,2.0921,6.4524,2.6827,3.7697,11.5686,0.0167,772.2991,NA
oolite.exe,4368,0x1F02A390,DXGI,1,0,0,Hardware Composed: Independent Flip,23907.8259,0.8061,0.6939,0.1122,0.0321,2.9660,2.5096,0.4564,3.0341,6.2288,8.5345,NA
oolite.exe,4368,0x1F02A390,DXGI,1,0,0,Hardware Composed: Independent Flip,23908.6320,6.0346,5.9260,0.1086,2.1920,6.2450,2.6807,3.5643,8.4568,8.2014,-5.4227,NA
oolite.exe,4368,0x1F02A390,DXGI,1,0,0,Hardware Composed: Independent Flip,23914.6666,8.2881,8.1544,0.1337,2.4024,8.2035,2.6096,5.5939,10.6236,7.6514,-2.1668,NA
oolite.exe,4368,0x1F02A390,DXGI,1,0,0,Hardware Composed: Independent Flip,23922.9547,7.8728,7.7661,0.1067,2.3178,7.6502,2.3314,5.3188,9.9869,8.5003,0.6367,NA
oolite.exe,4368,0x1F02A390,DXGI,1,0,0,Hardware Composed: Independent Flip,23930.8275,8.5089,8.3991,0.1098,2.0952,8.5020,2.3416,6.1604,10.6144,9.2008,-0.6275,NA


Edit #2: One more easy thing you could try is to open oolite.app/Resources/Config/logcontrol.plist, and edit the display.initGL line thus:

Code: Select all

display.initGL = yes;

Then run the game with the -hdr parameter and post the log, it will contain some additional info about the status of the swap chain it sets up.

https://paste.ofcode.org/39TkgCxUX2aiqMZjyqrw6AF

[another_commander]

I am sensing a driver problem. This here is an anomaly:

Code: Select all

23:17:34.380 [display.initGL]: Trying 16-bpcc, 24-bit depth buffer
23:17:34.976 [display.initGL]: Achieved color / depth buffer sizes (bits):
23:17:34.977 [display.initGL]: Red: 8
23:17:34.977 [display.initGL]: Green: 8
23:17:34.977 [display.initGL]: Blue: 8
23:17:34.977 [display.initGL]: Alpha: 8
23:17:34.977 [display.initGL]: Depth Buffer: 24
23:17:34.977 [display.initGL]: Pixel type is float : -1

Instead of giving you a 16-bit float buffer as requested, you get back an 8-bit one, non-float. It seems that for some reason your driver is missing the extension WGL_ARB_pixel_format. Would you mind running this glew info utility? It lists all available OpenGL extensions and pixel formats and will help confirm if this is indeed the issue. It will create a file called visualinfo.txt in its folder. Please post that file.

[Simba]

glew info utility

https://paste.ofcode.org/3adqJLP463nkQVrue27mvPm

[another_commander]

That last log and the visualinfo output were really helpful I think. Here is the rundown of what I believe happens:

The AMD driver cannot get Oolite to render in the pixel format it requests on startup. While Oolite wants a 16-bit float RGBA output buffer, it only gets an 8-bit integer one, which is of course SDR. But we already knew that. However, there are two interesting things happening in the visualinfo output.
1. All 16-bit formats - which should be of type float, appear as type " ? " in the list. This may be because visualinfo is looking for some very specific ATI extensions to determine the floatness of the pixel format and it could be that the driver doesn't provide them, without this necessarily meaning that the driver is bad or anything. So we will choose to consider this as just an interesting fact for now and move on.
2. The more interesting observation is that the exact 16-bit float pixel format requested by Oolite does not appear in the available formats list. Oolite requests 16 bit for each of R, G, B, A and a 24-bit depth buffer. That's it. But such a description does not appear in the list. All 16-bit RGBA formats that support a 24-bit depth buffer also require an 8-bit stencil buffer, which we do not specify. As a result. it fails to assign what we wanted (also evident by the -1 for float pixel format in the log) and falls back to 8-bit RGBA SDR.

So I was wondering, what if we give the AMD driver exactly what it needs? I recompiled the game executable adding an 8-bit stencil buffer in the setup. Oolite doesn't need it, but this way there will be at least one 16-bit float pixel format that is available in the list. I would expect that one of the formats with index number 193 to 198 gets picked up and then maybe hdr could be triggered, because your presentmon output indicates that the dxgi driver interop works. I have added some extra logging as well in order to be sure which exact pixel format it tries to pick.

The test exe is available here.

[Simba]

Still not working.


Application,ProcessID,SwapChainAddress,PresentRuntime,SyncInterval,PresentFlags,AllowsTearing,PresentMode,CPUStartTime,FrameTime,CPUBusy,CPUWait,GPULatency,GPUTime,GPUBusy,GPUWait,DisplayLatency,DisplayedTime,AnimationError,ClickToPhotonLatency
oolite.exe,47100,0x1FDAE760,DXGI,1,0,0,Composed: Flip,81022.1218,22.2705,21.7725,0.4980,2.1508,21.4417,1.1717,20.2700,52.9796,6.6859,0.0000,NA
oolite.exe,47100,0x1FDAE760,DXGI,1,0,0,Composed: Flip,81044.3923,3.9766,3.8814,0.0952,1.3220,15.5062,1.3719,14.1343,37.3950,746.6706,15.5846,NA
oolite.exe,47100,0x1FDAE760,DXGI,1,0,0,Composed: Flip,81048.3689,768.0921,767.9323,0.1598,12.8516,757.3344,3.7610,753.5734,780.0890,1.7663,-742.6940,3532.4708
oolite.exe,47100,0x1FDAE760,DXGI,1,0,0,Hardware Composed: Independent Flip,81816.4610,12.8211,2.8360,9.9851,2.0939,10.6950,2.2958,8.3992,13.7632,2.0460,766.3258,NA
oolite.exe,47100,0x1FDAE760,DXGI,1,0,0,Hardware Composed: Independent Flip,81829.2821,0.8347,0.7157,0.1190,0.0000,3.0018,2.4629,0.5389,2.9881,3.4802,10.7751,NA
oolite.exe,47100,0x1FDAE760,DXGI,1,0,0,Hardware Composed: Independent Flip,81830.1168,4.0332,3.9188,0.1144,2.1349,3.4830,1.8397,1.6433,5.6336,8.6329,-2.6455,NA


https://paste.ofcode.org/3aKA6eb7xUeXy2pHyV2Rbc

[another_commander]

OK, one last try, then I think I will have to give up. Let's see if another app that tries to enable specifically scRGB hdr works. The test app is SKIV, a superb image viewer and format converter created by the author of SpecialK. Download from here: https://we.tl/t-lCg9lFSiJF (just one 5.4MB exe file).

Run SKIV.exe and an empty borderless window will open up. Right click it and select Settings. Then navigate to the area entitled High dynamic range (HDR) and make sure scRGB (16 bpc) is selected. It should look like this:


Does this work for you? Do you see the UI brightness change when you select scRGB versus No hdr? Is that a proper hdr window?

[Simba]

Yes, it works fine.

[another_commander]

I am out of ideas. I am sorry, I don't know what is happening there. Oolite just can't receive the pixel format it's asking for, even though it is present in the driver. Maybe it's an issue with the OpenGL part of the driver, but I have no idea what to do to get it fixed at this point.