--
v3: mf/tests: Test IMFClockStateSink in shutdown state.
mf/tests: Test sample processing for MPEG4 media sink.
mf/tests: Use IMFMediaEventGenerator interface in event wait helper.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3369
Recap:
I implemented relative addressing in !229, but I was suggested to handle register indexes by moving all the registers to the heap, which I did in my [nonconst-offsets-6](https://gitlab.winehq.org/fcasas/vkd3d/-/commits/noncon… branch. A part of this implementation required !269, but I was asked to try to turn the sm4 register structs into the vkd3d-shader register structs instead, to get closer to a common low level IR.
This is the first part of that transformation. The whole thing is in my [use_vkd3d_reg_4](https://gitlab.winehq.org/fcasas/vkd3d/-/commits/use_vkd3d… branch.
~~This is built on top of !225 (the first two patches), so it may be good to get that upstream first.~~
---
This patch series aims to do the following replacements:
```
struct sm4_register -> struct vkd3d_shader_register
struct sm4_dst_register -> struct vkd3d_shader_dst_param
struct sm4_src_register -> struct vkd3d_shader_src_param
```
to get us closer to a common level IR and simplify the implementation of relative-addressing.
To achieve this, the fields in the sm4 register structs are replaced with fields in the vkd3d-shader structs or removed altogether, one at the time.
As can be seen when looking at the whole branch, it is possible to do this transformation without having to add additional fields to `struct vkd3d_shader_register`, by restricting each register type to a single `enum vkd3d_sm4_dimension` (and its src registers to a single `enum vkd3d_sm4_swizzle_type`) by default.
The only exception we need so far is for sampler registers: They always have dimension NONE, except when used as arguments of gather instructions, in which case they have dimension VEC4 and SCALAR swizzle. This, and similar exceptions we may find in the future, can be handled using the opcode_info, as in 7/8 [81e17506](https://gitlab.winehq.org/fcasas/vkd3d/-/commit/81e17506ba2cb1fbf….
--
v6: vkd3d-shader/tpf: Get rid of sm4_register.dim.
vkd3d-shader/tpf: Use 's' in src_info to expect sampler register with vec4 dimension.
vkd3d-shader/tpf: Separate dst register write function.
vkd3d-shader/tpf: Separate src register write function.
vkd3d-shader/tpf: Make register_type_table an array of structs with lookup tables.
vkd3d-shader/tpf: Introduce struct tpf_writer to group sm4 write arguments.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/281
On Wed Aug 2 20:04:56 2023 +0000, Bernhard Kölbl wrote:
> Since no one answered, yet:
> 1. IIRC we don't want ReactOS code in Wine, as it might be reverse engineered.
> 2. This very likely needs tests.
I wrote the functions in question here first; and also put up a PR over there with a modified version of it.
I can think about some tests.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3360#note_41123
1. Subtracting integers may result in an overflow or underflow.
2. Right at the 'edge' of underflowing, the result of subtraction may be
`INT_MIN`, and the call to `abs()` will also result in `INT_MIN`.
This fix accounts for all of these conditions.
EXAMPLES:
1. can be encountered by comparing 2.0 and -2.0
2. can be encountered by comparing -2.0 and 2.0
NOTE:
There are 14 more instances of `compare_float` across several modules.
I would like to make sure the logic is sound with this MR, then I can take on the rest.
--
v4: ddraw/tests: Use compare_uint() in compare_float() instead of abs().
https://gitlab.winehq.org/wine/wine/-/merge_requests/3458
On Wed Aug 2 20:04:56 2023 +0000, Huw Campbell wrote:
> I had a review from the ReactOS guys with some suggestions, but before I
> make them is there any interest in taking up maintenance changes like
> the for the shell?
> Who should I ping for a review?
Since no one answered, yet:
1. IIRC we don't want ReactOS code in Wine, as it might be reverse engineered.
2. This very likely needs tests.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3360#note_41115