Goes atop !583. The last two commits belong to this MR.
--
v3: 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
This serie is the first result of investigation of loops not
being played on dmusic for wave tracks.
It basically:
- extends tests so that we can check if loop work at some extend
(they don't right now)
- add and fix a couple of existing tests.
And contain fixes for crufts in existing code:
- fix an errouneous prototype
- removed unused fields.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4950
Shifting the rest of the variables by one towards indices of lesser value
overwrites the variable being cleared and effectively leaks it.
Signed-off-by: David Kahurani <k.kahurani(a)gmail.com>
--
v2: dlls/msvcrt: Free previous environment variable when clearing
https://gitlab.winehq.org/wine/wine/-/merge_requests/4944
Keep track of the window cursor set for each surface and apply it when
the pointer enters the corresponding surface. This fixes a problem where
due to transient disagreements between win32 pointer focus and Wayland
pointer focus a cursor update may be lost. For example:
1. Assume existing cursor C1.
2. Window is created beneath cursor.
3. The SetCursor(hwnd, C2) driver callback is called, but because the
wl_pointer hasn't entered the Wayland surface yet we don't update
the wl_pointer cursor.
4. wl_pointer enters the surface, we apply the latest cursor we know
about, which is C1.
5. Since no change in cursor window occurs, we don't get any
further SetCursor(hwnd, C2) callbacks, so we get stuck with C1.
This commit fixes the problem by tracking the per-surface HCURSOR in
step 3, regardless of whether the cursor is actually applied. So, in
step 4 we can use that HCURSOR for the surface.
This change also fixes some cases of our mouselook heuristics not
kicking in properly due to missing a SetCursor(hwnd, NULL) in the
manner described above.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4948
An alternative approach to `EnumAdapters2` that does not directly call to GDI driver and therefore does not require GDI driver functions to be expanded. The implementation now lives in `sysparams.c` to make it closer to win32u caches it accesses. It still uses `OpenAdapterFromLuid` internally because that's where adapter handles are actually assigned and to make sure returned handles are usable with other functions that rely on GDI driver being aware of what the handle represents to be able to function correctly (like `QueryVideoMemoryInfo`).
See !4791 for some background and why this version might be preferable over the one submitted there.
--
v4: win32u: Implement NtGdiDdDDIEnumAdapters2.
win32u: Maintain a list of GPUs in cache.
gdi32,win32u: Add stubs for D3DKMTEnumAdapters2 and NtGdiDdDDIEnumAdapters2.
gdi32/tests: Add D3DKMTEnumAdapters2 tests.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4857
--
v11: user32: Pass real argument to NtUserGetClassName in RealGetWindowClass{A/W}.
win32u: Add support for retrieving real window class ID across processes.
user32: Set real window class ID for user32 static controls.
win32u/tests: Add a test for real window class name retrieval.
comctl32/tests: Add tests for RealGetWindowClass.
user32/tests: Add tests for RealGetWindowClass.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4092
Oh and I believe part of the historic mess is that ddraw sets color keys per-surface, so on paper you might set a different key on a mipmap sublevel or cube face. Not that I expect that to do anything useful in practise.
test_ck_complex shows mipmap sub levels return DDERR_NOTONMIPMAPSUBLEVEL in ddraw7, but not earlier. I guess ddraw_surface_set_color_key() could use a FIXME for the !surface->is_root case...
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4888#note_59256
I just noticed this on wine-gitlab, and I am pretty sure the check was necessary at the time for the (IWineD3DTextureImpl *) stateblock->textures[0] cast.
Color keys have since been moved from surfaces to textures, and as Henri mentioned, textures unified. I don't know of a particular design reason why D3DRS_COLORKEYENABLE wouldn't work with cube textures. I don't know of any application that combines them though (the only ddraw thing I know that uses cube textures is a dx7 sdk sample), so I wouldn't be surprised if you hit driver bugs if you try.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4888#note_59255
On Tue Jan 23 10:02:40 2024 +0000, Krzysztof Bogacki wrote:
> I'm trying to follow the suggestion to read SetupAPI registry data but
> I'm having some difficulties, with the major one being: I'm not actually
> sure where that data is. Your sample code doesn't seem to read the
> registry and just returns/enumerates an empty device set. What am I
> missing here?
> On the other hand, I had a look at where win32u writes stores
> information when `add_gpu` is called and figured that I can (probably)
> use whatever this function writes. This gives me two possible leads:
> 1.
> `HKML\System\CurrentControlSet\Control\Class\{4D36E968-E325-11CE-BFC1-08002BE10318}\${gpu_id}`.
> Although easier to enumerate, this doesn't have the most important piece
> of data: GPU LUID, which I'd have to retrieve from the second key anyway
> and it doesn't have any links to second keys I could use to open it
> directly, so it's not very viable for my purposes here.
> 2. `HKML\System\CurrentControlSet\Enum\PCI\${pci_id}\${gpu_idx}`. This
> does have GPU LUID I can easily retrieve but some of the other data is
> kept only as wide strings which I'd need to parse if I wanted to use
> them (if only for bookkeeping purposes). E.g. the only way I see to
> retrieve PCI vendor and device IDs would be parsing `${pci_id}` but as
> far as I can tell, I can't just use `snwscanf` to process 2-byte wide
> strings in Unixlibs.
> Of course, I could pick the second version and read only the LUID while
> ignoring PCI IDs and GPU ID/index completely, but I'd like to ask first
> if it's correct thing to do before I commit to that.
HKML\\System\\CurrentControlSet\\Enum\\PCI is the correct key to enumerate GPUs.
> the only way I see to retrieve PCI vendor and device IDs would be parsing ${pci_id} but as far as I can tell, I can't just use snwscanf to process 2-byte wide strings in Unixlibs.
Do you really need PCI IDs for D3DKMTEnumAdapters2? If you do, I am sure there is a way to parse them.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4857#note_59247
For temporary registers, SM1-SM3 integer types are internally
represented as floating point, so, in order to perform a cast
from ints to floats we need a mere MOV.
By the same token, casts from floats to ints can also be implemented with a FLOOR + MOV,
where the FLOOR is then lowered by the lower_floor() pass.
For constant integer registers "iN" there is no operation for casting
from a floating point register to them. For address registers "aN", and
the loop counting register "aL", vertex shaders have the "mova" operation
but we haven't used these registers in any way yet.
We probably would want to introduce these as synthetic variables
allocated in a special register set. In that case we have to remember to
use MOVA instead of MOV in the store operations, but they shouldn't be src
or dst of CAST operations.
Regarding constant integer registers, in some shaders, constants are
expected to be received formatted as an integer, such as:
int m;
float4 main() : sv_target
{
float4 res = {0, 0, 0, 0};
for (int k = 0; k < m; ++k)
res += k;
return res;
}
which compiles as:
// Registers:
//
// Name Reg Size
// ------------ ----- ----
// m i0 1
//
ps_3_0
def c0, 0, 1, 0, 0
mov r0, c0.x
mov r1.x, c0.x
rep i0
add r0, r0, r1.x
add r1.x, r1.x, c0.y
endrep
mov oC0, r0
but this only happens if the integer constant is used directly in an
instruction that needs it, and as I said there is no instruction that
allows converting them to a float representation.
Notice how a more complex shader, that performs operations with this
integer variable "m":
int m;
float4 main() : sv_target
{
float4 res = {0, 0, 0, 0};
for (int k = 0; k < m * m; ++k)
res += k;
return res;
}
gives the following output:
// Registers:
//
// Name Reg Size
// ------------ ----- ----
// m c0 1
//
ps_3_0
def c1, 0, 0, 1, 0
defi i0, 255, 0, 0, 0
mul r0.x, c0.x, c0.x
mov r1, c1.y
mov r0.y, c1.y
rep i0
mov r0.z, r0.x
break_ge r0.y, r0.z
add r1, r0.y, r1
add r0.y, r0.y, c1.z
endrep
mov oC0, r1
Meaning that the uniform "m" is just stored as a floating point in
"c0", the constant integer register "i0" is just set to 255 (hoping
it is a high enough value) using "defi", and the "break_ge"
involving c0 is used to break from the loop.
We could potentially use this approach to implement loops from SM3
without expecting the variables being received as constant integer
registers.
According to the D3D documentation, for SM1-SM3 constant integer
registers are only used by the 'loop' and 'rep' instructions.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/608
I'm working on RISCV64 support for a while and would like to know the chances of it being accepted. WOW64 with emulation dlls (Hangover style) is already working somewhat, not perfectly, but I'm not done yet. That's also the main goal, having RISCV64 Wine built as Unix to run new WOW64 on top of it with emulators.
Cleanup/Fixing is still in progress, so this draft only contains early bits.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4896
Signed-off-by: David Kahurani k.kahurani(a)gmail.com
--
v5: 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
--
v2: dinput/tests: Add more tests for HID rawinput buffer.
dinput/tests: Add a helper to wait on HID input reads.
user32/tests: Rewrite the rawinput buffer test with keyboard input.
user32/tests: Run rawinput device tests in the separate desktop.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4946
These were in the staging user32-Mouse_Message_Hwnd series, I rewrote them to use the new test helpers. There were more tests with DC regions but I don't think they really belong to the input tests. The fixes are also not completely correct (they don't pass some tests now) so probably would need some investigation.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4945
Some driver, e.g. MoltenVK, fail in some cases if the image view usage is too broad or unknown.
--
v6: wined3d: Expose the image view usage for non-default views.
wined3d: Expose the image view usage for null views.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4022
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55421
Partial revert of 413fc34be7fca948dc53b3eb8cd1a08e951f2b4e.
Proton testing reveals that Arial font breaks another launcher, and it's not known to fix anything. Native behavior doesn't really matter here (since it's a situation that Windows will never encounter in practice), so go with the font that seems to be a better match until we have a proper replacement for Microsoft Sans Serif (not to be confused with MS Sans Serif).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4949
On Fri Jan 26 16:10:29 2024 +0000, Aida Jonikienė wrote:
> @rastos Just squash all of your commits into a single commit (and update
> that commit with my changes) and force push for a cleaner MR
I can see the message has been fixed
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4940#note_59166
On Fri Jan 26 16:09:11 2024 +0000, Rastislav Stanik wrote:
> Similar to above - there are two structures with very similar names but
> not identical: MIB_UNICASTIPADDRESS_TABLE vs MIB_ANYCASTIPADDRESS_TABLE.
Same comment as the struct above
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4940#note_59165
On Fri Jan 26 16:09:07 2024 +0000, Rastislav Stanik wrote:
> Hold on. Note that there are two structures with similar names: MIB_UNICASTIPADDRESS_ROW
> MIB_ANYCASTIPADDRESS_ROW
I shouldn't be reviewing code at late nights (anyway this was my own mistake)
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4940#note_59164
The goal here is to be able to convert between SSA and TEMP easily, which will be the second preliminary pass for the CFG structurizer.
Ideally I would have added the check in commit 4/4 for TEMPs as well, but typing information from TPF sources is insufficient. This leaves the current validation inconsistent: we check that a register is always used either as a scalar or a vec4, but that "scalar" might be 32 bit in some cases and 64 bit in others. Maybe the right thing to do here is just give up on trying to put some typing on TEMPs and just say they're always 4x32 bit words. I don't know, I'll leave this for when the dust is more settled.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/603
for details see https://bugs.winehq.org/show_bug.cgi?id=56065
This change adds an implementation of Win32 API function GetAnycastIpAddressTable() that is used by Adoptium OpenJDK 21 and later to initialize Secure Random Generator. This implementation does not return real information, it just says "no entries found".
--
v8: iphlpapi: add stub for GetAnycastIpAddressTable().
https://gitlab.winehq.org/wine/wine/-/merge_requests/4940
Shifting the rest of the variables by one towards indices of lesser value
overwrites the variable being cleared and effectively leaks it.
Signed-off-by: David Kahurani <k.kahurani(a)gmail.com>
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4944
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>
--
v3: wineps.drv: Avoid invalid unaligned accesses.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4930
for details see https://bugs.winehq.org/show_bug.cgi?id=56065
This change adds an implementation of Win32 API function GetAnycastIpAddressTable() that is used by Adoptium OpenJDK 21 and later to initialize Secure Random Generator. This implementation does not return real information, it just says "no entries found".
--
v7: iphlpapi: try to hammer out linux compilation in winehq gitlab
https://gitlab.winehq.org/wine/wine/-/merge_requests/4940
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.
--
v3: winhttp: Always return result at once if available in WinHttpReadData().
winhttp: Always return result at once if available in WinHttpQueryDataAvailable().
https://gitlab.winehq.org/wine/wine/-/merge_requests/4925
for details see https://bugs.winehq.org/show_bug.cgi?id=56065
This change adds an implementation of Win32 API function GetAnycastIpAddressTable() that is used by Adoptium OpenJDK 21 and later to initialize Secure Random Generator. This implementation does not return real information, it just says "no entries found".
--
v6: iphlpapi: fix compilation on linux.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4940
I should've pushed this shortly after the workaround for the WineD3D
WoW64 graphics corruption got upstreamed (which I discovered when
messing around) but never got around to MR anything in Wine.
The copies of mapped buffers introduce significant performance overhead
(I'll add a FIXME so that people don't get surprised when their old games
run like a slideshow like for example NFS Most Wanted).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4513
for details see https://bugs.winehq.org/show_bug.cgi?id=56065
This change adds an implementation of Win32 API function GetAnycastIpAddressTable() that is used by Adoptium OpenJDK 21 and later to initialize Secure Random Generator. This implementation does not return real information, it just says "no entries found".
--
v5: iphlpapi: add stub for GetAnycastIpAddressTable().
https://gitlab.winehq.org/wine/wine/-/merge_requests/4940
for details see https://bugs.winehq.org/show_bug.cgi?id=56065
This change adds an implementation of Win32 API function GetAnycastIpAddressTable() that is used by Adoptium OpenJDK 21 and later to initialize Secure Random Generator. This implementation does not return real information, it just says "no entries found".
--
v4: iphlpapi: add stub for GetAnycastIpAddressTable().
https://gitlab.winehq.org/wine/wine/-/merge_requests/4940
--
v5: vkd3d-shader/dxil: Implement DX intrinsic SplitDouble.
tests/shader-runner: Add an asuint() test to the 64-bit cast tests.
tests/shader-runner: Support testing for integer pixel data.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/589
This fixes a rendering issue (and ultimately a crash) in PowerPoint when
compiling with GCC 8.
GCC8 doesn't support the `excess-precision=standard` option under the
`#pragma GCC optimize` directive.
This results in unpredictable floating point rounding leading to errors
when inserting segments (with missing edges and/or triangles).
Using 24-bit precision ensures we don't have any excess precision.
--
v4: d2d1: Fix double free bug when d2d_geometry_sink_Close fails
d2d1: Use 24-bit FP precision for triangulate.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4824
for details see https://bugs.winehq.org/show_bug.cgi?id=56065
This change adds an implementation of Win32 API function GetAnycastIpAddressTable() that is used by Adoptium OpenJDK 21 and later to initialize Secure Random Generator. This implementation does not return real information, it just says "no entries found".
--
v2: iphlpapi: formatting.
iphlpapi: more compact code in GetAnycastIpAddressTable().
iphlpapi: changed TRACE() and FIXME() in GetAnycastIpAddressTable().
https://gitlab.winehq.org/wine/wine/-/merge_requests/4940
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);
```
--
v5: winex11.drv: Fix wglSwapBuffers() with NULL current context with child window rendering.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4912
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.
--
v2: winhttp: Always return result at once if available in WinHttpReadData().
winhttp: Always return result at once if available in WinHttpQueryDataAvailable().
https://gitlab.winehq.org/wine/wine/-/merge_requests/4925
--
v2: vkd3d-shader/spirv: Handle the TAN instruction in spirv_compiler_emit_ext_glsl_instruction().
vkd3d-shader/dxil: Handle DX intrinsic Tan in sm6_parser_emit_dx_unary().
vkd3d-shader/dxil: Implement DX intrinsics Cos and Sin.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/595
--
v4: vkd3d-shader/dxil: Implement DX intrinsic SplitDouble.
tests/shader-runner: Add an asuint() test to the 64-bit cast tests.
tests/shader-runner: Support testing for integer pixel data.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/589
I'll revise the operand codes once !572 is upstream.
--
v3: vkd3d-shader/spirv: Support 64-bit source value for bitfield instructions.
vkd3d-shader/dxil: Implement DX intrinsic Tertiary.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/587
This MR includes:
- A fix to a comment in vkd3d-shader/ir.c (out of MR scope but really tiny!).
- A fix when creating UAV buffers in the shader_runner d3d12 backend.
- Fixes to (hopefully) all the memory leaks in the shader_runner reported by valgrind when running all tests.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/600
With tests from !364, separated out from the HLSL changes there and updated. This MR can wait until 364 is upstream though.
It is apparently unnecessary to match the SM4/5 implementation, since the AMD Windows results differ. The RADV results are a bit wrong, but Proton uses the SPIR-V GLSL extension instructions too, and no workarounds have been implemented there.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/602
--
v3: vkd3d-shader/dxil: Implement DX intrinsic SplitDouble.
tests/shader-runner: Add an asuint() test to the 64-bit cast tests.
tests/shader-runner: Support testing for integer pixel data.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/589
I'll revise the operand codes once !572 is upstream.
--
v2: vkd3d-shader/spirv: Support 64-bit source value for bitfield instructions.
vkd3d-shader/dxil: Implement DX intrinsic Tertiary.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/587
--
v17: tests: Mark a strip cut test as buggy in MoltenVK.
tests: Mark a depth sampling test as buggy on MoltenVK.
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.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/531
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.
--
v3: vkd3d-shader/ir: Fixup PHI nodes when lowering switches to selection ladders.
vkd3d-shader/ir: Lower monolithic switches to selection ladders.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/598