This is in preparation for the mach thread id rework, which requires 64 bit there (and incidentally also stops truncating the FreeBSD one).
There wasn't any direct usage of `__int64` in the sever protocol before, so I added a new typedef and a new `dump_int64()` function (not sure if needed per se though).
--
v7: ntdll: Remove unneeded FreeBSD codepath in get_unix_tid().
server, ntdll: Use 64 bit for unix thread id.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5047
The last commit fixes glitches in Horizon Zero Dawn with vsync on, for reasons stated in the comment there.
The wined3d implementation already blocks the client's call to `Present()` when `vkAcquireNextImageKHR()` blocks, so is roughly equivalent to this when frame latency and buffer count are equal. It has a frame latency implementation which unblocks after calling `vkQueuePresentKHR()`, rather than waiting for its execution to complete. I think the d3d12 implementation is supposed to do the latter, though using `KHR_present_wait` may be unnecessary overkill. Waiting on queue execution comes with a performance cost either way, so without a compelling reason for a strict implementation, something similar to wined3d makes sense.
Another potential issue is after the call to `ID3D12CommandQueue_Signal()` in `d3d12_swapchain_present()`, the client is free to enqueue more commands when `Present()` returns, so by the time the signal is executed and the swapchain worker blits the image and calls `vkQueuePresentKHR()`, these commands are not necessarily enqueued immediately after the `Signal()`. This may not always be harmless.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5830
More details here: https://devblogs.microsoft.com/oldnewthing/20181206-00/?p=100415
However it does not mention that `PAGE_NOACCESS` and `PAGE_READONLY` still result in an error on Windows, which is properly implemented in this MR.
Only `WriteProcessMemory` offers this "service", `NtWriteVirtualMemory` will fail on non-writeable and executable regions (and already does so, except for the the mach server backend, which needs https://gitlab.winehq.org/wine/wine/-/merge_requests/4826 to also behave correctly here).
--
v4: kernelbase: Flush instruction cache in WriteProcessMemory.
kernelbase: Allow WriteProcessMemory to succeed on PAGE_EXECUTE and PAGE_EXECUTE_READ.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5222
For all mach vm operations this removes the task suspend and resume, which are not needed.
This uses `mach_vm_read_overwrite` to read into a caller-specified buffer, saving the `mach_vm_deallocate` call (bringing all read operations down to 1 syscall from 4).
The only alignment restriction on `mach_vm_write` according to the original CMU documentation is that data is
> [pointer to page aligned in array of bytes] An array of data to be written.
(In practice it also works with arbitrary addresses on macOS, but it probably doesn't hurt to follow the original specifications here).
The only other reference that these read/writes should be page-aligned is from the GNU Hurd documentation
> The current implementation requires that address, data and data_count all be page-aligned. Otherwise, KERN_INVALID_ARGUMENT is returned.
which I assume was the reason why this was originally done (plus it sounds to me like they will fix that in the future and 4fe19777 already broke GNU Hurd support anyways, if that was supposed to be working).
Also this includes the missing mach part of 5b1f3b14, which was only applied to the ptrace backend, and together with the `write_process_memory` rework, this gets rid of all fixmes in mach.c
--
v4: server: Simplify mach write_process_memory.
server: Use mach_vm_read_overwrite in get_selector_entry.
server: Use mach_vm_read_overwrite in read_process_memory.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4826
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=56769
--
v4: quartz/tests: Test that avi_decompressor_source_qc_Notify does not deadlock if called from a foreign thread during IMemInput_Receive.
quartz: Allow concurrent calls to AVI decoder qc_Notify and Receive.
msvfw32/tests: Test that Cinepak rejects unsupported output types.
iccvid: Reject unsupported output types.
quartz/tests: Add Cinepak test to avi splitter.
winegstreamer: Make AVI splitter use end of previous frame if the current frame doesn't have a timestamp.
winegstreamer: Implement AM_MEDIA_TYPE to wg_format converter for Cinepak video.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5846
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=56698
--
v8: quartz/tests: Test that avi_decompressor_source_qc_Notify does not deadlock if called from a foreign thread during IMemInput_Receive.
quartz: Allow concurrent calls to AVI decoder qc_Notify and Receive.
msvfw32/tests: Test that Cinepak rejects unsupported output types.
iccvid: Reject unsupported output types.
quartz/tests: Add Cinepak test to avi splitter.
winegstreamer: Make AVI splitter use end of previous frame if the current frame doesn't have a timestamp.
winegstreamer: Implement AM_MEDIA_TYPE to wg_format converter for Cinepak video.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5744
Rémi Bernon (@rbernon) commented about dlls/winegstreamer/wg_transform.c:
> - {
> - gst_caps_unref(parsed_caps);
> - parsed_caps = gst_caps_ref(src_caps);
> - }
> -
> - if (!(element = find_element(GST_ELEMENT_FACTORY_TYPE_DECODER, parsed_caps, sink_caps))
> - || !append_element(transform->container, element, &first, &last))
> - goto out;
> - break;
> -
> - case WG_MAJOR_TYPE_AUDIO:
> - case WG_MAJOR_TYPE_VIDEO:
> - break;
> - case WG_MAJOR_TYPE_UNKNOWN:
> - GST_FIXME("Format %u not implemented!", input_format.major_type);
> + if (!transform_create_transcoder(transform, src_caps, &input_format, &first, &last))
Can we add an encoder element without changing all this code? It doesn't look like you need all the complicated converter sequence, maybe only a videoconvert (do you even need one?).
I don't want to be a blocker but to be honest I'm a bit annoyed with the idea of having to rewrite the patches I am trying to upstream with transform media types.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5879#note_73696