May 2022 - Wine-Devel - list.winehq.org

[PATCH v2 0/2] MR17: programs/cmd: test that read is successful before using its result

by eric pouech (＠epo)

There are cases where the read can fail (not attached to a console, input stream mapped to /dev/null...) Signed-off-by: Eric Pouech <eric.pouech(a)gmail.com> -- v2: programs/cmd: skip too long paths https://gitlab.winehq.org/wine/wine/-/merge_requests/17

May 2, 2022

Re: [PATCH v3 3/3] d2d1: Implement LoadVertexShader().

by Henri Verbeet

On Fri, 29 Apr 2022 at 12:10, Ziqing Hui <zhui(a)codeweavers.com> wrote: > static void d2d_effect_context_cleanup(struct d2d_effect_context *effect_context) > { > + unsigned int i; > + > + for (i = 0; i < effect_context->shader_count; ++i) > + { > + if (effect_context->shaders[i].shader) > + IUnknown_Release(effect_context->shaders[i].shader); > + } > + heap_free(effect_context->shaders); > + > ID2D1DeviceContext_Release(&effect_context->device_context->ID2D1DeviceContext_iface); > } Can "effect_context->shaders[i].shader" legitimately be NULL above?

May 2, 2022

Re: [PATCH v3 2/3] d2d1: Implement ID2D1EffectContext_GetDpi().

by Henri Verbeet

On Fri, 29 Apr 2022 at 12:10, Ziqing Hui <zhui(a)codeweavers.com> wrote: > static void STDMETHODCALLTYPE d2d_effect_context_GetDpi(ID2D1EffectContext *iface, float *dpi_x, float *dpi_y) > { > - FIXME("iface %p, dpi_x %p, dpi_y %p stub!\n", iface, dpi_x, dpi_y); > + struct d2d_effect_context *effect_context = impl_from_ID2D1EffectContext(iface); > + > + TRACE("iface %p, dpi_x %p, dpi_y %p.\n", iface, dpi_x, dpi_y); > + > + return ID2D1DeviceContext_GetDpi(&effect_context->device_context->ID2D1DeviceContext_iface, dpi_x, dpi_y); > } Returning void values is best avoided.

May 2, 2022

Re: [PATCH v3 1/3] d2d1: Add stubs for ID2D1EffectContext.

by Henri Verbeet

On Fri, 29 Apr 2022 at 12:10, Ziqing Hui <zhui(a)codeweavers.com> wrote: > +static HRESULT STDMETHODCALLTYPE d2d_effect_context_CreateResourceTexture(ID2D1EffectContext *iface, > + const GUID *id, const D2D1_RESOURCE_TEXTURE_PROPERTIES *texture_properties, > + const BYTE *data, const UINT32 *strides, UINT32 data_size, ID2D1ResourceTexture **texture) > +{ > + FIXME("iface %p, id %s, texture_properties %p, data %p, strides %s, data_size %u, texture %p stub!\n", > + iface, debugstr_guid(id), texture_properties, data, > + strides ? wine_dbg_sprintf("%u", *strides) : "(null)", data_size, texture); > + > + return E_NOTIMPL; > +} I don't think tracing "strides" like that makes a lot of sense; for a 1D texture there would be zero strides, while for a 3D texture there would be 2.

May 2, 2022

MR19v3 - Fix msvcrt include for C++ support - closed

by eric pouech (＠epo)

This merge request was closed by eric pouech. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/19

May 2, 2022

Re: [PATCH vkd3d v2 3/4] vkd3d: Replace the signaled semaphore list with a resizable array.

by Henri Verbeet

Signed-off-by: Henri Verbeet <hverbeet(a)codeweavers.com>

May 2, 2022

Re: [PATCH vkd3d v2 2/4] vkd3d: Create one fence worker thread per command queue.

by Henri Verbeet

Signed-off-by: Henri Verbeet <hverbeet(a)codeweavers.com>

May 2, 2022

Re: [PATCH vkd3d 1/4] vkd3d: Introduce an internal refcount to d3d12_fence to replace the thread waiting mechanism.

by Henri Verbeet

Signed-off-by: Henri Verbeet <hverbeet(a)codeweavers.com>

May 2, 2022

Re: [PATCH vkd3d v2 4/4] vkd3d: Map timeline semaphore values to fence virtual values and submit commands in worker threads.

by Henri Verbeet

On Fri, 29 Apr 2022 at 15:21, Conor McCarthy <cmccarthy(a)codeweavers.com> wrote: > Correct fence behaviour requires: > > Map monotonically increasing timeline values to fence virtual values to > avoid invalid use of Vulkan timeline semaphores. In particular, non- > increasing values and value jumps of >= 4G are required for d3d12. > > Create a worker thread for each queue to handle queue commands. This > allows blocking of wait submission until an unblocking signal is > submitted, so out-of-order waits are handled correctly when two d3d12 > queues are mapped to the same Vulkan queue. > > Threaded queue submission also fixes the old fence implementation so it is > fully functional, though a bit less efficient than timeline semaphores. > > Based in part on vkd3d-proton patches by Hans-Kristian Arntzen. > > Signed-off-by: Conor McCarthy <cmccarthy(a)codeweavers.com> > --- > v2: Always broadcast on the null event condition after signaling. > > Threaded command queues on their own seem to bring out the problems with the > existing fence implementation, which results in games crashing. Combining them > with the fence changes avoids that issue. Is there any reason we couldn't apply the fence changes before the command queue submission changes? The commit message could be clearer, but if I understood it correctly, the command queue submission changes are intended to address the following scenario: - We have a fence F1, and two d3d12 command queues V1 and V2 sharing the same physical Vulkan queue Q1. - The application submits a Wait(F1, x) on V1. - The application submits a Signal(F1, x) on V2. - The Wait() on V1 never completes, because it's submitted to Q1 before the Signal() on V2. - And to complicate things some more, V2 may not be created until after the Wait(). Correct? That explains the need to delay Wait() submission, but not the need to introduce the worker threads. Is there anything preventing us from buffering these Wait() calls (and any subsequent Execute() calls) much like we do in this patch, and then simply submitting them when the corresponding Signal() is submitted? If we treat the need for these worker threads as a given for the sake of argument, the scheme introduced in this patch looks suspiciously similar to wined3d's command stream. The wined3d CS is probably a fair bit more complicated than what's needed here, but could we please at least keep the terminology consistent? d3d12_command_queue_acquire_serialised() is going to drain (i.e., stall) the queue on each vkd3d_acquire_vk_queue() call. That seems undesirable by itself, but in the case of Wine's dxgi/d3d12, that's going to happen on every Present() call. Perhaps worse, is there anything preventing an application from attempting to drain the queue (e.g. by calling vkd3d_acquire_vk_queue()) between a Wait() and its corresponding Signal()?

May 2, 2022

Re: [PATCH 05/13] win32u: Move menu item info management from user32.

by Marvin

Hi, While running your changed tests, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at: https://testbot.winehq.org/JobDetails.pl?Key=113920 Your paranoid android. === debian11 (32 bit WoW report) === user32: menu.c:2324: Test failed: test 25

May 2, 2022