[Git][wine/vkd3d][master] 5 commits: tests/shader_runner: Introduce a "cull-distance" capability.
Henri Verbeet pushed to branch master at wine / vkd3d Commits: cb7dac4d by Francisco Casas at 2025-10-29T12:24:50+01:00 tests/shader_runner: Introduce a "cull-distance" capability. - - - - - ca5bc63e by Francisco Casas at 2025-10-29T12:26:33+01:00 tests/hlsl: Add a simpler clip/cull distance test. - - - - - bc63aaf5 by Francisco Casas at 2025-10-29T13:13:44+01:00 tests/shader_runner_gl: Enable used GL_CLIP_DISTANCEs. Here I am just printing a trace message on the rare situation where GL_MAX_CLIP_DISTANCES is less than we need. The maximum in Direct3D is given by D3D#_CLIP_OR_CULL_DISTANCE_COUNT which is 8, which seems expectable here. Alternatively we could add a clip-distance capability and only enable it if gl_maxClipDistances is >= 8. Another potential problem is that OpenGL expects the gl_ClipDistance[] array to be the same size on every shader it is declared, which is a restriction I am not sure Direct3D has with its SV_ClipDistance components. Co-authored-by: Anna (navi) Figueiredo Gomes <agomes(a)codeweavers.com> - - - - - 32b622d7 by Francisco Casas at 2025-10-29T13:14:54+01:00 vkd3d-shader/dxil: Also map destination write masks for system values. Currently, on what we consider normalized vsir, destination write masks are not relative to the signature element's mask, even though source swizzles are. Also for most instructions, the source swizzles are masked by the destination write mask, as given by vsir_src_is_masked(). The DXIL parser however, is not derelativizing the destination write masks for system value signature elements, so we fix that to make it consistent with how other front-ends are handled. For instance, when the test introduced in commit ca5bc63e5e0e01fbf06979af788b82b0590fc6ba is compiled to DXIL using DXC, and then parsed using vkd3d-compiler, we get the following store instructions: vs_6_0 .input .param POSITION.xyzw, v0.xyzw, float .output .param SV_Position.xyzw, o0.xyzw, float, POS .param SV_CullDistance.x, o1.x, float, CULLDST .param SV_ClipDistance.y, o1.y, float, CLIPDST .descriptors .text label l1 ... mov o1.x <v4:f32>, sr1 <s:f32> mov o2.x <v4:f32>, sr2 <s:f32> // Note the .x write mask! ret whereas, when compiling using FXC and parsing the TPF using vkd3d-compiler we get: vs_4_0 .input .param POSITION.xyzw, v0.xyzw, float .output .param SV_POSITION.xyzw, o0.xyzw, float, POS .param SV_CULLDISTANCE.x, o1.x, float, CULLDST .param SV_CLIPDISTANCE.y, o1.y, float, CLIPDST .descriptors .text label l1 mov o0.xyzw <v4:f32>, v0.xyzw <v4:f32> mov o1.x <v4:f32>, v0.x <v4:f32> mov o2.y <v4:f32>, v0.y <v4:f32> // Note the .y write mask. ret This only really matters for cases where we have a system value semantic whose mask doesn't start at .x, which is very rare. For instance, it requires the clip/cull distance combo, which share registers, so one of them pushes the other to start on another component. According to the tests, the only thing relying on this behaviour is the handling of private variables for system value semantics on the SPIR-V backend, which expects destination write masks as if the element started at .x even though it might not. This is modified then. - - - - - f616e6c1 by Francisco Casas at 2025-10-29T13:23:29+01:00 vkd3d-shader/ir: Validate I/O destination write masks on normalised vsir. - - - - - 11 changed files: - libs/vkd3d-shader/dxil.c - libs/vkd3d-shader/ir.c - libs/vkd3d-shader/spirv.c - tests/d3d12_crosstest.h - tests/hlsl/clip-cull-distance.shader_test - tests/shader_runner.c - tests/shader_runner.h - tests/shader_runner_d3d11.c - tests/shader_runner_d3d12.c - tests/shader_runner_gl.c - tests/shader_runner_vulkan.c View it on GitLab: https://gitlab.winehq.org/wine/vkd3d/-/compare/d3f658d410c42d739bdb3513bfdbd... -- View it on GitLab: https://gitlab.winehq.org/wine/vkd3d/-/compare/d3f658d410c42d739bdb3513bfdbd... You're receiving this email because of your account on gitlab.winehq.org.
participants (1)
-
Henri Verbeet (＠hverbeet)