Mainly the implementation of SM1 comparison operators, defined in terms of CMP and SLT instructions, and the capacity to transform SLT->CMP for pixel shaders and CMP->SLT for vertex shaders.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/706
I goofed.
This commit replaces the use of "print" with "printf" in awk to avoid a newline in
the value of $xfcount, and replaces ">", which creates the spurious file, with "-gt" in the comparison.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/705
~~This applies on top of !672, the last three commits belong here.~~
Here we compute additional "synthetic" loops that will be used to implement non-trivial forward edges using (possibly conditional) `break` instructions.
--
v4: vkd3d-shader/ir: Sort loop intervals.
vkd3d-shader/ir: Generate synthetic intervals for forward edges.
vkd3d-shader/ir: Compute loop as intervals of the block order.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/698
--
v5: vkd3d-shader/fx: Add support for writing shared object descriptions for fx_4_x.
vkd3d-shader: Add an option to enable child effects compilation.
vkd3d-shader/fx: Add initial support for writing uninitialized vertex/pixel shader objects.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/692
--
v3: vkd3d-shader/dxil: Implement DX instruction Barrier.
vkd3d-shader/spirv: Emit a trace message if TGSM alignment is ignored.
vkd3d-shader/dxil: Implement structured groupshared address space global variables.
vkd3d-shader/dxil: Implement raw groupshared address space global variables.
vkd3d-shader/spirv: Support zero-initialisation for workgroup memory.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/681
On Tue Mar 12 13:47:41 2024 +0000, Yuxuan Shui wrote:
> @Alcaro Thank you for the help!
Yes, that certainly would explain your symptoms, and why I never saw those issues. That's why Proton has a beta period, isn't it? Sounds like an easy fix, easier than comparing media types.
Code duplication certainly has drawbacks, but I don't think we can blame me or WineHQ for this one; if you fork an active codebase, you get merge conflicts, and sometimes even behavioral conflicts like this. We can't let a fork constrain upstream development, can we? The safest way to avoid such trouble is get your code upstreamed.
The stream order is indeed not guaranteed; as long as the input video bytestream is the same, I'm trusting that the stream order is also the same.
Maybe that's naive of me, maybe it is indeed safe. I didn't check.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4449#note_64418
On Tue Mar 12 13:40:49 2024 +0000, Yuxuan Shui wrote:
> I spotted the problem. In `init_stream`:
> ```c
> stream->wg_stream = wg_parser_get_stream(reader->wg_parser,
> reader->stream_count - i - 1);
> ```
> vs `reinit_stream`:
> ```c
> stream->wg_stream = wg_parser_get_stream(reader->wg_parser, i);
> ```
> Though indeed the order of the streams is not guaranteed to stay the
> same (as per @rbernon)
(Sorry forgot to mention this is proton only)
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4449#note_64413