[PATCH 8/9] d3dx9: Add test for 'cmp' preshader opcode.

Paul Gofman gofmanp at gmail.com
Thu May 11 10:52:30 CDT 2017


On 05/11/2017 06:42 PM, Matteo Bruni wrote:
> 2017-05-11 17:32 GMT+02:00 Matteo Bruni <matteo.mystral at gmail.com>:
>> 2017-05-11 17:08 GMT+02:00 Paul Gofman <gofmanp at gmail.com>:
>>
>>> The problem is I met this opcode in the wild and thus added it in the first
>>> version of preshader implementation (and can "model" and test it by manually
>>> editing preshader code), but could not make native d3dx compiler to generate
>>> it so far. Whatever I tried in HLSL which would be a straightforward use of
>>> 'cmp' resulted in different opcode sequences. It was either generated by
>>> some earlier versions of compiler or I just could not find the conditions
>>> under which it will be used. As for adding some other 3-parameter opcode to
>>> effect blob, while scanning all the opcodes in the 3 hex digit opcode range
>>> I have found just one other 3 parameter opcode 'movc', but it seem to always
>>> return 0 and I cannot generate it in effect blob from source either. So by
>>> now I didn't find any other way to test this opcode rather than manually
>>> code it in the effect blob.
>>>
>>>      Maybe I would rather generate the code for all the other cases too? It
>>> won't make this part less evident but it will be a uniform approach.
>> Well, yes, I mean creating by hand an effect blob with the specific
>> instruction encodings you're currently testing in
>> test_effect_preshader_ops(). You might make a separate preshader /
>> state for each instruction or not (or anything in between), whatever
>> is easier.
> Not sure we're on the same page so let me try to say it differently:
> what I'd like to see is a hand-crafted effect blob which contains
> preshader(s) which use those "interesting" instructions. That would be
> used in a test replacing test_effect_preshader_ops().
>
> Hand-crafting an effect file is probably going to be a bit tedious
> (e.g. the typedefs can get quite convoluted) so I suggest you to start
> by picking a few pieces of one of the existing effect blobs (e.g.
> test_effect_preshader_effect_blob[]) and fixing up the offsets and
> counts.
>
The only feasible way for me to do and support it is to compile a small 
"sample" effect blob, take my current code as a "compiler" which will 
"fix" instructions and generate a blob and put a ready blob into the 
test. Do you think it really worth it? Instead of the table with 
parameters where one can see which values are tested, and some code 
which makes the localized changes to it, we will get a binary blob in 
test which has no public tool to compile it from any source or to 
decompile it. What if anyone else will want to add another test case for 
some instruction with different parameters? Adding such a test will 
require a full understanding of effect binary structure and will be a 
sort of nightmare.




More information about the wine-devel mailing list