From: Nikolay Sivov nsivov@codeweavers.com
Signed-off-by: Nikolay Sivov nsivov@codeweavers.com --- dlls/d3dx9_36/effect.c | 18 +++--------------- 1 file changed, 3 insertions(+), 15 deletions(-)
diff --git a/dlls/d3dx9_36/effect.c b/dlls/d3dx9_36/effect.c index d84ad749f30..ffe8227185c 100644 --- a/dlls/d3dx9_36/effect.c +++ b/dlls/d3dx9_36/effect.c @@ -441,19 +441,6 @@ static inline uint32_t read_u32(const char **ptr) return u; }
-static void skip_u32_unknown(const char **ptr, unsigned int count) -{ - unsigned int i; - uint32_t u; - - WARN("Skipping %u unknown DWORDs:\n", count); - for (i = 0; i < count; ++i) - { - u = read_u32(ptr); - WARN("\t0x%08x\n", u); - } -} - static inline D3DXHANDLE get_parameter_handle(struct d3dx_parameter *parameter) { return (D3DXHANDLE)parameter; @@ -6292,7 +6279,7 @@ static BOOL param_set_top_level_param(void *top_level_param, struct d3dx_paramet static HRESULT d3dx_parse_effect(struct d3dx_effect *effect, const char *data, UINT data_size, uint32_t start, const char **skip_constants, unsigned int skip_constants_count) { - unsigned int string_count, resource_count, params_count; + unsigned int string_count, resource_count, params_count, pass_count; const char *ptr = data + start; unsigned int i; HRESULT hr; @@ -6303,7 +6290,8 @@ static HRESULT d3dx_parse_effect(struct d3dx_effect *effect, const char *data, U effect->technique_count = read_u32(&ptr); TRACE("Technique count: %u.\n", effect->technique_count);
- skip_u32_unknown(&ptr, 1); + pass_count = read_u32(&ptr); + TRACE("Pass count: %u.\n", pass_count);
effect->object_count = read_u32(&ptr); TRACE("Object count: %u.\n", effect->object_count);
I'm probably missing something... Picking `test_effect_parameter_value_blob_object[]` from the d3dx9 tests as a random example, I see that this prints "Pass count: 7". How does it get to that count?
I thought this was the function count (so I guess I was wrong)
On Thu Jul 18 19:41:38 2024 +0000, Matteo Bruni wrote:
I'm probably missing something... Picking `test_effect_parameter_value_blob_object[]` from the d3dx9 tests as a random example, I see that this prints "Pass count: 7". How does it get to that count?
Yes, I see now it's not the count I thought it is. Thanks, I'll take a look at what it means. It definitely grows with pass count. I don't think it's some sort of offset.
On Thu Jul 18 19:41:38 2024 +0000, Nikolay Sivov wrote:
Yes, I see now it's not the count I thought it is. Thanks, I'll take a look at what it means. It definitely grows with pass count. I don't think it's some sort of offset.
I think this might be a total number of shader objects, accounting for arrays as well. Confusing part is that for some reason every pass contributes to that counter too.
On Thu Jul 18 23:07:32 2024 +0000, Nikolay Sivov wrote:
I think this might be a total number of shader objects, accounting for arrays as well. Confusing part is that for some reason every pass contributes to that counter too.
That seems to be it. Kind of an interesting find; hard to guess what they'd need that count for, or even a reasonable name for it. Not that it matters a whole lot, especially on the d3dx side.
On Thu Jul 18 23:50:05 2024 +0000, Matteo Bruni wrote:
That seems to be it. Kind of an interesting find; hard to guess what they'd need that count for, or even a reasonable name for it. Not that it matters a whole lot, especially on the d3dx side.
Aaand I just stumbled on a counterexample... `test_effect_preshader_effect_blob[]` gives 14 but it has 13 objects and 2 passes (1 technique).
On Thu Jul 18 23:53:10 2024 +0000, Aida Jonikienė wrote:
I thought this was the function count (so I guess I was wrong)
What do you mean by "function" exactly?
On Thu Jul 18 23:52:42 2024 +0000, Matteo Bruni wrote:
Aaand I just stumbled on a counterexample... `test_effect_preshader_effect_blob[]` gives 14 but it has 13 objects and 2 passes (1 technique).
A few more from the d3dx9 tests:
`test_effect_preshader_ops_blob`: 1 != 1 + 1
`test_effect_shared_parameters_blob`: 6 != 5 + 2
`test_effect_skip_constants_blob`: 2 != 2 + 1
`test_effect_unsupported_shader_blob`: 6 != 5 + 1 + 1
`test_effect_null_shader_blob`: 5 != 4 + 1 + 1
`effect_code` from test_effect_clone(): 5 != 6 + 1 + 1
`test_two_techniques_blob`: 2 != 1 + 1 + 1
So, many are 1 lower than expected (not necessarily all for the same reason) but then there's effect_code which is even weirder...
On Fri Jul 19 00:43:50 2024 +0000, Matteo Bruni wrote:
A few more from the d3dx9 tests: `test_effect_preshader_ops_blob`: 1 != 1 + 1 `test_effect_shared_parameters_blob`: 6 != 5 + 2 `test_effect_skip_constants_blob`: 2 != 2 + 1 `test_effect_unsupported_shader_blob`: 6 != 5 + 1 + 1 `test_effect_null_shader_blob`: 5 != 4 + 1 + 1 `effect_code` from test_effect_clone(): 5 != 6 + 1 + 1 `test_two_techniques_blob`: 2 != 1 + 1 + 1 So, many are 1 lower than expected (not necessarily all for the same reason) but then there's effect_code which is even weirder...
I think you're comparing wrong numbers. E.g. for test_effect_skip_constants_blob this field value is 2, for 1 pass + 1 inline shader object. For test_effect_preshader_ops_blob field value is 1, and there is 1 pass, and no shader objects.
What would be useful long term is to have the compiler as a system tool, to embed blobs compiled with vkd3d for testing on Windows. Just to make sure they load at least.
Also unrelated to that, many existing tests need to be redone not to depend on embedded binary offsets for value checks.
On Thu Jul 18 23:53:10 2024 +0000, Matteo Bruni wrote:
What do you mean by "function" exactly?
The same meaning as in GLSL/HLSL I guess
On Fri Jul 19 06:17:55 2024 +0000, Nikolay Sivov wrote:
I think you're comparing wrong numbers. E.g. for test_effect_skip_constants_blob this field value is 2, for 1 pass + 1 inline shader object. For test_effect_preshader_ops_blob field value is 1, and there is 1 pass, and no shader objects. What would be useful long term is to have the compiler as a system tool, to embed blobs compiled with vkd3d for testing on Windows. Just to make sure they load at least. Also unrelated to that, many existing tests need to be redone not to depend on embedded binary offsets for value checks.
I think you're right, I was looking at the total object count, so scratch all that.
WRT testing the compiler on Windows, maybe we can add a test setup where we run our d3dcompiler (general shaders), d3dx9 (fx_2_0) and d3d10 (fx_4_0) tests with Wine builtin DLLs and make sure the tests eventually pass?
Also true on the last point: we eventually don't want tests to rely on implementation-dependent offsets. I think most (all?) the cases of that are used to look up expected results from the shader blob itself. That made it quicker to introduce tests at the time; hopefully it's not too much of a hassle to fix them up when we'll need to.
-
Aida Jonikienė (＠DodoGTA) -
Matteo Bruni (＠Mystral)
-
Nikolay Sivov
-
Nikolay Sivov (＠nsivov)