[PATCH vkd3d 5/5] vkd3d-shader: Write SM1 store instructions.

Zebediah Figura (she/her) zfigura at codeweavers.com
Sun May 16 12:30:39 CDT 2021


On 5/14/21 4:41 AM, Matteo Bruni wrote:
> On Tue, May 11, 2021 at 6:36 AM Zebediah Figura <zfigura at codeweavers.com> wrote:
>>
>> Signed-off-by: Zebediah Figura <zfigura at codeweavers.com>
>> ---
>>  include/vkd3d_d3d9types.h        |  22 ++++
>>  libs/vkd3d-shader/hlsl_codegen.c | 220 +++++++++++++++++++++++++++++++
>>  2 files changed, 242 insertions(+)
> 
> Very nice. The generated bytecode looks a bit silly right now, because
> oftentimes we end up generating instructions like "mov r0, r0" but 1.
> it doesn't matter and 2. it shouldn't be hard to clean it up at some
> point.
> 
>> diff --git a/libs/vkd3d-shader/hlsl_codegen.c b/libs/vkd3d-shader/hlsl_codegen.c
>> index d4995110..0dfbfb9f 100644
>> --- a/libs/vkd3d-shader/hlsl_codegen.c
>> +++ b/libs/vkd3d-shader/hlsl_codegen.c
> 
>> +static struct hlsl_reg hlsl_reg_from_deref(const struct hlsl_deref *deref, const struct hlsl_type *type)
>> +{
>> +    struct hlsl_ir_node *offset_node = deref->offset.node;
>> +    const struct hlsl_ir_var *var = deref->var;
>> +    struct hlsl_reg ret = {0};
>> +    unsigned int offset = 0;
>> +
>> +    if (offset_node && offset_node->type != HLSL_IR_CONSTANT)
>> +    {
>> +        FIXME("Dereference with non-constant offset of type %s.\n", hlsl_node_type_to_string(offset_node->type));
>> +        return ret;
>> +    }
>> +
>> +    ret = var->reg;
>> +
>> +    ret.allocated = var->reg.allocated;
>> +    ret.id = var->reg.id;
>> +    if (offset_node)
>> +        offset = hlsl_ir_constant(offset_node)->value.u[0];
> 
> Maybe it makes sense to assert() that the offset is a HLSL_TYPE_UINT scalar?

Eh, yes, that's a good idea, will do.

> 
>> @@ -1428,6 +1523,57 @@ static uint32_t sm1_encode_dst(D3DSHADER_PARAM_REGISTER_TYPE type,
>>      return (1u << 31) | sm1_encode_register_type(type) | modifier | (writemask << 16) | reg;
>>  }
>>
>> +static uint32_t sm1_encode_src(D3DSHADER_PARAM_REGISTER_TYPE type,
>> +        D3DSHADER_PARAM_SRCMOD_TYPE modifier, unsigned int swizzle, uint32_t reg)
>> +{
>> +    return (1u << 31) | sm1_encode_register_type(type) | modifier | (swizzle << 16) | reg;
>> +}
>> +
>> +struct sm1_instruction
>> +{
>> +    D3DSHADER_INSTRUCTION_OPCODE_TYPE opcode;
>> +
>> +    struct
>> +    {
>> +        D3DSHADER_PARAM_REGISTER_TYPE type;
>> +        D3DSHADER_PARAM_DSTMOD_TYPE mod;
>> +        unsigned int writemask;
>> +        uint32_t reg;
>> +    } dst;
>> +
>> +    struct
>> +    {
>> +        D3DSHADER_PARAM_REGISTER_TYPE type;
>> +        D3DSHADER_PARAM_SRCMOD_TYPE mod;
>> +        unsigned int swizzle;
>> +        uint32_t reg;
>> +    } srcs[2];
>> +    unsigned int src_count;
>> +
>> +    unsigned int has_dst;
>> +};
> 
> It might make sense to embrace this direction and e.g. assign a type
> to the src / dst register structs, so that you can pass a pointer to
> the struct to sm1_encode_(src,dst)() instead of each piece of register
> specification individually. 

I think the only reason I didn't do this in the first place was because
of semantic declarations, but honestly it should be easy to just create
structures, if not sm1_instruction as a whole.

That, or this code was gradually transformed from a version that didn't
even have the sm1_instruction helper.

> We could even go a step further and have
> an array of struct sm1_instruction as a low-level IR, splitting the
> actual bytecode emission from the instruction generation.
> 
> Not a must by any means, but do keep the possibility in mind: there is
> a non-zero chance that some transformation passes become much simpler
> in a lower level IR.
> 

There are probably some optimization passes that do get easy at a very
low level, though I can't immediately of any that can't also be solved
at a higher level. Plus hlsl_ir could probably be made lower-level than
it is anyway. I dunno, compilers are hard...

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20210516/8d48310c/attachment.sig>


More information about the wine-devel mailing list