View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0000630 | madVR | bug | public | 2019-12-21 14:27 | 2020-02-20 17:17 |
Reporter | mclingo | Assigned To | |||
Priority | normal | Severity | major | Reproducibility | always |
Status | new | Resolution | open | ||
Platform | windows | OS | 10 | OS Version | 1809 |
Summary | 0000630: Low colour saturation when using AMD API on AMD 5700 series cards - not apparent on old RX 4/500 series | ||||
Description | When using AMD HDR APi in MADVR colours are very unsturated, it has been suggested BT2020 is not being selected for output by MADVR for this generation of cards. So far this has been reported and confirmed by a number of people including huhn on the MADVR forum. | ||||
Steps To Reproduce | Play and HDR movie using MADVR, output in HDR must be selected. | ||||
Additional Information | If Windows HDR switch is used instead and AMD API is disabled in MADVR colours are correct and normal so this seems to be an issue with how MADVR and AMD API are interacting, we cant tell if this is a MADVR or AMD issue. However this has been an issue since day one of this series of cards and AMD still havent fixed it, can a workaround be added to MADVR mabe to force BT2020 output? | ||||
Tags | No tags attached. | ||||
madVR Version | v0.92.17 + 112b madvrm beta | ||||
Media Player (with version info) | all players, main drivers / kodi ds / mpc-hc | ||||
Splitter (with version info) | lav 0.74.1 | ||||
Decoder (with version info) | lav 0.74.1 | ||||
Decoding | DXVA2 Copyback | ||||
Deinterlacing | none (progressive) | ||||
DXVA2 Scaling Active | no | ||||
Aero / Desktop Composition | Off | ||||
Problem occurs with mode | all modes | ||||
GPU Manufacturer | AMD | ||||
GPU Model | MSI amd rx 5700 8gb oc | ||||
GPU Driver Version | 19.12.3 | ||||
|
Hi, just some more info on this from user DMU on doom9, this is a support request he sent in to AMD which I dont think he's had a reply on yet, just thought it might be useful to you in case you had any ideas on a workaround as going forward its likely all new AMD will have this bug of this generation and it hasnt been fixed for months, so might not get fixed. Hi there. You have entered support for HDR mode. The agsSetDisplayMode() function used to set a specific display in HDR mode, does its job perfectly: it sends metadata to the display device, which is defined in section 6.9 «Dynamic Range and Mastering InfoFrame» according to Table 5 of the CTA-861 standard. But in the same Table 5 there is also «Auxiliary Video Information (AVI)» defined in section 6.4. And all display devices are required to use the color space (colorimetry) from this data section (AVI InfoFrame) for the current video signal. Suppose we are in SDR mode with the standard sRGB color space. And we want to switch to the HDR mode with the BT.2020 color space, which is the main one for this mode. By calling the agsSetDisplayMode() function, we put the display device in HDR mode. And we see distorted or unsaturated colors. This is because the display device did not receive the corresponding flag from the GPU in the AVI InfoFrame and is trying to display our BT.2020 color space in its sRGB. Please tell me, do you think that such HDR support in AGS_SDK is sufficient? If yes, then advise what else needs to be done so that the display device passes into the correct color space when activating the HDR mode using AGS? |
|
Received response from gareththomasamd. https://github.com/GPUOpen-LibrariesAndSDKs/AGS_SDK/issues/33 Cool, but with 20.2.1 version the AMD AGS HDR does not work at all. |
|
AGS HDR has a few requirements, e.g. it has to be D3D11, fullscreen and 10bit. Are all those requirements met in your case? Which is the last driver with which AGS HDR worked at all for you? |
|
Hi, yeah I have all those requirements in place, the fact that HDR works in MADVR with windows HDR turned on it quite telling though, it suggests that windows is locked at BT2020 and overrides MADVR somehow. with the 5700 series none of the drivers have worked with MADVR HDR unfortunately :( So thw workaround right now is to turn on windows HDR then use video app + MADVR as normal, this works fine but it looks like we'll need some sort of force BT2020 switch in MADVR for AMD NAVI cards for the forseable future. |
|
Oh wow, so the dynamic HDR switch doesn't work at all with 5700, with any driver version? That's disappointing, for sure. Have you tried the sample garththomasamd linked? Does that sample have the same problem? Or does that sample actually manage to switch to HDR mode, with the OS HDR switch turned off? |
|
Hi, no its never worked, its a shame as its a really great card with MADVR, just glad there is a workaround as your recent tone mapping work is incredible. I had a look at those links and could not find the actual samples other than some freesync stuff. i'm currently downloading everything on there but its taking ages for some reason. |
|
Thx, glad you like my tone mapping! Would be great if you could find and test that sample. If that sample works, maybe I can figure out why madVR doesn't. But if the sample also fails, then it's clear that it can't be madVR's fault. |
|
they all look to be code samples no actual video samples as such, I cant see anything to test i'm afraid. |
|
So just source code, no EXE files to run? That's a pity. No time atm to compile that stuff for you. Maybe garththomasamd can provide a simple EXE sample for you to try? Might help if you told him that madVR worked fine with AMD 4xxx series (using AMD AGS), but never worked with AMD 5xxx series? |
|
ive asked for a sample but I dont think we'll learn anything to be honest, I think we're all now sure its not a MADVR issue as it still works with last gen RX400/500 cards and they are using the same API, it must be something to do with the NAVI driver itself. |
|
thanks for having a look though, we know you're super busy with envy / tone mapping. |
|
I can check using HDFury. But I am not a programmer and I can not create code for verification. And the following is required: https://gpuopen.com/using-amd-freesync-premium-pro-hdr-code-samples/ --------------------------------------------------------- After confirming the monitor supports HDR, the swap chain is created using standard DX12 code. It is important to initialize its color format to the required HDR color format that we want to support. This would be DXGI_FORMAT_R10G10B10A2_UNORM for DisplayNative or Gamma22 and DXGI_FORMAT_R16G16B16A16_FLOAT for scRGB. The app also needs to setup its window to get exclusive full screen mode via the Windows® API. This is achieved by creating a window with borderless full screen flags and making its size and resolution match that of the monitor. --------------------------------------------------------- All that is needed is to create a full-screen window according to their requirements. And I will launch the AGS in it. PS This problem concerns not only AMD Navi video cards, but Vega too. |
|
sorry you're quite right, its just polaris which isnt affected I think. let us know what you find out DMU |
|
> After confirming the monitor supports HDR, the swap > chain is created using standard DX12 code. FWIW, madVR uses DX11. But other than that, all the requested details are fulfilled by madVR. |
|
polaris cards work totally fine with your current code as confirmed. so you have to yet again workaround a driver bug if you want to change something about this situation. maybe it works with dx12 correctly. who knows. AMD doesn't seem to really care about video playback at the moment and other stuff that doesn't crash the driver. |
|
i guess if we could find a game that uses dx12 and amd api we could test that theory Huhn, i had a look for one a while back but its impossible to get this sort of info without looking at every single game in detail one by one. |
|
Microsoft has a sample DX12 fullscreen code. https://github.com/microsoft/DirectX-Graphics-Samples/tree/master/Samples/Desktop/D3D12Fullscreen I tried to introduce the AGS HDR into it - the result is negative (no BT.2020 flag). But I'm not a programmer, maybe I did something wrong. |
|
Hi Madshi, do you think you'll be able to create some sort of workaround within MADVR itself at some point when ENVY is released, it doesnt look like AMD are going to move on this any time soon with all the other issues they have at the moment. |
|
As you said earlier: > I think we're all now sure its not a MADVR issue So I'm not really sure what I could do here. |
|
Hiya, could you maybe set MADVR to always force BT2020 output for all HDR movies somehow, or maybe create a switch we can turn on or off using a profile? The fact that it works fine in MADVR when windows HDR is also turned on suggests that MADVR can be forced to output BT2020, if you see what I mean. |
|
My understanding is that it's just the HDMI InfoFrame BT.2020 flag which is missing. Which I have no control over. The pixel data madVR renders and outputs seems to be correct, as far as I understand. |
|
another option would be to add windows HDR API back in so that could be selected over the GPU private API. |
|
Windows API is supported. You can manually switch the OS into HDR mode, and madVR should happily output HDR that way. |
|
Hi, yes but it can only be switched on manually, we're already using that as a workaround, is it not possible to bake in windows HDR so that HDR can be turned on automatically like it does for AMD/NVIDIA API? |
|
Maybe. |
|
a "use windows HDR" switch that could be toggled in MADVR so it bypasses the other API's |
|
I know you are super busy with ENVY though mate so we're not expecting anything from you at all right now, but something you could maybe think about for V1.0 relese :) |
Date Modified | Username | Field | Change |
---|---|---|---|
2019-12-21 14:27 | mclingo | New Issue | |
2020-01-09 17:16 | mclingo | Note Added: 0002612 | |
2020-02-12 07:29 | DMU | Note Added: 0002645 | |
2020-02-12 07:40 | DMU | Note Edited: 0002645 | |
2020-02-12 13:06 | DMU | Note Edited: 0002645 | |
2020-02-12 16:27 | madshi | Note Added: 0002646 | |
2020-02-12 16:32 | mclingo | Note Added: 0002647 | |
2020-02-12 16:35 | madshi | Note Added: 0002648 | |
2020-02-12 16:44 | mclingo | Note Added: 0002649 | |
2020-02-12 16:46 | madshi | Note Added: 0002650 | |
2020-02-12 16:54 | mclingo | Note Added: 0002651 | |
2020-02-12 16:56 | madshi | Note Added: 0002652 | |
2020-02-12 17:11 | mclingo | Note Added: 0002653 | |
2020-02-12 18:48 | mclingo | Note Added: 0002654 | |
2020-02-12 20:55 | DMU | Note Added: 0002655 | |
2020-02-12 21:05 | DMU | Note Edited: 0002655 | |
2020-02-12 21:21 | mclingo | Note Added: 0002656 | |
2020-02-12 21:33 | madshi | Note Added: 0002657 | |
2020-02-13 00:36 | huhn | Note Added: 0002658 | |
2020-02-13 01:06 | mclingo | Note Added: 0002659 | |
2020-02-13 08:31 | DMU | Note Added: 0002660 | |
2020-02-13 08:34 | DMU | Note Edited: 0002660 | |
2020-02-17 17:00 | mclingo | Note Added: 0002662 | |
2020-02-20 16:57 | madshi | Note Added: 0002663 | |
2020-02-20 17:05 | mclingo | Note Added: 0002664 | |
2020-02-20 17:08 | madshi | Note Added: 0002665 | |
2020-02-20 17:10 | mclingo | Note Added: 0002666 | |
2020-02-20 17:11 | madshi | Note Added: 0002668 | |
2020-02-20 17:14 | mclingo | Note Added: 0002669 | |
2020-02-20 17:15 | madshi | Note Added: 0002670 | |
2020-02-20 17:16 | mclingo | Note Added: 0002671 | |
2020-02-20 17:17 | mclingo | Note Added: 0002672 |