[PATCH vkd3d 2/3] vkd3d-shader/hlsl: Take writemask into account when emitting a SM4 constant.

Matteo Bruni matteo.mystral at gmail.com
Wed Dec 1 10:14:21 CST 2021


On Mon, Nov 22, 2021 at 11:41 AM Giovanni Mascellani
<gmascellani at codeweavers.com> wrote:
>
> Hi,
>
> the patch has already been accepted, but since this discussion also
> concerns more long term work...
>
> On 18/11/21 18:19, Zebediah Figura (she/her) wrote:
> >> What I'm getting at is this kind of half one thing, half the opposite
> >> is bad. I think we should move towards eventually making struct
> >> sm4_instruction a proper IR and every time there is a chance of making
> >> progress in that direction we should take it.
> >
> > I don't think I see why this is half of anything. We have to translate
> > between the hlsl_ir representation of swizzles and the DXBC
> > representation of swizzles somewhere, why not here?
>
> Agreed, neither I can see what would be the two half things. As I see
> it, write_sm4_instruction is basically a serialization function, which
> is useful as it is and shouldn't do anything else than serialization,
> and struct sm4_instruction is just a way to provide structured input to
> write_sm4_instruction. I find it logical that all processing is done
> before data is fed to write_sm4_instruction, so processing and
> serialization are well separated.
>
> I think it might make sense to have another optimization framework which
> is lower level than IR, but this should happen before
> write_sm4_instruction and be essentially independent of it. It might
> reuse struct sm4_instruction, possibly with some changes to make it
> easier to manipulate (like, for example, store it in a linked list).
>
> If this were to happen, my guess is that it would make sense to have
> this pass at an actual lower level than our current IR, therefore drop
> out knowledge of the IR variables and temporaries, implying that we
> store the "actual" writemasks and swizzles, not those that make sense
> given the IR variables and temporaries. But this can only be evaluated
> once some actual optimization pass is there.
>
> Just my two cents!
>
> Giovanni.

Yeah, I still disagree at a fundamental level. I don't think further
arguing is useful; I'll try to write some patches at some point.



More information about the wine-devel mailing list