[Windows][dxva] log conversions supported by the processor #23136
Conversation
CrystalP
force-pushed
the
dxva-processor-list-conversions
branch
4 times, most recently
from
7b88613
to
400d32b
Compare
|
The work and effort in making this is appreciated but there are some aspects of the design that I don't like: Too many changes are made to the current code (which works fine) and therefore may introduce bugs. The changes do not seem clear to me and the code is difficult to review. There are also changes that do not seem necessary or are not directly related to the PR. First I would ask to separate the deviceResources changes in a separate commit. Perhaps the changes in debug info are unnecessary and penalize performance (it is not necessary to evaluate 100 pixel formats if swap chain can only have 2). Note that this code is executed 60 times per second while the debug OSD is visible. I don't think it's necessary to make changes to That is, the new log function should call I also don't think there is much value in listing combinations that are by nature impossible i.e. all X601, P601, P709 color space for videos that are BT.2020: Perhaps it would be better to limit the listing to color spaces that match the source only. |
|
No worries, criticize away, there are many ways to do this and to present the information, it took me a while to settle on something but still am not very happy. I wish that information was dumped by dxdiag and this whole thing could be avoided, but it's not. I'm going to split into multiple commits. To address your points:
note: The input format is not very helpful to cut the list. P010 does not automatically mean BT2020. Encoding SDR with 10 bit H265 is common, same for anime in 10 bit H264.
|
CrystalP
force-pushed
the
dxva-processor-list-conversions
branch
from
400d32b
to
b587340
Compare
|
Here it is, broken up in discrete steps that should be easier to follow. Tested with SDR/HDR/HLG clips played as HDR and SDR, with HDR capable and not capable hardware. Functionality is the same as before PR in GetDXGIColorSpaceSource, with the small exception of doing for HLG what you added in 5b528b9 / PR#23109 (processor supporting TOPLEFT not LEFT) To me the benefit of separating standard mapping from the various processor limitation workarounds is that it's much easier to keep track of them that way and it should be easier when more have to be added. |
CrystalP
added
Type: Improvement
CrystalP
force-pushed
the
dxva-processor-list-conversions
branch
2 times, most recently
from
632c72d
to
442452d
Compare
|
I had already corrected and pushed for Jenkins last diff suggestion - not applicable. |
CrystalP
force-pushed
the
dxva-processor-list-conversions
branch
2 times, most recently
from
8671930
to
0df867c
Compare
CrystalP
force-pushed
the
dxva-processor-list-conversions
branch
2 times, most recently
from
293c675
to
5856f3b
Compare
CrystalP
force-pushed
the
dxva-processor-list-conversions
branch
from
5856f3b
to
c2f80d2
Compare
|
Feedback merged
I can't say I understand the threading model of Kodi and whether it's a possible scenario, but now the enumerator/enumerator1 shouldn't be destructable while being used in ListSupportedConversions() and IsFormatConversionSupported(). |
CrystalP
force-pushed
the
dxva-processor-list-conversions
branch
from
c2f80d2
to
d9bd450
Compare
|
sorry messed up the rebase, pushed a fix and will leave things alone for the rest of the day |
CrystalP
force-pushed
the
dxva-processor-list-conversions
branch
from
d9bd450
to
a76ffc9
Compare
…usive determination
…he input format in the debug log
CrystalP
force-pushed
the
dxva-processor-list-conversions
branch
from
a76ffc9
to
45c517e
Compare
|
The use of the CriticalSection was bugging me so I checked. All functions of DXVAHD are called exclusively on the render thread (main thread) so I'm not sure what the critical section is supposed to protect. Did you have other concerns or does this seem ready to merge? The Jenkins build failure of android-arm64-docker is not related. |
|
Jenkins build this please |
|
@CrystalP |
Description
New function to log the conversion capabilities of a dxva processor, based on the Windows 10 function ID3D11VideoProcessorEnumerator1::CheckVideoProcessorFormatConversion().
On Windows 8 the function exits early and logs nothing.
The input format (NV12, P010, ...) is fixed by the file being played and the function will go over possible combinations of the other 3 parameters of a color conversion:
In order to make it the logged information more readable the function adds special marks to the values currently chosen by Kodi's algorithms, the values that are a more natural mapping but may be missing processor support,
A few technical points:
Motivation and context
Helps with troubleshooting and fixing of dxva processor issues.
A previous PR started testing whether the conversion is supported, this PR lists possible alternatives for a fix.
How has this been tested?
Window 10: Intel 4th and 8th gen, AMD Cezanne igfx
to help with the testing, put a breakpoint in DXVAHD.cpp on the last line of ListSupportedConversions
No Windows 8 needed because the new code exits early under W8.
The processor of Intel 8th gen is strange and CheckVideoProcessorFormatConversion() rejects some conversions even though the processor is able to output a picture (maybe it falls back on a default conversion, with some visual imperfections - unknown at this time). That testing will continue.
What is the effect on users?
no direct effect and the code activates only when the log level is debug.
Screenshots (if appropriate):
Example of a couple lines - not a complete log
Types of change
Checklist: