[PATCH vkd3d v3 05/12] vkd3d-shader/hlsl: Add Gather methods with offset and tests.

Zebediah Figura (she/her) zfigura at codeweavers.com
Mon Dec 20 11:39:55 CST 2021


On 12/20/21 10:14, Francisco Casas wrote:
> December 17, 2021 8:13 PM, "Zebediah Figura (she/her)" <zfigura at codeweavers.com> wrote:
> 
>> Just to nitpick, how about "gather_r" or "gather_red"? Just because the 4 is there in DXBC doesn't
>> mean it has any semantic meaning.
> 
> Okay, I will change those.
>   
>> I think the assert is a bit superfluous.
>>
>> On the other hand, when this kind of code pattern comes up, I tend to prefer using a helper, along
>> the lines of
>>
>> else if (!strcmp(name, "GatherGreen"))
>> {
>> add_gather(HLSL_RESOURCE_GATHER_GREEN, 1, ...);
>> }
>>
>> which avoids that kind of implicit agreement.
> 
> I am more inclined to just remove the assert.
> I must confess that I don't like jumping from function definition to function definition too much,
> so I prefer not to make new functions unless they will be called in two or more different places.
> 
> But if you insist I will add the helper, and not follow that policy of mine too much.
> In that case I think it would also make sense to add helpers for Load and Sample too.
> This since the code for these methods is fairly similar, so I think it would be better to keep
> them close, also for the sake of consistency.

I don't personally mind large functions, but on the other hand, the code 
style we use in wined3d tends to be relatively liberal with helpers (as 
long as they're well-defined, I guess.)

It's a minor thing, really, just something that struck me as a possible 
improvement.

> 
>>> + if (status_out_arg != -1)
>>> + FIXME("Ignoring 'status' output parameter.\n");
>>
>> This probably should be hlsl_fixme().
>>
>>> +
>>> + if (params->args_count == 6 || params->args_count == 7)
>>> + FIXME("Ignoring multiple offset parameters.\n");
>>
>> And this pretty certainly should.
>>
> 
> Okay! I see.
> 
>>> + int n_srcs = 0;
>>
>> I would just leave out this variable and use "instr.src_count" directly.
> 
> Okay.
> 
>> Hmm, looking at this, it is a little tempting to add a separate field instead. Have you considered
>> that approach?
> 
> I have considered adding a "channel" field to struct hlsl_ir_resource_load and only
> have one value for the Gather* methods in enum hlsl_resource_load_type.
> 
> The disadvantage of the "channel" field is that it won't be used by other resource load
> instructions, and that dump_ir_resource_load() may get a little more complicated.
> If you think that's ok I can change it.

It wouldn't be the first field that's only relevant to some load ops, at 
least.

> FWIW I don't think these switch cases hurt too much,
> and eventually a function or a switch would be needed to map "channel" to the right swizzle anyways.

Well, it'd presumably be a HLSL_SWIZZLE_* value, so you don't need a switch.

But yes, in terms of duplicated code it's relatively anodyne I think. 
Hence more of a "have you considered" kind of question.



More information about the wine-devel mailing list