--
v14: tests: Mark the tessellation pipeline as buggy on MoltenVK.
tests: Mark geometry shaders as buggy on MoltenVK.
tests: Mark ReadFromSubresource() and WriteToSubresource() as todo on MoltenVK.
tests: Mark a test related to instanced draws as buggy on MoltenVK.
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: Mark unbounded descriptor ranges as buggy on MoltenVK.
tests: Mark loading from stencil as buggy on MoltenVK.
tests: Mark resource arrays as buggy on MoltenVK.
tests: Mark predicated rendering as buggy on MoltenVK.
tests: Mark streaming output as buggy on MoltenVK.
tests: Mark some sampling tests as buggy on MoltenVK.
vkd3d-shader/spirv: Specify behavior for bit field instructions.
tests: Use a uint target for rendering uint data.
vkd3d: Specify the aspect when creating NULL UAVs.
ci: Dump the d3d12 summary line in the CI log.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/531
While debugging a test failure on MoltenVK I discovered that commit 66cb2815f0662713c3255113255cfd7cf5e406fb triggers a validation failure in `test_shader_input_output_components()`:
```
VUID-RuntimeSpirv-OpTypeVector-06816(ERROR / SPEC): msgNum: 79036675 - Validation Error: [ VUID-RuntimeSpirv-OpTypeVector-06816 ] Object 0: handle = 0x590000000059, type = VK_OBJECT_TYPE_SHADER_MODULE; Object 1: handle = 0x5a000000005a, type = VK_OBJECT_TYPE_SHADER_MODULE; | MessageID = 0x4b60103 | vkCreateGraphicsPipelines(): pCreateInfos[0] starting at Location 2 Component 0 the Output (VK_SHADER_STAGE_VERTEX_BIT) has a Vec4 while Input (VK_SHADER_STAGE_FRAGMENT_BIT) as a Vec3. Enable VK_KHR_maintenance4 device extension to allow relaxed interface matching between input and output vectors. The Vulkan spec states: Any OpTypeVector output interface variables must not have a higher Component Count than a matching OpTypeVector input interface variable (https://www.khronos.org/registry/vulkan/specs/1.2/html/vkspec.html#VUID-Run…)
```
The validation error seems to be related to the MoltenVK failure I'm debugging, but there must be something more because testing on the parent commit gets rid of the validation error, but not of the MoltenVK failure, which incidentally is:
```
[mvk-error] VK_ERROR_INITIALIZATION_FAILED: Render pipeline compile failed (Error code 3):
Fragment input(s) `user(locn2_3)` mismatching vertex shader output type(s) or not written by vertex shader.
d3d12:11826: Test 4: Test failed: Got {0.00000000e+00, 1.00000000e+00, 0.00000000e+00, 1.00000000e+00}, expected {0.00000000e+00, 1.00000000e+00, 0.00000000e+00, 2.50000000e-01} at (0, 0).
```
Even if the validation error is not the direct cause of the failure, it looks like something we'd want to fix anyway.
I intent to spend some more time on this, but if in the meantime somebody more expert of I/O interfaces wants to have a look, now you know!
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/464#note_56708
d2d9f713d forces us to create a separate wined3d_texture for texturing or RTV usage. I don't know why it was done this way instead of just continuing to allow CPU textures to be used as a texture/RTV; unfortunately neither the commit message nor the patches as submitted on wine-devel give any explanation.
Even at that point the offending Emperor texture wasn't created with any bind flags. (Despite the fact that a color fill uses an RTV, it wasn't created with WINED3D_BIND_RENDER_TARGET; we don't currently validate that.)
ee7d047dd55a forces all sysmem textures to get a draw texture. That means that the color fill acts on the draw texture instead of the sysmem texture, and the subsequent blits use ddraw_surface_get_any_texture() and hence pick the draw texture since that location is valid.
It does slightly bother me that we're reimplementing all this logic on the client side, but I guess there was a reason for doing it this way...
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4781#note_56702
MR !531 contains the rest.
--
v2: tests: Mark resource arrays as buggy on MoltenVK.
tests: Mark predicated rendering as buggy on MoltenVK.
tests: Mark streaming output as buggy on MoltenVK.
tests: Mark some sampling tests as buggy on MoltenVK.
vkd3d-shader/spirv: Specify behavior for bit field instructions.
tests: Use a uint target for rendering uint data.
vkd3d: Specify the aspect when creating NULL UAVs.
ci: Dump the d3d12 summary line in the CI log.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/532
Currently there is `NtContinue()` test only for `aarch64` so implement it for amd64 aswell.
This implementation is very similar to `aarch64` and it's very basic test.
It doesn't change/test `ContextFlags` so it won't catch https://bugs.winehq.org/show_bug.cgi?id=56050 but that can be implemented later on top of this.
--
v6: ntdll/tests: Implement test_continue() for amd64
https://gitlab.winehq.org/wine/wine/-/merge_requests/4720
Conflicts with !450 but can probably go upstream before it since backend changes here are minimal.
--
v7: vkd3d-shader/dxil: Handle the DXIL SWITCH instruction.
vkd3d-shader: Rename shader_instruction_array_add_icb() to shader_instruction_array_add_opaque_param().
vkd3d-shader/dxil: Handle the DXIL PHI instruction.
vkd3d-shader/dxil: Handle the DXIL BR instruction conditional variant.
vkd3d-shader/dxil: Handle the DXIL BR instruction unconditional variant.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/491
I am confused - once upon a time, there would have been only a sysmem surface on the wined3d side, and wined3d does the clear directly on its system memory and reads the data from the source's system memory in the Blt() call.
Nowadays we have a video memory draw texture for sysmem surfaces because one can use them for texturing on native ddraw.
Is the issue here that ddraw accidentally made wined3d perform stuff on the vidmem draw texture rather than the 'original' system wiend3d_texture?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4781#note_56670
This mainly allows Wine to reset the tty settings upon
termination and not let gdb do it (cf bug report).
Change: user is now required to explicitely terminate gdb
('quit' command) upon debuggee termination.
Wine-Bugs: https://bugs.winehq.org/show_bug.cgi?id=56032
Signed-off-by: Eric Pouech <epouech(a)codeweavers.com>
--
v2: winedbg: Wait for gdb to terminate before exiting (proxy mode).
https://gitlab.winehq.org/wine/wine/-/merge_requests/4776
--
v2: vkd3d-shader/dxil: Pre-allocate instruction space for globals in sm6_parser_globals_init().
vkd3d-shader/dxil: Count global variables in dxil_block_compute_module_decl_count().
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/505
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.
--
v6: tests: Use the vulkan runner to run SM1 compilation tests.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/514
So that ddraw isn't always loaded, esp. for app not requesting vmr7.
Could lower memory pressure on 32bit.
Note: on win10, the native 32bit and 64bit quartz DLL delay imports ddraw.
Signed-off-by: Eric Pouech <epouech(a)codeweavers.com>
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4753
On Fri Dec 22 23:04:14 2023 +0000, Petrichor Park wrote:
> OK, and this is because the code is *compiled* in `compile_shader`, but
> it's only checked for validity in the `STATE_PREPROC`? So it's showing
> the line where the preprocessing is done even though it "should" be
> showing the line where the compiling is done?
I'd say the point is rather that, independently of whether you're testing compilation or preprocessing, while the parser is scanning the code section the code itself [is only copied line by line in buffer `shader_source`](https://gitlab.winehq.org/wine/vkd3d/-/blob/78343dcf87d3a911264c6c9a87a9146c43c859c3/tests/shader_runner.c#L1464). Only then the following line beginning with `[` is found the parser knows that the section is finished and [can preprocess/compile it](https://gitlab.winehq.org/wine/vkd3d/-/blob/78343dcf87d3a911264c6c9a87a…. By that moment the line number is that of the beginning of the following section, which might result in a misleading error message, unless you set a different context while the parser is [within the scope of `if (!ret || line[0] == '[')`](https://gitlab.winehq.org/wine/vkd3d/-/blob/78343dcf87d3a911264c6c9a87a9146c43c859c3/tests/shader_runner.c#L1161).
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/516#note_56610
Currently, if a probe fails, it will print the line number of the [test]
block the probe is in, not the line number of the probe itself. This
makes it somewhat difficult to debug.
This commit makes it print the line number that a test fails at.
This code was actually written by @hverbeet for my first attempt at fixing this, !499.
CC @zfigura
--
v3: tests: Print the failing line numbers when a test fails.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/516
Many of these patches are small, but the series can be split in two if necessary.
--
v6: vkd3d-shader/spirv: Handle ITOI and UTOU in spirv_compiler_map_alu_instruction().
vkd3d-shader/spirv: Support UINT64 source in spirv_compiler_emit_bool_cast().
vkd3d-shader/spirv: Support 64-bit sources in spirv_compiler_emit_int_div().
vkd3d-shader/spirv: Introduce a UINT64 component type.
vkd3d-shader/spirv: Introduce a data_type_is_64_bit() helper function.
vkd3d-shader/spirv: Use data_type_is_integer() in spirv_compiler_emit_neg().
vkd3d: Pass int64 capability info to vkd3d-shader.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/490
This MR stems out from testing if an app may be detecting
Wine presence by checking wine_get_version() entry point
presence in ntdll.
I had wished that simply commenting out the entry point in
ntdll.spec would be sufficient.
It isn't as 2 buitin DLLs directly link to wine_get_version().
This MR let them dynamically load the entry point's address.
For the record, there are three other DLLs/programs which
make use of wine_get_version(), but using dynamic loading.
I can live without this MR being merged upstream, but looked
a good idea:
- to be consistent throughout the code
- allow the simple comment in ntdll.spec to be possible.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4772
When len is 256, (ARRAY_SIZE(title) - len) is 0. When LoadStringW() is called with the last parameter
being zero, a WCHAR string pointer is stored at 'title + 256', writing title out of bounds.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4767
Currently there is `NtContinue()` test only for `aarch64` so implement it for amd64 aswell.
This implementation is very similar to `aarch64` and it's very basic test.
It doesn't change/test `ContextFlags` so it won't catch https://bugs.winehq.org/show_bug.cgi?id=56050 but that can be implemented later on top of this.
--
v5: ntdll/tests: Implement test_continue() for amd64
https://gitlab.winehq.org/wine/wine/-/merge_requests/4720
This MR implements `NtContinueEx(PCONTEXT, PCONTINUE_OPTIONS)` which was added in Windows 10 20H1.
Also added basic test reusing existing `test_continue()` (included from !4720)
League of Legends game hooks `NtContinue()` and `NtContinueEx()` by putting `jmp` instruction in front of it.
Note that LoL doesn't actually use `NtContinueEx()` itself and game will work fine without it but if game doesn't find `NtContinueEx()` it will permanently ban your account due to detecting "scripting program"
--
v2: ntdll/tests: Add basic test for NtContinueEx()
ntdll: NtContinueEx() handle few error cases
ntdll: Implement NtContinueEx()
https://gitlab.winehq.org/wine/wine/-/merge_requests/4761
This MR implements `NtContinueEx(PCONTEXT, PCONTINUE_OPTIONS)` which was added in Windows 10 20H1.
Also added basic test reusing existing `test_continue()` (included from !4720)
League of Legends game hooks `NtContinue()` and `NtContinueEx()` by putting `jmp` instruction in front of it.
Note that LoL doesn't actually use `NtContinueEx()` itself and game will work fine without it but if game doesn't find `NtContinueEx()` it will permanently ban your account due to detecting "scripting program"
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4761
I think this is a security issue. Listening to 0.0.0.0 instead of my VPN address that is not yet up is a problem.
With the fix, the bind fails if the address is invalid.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4760
On Sat Dec 30 18:30:27 2023 +0000, Dāvis Mosāns (davispuh) wrote:
> changed this line in [version 3 of the diff](/wine/wine/-/merge_requests/4720/diffs?diff_id=91593&start_sha=7ed40b96224c3125f2ecbda44a47cf553e1cb82a#1104a825a741495a2a3c3093b4d85d95e4f8180f_4467_4468)
Are you suggesting to clear them? I don't think that's good idea since most of them will be zeros anyway. Current implementation allows to more easily see if something doesn't get restored back. They all are filled with particular pattern.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4720#note_56500
On Sat Dec 30 18:30:27 2023 +0000, Dāvis Mosāns (davispuh) wrote:
> changed this line in [version 3 of the diff](/wine/wine/-/merge_requests/4720/diffs?diff_id=91593&start_sha=7ed40b96224c3125f2ecbda44a47cf553e1cb82a#1104a825a741495a2a3c3093b4d85d95e4f8180f_4443_4442)
Yeah I know but I intentionally did that way to make it easier understandable/readable as I don't think few bytes matter at all. Anyway changed now.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4720#note_56499
On Sat Dec 30 18:30:26 2023 +0000, Dāvis Mosāns (davispuh) wrote:
> changed this line in [version 3 of the diff](/wine/wine/-/merge_requests/4720/diffs?diff_id=91593&start_sha=7ed40b96224c3125f2ecbda44a47cf553e1cb82a#1104a825a741495a2a3c3093b4d85d95e4f8180f_4502_4494)
Fixed
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4720#note_56498
On Sat Dec 30 18:30:25 2023 +0000, Dāvis Mosāns (davispuh) wrote:
> changed this line in [version 3 of the diff](/wine/wine/-/merge_requests/4720/diffs?diff_id=91593&start_sha=7ed40b96224c3125f2ecbda44a47cf553e1cb82a#1104a825a741495a2a3c3093b4d85d95e4f8180f_4427_4429)
Can't stand it, updated to it now.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4720#note_56497
Main window title was incorrect in a couple of cases:
- the value displayed when the .HLP file didn't contain nor
the main window caption nor the default help file title
was incorrect (they are different patterns used, but the
trigger was incorrect)
- some titles were cropped (because incorrectly stored in
main window caption - which is of fixed size)
Changes made:
- never generate a caption when none present on file, but
always fallback to the help file title in this case
- generate default titles when none are present on file
(title pattern depends on file version)
- in pattern displaying filename, only show the basename.
These changes give the same result for the main window's title
on all the .hlp files from my test database.
(except for some cases where 'Wine help' is used instead of
'help', but I didn't bother adding a new entry in string table).
Signed-off-by: Eric Pouech <epouech(a)codeweavers.com>
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4758
--
v12: 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: Mark unbounded descriptor ranges as buggy on MoltenVK.
tests: Mark loading from stencil as buggy on MoltenVK.
tests: Mark resource arrays as buggy on MoltenVK.
tests: Mark predicated rendering as buggy on MoltenVK.
tests: Mark streaming output as buggy on MoltenVK.
tests: Mark some sampling tests as buggy on MoltenVK.
vkd3d-shader/spirv: Specify behavior for bit field instructions.
tests: Use a uint target for rendering uint data.
vkd3d: Specify the aspect when creating NULL UAVs.
ci: Dump the d3d12 summary line in the CI log.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/531
--
v11: 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: Mark unbounded descriptor ranges as buggy on MoltenVK.
tests: Mark loading from stencil as buggy on MoltenVK.
tests: Mark resource arrays as buggy on MoltenVK.
tests: Mark predicated rendering as buggy on MoltenVK.
tests: Mark streaming output as buggy on MoltenVK.
tests: Mark some sampling tests as buggy on MoltenVK.
vkd3d-shader/spirv: Specify behavior for bit field instructions.
tests: Use a uint target for rendering uint data.
vkd3d: Specify the aspect when creating NULL UAVs.
ci: Dump the d3d12 summary line in the CI log.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/531
--
v10: tests: Mark count buffers as buggy on MoltenVK.
tests: Mark a timestamp query test as buggy on MoltenVK.
tests: Mark clip distance as unsuppoerted on MoltenVK.
tests: Mark cull distance as buggy on MoltenVK.
tests: Mark unbounded descriptor ranges as buggy on MoltenVK.
tests: Mark loading from stencil as buggy on MoltenVK.
tests: Mark resource arrays as buggy on MoltenVK.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/531