This patch series includes an implementation of the long-pending `transpose` intrinsic and the `smoothstep` intrinsic.
While implementing `smoothstep` I realized that some intrinsics have different rules for the allowed data types than expressions:
- Vectors and matrices at the same time are not allowed, regardless of their dimensions. Even if they have the same number of components.
- Any combination of matrices is always allowed, even those when no matrix fits inside another, e.g.:
`float2x3` is compatible with `float3x2`, resulting in `float2x2`.
The common data type is the min on each dimension.
This is the case for `max`, `pow`, `ldexp`, `clamp` and `smoothstep`; which suggest that it is the case for all intrinsics where the operation is applied element-wise. So this was corrected.
A minor fix in `pow`'s type conversion is also included.
--
v2: vkd3d-shader/hlsl: Use add_unary_arithmetic_expr() in intrinsic_pow().
vkd3d-shader/hlsl: Convert elementwise intrinsics args to the proper common type.
tests: Test for common type conversion for element-wise intrinsics.
vkd3d-shader/hlsl: Support smoothstep() intrinsic.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/53
Matteo Bruni (@Mystral) commented about dlls/d3d10/effect.c:
> + unsigned int i;
> +
> + *retval = 0.0f;
> + for (i = 0; i < instr->comp_count; ++i)
> + *retval += args[0][instr->scalar ? 0 : i] * args[1][i];
> +}
> +
> +static void pres_dotswiz(float **args, unsigned int n, const struct preshader_instr *instr)
> +{
> + float *retval = args[n];
> + unsigned int i;
> +
> + *retval = 0.0f;
> + for (i = 0; i < n; ++i)
> + *retval += *args[i] * *args[i + n / 2];
> +}
This doesn't look right to me either.
In any case, I think we want a test for this right away.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1684#note_19578
Matteo Bruni (@Mystral) commented about dlls/d3d10/effect.c:
>
> typedef void (*pres_op_func)(float **args, unsigned int n, const struct preshader_instr *instr);
>
> +static void pres_mov(float **args, unsigned int n, const struct preshader_instr *instr)
> +{
> + *args[1] = *args[0];
> +}
> +
Does this do what you want? Right now I think it just copies a pointer around.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1684#note_19577
Matteo Bruni (@Mystral) commented about dlls/d3d10/effect.c:
> { 0x211, "bige", pres_bige },
> { 0x212, "bieq", pres_bieq },
> { 0x213, "bine", pres_bine },
> + { 0x214, "buge", pres_buge },
> + { 0x215, "bult", pres_bult },
> + { 0x219, "imul", pres_imul },
> { 0x21a, "udiv", pres_udiv },
> { 0x21e, "imax", pres_imax },
> + { 0x21f, "umin", pres_umin },
> + { 0x220, "umax", pres_umax },
Same for these.
I guess you have some test in queue after this MR. Maybe it could go in early with some temporary todo_wine and error handling, if it's not too messy.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1684#note_19576
If a hlsl_ir_load loads a variable whose components are stored from different
instructions, copy propagation doesn't replace it.
But if all these instructions are constants (which currently is the case
for value constructors), the load can be replaced with a constant value, which
is what the first patch of this series does.
For instance, this shader:
```
sampler s;
Texture2D t;
float4 main() : sv_target
{
return t.Gather(s, float2(0.6, 0.6), int2(0, 0));
}
```
results in the following IR before applying the patch:
```
float | 6.00000024e-01
float | 6.00000024e-01
uint | 0
| = (<constructor-2>[@4].x @2)
uint | 1
| = (<constructor-2>[@6].x @3)
float2 | <constructor-2>
int | 0
int | 0
uint | 0
| = (<constructor-5>[@11].x @9)
uint | 1
| = (<constructor-5>[@13].x @10)
int2 | <constructor-5>
float4 | gather_red(resource = t, sampler = s, coords = @8, offset = @15)
| return
| = (<output-sv_target0> @16)
```
and this IR afterwards:
```
float2 | {6.00000024e-01 6.00000024e-01 }
int2 | {0 0 }
float4 | gather_red(resource = t, sampler = s, coords = @2, offset = @3)
| return
| = (<output-sv_target0> @4)
```
This is required to write texel_offsets as aoffimmi modifiers in the sm4 backend, since it expects the texel_offset arguments to be hlsl_ir_constant.
This series also:
* Allows Gather() methods to use aoffimmi modifiers instead of an additional source register (which is the only way allowed for shader model 4.1), when possible.
* Adds support to texel_offsets in the Load() method via aoffimmi modifiers (the only allowed method).
--
v4: vkd3d-shader/hlsl: Propagate swizzle chains in copy propagation.
vkd3d-shader/hlsl: Replace swizzles with constants in copy prop.
tests: Test constant propagation through swizzles.
vkd3d-shader/hlsl: Support offset argument for the texture Load() method.
tests: Test offset argument for the texture Load() method.
vkd3d-shader/hlsl: Use aoffimmis when writing gather methods.
vkd3d-shader/hlsl: Replace loads with constants in copy prop.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/51
This may fail for multiple legitimate reasons. Most commonly, the device may not
actually be present on the machine (it will appear in the registry regardless).
Less commonly, the device may have been removed between the call to
NtEnumerateKey and here.
We can get around the former by checking the Linked subkey value, but there is
not much point; failing to open the file gives us just as much information.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53300
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1804
When .so module initialization was moved from ntdll to winecrt0 with
commit bef09697 we lost a number of include files. FreeBSD-specific
code in dll_soinit.c uses offsetof(), so include <stddef.h>.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1770
Standalone MR:
- the argN and texture_id types could have been alternatively
changed into unsigned int.
- that would save a couple of size specifier in printf (this patch
and next ones), but at the cost of lots of other changes:
- as texture_id is used in some apply methods, that would mean
~200 function prototypes to change
- didn't count for argN (even this could be changed on function
level, contrary the previous item)
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1706
This is a draft proposal for enabling long types in wined3d.
Its purpose is to share with wined3d maintainers the best way to
enable long types. It's not meant to be committed as is (draft MR).
I tried to minimize the number of changes by migrating some types to
pure int/unsigned int types.
The net result is not a huge change, but still quite a change:
dlls/d3d11/device.c | 6 +-
dlls/d3d8/device.c | 4 +-
dlls/d3d9/device.c | 4 +-
dlls/ddraw/ddraw.c | 4 +-
dlls/wined3d/Makefile.in | 1 -
dlls/wined3d/adapter_gl.c | 32 ++++-----
dlls/wined3d/adapter_vk.c | 18 +++---
dlls/wined3d/arb_program_shader.c | 84 ++++++++++++------------
dlls/wined3d/ati_fragment_shader.c | 4 +-
dlls/wined3d/buffer.c | 16 ++---
dlls/wined3d/context_gl.c | 26 ++++----
dlls/wined3d/cs.c | 14 ++--
dlls/wined3d/device.c | 52 +++++++--------
dlls/wined3d/directx.c | 40 ++++++------
dlls/wined3d/glsl_shader.c | 112 ++++++++++++++++----------------
dlls/wined3d/nvidia_texture_shader.c | 12 ++--
dlls/wined3d/palette.c | 14 ++--
dlls/wined3d/query.c | 34 +++++-----
dlls/wined3d/resource.c | 12 ++--
dlls/wined3d/sampler.c | 4 +-
dlls/wined3d/shader.c | 51 ++++++++-------
dlls/wined3d/shader_sm1.c | 12 ++--
dlls/wined3d/shader_sm4.c | 62 +++++++++---------
dlls/wined3d/shader_spirv.c | 4 +-
dlls/wined3d/state.c | 84 ++++++++++++------------
dlls/wined3d/stateblock.c | 36 +++++------
dlls/wined3d/surface.c | 32 ++++-----
dlls/wined3d/swapchain.c | 85 ++++++++++++------------
dlls/wined3d/texture.c | 60 ++++++++---------
dlls/wined3d/utils.c | 34 +++++-----
dlls/wined3d/vertexdeclaration.c | 10 +--
dlls/wined3d/view.c | 26 ++++----
dlls/wined3d/wined3d_main.c | 16 ++---
dlls/wined3d/wined3d_private.h | 122 +++++++++++++++++------------------
include/wine/wined3d.h | 29 +++++----
35 files changed, 580 insertions(+), 576 deletions(-)
This is a fairly long series as:
- long type enabling is done on a file basis instead of the module basis.
- I tried to split as much as possible:
+ global changes (shared across multiple file)
+ type changes linked to a single file
+ printf-related changes linked to a single file.
At the implementation level, there's lots of things to be discussed:
- choice of integral type (unsigned int/uint32_t/UINT...). I tried to
follow Zebediah's guide-lines. Even if there are counter examples.
- changing type vs changing printf (there are still areas to tackle if
needed), even if some are (IMO) unavoidable (like GetLastError() or
HRESULT)
So comments welcome. I likely start next week pushing the first bits.
--
This merge request has too many patches to be relayed via email.
Please visit the URL below to see the contents of the merge request.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1446
First part of v2 of !38, trying to follow the wide feedback provided.
Following patches in: https://gitlab.winehq.org/fcasas/vkd3d/-/tree/documentation
--
v2: vkd3d-shader/hlsl: Add field-level documentation to struct hlsl_src.
vkd3d-shader/hlsl: Add field-level documentation to struct hlsl_ir_node.
vkd3d-shader/hlsl: Add field-level documentation to struct hlsl_ctx.
vkd3d-shader/hlsl: Add field-level documentation to struct hlsl_ir_var.
vkd3d-shader/hlsl: Add field-level documentation to struct hlsl_struct_field.
vkd3d-shader/hlsl: Add field-level documentation to struct hlsl_type.
vkd3d-shader/hlsl: Rename hlsl_struct_field.modifiers to "storage_modifiers".
vkd3d-shader/hlsl: Rename hlsl_ir_var.modifiers to "storage_modifiers".
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/50