Skip to content
Snippets Groups Projects

vkd3d-shader/fx: Handle SetBlendState().

Merged Nikolay Sivov requested to merge nsivov/vkd3d:fx4_2 into master
1 unresolved thread

Signed-off-by: Nikolay Sivov nsivov@codeweavers.com

Merge request reports

Loading
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
  • Henri Verbeet approved this merge request

    approved this merge request

  • Henri Verbeet added 6 commits

    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.

    Compare with previous version

    • Well, this is already merged, but I'm not sure I'm a fan.

      What is 3/5 actually doing? It's not obvious to me. The base type and dimx/dimy should be specific to numeric types.

      Why are we using a separate lowering pass in 4/5, instead of just handling both options on the fx side?

    • Author Developer

      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?

    • Author Developer

      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.

    • Please register or sign in to reply
Please register or sign in to reply
Loading