vkd3d-shader: Point size.
Merge request reports
Activity
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.
Toggle commit listadded 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.
Toggle commit list-
41330a15...f0e31dd6 - 90 commits from branch