vkd3d-shader/fx: Handle SetBlendState().
Signed-off-by: Nikolay Sivov nsivov@codeweavers.com
Merge request reports
Activity
added 6 commits
-
16e98727 - 1 commit from branch
wine:master
- 2c533e49 - vkd3d-shader/fx: Handle SetBlendState().
- aa0ea548 - vkd3d-shader/fx: Handle SetPixelShader() and SetVertexShader().
- c3075d6f - vkd3d-shader/hlsl: Adjust NULL type properties to make it usable in transformations.
- 873b1820 - vkd3d-shader/fx: Support NULL constants for object fields.
- ebc039d1 - vkd3d-shader/fx: Resolve NULL values for SamplerState.Texture field.
Toggle commit list-
16e98727 - 1 commit from branch
3/5 makes it possible to use hlsl_replace_node(), to replace null constant with uint(0) constant. Base type is not important here, and dimx is used for other things, not just numeric types.
4/5 what is the fx side? None of the changes affect anything else but effects. If you mean why Texture field is different, you can use case-insensitive "null" string only for "field = value;" assignments, Set*() state assignments use strictly NULL or 0.
3/5 makes it possible to use hlsl_replace_node(), to replace null constant with uint(0) constant. Base type is not important here, and dimx is used for other things, not just numeric types.
Yeah, but that should go away. Those asserts shouldn't be accessing dimx/dimy without checking if they're numeric types first.
4/5 what is the fx side? None of the changes affect anything else but effects. If you mean why Texture field is different, you can use case-insensitive "null" string only for "field = value;" assignments, Set*() state assignments use strictly NULL or 0.
I just mean, why do we need to have a pass to convert one to the other? Why can't we handle both at the point we're translating those values to FX bytecode?
Yeah, but that should go away. Those asserts shouldn't be accessing dimx/dimy without checking if they're numeric types first.
If it should, please remove it.
I just mean, why do we need to have a pass to convert one to the other? Why can't we handle both at the point we're translating those values to FX bytecode?
Many things we don't need to do, in this case it seemed easier to have a numeric constants at all times. My plan is to add at least some of the fx_2_0 handling first, and then potentially consolidate the two where possible. I see your point, it might be an improvement to simply leave nulls as is.
Yeah, but that should go away. Those asserts shouldn't be accessing dimx/dimy without checking if they're numeric types first.
If it should, please remove it.
I'll send a patch for this, though probably after the release at this rate.
I just mean, why do we need to have a pass to convert one to the other? Why can't we handle both at the point we're translating those values to FX bytecode?
Many things we don't need to do, in this case it seemed easier to have a numeric constants at all times. My plan is to add at least some of the fx_2_0 handling first, and then potentially consolidate the two where possible. I see your point, it might be an improvement to simply leave nulls as is.
Honestly, stepping back, maybe I'm too against using compiler passes for things.
I do think they're not always the right solution. Often dealing with things at translation time (whether that's translation from HLSL tokens to HLSL IR, or translation from HLSL IR to VSIR) can end up being less code. I haven't really looked to see whether that's the case here.
The other main reason to avoid compiler passes is to reduce the scope of the IR, i.e. so that it doesn't have to be complex enough to be able to express both the pre-form and the post-form. Of course, I don't think that applies here.