Skip to content
Snippets Groups Projects

vkd3d-shader: Point size.

Merged Elizabeth Figura requested to merge zfigura/vkd3d:mr0 into master

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
  • Subject: [PATCH 3/8] vkd3d-shader/d3dbc: Give output point size a system
     value.

    Do we have to? Could we e.g. create a vsir register type for this instead? The main concern is that existing users of the API may not expect to receive SV_POINT_SIZE, and may not know how to handle it. We could put that behind API_VERSION_1_14, or perhaps it's fine in practice, but it may be nicer to avoid the issue altogether.

  • Subject: [PATCH 3/8] vkd3d-shader/d3dbc: Give output point size a system
     value.

    Do we have to? Could we e.g. create a vsir register type for this instead? The main concern is that existing users of the API may not expect to receive SV_POINT_SIZE, and may not know how to handle it. We could put that behind API_VERSION_1_14, or perhaps it's fine in practice, but it may be nicer to avoid the issue altogether.

    I don't think there's any reason we can't use a different register type instead. I'll switch to that.

  • Okay, well, it's a bit tricky in terms of architecture. Having point size in the signature means that we just declare it like a normal i/o register. Having it not in the signature means that we need to synthesize a dcl_output instruction (something we'd been moving away from, I think for good reasons) or I guess we could lazily declare the spirv variable.

    I imagine the right way to address this is to add point size to the signature but with a distinct marker. Basically we want something like SV_POINT_SIZE except it should be internal and therefore not part of that enum.

    That could be the register type (but I'm not sure it should—since one of the advantages of normalized I/O is that it's, well, simpler to express and deal with internally, and having it be v#/o# in the bytecode is part of that). It could also be an "internal_sysval" enum I guess.

    I imagine this will be extended to other register semantics, vThreadID and so on.

    But at the same time I'm not sure that we want to not expose this information to the user. It's kind of pointless to speculate on hypothetical API users, but it seems like useful information. On the other hand we are hamstrung by sm4 signatures anyway...

  • added 5 commits

    • cfdfd508 - vkd3d-shader/spirv: Implement shader point size.
    • 766634b6 - vkd3d-shader: Allow controlling FFP point size through a vkd3d-shader parameter.
    • d5d49607 - tests: Test FFP point size.
    • 35b0de40 - vkd3d-shader: Allow controlling FFP point size clamping through vkd3d-shader parameters.
    • 41330a15 - tests: Test FFP point size clamping.

    Compare with previous version

  • New version preserves oPts, and uses a flag in the program to determine whether point size is written.

  • Henri Verbeet approved this merge request

    approved this merge request

  • Henri Verbeet added 98 commits

    added 98 commits

    • 41330a15...f0e31dd6 - 90 commits from branch wine:master
    • 56e5fca5 - vkd3d-shader/spirv: Always write the point size in vertex shaders.
    • a29a4288 - tests: Add a test for shader point size output.
    • 6ee17cf7 - vkd3d-shader/spirv: Implement shader point size.
    • 54092286 - vkd3d-shader/ir: Allow controlling FFP point size through a vkd3d-shader parameter.
    • 3ddf4664 - tests/shader_runner: Trace the "clip-planes" cap.
    • ec53e325 - tests: Test FFP point size.
    • 1e3c1392 - vkd3d-shader/ir: Allow controlling FFP point size clamping through vkd3d-shader parameters.
    • cd249a47 - tests: Test FFP point size clamping.

    Compare with previous version

Please register or sign in to reply
Loading