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