It looks like when the data is available but the recursion limit is reached Windows (after 7 when WinHttpQueryDataAvailable is concerned) fills the output immediately and only queues completion callback. I hope the updated test should be stable as we should have the server response read during WinHttpSendRequest already (like on Windows).
Fixes market window in Black Desert Online.
The game depends on WinHttpReadData returning the result synchronously in WINHTTP_CALLBACK_STATUS_DATA_AVAILABLE callback (and doesn't mind WINHTTP_CALLBACK_STATUS_READ_COMPLETE at all). By the time it reaches there through previous callbacks the recursion limit doesn't allow full synchronous return (and after playing with test_recursion() I think at least Windows 10 has the same recursion limit as we do currently). But as the test shows the output of WinHttpReadData / WinHttpQueryDataAvailable is filled in immediately, probably only the callback should be queued asynchronously to break the recursion.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4925
Since recently, unwinding never should need to look at the
unix libs any longer, and as aarch64 requires PE builds, there
should be no need to unwind through any .dll.so files any
longer.
Remove assembly unwind opcodes in the aarch64 unixlib.
These no longer are needed, as none of the code in unix libraries
is being unwound any more.
We could probably remove all the `__ASM_CFI` from all the other `unix/signal_*.c` files, but I kept this limited to aarch64 for now.
--
v2:
https://gitlab.winehq.org/wine/wine/-/merge_requests/4937
Since recently, unwinding never should need to look at the
unix libs any longer, and as aarch64 requires PE builds, there
should be no need to unwind through any .dll.so files any
longer.
Remove assembly unwind opcodes in the aarch64 unixlib.
These no longer are needed, as none of the code in unix libraries
is being unwound any more.
We could probably remove all the `__ASM_CFI` from all the other `unix/signal_*.c` files, but I kept this limited to aarch64 for now.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4937
While armv7 generally tolerates unaligned loads/stores in most
cases, the compiler is free to use the ldrd/strd instructions,
for loading/storing two consecutive 32 bit registers, and this
requires the destination to be aligned to a 4 byte boundary.
When packing a number of variable length structures, make sure
that each actual struct gets aligned at the right address
boundary.
This fixes crashes in DllMain of wineps.drv, when built for
armv7, since 351e58dc2d0aafe19294cbeaed9cd30ae965d591.
Signed-off-by: Martin Storsjö <martin(a)martin.st>
--
v2: wineps.drv: Avoid invalid unaligned accesses.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4930
This is a preliminary pass for the control flow graph structurizer. The plan, at least for the first version of the structurizer, is to have this pass, then another pass that converts all SSA registers to TEMPs (and correspondingly PHI nodes to MOVs/MOVCs), then a simple structurizer based on the so-called Böhm–Jacopini theorem. Some changes to the SPIR-V backend will also be needed, for supporting BOOL TEMP registers and fixing some details of 64 bit types.
But this pass is already quite complicated, so large enough for its own MR.
--
v2: vkd3d-shader/ir: Fixup PHI nodes when lowering switches to selection ladders.
vkd3d-shader/ir: Lower monolithic switches to selection ladders.
vkd3d-shader/spirv: Emit an error if merge information is missing.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/598
Goes atop !583. The last two commits belong to this MR.
--
v2: vkd3d-shader/spirv: Emit a vector bitcast if necessary in spirv_compiler_emit_load_ssa_reg().
vkd3d-shader/dxil: Implement DX intrinsic TextureLoad.
vkd3d-shader/dxil: Implement DX intrinsic RawBufferLoad.
vkd3d-shader/dxil: Load raw/structured buffer SRV/UAV descriptors.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/601
Windows SDK skips the value 14 and KMTQAITYPE_DISPLAY_UMDRIVERNAME was assigned
a value of 71 in the SDK but wasn't in the correct order.
Moved KMTQAITYPE_DISPLAY_UMDRIVERNAME to be correct location and left the assignment to make it clear as it's value.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4935
Signed-off-by: David Kahurani k.kahurani(a)gmail.com
--
v4: dlls/gdiplus: Use path_list to path helper in GdipWidenPath.
dlls/gdiplus: Use path_list to path helper in GdipFlattenPath.
dlls/gdiplus: Use GdipCreatePath2 when serializing paths
dlls/gdiplus: Use GdipCreatePath2 in GdipClonePath
https://gitlab.winehq.org/wine/wine/-/merge_requests/4803
I just noticed that a8b0c0391273bbeeec9ca9438fc0d2fa8d2ccd90 makes test `switch.shader_test` fail on my M2 MacBook with MoltenVK 1.2.7. I haven't debugged that yet, but it seems pretty consistently reproducible. It doesn't seem to happen on the macOS CI runner (which is Intel-based, though).
Specifically the failure is:
```
shader_runner:735: switch.shader_test:553: Test failed: Got {1.00000000e+00, 2.00000000e+00, 3.00000000e+00, 4.00000000e+00}, expected {7.00000000e+00, 8.00000000e+00, 9.00000000e+00, 1.00000000e+01} at (0, 0).
```
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/577#note_58880
Libunwind hasn't been necessary for unwinding through the ELF
bits since 03d4ba67f4a0b75548f27eb4bf1c4715888de07d.
This reduces the number of potential build configurations to
keep track of.
Signed-off-by: Martin Storsjö <martin(a)martin.st>
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4931
While armv7 generally tolerates unaligned loads/stores in most
cases, the compiler is free to use the ldrd/strd instructions,
for loading/storing two consecutive 32 bit registers, and this
requires the destination to be aligned to a 4 byte boundary.
When packing a number of variable length structures, make sure
that each actual struct gets aligned at the right address
boundary.
This fixes crashes in DllMain of wineps.drv, when built for
armv7, since 351e58dc2d0aafe19294cbeaed9cd30ae965d591.
Signed-off-by: Martin Storsjö <martin(a)martin.st>
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4930
This makes some of the wine build tools handle LTO properly (when passed via CFLAGS/LDFLAGS in some way). Of course more work is needed for a successful build with LTO, but not that far fetched honestly (asm functions are the biggest issue, also because they can call "seemingly unused" C functions which have to be marked with the `used` attribute). But that's for other MRs not related to wine tools.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4908
Building for ARM with libunwind available has been broken
since 89f3c59739e6a879b6f362dfd29d41347590449d, due to
references to raise_func_trampoline that were left behind.
In Linux builds, libunwind isn't practically needed since
a27b202a4ddc314e3e856c10f2e5d010c4a88ee0 (which implemented an
internal EHABI unwinder). That unwinder currently only supports
Linux, due to relying on dl_iterate_phdr, but if necessary, we
could also try to detect support for dl_iterate_phdr in configure
for other OSes.
--
v2: ntdll: Remove libunwind support for ARM.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4928
This is a preliminary pass for the control flow graph structurizer. The plan, at least for the first version of the structurizer, is to have this pass, then another pass that converts all SSA registers to TEMPs (and correspondingly PHI nodes to MOVs/MOVCs), then a simple structurizer based on the so-called Böhm–Jacopini theorem. Some changes to the SPIR-V backend will also be needed, for supporting BOOL TEMP registers and fixing some details of 64 bit types.
But this pass is already quite complicated, so large enough for its own MR.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/598
The references to raise_func_trampoline were left behind in
89f3c59739e6a879b6f362dfd29d41347590449d.
In Linux builds, libunwind isn't practically needed since
a27b202a4ddc314e3e856c10f2e5d010c4a88ee0 (which implemented an
internal EHABI unwinder).
However if the internal EHABI support is skipped (as it would be
if building on an OS different than Linux), libunwind doesn't
seem to be able to unwind properly through all cases after the
changes in commits 5b068472141, 75d0d466ec9 and 89f3c59739e any
longer, in a non-PE build.
Signed-off-by: Martin Storsjö <martin(a)martin.st>
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4928
The rest is in MR !531.
--
v3: tests: Mark count buffers as buggy on MoltenVK.
tests: Mark a timestamp query test as buggy on MoltenVK.
tests: Mark clip distance as unsupported on MoltenVK.
tests: Mark cull distance as buggy on MoltenVK.
tests: Skip unbounded descriptor ranges tests when they're unsupported.
tests: Mark loading from stencil as buggy on MoltenVK.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/545
Once we've reached the condition for skipping a core, we will
skip all other cores in the same range as well - don't print
a fixme message for each of them.
Signed-off-by: Martin Storsjö <martin(a)martin.st>
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4929
After wglMakeCurrent(NULL, NULL); wglSwapBuffers(HDC) actually swaps buffers for the device context. That works on Windows and basically with Wine glx (as glxSwapBuffers also works on drawable and doesn't need GLX context). But that doesn't work for child window rendering: first because of NULL ctx dereference (checked for NULL elsewhere) and next because of GLX_OML_sync_control path.
Fixes Black Desert Online launcher being black screen. The launcher does the following for drawing a frame (while drawing on the child window):
```
wglMakeCurrent(hdc, valid context);
<gl drawing>
wglMakeCurrent(NULL, NULL);
wglSwapBuffers(hdc);
```
--
v3: winex11.drv: Fix wglSwapBuffers() with NULL current context with child window rendering.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4912
--
v3: vkd3d-shader/spirv: Handle the ISINF and ISNAN instructions in spirv_compiler_emit_alu_instruction().
vkd3d-shader/spirv: Implement the ISFINITE instruction.
tests/shader-runner: Add tests for floating point special values.
vkd3d-shader/dxil: Handle floating point special value comparisons in sm6_parser_emit_dx_unary().
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/584
Unlike previous vkd3d-utils interfaces, ID3D12ShaderReflection is rather more
large and complex, and will probably end up needing several new individual
scan interfaces from vkd3d-shader, which are themselves not exactly trivial to
design.
Therefore, instead of implementing everything in vkd3d-shader and then hooking
up the vkd3d-utils interfaces on top of that, this patch series copies the
existing implementation of reflection and then begins the process of moving its
implementation to vkd3d-shader.
The primary motivation here is to add reflection crosstests (primarily for the
benefit of the HLSL compiler) without being blocked on API design. Part 2 of
this patch series does this.
--
v7: tests: Test signature reflection via D3DReflect().
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/561
Recap:
My previous proposals to extend the shader_runner to SM1 were focusing on separating compilation tests ([shader] directives) from execution tests ([test] directives), and let the generic shader_runner.c:compile_shader() in charge of the former.
However, Henri was more inclined to aim for making the parser agnostic to the language of the tests so we can potentially extend the shader_runner tests to other languages such as d3d-asm. This means, removing the burden of compilation from the parser altogether, and moving it to the runners, probably through a runner->compile function pointer (even if most of them end up doing the same thing, compiling with vkd3d-shader or the native compiler, depending on availability).
Agreeing with going in this general direction, this MR contains patches to do SM1 compilation calling run_shader_tests() for SM1 profiles from the Vulkan runner (skipping execution for now), and some improvements to the qualifiers syntax.
Despite this, there are parallel discussions on:
- Whether to name the shader models individually in the [require] directives or expressing the range of shader models where the test should pass. In the latter case, whether to run for all shader models, only the lowest one in the SM1, SM4, and SM6 groups, or to allow the runner to select a shader model within the range (I feel strongly against this now, I think the runner should just retrieve a boolean in runner->check_requirements).
- Where to do the iteration across different shader models, if in run_shader_tests() or expect each runner to call run_shader_tests() several times as we do now.
But there is no need to settle on something for these yet.
---
Now, what may be the most noisy part of this MR is that even though we are calling run_shader_tests() through the Vulkan runner, this will result in calling shader_runner.c:compile_shader() instead of shader_runner_vulkan.c:compile_shader(), but if we follow the "making the parser agnostic" plan, we eventually should get rid of shader_runner.c:compile_shader() and introduce the runner->compile pointer instead.
--
v17: tests: Use the vulkan runner to run SM1 compilation tests.
vkd3d-shader/ir: Lower texkill instructions to discard_nz.
vkd3d-shader/d3dbc: Emit fixme for HLSL_RESOURCE_SAMPLE_LOD.
tests/shader-runner: Call each runner only once.
tests/shader-runner: Support reading multiple model range args for qualifiers.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/514
This allows to declare SRV buffers in the shader tests using `[buffer srv n]` blocks, and passing them to the different backends.
Also, 1/2 includes a missing bit required to parse `Buffer<>` types in the HLSL compiler.
This is a step towards supporting StructuredBuffer types in further patches.
--
v3: tests/shader_runner: Support SRV buffers.
tests/shader-runner: Override resource types of the same category.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/569
--
v4: imm32: Complete the composition string when the IME is closed.
imm32/tests: Test the effect of CPS_CANCEL and CPS_COMPLETE.
win32u: Also pass WM_KEYUP messages to ImmProcessKey.
imm32/tests: Test that WM_KEYUP are passed to ImeProcessKey.
imm32: Mask the scancode before passing it to ImeToAsciiEx.
imm32/tests: Adjust todo_wine for the new Wine CJK keyboard layouts.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4887
--
v3: imm32: Complete the composition string when the IME is closed.
imm32/tests: Test the effect of CPS_CANCEL and CPS_COMPLETE.
win32u: Also pass WM_KEYUP messages to ImmProcessKey.
imm32/tests: Test that WM_KEYUP are passed to ImeProcessKey.
imm32: Mask the scancode before passing it to ImeToAsciiEx.
imm32/tests: Adjust todo_wine for the new Wine CJK keyboard layouts.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4887
Shader Model 6 introduces a 16-bit float (half) type, and 16-bit and 64-bit integer types. Storing extra info in the type enum simplifies checking if a type is any integer, floating point or numeric type, and the declaration of SPIR-V types. The benefits depend on using enum vkd3d_data_type in the backend instead of vkd3d_shader_component_type.
Patch 2 is difficult to split because types typically flow through to vkd3d_spirv_get_type_id(), so partial changes would require new calls to conversion functions which would be deleted again later.
--
v5: vkd3d-shader/spirv: Use enum vkd3d_data_type instead of vkd3d_shader_component_type.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/263
--
v12: tests/d3d12: Test multiple clip distance inputs in test_clip_distance().
tests/d3d12: Use five clip distances for the multiple test in test_clip_distance().
vkd3d-shader/ir: Transform clip/cull outputs and patch constants into arrays.
vkd3d-shader/ir: Transform clip/cull inputs into an array.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/564
On Tue Jan 23 19:25:36 2024 +0000, Alexandre Julliard wrote:
> > It looks like before Vista it returned `STATUS_SUCCESS` which is
> current Wine implementation, but since Vista it started to return
> `STATUS_INFO_LENGTH_MISMATCH` instead
> Is there an actual app that depends on this?
We didn't know so we just tried this but in the end it didn't make any difference.
So no I don't know any such app. And it's such an edge case that I guess only way for it to matter is if someone compares `GetVersion()` with result (eg. to detect poor sandbox etc) but that seems incredibly unlikely and there's probably hundreds of other functions to compare aswell.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4834#note_58735
This was broken by commit a1830c03a50ad38ec3f857a2a8b88498d1bf5e54 ("ntdll: Add a separate helper to build the main module on Wow64."). `init_wow64()` is called on thread creation, and each new thread was re-creating the main module and `ntdll`. `+relay` seemed to be the only functionality broken by this.
That commit also made a helper which calls `NtQueryVirtualMemory(LdrInitializeThunk,MemoryBasicInformation)`, but didn't remove the original call.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4924
Allows such IMEs that process keyboard input to do so. For instance, fixes backspace and escape for handwriting methods.
Unfortunately there doesn't seem to be a way to detect the activation of non-keyboard IMEs, so this needs to be checked per-keystroke. Some rough benchmarking shows that it adds about 15 microseconds of overhead, which is somewhat dwarfed by the ~50 microseconds for the dispatch to the main thread, which was always already happening.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4923
> It looks like before Vista it returned `STATUS_SUCCESS` which is current Wine implementation, but since Vista it started to return `STATUS_INFO_LENGTH_MISMATCH` instead
Is there an actual app that depends on this?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4834#note_58683
On Tue Jan 23 16:39:13 2024 +0000, Esme Povirk wrote:
> Now that I'm looking closer, I'm even more confused. As far as I can
> tell from the tests, the parameter size of RedEyeCorrectionEffect should
> always be sizeof(RedEyeCorrectionEffect). So, why does
> GdipGetEffectParameterSize return something different?
> And if a different size is allowed to be passed in, there should be
> tests for it.
I have tested it, it always includes the size of the numareas. I have tested it, it throws InvalidParameter errors.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4661#note_58668
On Tue Jan 23 16:34:02 2024 +0000, Esme Povirk wrote:
> I don't see anything changed that would address this.
Now that I'm looking closer, I'm even more confused. As far as I can tell from the tests, the parameter size of RedEyeCorrectionEffect should always be sizeof(RedEyeCorrectionEffect). So, why does GdipGetEffectParameterSize return something different?
And if a different size is allowed to be passed in, there should be tests for it.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4661#note_58667
On Mon Jan 22 20:37:06 2024 +0000, Vijay Kiran Kamuju wrote:
> I have changed the structure of the CGpEffect and with it some
> functionality. Please re-check.
I don't see anything changed that would address this.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4661#note_58666
--
v2: vkd3d-shader/dxil: Use strcmp() to find the handle type.
vkd3d-shader/dxil: Use strcmp() to find function names.
vkd3d-shader/dxil: Use strcmp() to check the entry point name.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/591
--
v3: tests: Add tests for valid conditional types.
vkd3d-shader/hlsl: Always cast to bool in if() statements.
vkd3d-shader/hlsl: Validate that condition expressions are numeric.
vkd3d-shader/hlsl: Validate the condition data type for loops as well.
vkd3d-shader/hlsl: Copy some missing fields in hlsl_type_clone().
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/577
Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com>
--
v4: vkd3d-shader/fx: Add initial support for writing passes for fx_2_0.
vkd3d-shader/fx: Add initial support for writing fx_2_0 binaries.
vkd3d-shader/fx: Check technique type in global scope as well.
vkd3d-shader/hlsl: Allow annotations on techniques.
vkd3d-shader/hlsl: Allow annotations on passes.
vkd3d-shader/hlsl: Add passes variables to the techniques.
vkd3d-shader/hlsl: Add initial support for parsing annotations.
tests/hlsl: Add some tests for annotations.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/565
~~Other validation stuff I plan to send as soon as !450 and !550 are in.~~
~~I guess the CI is going to timeout because of too many commits, so I'll preemptively stop it.~~
--
v9: vkd3d-shader/ir: Validate PHI instructions.
vkd3d-shader/ir: Do not allow IMMCONST and IMMCONST64 as destination registers.
vkd3d-shader/ir: Refactor register-type-specific code in parameter validation.
vkd3d-shader/ir: Check that all instructions appear in a block.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/559