On 9/1/20 18:16, Matteo Bruni wrote:
On Tue, Sep 1, 2020 at 5:08 PM Paul Gofman pgofman@codeweavers.com wrote:
On 9/1/20 17:43, Matteo Bruni wrote:
On Tue, Aug 11, 2020 at 2:31 PM Paul Gofman pgofman@codeweavers.com wrote:
Signed-off-by: Paul Gofman pgofman@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.