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

Paul Gofman gofmanp at gmail.com
Thu May 11 16:57:38 CDT 2017


On 05/11/2017 11:57 PM, Matteo Bruni wrote:
> 2017-05-11 22:00 GMT+02:00 Paul Gofman <gofmanp at gmail.com>:
>> On 05/11/2017 10:17 PM, Matteo Bruni wrote:
>>>
>>> As I said in my first reply, I'm okay with accepting the original
>>> patch. I'm not particularly happy with it and I hoped you would give
>>> at least a half-hearted try to the alternative but I'm not vetoing it.
>>>
>> I will look at "bytecode writer" to see how long it might be to generate
>> something. But to generate a single preshader at full I will probably need
>> to generate "PRSI" section which we are not even parsing now, also there are
>> "unknown DWORDS" skipped but it is subject to testing if native d3dx will go
>> well without them filled right
> That's an opportunity for more tests, which is good :)
Yes, but such tests are not much related to the functionality I was keen 
to bring to some more or less finalized state. Guessing these 
(partially) unknown fields and structures are of interest for effect 
compiler implementation only in my understanding, but if was starting 
that I would think the primary thing to do is HLSL shader compiler, as 
it is the fully independent part of effect compilation (usable alone), 
without which effect compiler would be mostly unusable anywhere but some 
specially crafted tests without shaders.
>> Of course there is still an
>> option to craft preshaders from a ready effect blob fixing opcodes, pretty
>> much the same way they are generated now inside the test but putting a ready
>> blob into the test file. If you are sure that it is a better approach I can
>> do that, adding an array of blobs instead of array of ops + parameters.
> What do you mean exactly? I'd be okay with creating the effect blob by
> writing a "skeleton" effect, compiling it with fxc and then manually
> adding / replacing some preshader instructions in the bytecode with
> those you want to test, fixing up the affected offsets / sizes /
> counts to account for the changed stuff.
Yes, it is pretty much what I mean here, but I don't really need to 
update any sizes as the actual preshader can take less space then it has 
in effect blob (that's what I do now in 3 argument function test 
generation where I am using a space from longer preshader). Preshader 
has instruction count in the beginning and neither native d3dx nor we 
care if there are any extra bytes after preshader end (it also has a 
sort of end marker for which no one cares either). So the essence of 
such a change is bringing effect change offline.
> With a suitable skeleton the changes should be pretty localized and
> you could document them in comments inside the blob array (and still
> document the original effect's source). In the end it would be pretty
> similar to the current test except that 1. you do the changes offline
> and not at runtime 2. the changes have comments right in the bytecode
> 3. you don't need to hack a huge effect with a lot of unrelated stuff.
I would suggest doing the following:
  1. prepare a separate blob for the instructions testing not to mess up 
with a copy of a big one which suits for different tests;
  2. comment the fields directly related to the preshader being changed 
right in the effect blob;
  3. leave the code modifying the blob online but add comments for 
setting fields.

     Otherwise I can prepare the single blob with everything buildin, 
mark preshader code in comments pointing where manual changes are, and 
leave test function just to set parameters. I could possibly do the same 
in the very beginning when was adding this test, somehow this was not 
discussed that time. But actually I was previously sure that having all 
that binary blobs in tests is an ugly but unavoidable measure, and 
generating what we need to test based on some patterns or readable data 
is preferred if possible, as makes those tests easier verifiable and 
easier producible.



More information about the wine-devel mailing list