[PATCH v3 2/5] d3dcompiler: Add stub ID3D12ShaderReflection interface.

[Paul Gofman]

On 9/1/20 18:16, Matteo Bruni wrote:
> On Tue, Sep 1, 2020 at 5:08 PM Paul Gofman <pgofman at codeweavers.com> wrote:
>> On 9/1/20 17:43, Matteo Bruni wrote:
>>> On Tue, Aug 11, 2020 at 2:31 PM Paul Gofman <pgofman at codeweavers.com> wrote:
>>>> Signed-off-by: Paul Gofman <pgofman at codeweavers.com>
>>>> ---
>>>> v2:
>>>>       - fix reflection test in d3d10.
>>>> v3:
>>>>       - show in test that QueryInterface between ID3D11.../ID3D12ShaderReflection returns the same interface pointer.
>>> I had also noticed that the d3d11 and d3d12 interfaces coincide. It's
>>> an implementation detail and it seems very unlikely that any
>>> application depends on it, thus your implementation is certainly fine
>>> as far as I'm concerned. I'm curious though how would it look without
>>> the duplication. GetResourceBindingDesc[ByName]() will need some care,
>>> but that's the case either way.
>>> Bottom line, I'd like to see some patches for the alternative version
>>> and, if it doesn't look too terrible, probably go with that. If you
>>> already tried and it didn't feel right that's good enough for me.
>> I did not make such patches, but the idea is very simple. The only
>> binary difference between interfaces is in
>> d3d11_shader_reflection_GetResourceBindingDesc() method: d3d12 version
>> of _SHADER_INPUT_BIND_DESC is longer. We could store the structure size
>> in the reflection structure from D3DReflect() based on requested
>> interface name. Then, just return existing ID3D11ShaderReflection
>> interface for d3d12, and modify
>> d3d11_shader_reflection_GetResourceBindingDesc to copy the result to
>> output based on the stored length. As far as I interpret the tests, that
>> is exactly what the native implementation is doing. I honestly don't see
>> anything terrible about casting the interface in this case, given it
>> saves so many lines and matches native behaviour.
> Me neither, mainly I don't want to force you to spend time rewriting
> patches that you might already have. But if you want to change over to
> single vtable + version flag you have my blessing :)

I have all the reimplementing patches ready, but given the huge 
difference in size (I suppose the "aliasing" patch or two will be just a 
few lines) I guess we both spend less time if I go reimplement it this 
way, it is going to be short. Do you mind if I send the implementation 
first in the series and then the tests in the same series (probably 
squashed a bit), to avoid shuffling the todo_wine's around? Not a big 
deal to shuffle though if that is preferred.