DXVK 2.1 Released With HDR Support, Many Game Improvements

[piotrj3]

its not really that there has been no progress, but HDR needs to suit a very wide variety of needs and yes, it is extremely slow, but still being hammered away on and refined, there is a LOT you have to contend with, from everything between accurate colour reproduction for creatives, to brightness normalization for people consuming HDR and SDR content at the same time (it's really not fun when you are looking at a white webpage and a video blasts so much light at you it makes it look visible dim, Thanks Apple).

so you have all sorts of tech needing their piece of the pie, and the wayland protocols need to work for people consuming games and video, to people making games and videos, you need to make these protocols suitable for everyone the consumers and the developers though I assume the development side will be a lot easier when a protocol is ironed out, or else you get what happened on windows, where everything looks washed out in "HDR mode" or you are relegated to HDR on SDR mode, where you need to use fullscreen apps and let the apps themselves exclusively handle the display and HDR.

or you get the apple problem where you need sunglasses to look at your screen. I don't think gamescope's method is "the right method" but I do think its the right method for them, I would love to see DRM leasing become a valid "HDR on SDR" mode for this, and would love to see other apps supporting gamescope for HDR, particularly games and if gamescope does find that DRM leasing will become a viable method for "HDR on SDR" even media apps I think could support gamescope.

I actually personally think HDR isn't as far off as it seems, I think the goal of 1-2 years that Red hat is predicting is a fairly viable one myself

What you write about, is correct in manner of practical usability. It is to be honest not quite easy to solve problem but possible by adjusting how SDR to HDR convertion works.

Problem is current *working* parts of HDR on linux, depend on not part of any specification work, that works only on X client working on gamescope that itself doesn't use compositor with also specific kernel patches. Not to mention it is easiest case to handle, as you don't fight against case half of my windows is SDR half of them is HDR. We don't have even prototype working on native wayland program, none of specification work went forward enough (few stuff i consider core like explicit sync are basicly stuck for 2 years in some discussions, if things are going that slowly, then i have no clue when it will arrive) etc. We currently are still veerrrry far from something actually working for average user.

[Quackdoc]

What you write about, is correct in manner of practical usability. It is to be honest not quite easy to solve problem but possible by adjusting how SDR to HDR convertion works.

Problem is current *working* parts of HDR on linux, depend on not part of any specification work, that works only on X client working on gamescope that itself doesn't use compositor with also specific kernel patches. Not to mention it is easiest case to handle, as you don't fight against case half of my windows is SDR half of them is HDR. We don't have even prototype working on native wayland program, none of specification work went forward enough (few stuff i consider core like explicit sync are basicly stuck for 2 years in some discussions, if things are going that slowly, then i have no clue when it will arrive) etc. We currently are still veerrrry far from something actually working for average user.

im not sure on how far out it is, things like MPV already have the plumbing to support HDR, when we finally do get HDR, it will pretty much be minimal effort to get it working, this is absolutely not the case for everything, but a lot of things are just waiting on the protocol stuff to get ironed out now

[CochainComplex]

As always with Nvidia, go beg in the forum, maybe pray to some god too. Otherwise you will have to wait for Nouveau to be ready or Nvidia for whatever reason suddenly getting interested in that.

Having a shrine with a small Statue of holly Huang. Inflame some dollarbills in front of it each time when you send your prayers might increase the chances.

[skeevy420]

you can test it with a very minimal config, I like to use no-config to make sure I dont have any settings interfering when I initially test, so far I have only had it working on amdvlk, but IIRC there are patches that add support for mesa drivers too, no idea if they have been merged or are in limbo, still trying to see if there is an elegant way to make it open on another session from the main session, but no luck so far, so make sure to manually swap vt first

mpv --no-config --target-colorspace-hint=yes --vo=gpu-next your-video-here.mkv

Not sure what I'm doing wrong here. That was the command I was using, AMDVLK is the one in use, and I'm using a Samsung reference video. The video plays and looks fine, only my TV doesn't switch to its HDR mode like it does with Windows or Gamescope.

[Quackdoc]

Not sure what I'm doing wrong here. That was the command I was using, AMDVLK is the one in use, and I'm using a Samsung reference video. The video plays and looks fine, only my TV doesn't switch to its HDR mode like it does with Windows or Gamescope.

I can try and replicate tonight, but best advice I have is to use vk icd name override to force amdvlk, is what I need to do, exporting it in environment isn't enough

[Melcar]

Anyone know why this release did not include the handy install script? Also noticed the instructions on the github page for installing the release packages no longer includes this method. Now they only instruct you to do it "manually", which is fine, but a bit of a pain if you have more than a few wineprefixes.

[piotrj3]

you can test it with a very minimal config, I like to use no-config to make sure I dont have any settings interfering when I initially test, so far I have only had it working on amdvlk, but IIRC there are patches that add support for mesa drivers too, no idea if they have been merged or are in limbo, still trying to see if there is an elegant way to make it open on another session from the main session, but no luck so far, so make sure to manually swap vt first

mpv --no-config --target-colorspace-hint=yes --vo=gpu-next your-video-here.mkv

That cannot work either on Xorg or Wayland because both don't support it.

So it is only limited to DRM and KMS directly and in cases when it can be managed manually by MPV, it can pass HDR data to AMDVLK and AMDVLK can output HDR data to monitor. BUT moment any other driver or Xorg or Wayland gets involved you are doomed. In fact AMDVLK supports it for ~~2 years and since those 2 years have passed only thing that changed is DXVK HDR and gamescope that again avoid Xorg or Wayland.

This is particulary painful part, we already do have driver that supports it for long time, and yet in so long time, nothing in Xorg or Wayland has changed. The HDR relevant bits in kernel exist since 5.4

[Quackdoc]

That cannot work either on Xorg or Wayland because both don't support it.

So it is only limited to DRM and KMS directly and in cases when it can be managed manually by MPV, it can pass HDR data to AMDVLK and AMDVLK can output HDR data to monitor. BUT moment any other driver or Xorg or Wayland gets involved you are doomed. In fact AMDVLK supports it for ~~2 years and since those 2 years have passed only thing that changed is DXVK HDR and gamescope that again avoid Xorg or Wayland.

This is particulary painful part, we already do have driver that supports it for long time, and yet in so long time, nothing in Xorg or Wayland has changed. The HDR relevant bits in kernel exist since 5.4

in theory IIRC you can manually launch it and have it open on another session (VT/TTY) automatically, I just cannot remeber how to achieve this, nor do I really care enough to really look into it