[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wine-devel
Subject:    Re: [PATCH 1/3] d3dx9/tests: Add test for effect with unsupported shader.
From:       Matteo Bruni <matteo.mystral () gmail ! com>
Date:       2017-08-31 18:41:34
Message-ID: CABvNrtOGQQSJ+ifKRkD5+SYG69Ki=WwuJ_HNgCnuHJRysejACA () mail ! gmail ! com
[Download RAW message or body]

2017-08-31 20:35 GMT+02:00 Paul Gofman <gofmanp@gmail.com>:
> On 08/31/2017 09:25 PM, Matteo Bruni wrote:
>>
>> 2017-08-31 19:40 GMT+02:00 Paul Gofman <gofmanp@gmail.com>:
>>>
>>> +    ok(!memcmp(byte_code,
>>> +
>>> &test_effect_unsupported_shader_blob[TEST_EFFECT_UNSUPPORTED_SHADER_VSHADER_POS],
>>> +            byte_code_size), "Incorrect shader selected.\n");
>>
>> I was confused by this at first, I thought somehow the unsupported
>> vs_3_sw shader was set. That's not the case,
>> TEST_EFFECT_UNSUPPORTED_SHADER_VSHADER_POS is the position of the
>> vs_3_0 shader, but the naming throw me off.
>> Can you rename those defines to "BYTECODE_VS_3_0_POS" or something
>> that makes it clear that it refers to the hardware shader in
>> vs_arr[0]?
>>
>>
> Yes, sure, I will rename that. I just spotted I have the bytecode with
> 0x0300 version for unsupported shader (not 0x03ff as it should be for
> vs_3_sw as in effect source in #if 0), sorry for that. I tested both ways,
> the result is the same (either way it is not supported with hardware vertex
> processing), but apparently I kept wrong source for effect. I will recompile
> the code to match vs_3_sw (for easier spotting that shader in the blob).

Ah, good to know. Actually I was about to test whether vs_3_sw really
made no difference in the generated bytecode.
Your d3d9 tests made it clear that the version (sw vs hw) doesn't
really matter so this d3dx9 behavior isn't quite as surprising.



[prev in list] [next in list] [prev in thread] [next in thread]