- Apr 04, 2023
-
-
- Apr 03, 2023
-
-
Some drivers (AMD Radeon RX 6700 XT, with radeonsi from Mesa 22.2.0-rc3) emit less than one invocation per pixel, presumably because they detect that the shader control flow is uniform for all pixels. Having the control flow depend on SV_Position avoids this test failure. Cf. 34bd0dd0704c613abef8a9aa3ba2a2507ed02843 in wine.
-
Because %i sscanf() converters are deprecated, and in practice clamp to [-2^31, 2^31) on 32 bit.
-
-
The expected use case where a heap is freed before its contained resources is not reasonably testable, so the ability to place a new resource is tested instead.
-
Fixes a crash on exit in Horizon Zero Dawn (which requres added SM 6.0 support). Placed resources should hold a reference to their heap: https://learn.microsoft.com/en-us/windows/win32/api/d3d12/nf-d3d12-id3d12device-createheap
-
To be consistent with enum hlsl_type_class and HLSL_CLASS_*.
-
Signed-off-by:
Nikolay Sivov <nsivov@codeweavers.com>
-
-
The convoluted code path is no longer needed.
-
With no more than one phase each of control point and fork/join type, an array is not required.
-
-
Normalise the incoming vkd3d_shader_instruction IR to the shader model 6 pattern. This allows generation of a single patch constant function in SPIR-V.
-
- Mar 24, 2023
-
-
- Mar 20, 2023
-
-
- Mar 15, 2023
-
-
- Mar 13, 2023
-
-
-
Since the introduction of instruction arrays, the parser location no longer matches the location of the current instruction. Ultimately we'll likely want to add some kind of explicit location information to struct vkd3d_shader_instruction_array, because we might do transformations that change the order of the original instructions.
-
vkd3d-shader/sm4: Do not specify a destination register for VKD3D_SM4_OP_DCL_RESOURCE in opcode_table[]. We do not set one in shader_sm4_read_dcl_resource(), and shader_sm4_read_instruction() explicitly sets this to 0.
-
VKD3D_SM4_OP_DCL_RESOURCE currently has 1 for "dst_count", but NULL for "dst". This is largely harmless because we never attempt to access the destination register of VKD3DSIH_DCL instructions, but nevertheless not quite proper.
-
- Mar 10, 2023
-
-
Inspired by a patch by Giovanni Mascellani.
-
-
-
- Mar 09, 2023
-
-
-
-
-
Currently this affects SM1 compilation only, with a minimal example like this: float4 var[3]; float4 main() : sv_target { return var[1]; }
-
- Mar 08, 2023
-
-
Signed-off-by:
Nikolay Sivov <nsivov@codeweavers.com>
-
-
-
Silences a very common warning.
-
-
-
-
d3d12_command_queue_flush_ops() can renter itself while processing signal events. Since we don't use recursive mutexes, we currently have to check some of the queue variables without holding the mutex, which is not safe. This is solved by allowing the queue to release its mutex while it is processing entries: when flushing, the queue is briefly locked, the is_flushing flag is set, the queue content is copied away and the queue is unlocked again. After having processed the entries, the queue is locked again to check is something else was added in the meantime. This is repeated until the queue is empty (or a wait operation is blocking it). This should also remove some latency when a thread pushes to the queue while another one is processing it, but I didn't try to measure any impact. While it is expected that with this patch the queue mutex will be locked and unlocked more frequently, it should also remain locked for less time, hopefully creating little contention.
-