Anonymous edits have been disabled on the wiki. If you want to contribute please login or create an account.
Warning for game developers: PCGamingWiki staff members will only ever reach out to you using the official press@pcgamingwiki.com mail address.
Be aware of scammers claiming to be representatives or affiliates of PCGamingWiki who promise a PCGW page for a game key.
Not editable
Content is available under Creative Commons Attribution Non-Commercial Share Alike unless otherwise noted.
Found on [this](https://www.reddit.com/r/Monitors/comments/167dphy/force_enabling_auto_hdr_on_unsupported_games) Reddit post.
- Add a registry key with any name to HKEY_CURRENT_USER\SOFTWARE\Microsoft\Direct3D, with the string value being the name of the EXE - Add/set the key D3DBehaviors to BufferUpgradeOverride=1 or BufferUpgradeOverride=1;BufferUpgradeEnable10Bit=1
Changes have been implemented.
Since 23.7.1, the AMD driver supports using a DXGI swapchain to present games for both Vulkan and OpenGL. The only required condition for this to kick in is to have desktop HDR enabled in Windows. So the "For OpenGL and Vulkan games" paragraph should be edited to mention this as well. I would suggest something like the following:
Prefer layered on DXGI Swapchain. Nvidia Profile Inspector can extend the support even further to games running through DXVK or emulators.[1]
https://arstechnica.com/gadgets/2016/12/high-dynamic-range-explained-theres-a-reason-to-finally-get-a-new-tv/
In addition to hdr rendering.. I almost wonder if we shouldn't mention HDR 'cameras' too (very briefly, but still).
Also mention about color spaces (e.g. Rec. 2020), framebuffers and how HDR, UHD and 4K namings intertwine. Also also dynamic metadata maybe?
trivia: sort of half-assed patches for older games should be possible
Putting aside that I'm wondering if we shouldn't eventually explain/link what a color space, gamut, and whatnot are (maybe also bit depth and chroma subsampling, given HDR can put a serious strain on the bandwidth of cables?), I just so happen to have a new HDR monitor and this recent linux commit made me ask what this actually implies.
Guess what, it's a mess. And among all: most official FAQs are bullshit.
For starters, everybody and their cousins refer to version numbers even though they are mostly meaningless for both displayport and HDMI (a bit like happened with VRR I guess) and even when they explicitly mention specific "minimum boundaries" they are wrong.
Arguably, I could play and watch HDR content on my 290 only because AMD had the good will of updating their drivers sooner or later (and perhaps the luck of choosing flexible enough display controllers back in the days) but still.
(Nvidia and Intel weren't so courteous instead.. It's unknown if GCN 1.0 and Maxwell 1.0 are enabled then)
So what is the deal? <TBA>
> explain/link what a color space, gamut, and whatnot are
Ughhhhhhhh.... That's one topic I haven't wanted to delve into at all.
---
Regarding hardware requirements, it's at the end of the day all relative to what color depth/bitrate, refresh rate, resolution, etc selected as the bandwidth/pixel clock becomes the limiting factor.
This is the limitation that Asus ROG Swift PG27UQ and Acer Predator X27 ran into -- the DisplayPort pixel clock (and subsequently the bandwidth it resulted in) resulted in compromises being required to keep the display signal below the bandwidth limit.
Here's an overview for a 4K resolution on the Asus ROG Swift PG27UQ (though the same exact limitations applies to the Acer display as well): https://i.imgur.com/Hrr4apw.png
A user wanting to run 4K at 12-bit RGB (or no chroma subsampling at YCbCr 4:4:4) with HDR enabled would be limited to 82 Hz. Above that Nvidia's GPUs would automatically enable chroma subsampling to keep the bandwidth below limitations (and effectively result in a worse visual experience whenever the frame rate got too high, lol).
And while 4K at the normal 8-bit and RGB/YCbCr 4:4:4 is possible at 120 Hz, you wont get "proper" HDR at 8-bit -- it is generally said to require at least 10-bit color depth.
---
Nowadays the hardware requirements are pretty simple all things considered -- get a proper HDR display (not one of those HDR400 "hardly-even-entry-level" displays), a semi-modern GPU (GTX 10 series or later), an updated copy of Windows 10 and you're basically at the finishing line.
Where the major limitations are nowadays are primarily in the software-side of things. Media playback of HDR, for example, in Windows is still in its infancy and while stuff like VLC and recently MPV supports it out of the box, other players like MPC does not unless paired with madVR (and even then users can have different experiences such as Rose had where HDR passthrough didn't kick in at all). Other products such as Plex doesn't even support HDR playback on their Windows clients yet, and instead opts to tonemap it to SDR which Windows then rebalances the whitepoint of over to the HDR range (gah?!).
In games, it becomes a question whether a game makes use of DXGI's native stuff to enable HDR (which Special K itself makes use of), or if they use proprietary NVAPI or AGS calls to enable HDR on those particular hardware. Suffice to say DXGI is cross-vendor, and plays fine with Windows' own HDR settings, whereas NVAPI/AGS can result in weirdnesses where e.g. the DWM isn't restored properly to the previous color space after an Alt+Tab and whatnot.
I deliberately put the paragraph about rendering first, because you can't talk about HDR output before explaining what HDR actually is.
> "High Dynamic Range output or High Dynamic Range is a technology that first and foremost enables a screen to display an image at a much greater range of contrast. In practice this usually goes hand in hand with an increased color bit depth from standard 8-bits per color to 10-bits per color or more. In any case, both the software, graphics card (incl. driver), connection and display need to support this technology in order to actually be able to put a HDR image onto a HDR display."
The above is more than enough to explain the basics. People don't have to read the "HDR rendering" section to understand the "HDR output on a HDR display" section, which is what most people care about.
We should preferably list the two sections in order of importance and relevance, and the HDR rendering section is not as relevant or important today.
This ties into the "High dynamic range display (HDR)" option in the video settings template as well, which links to this glossary page. Listing "HDR rendering" first can incorrectly make new editors or readers believe that any and all games that supports HDR rendering should be treated as true, e.g. even older games like Half-Life 2 and the like should be set to true.
Nobody cares about the technicalities behind the feature. Everyone cares about what's relevant to them >right now< and what's required of them, and that's covered in the "HDR output on a HDR display" section.
Further on, "HDR rendering" only discusses HDR from a game and rendering perspective. It is not relevant to e.g. video content that have been recorded in HDR, which is also of interest today and should be at least partially accounted for.
All in all, we don't gain anything by listing "HDR rendering" first, and only introduces potential for misunderstandings.
You say that as if the current content is set in stone and those 2 sections are all there'll ever be. And again, you explain a topic step by step. In this case: by explaining what "HDR" (which is what the topic is, not "HDR output") actually is, then you can talk about how to make use it. Otherwise you might as well not explain HDR at all.
> "You say that as if the current content is set in stone and those 2 sections are all there'll ever be."
I am not. But the other order of those two sections better bring the >current< focus of the glossary page across. It is, as I mentioned, important to properly educate readers and authors that e.g. Half-Life 2 isn't relevant in terms of modern focus of the "HDR" term in relation to gaming.
> "And again, you explain a topic step by step. In this case: by explaining what "HDR" (which is what the topic is, not "HDR output") actually is, then you can talk about how to make use it. Otherwise you might as well not explain HDR at all. "
"HDR rendering" describes what >HDR rendering< is, not what >HDR< as a whole is about. And again, it is not necessary to understand the specifics of HDR rendering to understand the main purpose of HDR output, which is as I've mentioned the primary focus of the glossary page right now.
It's why the HDR rendering section is better listed further down the article, as you start by a short summary to get the key points of the glossary page across (HDR output in relation to PCs), and then expand upon it with details further down (how HDR rendering works internally).
It is also why e.g. Wikipedia's own HDR article looks as it does, with more in-depth information scattered in relevant sub-articles, one of which is about HDR rendering.
The summary is already at the very top: the "key points". Then you explain what the term "HDR" actually means, then how "HDR output" is a new thing. If you don't agree with that, then I have nothing else to say. That's basic article structuring. This is not a blog where the most recent changes are at the top.
