Skip to content

Conversation

@MajorPainTheCactus
Copy link
Contributor

@MajorPainTheCactus MajorPainTheCactus commented Jan 17, 2026

The advent of the latest monitors and TVs shown at CES—such as Nvidia's G-SYNC Pulsar, TCL's X11L 9000-nit TV, Samsung's RGB V-Stripe QD-OLED displays, and LG's RGB Stripe OLED displays—means we'll be able to more accurately simulate CRT displays this year. Consequently, I thought a long-overdue revisit of RetroArch's HDR system was necessary in preparation.

This is a major upgrade to the HDR system. Firstly, it changes the inverse tone mapping in two major ways:

  1. It uses RGB maxing rather than luminance, which was causing cloudy colour reproduction.
  2. It abandons the old elbow approach for a full-spectrum remapping of the SDR space to HDR. Previously, we were only mapping the highlights to HDR; now, the shadows and mid-tones should also be mapped linearly into the larger space.
  3. The Contrast option has been removed as it's no longer needed. This makes the whole calibration step much easier for the end user: they should just set the peak luminance to their display's peak luminance and then use 'Paper White' as their overall brightness setting.

I've also made a number of changes to the D3D11, D3D12, and Vulkan drivers, making HDR more of a first-class citizen (don't worry, SDR is just as it's always been). Now, it is not done as a post-processing step; instead, it is done when we copy the emulation output to the screen. This both speeds up HDR and reduces GPU memory usage.

I've also exposed all the HDR menu settings to the custom shaders. There is no longer a set of menu options and conflicting shader options confusing users. Custom shaders will need to be updated to take advantage of this—hopefully, this will mean stuff just works for the end user.

I've also added a scanline simulation for HDR, as this is the main reason you want to turn on HDR for end users of RetroArch. This simulation is aimed at getting HDR scanline simulation working on a Raspberry Pi 5 at 4K, so it's incredibly fast and is all done in a single pass tied in with the HDR. It has a single option: the sub-pixel layout of your TV; everything else is fixed. Obviously, for more options, all the custom shaders we know and love are still there. This is an HDR-only scanline simulation that will turn itself off if any shaders are selected (you can turn it back on once a specific custom shader has been loaded, for example, if it's just a colour grading shader).

All in all, this should prove to be a big change for end users, mainly from the simplicity and quality perspectives. HDR should 'just work' out of the box for the majority of users, with tweaks only really needed on displays that claim to be HDR but aren't truly capable.

@hizzlekizzle
Copy link
Collaborator

whoa, exciting stuff! Thanks for the big update

@LibretroAdmin LibretroAdmin merged commit 333e39f into libretro:master Jan 17, 2026
34 checks passed
@sonninnos
Copy link
Collaborator

Leaving all those /**/ commented out things in place is incredibly messy, and also there is a new warning:

gfx/drivers/vulkan.c: In function 'vulkan_frame':
gfx/drivers/vulkan.c:5054:8: warning: "/*" within comment [-Wcomment]
 5054 | #endif /* VULKAN_HDR_SWAPCHAIN */
      |

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants