--
v2: dmime: Use latency time to decide when to process messages.
dmime: Update performance latency time with port latency.
dmime: Use port latency time for messages with -1 time.
dmusic: Forward IDirectMusicPort_Activate to synth and sink.
dmsynth: Do nothing in IDirectMusicSynth_SetMasterClock.
dmusic: Set synth sink master clock when creating port.
dmime: Rewrite message thread with a condition variable.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4110
This depends on !412, and might need some finishing touches before being ready.
--
v2: ci: Run the HLSL compiler tests on Windows.
ci: Run the HLSL preprocessor tests on Windows.
ci: Run cross tests on Windows.
tests: Skip processing resources according to [require] directives.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/413
--
v3: 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 standard 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
Don't use hard coded string indexes as one of the expected string
can be absent, hence decreasing its index; nothing ensures that the
strings are placed in the order of the fields in the smbios structure.
So use, smbios structures' indexes instead.
Wbemprox was also expecting one string too much.
Signed-off-by: Eric Pouech <epouech(a)codeweavers.com>
--
v3: wbemprox: Use correct string id.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4107
On Tue Oct 17 13:58:32 2023 +0000, eric pouech wrote:
> IMO there's no difference in privacy concerns between hardware ID and
> software ones (some BIOS:es allow you to change the HW id, so the
> boundary between HW or not is also not that clear). The point is what
> they identify.
> what are your concerns about following systemd recommandations?
Like I said, Wine is not a regular application, it's just the middle layer between the Unix OS and Windows applications. Your proposal doesn't achieve systemd's goal because you can run multiple applications on Wine which would still get the same ID (even if run in different prefixes).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4108#note_49001
On Tue Oct 17 13:41:31 2023 +0000, Hans Leidekker wrote:
> > concerning the migration phase:
> >
> > * do you have an idea of which applications make use of it? (asking in
> case you have some idea, but likely we cannot be sure of all of it)
> I remember working on a game but I forgot the name. Generally it's DRM
> schemes that try to bind an account or install to a particular machine.
> > * a countermeasure could be to set a flag in the Wine prefix
> (dont_hash_machineid, at value 0 when not defined) to control the
> activation of the hashing ; every new prefix would be created with the
> flag set to 1 ; that would limit the impact, but not eradicate it (if
> user reinstalls his/her app in newly created prefix) ; that could
> eventually controlled in winecfg with more context on the pros&cons
> I don't think we'd want such code in Wine.
neither do I ;-)
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4108#note_48999
On Tue Oct 17 13:41:33 2023 +0000, Hans Leidekker wrote:
> > for the very same reason that /sys/class/dmi/id/board_serial,
> chassis_serial, product_serial and product_uuid are not readable by user
> >
> > exposing directly /etc/machine-id is hence a major privacy concern
> >
> > Note: Windows expose these HW id:s without constraints whereas Linux
> puts some limitations.
> Right, and macOS also exposes a hardware ID. Windows/Mac applications
> should be equally careful with that information. I don't think exposing
> /etc/machine-id is at the same level though. It's not a hardware ID and
> you can change it. If privacy is a concern when running Windows
> applications an alternative would be to sandbox Wine and give it its own
> machine ID.
IMO there's no difference in privacy concerns between hardware ID and software ones (some BIOS:es allow you to change the HW id, so the boundary between HW or not is also not that clear). The point is what they identify.
what are your concerns about following systemd recommandations?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4108#note_48998
This fixes -Wenum-conversion warnings (enabled by default on clang) and -Wpointer-sign warnings (enums are signed on MSVC target, so their pointers should not be implicitly converted to `unsigned int *`).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4127
> concerning the migration phase:
>
> * do you have an idea of which applications make use of it? (asking in case you have some idea, but likely we cannot be sure of all of it)
I remember working on a game but I forgot the name. Generally it's DRM schemes that try to bind an account or install to a particular machine.
> * a countermeasure could be to set a flag in the Wine prefix (dont_hash_machineid, at value 0 when not defined) to control the activation of the hashing ; every new prefix would be created with the flag set to 1 ; that would limit the impact, but not eradicate it (if user reinstalls his/her app in newly created prefix) ; that could eventually controlled in winecfg with more context on the pros&cons
I don't think we'd want such code in Wine.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4108#note_48993
> for the very same reason that /sys/class/dmi/id/board_serial, chassis_serial, product_serial and product_uuid are not readable by user
>
> exposing directly /etc/machine-id is hence a major privacy concern
>
> Note: Windows expose these HW id:s without constraints whereas Linux puts some limitations.
Right, and macOS also exposes a hardware ID. Windows/Mac applications should be equally careful with that information. I don't think exposing /etc/machine-id is at the same level though. It's not a hardware ID and you can change it. If privacy is a concern when running Windows applications an alternative would be to sandbox Wine and give it its own machine ID.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4108#note_48991
Goes atop MR 388 (the error codes would clash otherwise). The last four commits belong to this MR.
--
v9: vkd3d-shader: Clone descriptor scan info from struct vkd3d_shader_desc.
vkd3d-shader/dxil: Read CBV descriptors.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/401
This MR improves Wine's DMI tables by:
- no longer exposing /etc/machine-id content. Current documentation
of systemd strongly suggests to use a hash of it
(with app dedicated key). (1)
- generates DMI entries for files that are no longer user readable
on Linux (like bios serial number).
The values are derived from hashed value in step #1.
(1) current implementation integrates into unix ntdll a bunch of
sha 256 related code. It's basically a reimplementation
of libsystemd's sd_id128_get_machine_app_specific().
We could alternatively dynamically link to libsystemd.so.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4108
Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com>
--
v5: programs/vkd3d-compiler: Dynamically allocate options array.
vkd3d-shader/tpf: Convert some of the semantic names to system values names when in compatibility mode.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/381
Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com>
--
v16: vkd3d-shader/tpf: Write out 'switch' statements.
vkd3d-shader/hlsl: Add a pass to validate switch cases blocks.
vkd3d-shader/hlsl: Add a pass to remove unreachable code.
vkd3d-shader/hlsl: Add copy propagation logic for switches.
vkd3d-shader/hlsl: Validate break/continue context.
vkd3d-shader/hlsl: Check for duplicate case statements.
vkd3d-shader/hlsl: Add initial support for parsing 'switch' statements.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/361
Full focus lost / focus gained events on the Windows side are not
feasible for X11's FocusIn/FocusOut events generated by keyboard grabs
(see XGrabKeyboard()) that are used for example for Atl+Tab handling.
Using them would degrade user's experience by causing the window to
minimize or flash multiple times depending on a game/window manager
combo.
Because of that the programs may miss on some KEYUP events that happen
during the grab, and since there are no focus changes on the Windows
side the state doesn't get resynced.
This change attempts to improve user experience by syncing any missed
key release events that happened while the window haven't had focus on
the X11 side.
There's no syncing of key presses as those are more problematic because
of window manager quirks, e.g. on KDE it may end up syncing the Tab
press portion of Alt+Tab. Luckily missing key events for keys that were
pressed and not released while the WM had the keyboard grab is not
nearly as confusing as stuck keys.
For Warhammer: Chaosbane, theHunter: Call of the Wild, Far Cry Primal
and many other games that end up with stuck Alt after Alt+Tabbing.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4126
Hans Leidekker (@hans) commented about dlls/wbemprox/builtin.c:
> rec->manufacturer = get_bios_manufacturer( buf, len );
> rec->name = L"Default System BIOS";
> rec->releasedate = get_bios_releasedate( buf, len );
> - rec->serialnumber = get_bios_serialnumber( buf, len );
> + rec->serialnumber = L"Serial number";
You also need to remove COL_FLAG_DYNAMIC from the column definition otherwise free() will be called on a static string.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4107#note_48966
init_dmo_media_type_video uses head + extra bytes memory,
and with MEDIASUBTYPE_RGB8 the extra bytes are already 1024.
This leads to stack corruption.
Note that not all of those are strictly necessary to prevent a crash, but I think it's safer in case it becomes relevant in the future.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4112
On Tue Oct 17 05:34:53 2023 +0000, Nikolay Sivov wrote:
> We have a number of debugstr_an(..., 4) used for the same purpose in
> different modules. It will give different output if replaced with fourcc
> helper, because of isprint(), but still might be worth considering.
Thanks for pointing that out. I've started to send merge requests to clean those up.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3994#note_48952
It is really nice to be able to double-click batch files and have them run in an interactive console window, just like on Windows.
If this patch doesn't work for you, you may need a newer version of the shared-mime-info package.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4114
Goes atop MR 388 and 401. The last five commits belong to this MR.
--
v2: vkd3d-shader/dxil: Implement the DXIL EXTRACTVAL instruction.
vkd3d-shader/spirv: Support scalar swizzle of vector SSA registers.
vkd3d-shader/dxil: Implement DX instruction CBufferLoadLegacy.
vkd3d-shader/dxil: Implement DX instruction CreateHandle.
vkd3d-shader/dxil: Move the register_address_init() index parameter to position 2.
vkd3d-shader: Clone descriptor scan info from struct vkd3d_shader_desc.
vkd3d-shader/dxil: Read CBV descriptors.
vkd3d-shader/dxil: Validate the descriptor list metadata nodes.
vkd3d-shader/spirv: Align constant buffer sizes to 16 bytes.
vkd3d-shader/dxil: Read DXIL compute shader thread group dimensions.
vkd3d-shader/dxil: Read DXIL global flags.
vkd3d-shader: Define more global flags.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/408
Goes atop MR 388 (the error codes would clash otherwise). The last four commits belong to this MR.
--
v8: vkd3d-shader: Clone descriptor scan info from struct vkd3d_shader_desc.
vkd3d-shader/dxil: Read CBV descriptors.
vkd3d-shader/dxil: Validate the descriptor list metadata nodes.
vkd3d-shader/spirv: Align constant buffer sizes to 16 bytes.
vkd3d-shader/dxil: Read DXIL compute shader thread group dimensions.
vkd3d-shader/dxil: Read DXIL global flags.
vkd3d-shader: Define more global flags.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/401
On Mon Oct 16 22:21:57 2023 +0000, Zebediah Figura wrote:
> Hrm, that's suspicious, IMemAllocator::GetBuffer() returns
> VFW_E_NOT_COMMITTED. Does the VMR's IMemAllocator change by any chance
> when we reconnect? I.e. is IMemInputPin::GetAllocator() actually
> returning the same allocator that it was returning before?
Worth checking, but the answer is they're the same. https://testbot.winehq.org/JobDetails.pl?Key=138797&f101=exe64.report (First - the one already acquired. Second - after changing and sleeping. Third - after decommitting and recommitting.)
As I may have said, I have a vague suspicion this component is haunted.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3970#note_48919
On Tue Oct 3 09:21:16 2023 +0000, Rémi Bernon wrote:
> I don't know whether this is correct or not, I think it'd be better to
> leave this aspect aside for now as like you said this is going a bit out
> of the scope of this MR.
I would expect quartz to do one of three things, although others are possible:
* ignore format changes entirely,
* report the new format in the sample itself, via IMediaSample::GetMediaType(),
* reconnect the downstream pin.
In this case, as I understand, there's no real format change, it's just that GStreamer gains a bit of information more asynchronously; in that case nothing should happen.
Probably we shouldn't even be reporting a format change if the translated wg_format doesn't change.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3938#note_48917
Hi, really sorry about the very late review on this one (I was out for a while, and then spent a lot of time catching up on review while I was out, and then trying to get some more important Wine work done...)
2/7, seeking parts aside, is broadly doing the right thing (from my perspective) but I would like to see it arranged differently. What I would like to see is something like the following, in a series of individual patches:
* Introduce a wg_parser_create option to use the encoded format; this should end up being translated to "chain_decodebins" basically as you have it. I would also rename that to something like "output_compressed" (with inverted meaning).
Note that in this case autoplug-continue already does what we want, you shouldn't need to set the "caps" property on top of that.
* Use this property, plus WG_PARSER_DECODEBIN, in the existing frontend instead of WG_PARSER_MPEGAUDIOPARSE. Delete WG_PARSER_MPEGAUDIOPARSE.
* Ideally patch 1/7 should be moved from the beginning of the series to here.
* Add MPEG-1 system stream support to the quartz frontend.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3938#note_48918
Zebediah Figura (@zfigura) commented about dlls/quartz/tests/mpegvideo.c:
> + HRESULT hr = CoCreateInstance(&CLSID_CMpegVideoCodec, NULL, CLSCTX_INPROC_SERVER,
> + &IID_IBaseFilter, (void **)&filter);
> + ok(hr == S_OK, "Got hr %#lx.\n", hr);
> + return filter;
> +}
> +
> +static inline BOOL compare_media_types(const AM_MEDIA_TYPE *a, const AM_MEDIA_TYPE *b)
> +{
> + return !memcmp(a, b, offsetof(AM_MEDIA_TYPE, pbFormat))
> + && !memcmp(a->pbFormat, b->pbFormat, a->cbFormat);
> +}
> +
> +enum video_type_t {
> + vt_yv12, vt_y41p, vt_yuy2, vt_uyvy,
> + vt_rgb24, vt_rgb32, vt_rgb565, vt_rgb555, vt_rgb8,
> +};
Usually enum values are capitalized; also, _t is usually reserved for typedefs. That said, do we even want this enum? Is there any instance where we shouldn't just iterate over the whole array?
Two of these formats are todo, but I think something like "todo_wine_if (i == 1 || i == 8)" would be fine.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3938#note_48916
Zebediah Figura (@zfigura) commented about dlls/quartz/tests/mpegsplit.c:
> HRESULT hr;
>
> hr = IMediaSample_GetTime(sample, &start, &end);
> - todo_wine_if (hr == VFW_S_NO_STOP_TIME) ok(hr == S_OK, "Got hr %#lx.\n", hr);
> + todo_wine_if (hr == VFW_S_NO_STOP_TIME) {
> + ok(hr == S_OK || (filter->sample_count > 0 && hr == VFW_E_SAMPLE_TIME_NOT_SET), "Got hr %#lx.\n", hr);
> + }
If Windows never sets the sample time for video samples after the first then we should probably make this check more restrictive to explicitly check that.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3938#note_48910
Zebediah Figura (@zfigura) commented about dlls/winegstreamer/wg_parser.c:
> * file (or other medium), but gst_event_new_qos() expects the timestamp in
> * running time. */
> stream_time = gst_segment_to_running_time(&stream->segment, GST_FORMAT_TIME, params->timestamp * 100);
> - if (stream_time == -1)
> + if (stream_time == -1 || -params->diff*100 >= stream_time)
That doesn't seem right. What is this doing?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3938#note_48900
Zebediah Figura (@zfigura) commented about dlls/winegstreamer/wg_format.c:
> return NULL;
>
> gst_video_info_set_format(&info, video_format, format->u.video.width, abs(format->u.video.height));
> + info.fps_n = format->u.video.fps_n;
> + info.fps_d = format->u.video.fps_d;
> + if (!format->u.video.fps_d && !format->u.video.fps_n)
> + info.fps_d = 1;
This may be correct (although I'm curious if it actually matters here?) but should be a separate patch.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3938#note_48901
Zebediah Figura (@zfigura) commented about dlls/winegstreamer/quartz_parser.c:
> * but as long as every sample fits into our allocator, we're fine. */
> return format->u.video_cinepak.width * format->u.video_cinepak.height * 3;
>
> + case WG_MAJOR_TYPE_VIDEO_MPEG1:
> + return wg_format_get_bytes_for_uncompressed(WG_VIDEO_FORMAT_YV12,
> + format->u.video_mpeg1.width, format->u.video_mpeg1.height);
> +
This is overestimation because we can't do any better, right? In that case it probably deserves a comment just to clarify that's what's happening.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3938#note_48896
Zebediah Figura (@zfigura) commented about dlls/winegstreamer/wg_format.c:
> if (gst_video_info_from_caps(&info, caps))
> wg_format_from_video_info(format, &info);
> }
> - else if (!strcmp(name, "audio/mpeg"))
> + else if (!strcmp(name, "audio/mpeg") && gst_structure_get_boolean(structure, "parsed", &parsed) && parsed)
This is correct, I think, but also orthogonal to the purpose of this patch. Can you please split this out into a separate patch?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3938#note_48897
On Mon Oct 16 21:55:32 2023 +0000, Alfred Agrell wrote:
> Unfortunately, we do. I had sleeps everywhere during development, then
> removed every one I could, but that specific one is load-bearing.
> https://testbot.winehq.org/JobDetails.pl?Key=138782&f101=exe64.report
> https://testbot.winehq.org/JobDetails.pl?Key=138783&f101=exe64.report
> I tried swapping it for IBaseFilter_GetState(), but that just returned
> immediately then gave the same segfault. https://testbot.winehq.org/JobDetails.pl?Key=138786&f101=exe64.report
> Calling GetState twice worked, but I'm pretty sure that's just because
> those calls take long enough to satisfy its timing demands. A sleep is
> cleaner. (Slightly. Still ugly.)
> I could also move the sleep, but I don't think that would accomplish anything.
Hrm, that's suspicious, IMemAllocator::GetBuffer() returns VFW_E_NOT_COMMITTED. Does the VMR's IMemAllocator change by any chance when we reconnect? I.e. is IMemInputPin::GetAllocator() actually returning the same allocator that it was returning before?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3970#note_48893
> Found it. Native VMR9 disconnects and reconnects the pin when changing d3d device. Unfortunately, neither party remembers the media type, so they can't reconnect.
>
> Fixed. Took approximately seven forevers to figure out @\_@
Ah, that makes sense, thanks. That's done in some other filters as well.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3970#note_48874
Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com>
--
v4: programs/vkd3d-compiler: Dynamically allocate options array.
vkd3d-shader/tpf: Convert some of the semantic names to system values names when in compatibility mode.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/381
I've fixed the `beforeunload` case, since it happens during `load_nsuri`. I added tests for both it and `unload`, but unfortunately the new tests are somewhat hackish, as we have to release the View without actually closing it to test this, because closing the view sends those events (this is already tested by existing tests), and we want to test if releasing the doc obj sends those events. As for why we have to release the View, it's because it holds a ref to the doc obj.
So I placed the test last now since it doesn't close the view properly. If you think the test is too hackish I can remove it.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4109
Don't use hard coded string indexes as one of the expected string
can be absent, hence decreasing its index; nothing ensures that the
strings are placed in the order of the fields in the smbios structure.
So use, smbios structures' indexes instead.
Wbemprox was also expecting one string too much.
Signed-off-by: Eric Pouech <epouech(a)codeweavers.com>
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4107
--
v2: user32: Pass real argument to NtUserGetClassName in RealGetWindowClass.
win32u: Add support for retrieving real window class ID across processes.
user32: Set real window class ID for user32 standard controls.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4092
On Sat Oct 14 22:06:36 2023 +0000, Bartosz Kosiorek wrote:
> With previous implementation we have 2*4 float multiplication inside
> `GdipTransformMatrixPoints` function:
> ```
> pts[i].X = x * matrix->matrix[0] + y * matrix->matrix[2] + matrix->matrix[4];
> pts[i].Y = x * matrix->matrix[1] + y * matrix->matrix[3] + matrix->matrix[5];
> ```
> Here is the full source code:
> ```
> GpStatus WINGDIPAPI GdipTransformMatrixPoints(GpMatrix *matrix, GpPointF *pts,
> INT count)
> {
> REAL x, y;
> INT i;
> TRACE("(%s, %p, %d)\n", debugstr_matrix(matrix), pts, count);
> if(!matrix || !pts || count <= 0)
> return InvalidParameter;
> for(i = 0; i < count; i++)
> {
> x = pts[i].X;
> y = pts[i].Y;
> pts[i].X = x * matrix->matrix[0] + y * matrix->matrix[2] + matrix->matrix[4];
> pts[i].Y = x * matrix->matrix[1] + y * matrix->matrix[3] + matrix->matrix[5];
> }
> return Ok;
> }
> ```
> As the vector is (0,0) and (1, 1), we could replace invocation of this
> function by simple assigment (no need to multiple anything):
> ```
> scale_x = graphics->worldtrans.matrix[0] + graphics->worldtrans.matrix[2];
> scale_y = graphics->worldtrans.matrix[1] + graphics->worldtrans.matrix[3];
> ```
> We could also optimize it more and calculate width via `sqrt` only once
> (I would like to leave it for next MR).
This seems simple enough that I have no problem changing it without performance numbers. Note that we immediately turn around and do the same thing with graphics->gdi_transform (with some indirection through gdip_transform_points and get_graphics_transform that could be eliminated).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3971#note_48812
Goes atop MR 403 and 388. The last four commits belong to this MR.
--
v7: vkd3d-shader: Clone descriptor scan info from struct vkd3d_shader_desc.
vkd3d-shader/dxil: Read CBV descriptors.
vkd3d-shader/dxil: Validate the descriptor list metadata nodes.
vkd3d-shader/spirv: Align constant buffer sizes to 16 bytes.
vkd3d-shader/dxil: Read DXIL compute shader thread group dimensions.
vkd3d-shader/dxil: Read DXIL global flags.
vkd3d-shader: Define more global flags.
vkd3d-shader/dxil: Handle multi-row signature elements.
vkd3d-shader/dxil: Handle signature element additional tag/value pairs.
vkd3d-shader/dxil: Read the DXIL input and output signatures.
vkd3d-shader/dxil: Validate the entry point info.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/401
The PE build uses FlsAlloc(), which for our purposes makes no difference vs TlsAlloc(), and allows the use of a destruction callback.
--
v5: vkd3d: Replace the descriptor object cache with a thread-local implementation.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/384
This is in view of eventually running the vkd3d cross tests in the CI. With this MR d3d12 passes all the tests ([see a test pipeline](https://gitlab.winehq.org/giomasce/vkd3d/-/jobs/32587)), but some shader runner tests are still failing.
I haven't investigated in detail all these issues. Also, it is known that WARP doesn't emulate faithfully a hardware device. The idea is that having the CI able to quickly check most (even if not all) our tests on native is still better than nothing.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/406
Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com>
--
v15: vkd3d-shader/tpf: Write out 'switch' statements.
vkd3d-shader/hlsl: Add a pass to validate switch cases blocks.
vkd3d-shader/hlsl: Add a pass to remove unreachable code.
vkd3d-shader/hlsl: Add copy propagation logic for switches.
vkd3d-shader/hlsl: Validate break/continue context.
vkd3d-shader/hlsl: Check for duplicate case statements.
vkd3d-shader/hlsl: Add initial support for parsing 'switch' statements.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/361