Doesn’t mean much as long as no game is using it.
-
“no game is using it”
-
Special K
-
Retrofitting HDR into non-HDR games…
1 Like
This isn’t getting backported to already released games.
And having the VK extension doesn’t mean developers will make use of it.
It’s an AMD extension, as far as I can see it’s not a new standard.
Out of a pool of maybe 3 exiting Vulkan games, I’m happy with that not being a feature 
If I have to support a low-level API, D3D12 has a bazillion games.
That said, the new way that Crosire is componentizing the core of ReShade, I can probably just build an ‘add-on’ renderer to handle SDR->HDR in Vulkan, by converting it to D3D11 like all the other AAA games do, lol.
The game’s primary rendering still stays Vk, but it gets this medusa’s head at the end where the output from Vk passes through to D3D11 for swapchain presentation.
I assume Vulkan is the same as DXGI and OpenGL in that developers can request and subsequently use whatever version of the API they ask for (provided the support is there for it).
If it is, then “not being backported to already released games” is irrelevant as that wouldn’t stop Kaldaien from just having Special K request a newer version of the API that supports the feature.
Same as he’s doing with DXGI and OpenGL if I remember it correctly.
This is true, and not something I spotted initially (I never opened the link). This particular extension is irrelevant as it relates to FreeSync 2 HDR usage.
Beyond that, though, Vulkan should already have native HDR support since a few years ago if I remember the last discussion I had regarding that particular Phoronix article a few weeks ago.
What part of Vulkan’s HDR implementation isn’t up to par currently? If I remember it correctly, they should support it somehow ‘natively’ already without using vendor-specific extensions.
I’ve forgotten the details though, but it was mentioned by someone somewhere last time that Phoronix article was brought up.
Basically, the same sorts of problems that hacking your way into HDR using NvAPI and AGS have. It’s not a well-oiled machine like DXGI HDR, you have to be in Fullscreen Exclusive mode, the DWM’s probably not going to go back to the original HDR setting when you alt-tab out of the game… just straight up bad for use on a computer that does things besides games.
OpenGL has an HDR extension, I’ve played with it and I hate everything about it for it basically not feeling anything at all like the platform it’s running on. Chances are you launch one OpenGL game and now the DWM’s @#%^'d an you need to logout and back in for HDR to work correctly.
I’m sure that’s down to NVIDIA’s crappy drivers, but with DXGI you’ve got Microsoft doing at least some quality control. Vk and GL are every vendor for themselves.
And, thus, we have AAA developers who I have much respect for, opting to say @#$% it and pass Vk to D3D11 so they can use DXGI instead of whatever AMD and NV duct-tape together 
Can this be related to how Vulkan doesn’t seem to support scRGB as a color space yet?
And yeah, I can imagine Fullscreen Exclusive + DWM making a mess of things. Until the VK_EXT_full_screen_exclusive extension arrived, Windows drivers would implicitly attempt to enforce exclusive mode for Vulkan games whenever possible. However using that extension it’s at least possible to prevent that sort of behavior from the driver 
They support scRGB, in fact they “support” it so much that they invented their own non-standard standard for it scRGB is supposed to be linear, but the extension spec. for Khronos’ scRGB is like two gammas in one.
Which is ironic, because sRGB was two different gamma curves joined together near-black. scRGB is not supposed to be.
13.3.4 scRGB EOTF and EOTF-1
The original sRGB specification was defined only in terms of positive values between 0 and 1. Subsequent standards,
such as scRGB annex B, use the same transfer function but expand the range to incorporate values less than 0 and greater
than 1.0. In these cases, when the input channel to the conversion is negative, the output should be the negative version of
the conversion applied to the absolute value of the input. That is:
R
0 =
−1.055×(−R)
1
2.4 +0.055, R ≤ −0.0031308
R×12.92, −0.0031308 < R < 0.0031308
1.055×R
1
2.4 −0.055, R ≥ 0.0031308
G
0 =
−1.055×(−G)
1
2.4 +0.055, G ≤ −0.0031308
G×12.92, −0.0031308 < G < 0.0031308
1.055×G
1
2.4 −0.055, G ≥ 0.0031308
B
0 =
−1.055×(−B)
1
2.4 +0.055, B ≤ −0.0031308
B×12.92, −0.0031308 < B < 0.0031308
1.055×B
1
2.4 −0.055, B ≥ 0.0031308
Note
scRGB annex B changes the behavior of the {R,G,B} = 0.0031308 case compared with the sRGB specification. Since
both calculations agree to seven decimal places, this is unlikely to be significant in most applications. scRGB annex B
does not define the EOTF -1, so the formulae below are derived by extending the sRGB formulae.
https://www.khronos.org/registry/DataFormat/specs/1.2/dataformat.1.2.pdf ### pg. 86
Someday I should really really hit the books in terms of color science and actually build myself a good understanding of it.
Though, from my short foray into it right now, I understand it as Vulkan supporting scRGB simply by using a different transfer function compared to regular sRGB as that is, as I understand it, the core difference between the two color spaces.
I started getting some hard GPU crashes in 2077.
First thought it was caused by the new Nvidia hotfix driver that fixes HDR raised blacks.
DDU and back to GRD driver, same thing. DDU and back to hotfix, no change.
Adjusted GPU OC with clock drop and massive voltage increase, same crash (mind you it happened even in main menu after couple minutes), tested stability in RDR2 which massacres my GPU and causes 400W+ draw (unlocked vBIOS), no crashing there.
Started thinking it was 1.05 patch doing this, but there’s no such reports from other people.
Narrowed it down to SpecialK, using newest version posted here. Removed it and been running for a while crash-free.
The GPU crash caused loss of signal video, only thing I can do is force reboot the PC.
My last crash log:
12-21-2020__14’02’51.rar (114.7 KB)
Kaldaien posted a new version on the Discord previously today with a unified D3D11/D3D12 codebase. It might do the trick as long as you don’t use the resolution overrides.
https://cdn.discordapp.com/attachments/778539700981071875/790532182128066570/SpecialK.7z
It can be hard to tell what version people are talking about a lot of the time. I wish the version tag of SK had some sort of short 4-6 character hash that people could include in their posts.
(Or if there is something already like that, it should be more noticeable)
Kaldaien have mentioned wanting to move over to a year/month version numbering scheme instead of the current one. If it included the day as well it’d be easy to tell exactly how up-to-date a specific copy is.
Currently the way most of us separate day-to-day versions from one another is by using the ‘Date modified’ timestamp on the DLL files.
The ‘Date modified’ timestamp will basically be the timestamp when Kaldaien compiled that particular DLL file, so it’s easy to tell how old a specific DLL file is.
Nevermind I started getting the crashes again without SK.
I give up trying to play this game any further.
If it’s not the game update then I don’t know what it could be.
Would imagine a incorrect parameter or issue with D3D12 would be a lot worse compared to D3D11 which can already take out the display driver even with AMD and NVIDIA doing their thing to prevent this.
(Or the OS being able to gracefully recover from a lot of this even if it means restarting the display driver.)
Can’t really tell what breaks though but 1.05 has it’s issues, the SMT fix is only partial and at least one quest about some “Johnny” is now broken as a NPC was removed.
In addition to whatever else is going on with the code, hopefully CD Project can eventually turn it around but they’re under a lot of pressure now I would imagine from investors and such even if the stock was kinda inflated this backlash was probably worse than expected.
(They had to have had some expectations for how poorly the old-gen console builds would be received at the very least.)
Try deleting the cache found at:
%LOCALAPPDATA%\CD Projekt Red\Cyberpunk 2077\cache
And redo the settings in your game. Apparently each time you change settings in graphics you need to delete the file in there and such so game has it compiled correctly. Some ppl claimed their crashes stopped after deleting that file and verifying files.
@JonasBeckman
“t least one quest about some “Johnny” is now broken as a NPC was removed.”
Is that the one where you get his clothes and car?
Ty for the tip
Sadly did not work