D3D shader assembler

Henri Verbeet hverbeet at gmail.com
Mon Jul 20 13:33:44 CDT 2009


2009/7/20 Matteo Bruni <matteo.mystral at gmail.com>:
> 2009/7/20 Henri Verbeet <hverbeet at gmail.com>:
>> Yeah, but you can treat the debug output just like another
>> asmparser_backend. That would mean calling the parser twice when
>> debugging, but that should be ok. You can do something similar on the
>> bytecode writing side.
>
> I'm not so persuaded on making another backend for debug messages, as
> in this way the debug things would be separated from the processing
> code, and could easily happen they don't perfectly match (by
> mistakes).
They don't necessarily have to, the debug code only has to print what
the parser read.

> If you don't feel strongly against, I prefer to just fix the debug_src
> things as you suggested, without splitting the parsed_shader
> infrastructure.
I don't feel strongly about it, but it's probably less trouble in the long run.

>> Thinking about the
>> basic design some more, it's not entirely clear to me why you've got
>> separate asmparser_*() functions for each instruction though. They
>> look largely similar, and I think the differences like e.g. number of
>> source arguments could be handled by an appropriate lookup table.
>>
>
> While in principle this is right, as many functions are indeed very
> similar, this won't be pretty practically, even excluding that some
> instructions really need special treatment. The problem is that the
> different asmparser_* functions have different signatures (0, 1, 2 or
> 3 src registers, comparison or not, etc). So the generic function
> should accept all the parameter combinations used by them (leading to
> a quite long function signature), most of them set to NULL in the
> function invocation, or it should manage a variable number of
> arguments.
Which functions need special treatment?
You can pass source arguments as an array + count, that's how they're
stored in "struct instruction" anyway. All these callbacks really do
is building an instruction and adding them to the array. You may not
need a callback for that at all. Of course this will require some
changes to the way the parser is setup.



More information about the wine-devel mailing list