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

Re: [PATCH 1/6] msvcp140_atomic_wait/tests: Add test for threadpool_work functions.

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=106117 Your paranoid android. === build (build log) === Task: Patch failed to apply === debian11 (build log) === Task: Patch failed to apply === debian11 (build log) === Task: Patch failed to apply

Jan. 26, 2022

[PATCH 6/6] msvcp140_atomic_wait: Implement __std_bulk_submit_threadpool_work.

by Daniel Lehman

Jan. 26, 2022

[PATCH 5/6] msvcp140_atomic_wait: Implement __std_close_threadpool_work.

by Daniel Lehman

Jan. 26, 2022

[PATCH 4/6] msvcp140_atomic_wait: Implement __std_wait_for_threadpool_work_callbacks.

by Daniel Lehman

Jan. 26, 2022

[PATCH 3/6] msvcp140_atomic_wait: Implement __std_submit_threadpool_work.

by Daniel Lehman

Jan. 26, 2022

[PATCH 2/6] msvcp140_atomic_wait: Implement __std_create_threadpool_work.

by Daniel Lehman

Jan. 26, 2022

[PATCH 1/6] msvcp140_atomic_wait/tests: Add test for threadpool_work functions.

by Daniel Lehman

Jan. 26, 2022

Re: Arbitrary DOS device name

by Daniel Kucera

On 2022-01-26 10:09, Stefan Dösinger wrote: > > One other option to investigate: Write a small Windows/Wine device > driver that > registers the character device and forwards it to the Unix device node. > If you > get that working you shouldn't need to modify wineserver in a very > device > specific way. In theory the API is also stable (Wine just implements > the > Windows driver API), so the Windows device driver can live out of tree. > > See dlls/*.sys for some examples of existing device drivers; In > particular > mountmgr.sys, wineusb.sys are examples of drivers that talk to both the > Windows and Unix side. Okay, I'm going to try this. So far I have managed to compile an empty hantek.sys.so (copied and renamed tdi.sys). danman(a)silverhorse:~/storage/Projects/hantek-usb/wine/dlls/hantek.sys$ ls -lah total 256K drwxrwxr-x 2 danman danman 4,0K jan 26 23:33 . drwxrwxr-x 864 danman danman 36K jan 26 23:21 .. -rw-rw-r-- 1 danman danman 118 jan 26 23:33 .gitignore -rw-rw-r-- 1 danman danman 1,1K jan 26 23:33 hantek.sys.fake -rwxrwxr-x 1 danman danman 126K jan 26 23:33 hantek.sys.so -rw-rw-r-- 1 danman danman 1,7K jan 26 23:21 hantek.sys.spec -rw-rw-r-- 1 danman danman 1,2K jan 26 23:22 main.c -rw-rw-r-- 1 danman danman 52K jan 26 23:33 main.o -rw-rw-r-- 1 danman danman 11K jan 26 23:33 Makefile -rw-rw-r-- 1 danman danman 95 jan 26 23:22 Makefile.in How do I load it in wine now?

Jan. 26, 2022

Re: [PATCH] ws2_32: Increased MAX_SOCKETS_PER_PROCESS to 256

by Zebediah Figura (she/her)

Hello Andrew, thanks for the patch! On 1/26/22 11:10, Andrew Miskell wrote: > Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=50352 > Signed-off-by: Andrew Miskell <andrewmiskell(a)mac.com> > --- > dlls/ws2_32/socket.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/dlls/ws2_32/socket.c b/dlls/ws2_32/socket.c > index fe7e4fb3464..004e386e5a8 100644 > --- a/dlls/ws2_32/socket.c > +++ b/dlls/ws2_32/socket.c > @@ -419,7 +419,7 @@ static BOOL socket_list_remove( SOCKET socket ) > return FALSE; > } > > -#define MAX_SOCKETS_PER_PROCESS 128 /* reasonable guess */ > +#define MAX_SOCKETS_PER_PROCESS 256 /* reasonable guess */ > #define MAX_UDP_DATAGRAM 1024 > static INT WINAPI WSA_DefaultBlockingHook( FARPROC x ); > Could you please add some tests for this, and in particular tests for different version numbers passed to WSAStartup()? A brief check suggests this isn't what modern Windows returns. While you're at it, I think there's no reason to keep this in a #define near the top of the file; it's only used in one place.

Jan. 26, 2022

Re: [PATCH v5 vkd3d 12/13] vkd3d-shader/hlsl: Implement texture gather methods.

by Matteo Bruni

On Wed, Jan 26, 2022 at 11:02 PM Matteo Bruni <matteo.mystral(a)gmail.com> wrote: > > On Wed, Jan 26, 2022 at 11:00 PM Zebediah Figura (she/her) > <zfigura(a)codeweavers.com> wrote: > > > > On 1/26/22 15:48, Matteo Bruni wrote: > > > On Wed, Jan 26, 2022 at 10:33 PM Zebediah Figura (she/her) > > > <zfigura(a)codeweavers.com> wrote: > > >> > > >> On 1/26/22 08:52, Matteo Bruni wrote: > > >>> On Wed, Jan 19, 2022 at 1:06 PM Matteo Bruni <matteo.mystral(a)gmail.com> wrote: > > >>>> > > >>>> On Wed, Dec 22, 2021 at 12:23 AM Zebediah Figura > > >>>> <zfigura(a)codeweavers.com> wrote: > > >>>>> > > >>>>> From: Francisco Casas <fcasas(a)codeweavers.com> > > >>>>> > > >>>>> Signed-off-by: Francisco Casas <fcasas(a)codeweavers.com> > > >>>>> Signed-off-by: Zebediah Figura <zfigura(a)codeweavers.com> > > >>>>> --- > > >>>>> v5: Strip newlines from hlsl_fixme(), get rid of the as-yet-unused > > >>>>> status_out_arg variable, expand the srcs[] array to have size 4, use sm4 > > >>>>> register helpers, minor stylistic tweaks. > > >>>>> > > >>>>> libs/vkd3d-shader/hlsl.c | 4 ++ > > >>>>> libs/vkd3d-shader/hlsl.h | 4 ++ > > >>>>> libs/vkd3d-shader/hlsl.y | 99 ++++++++++++++++++++++++++++++++++++ > > >>>>> libs/vkd3d-shader/hlsl_sm4.c | 57 ++++++++++++++++++++- > > >>>>> 4 files changed, 163 insertions(+), 1 deletion(-) > > >>>>> > > >>>>> diff --git a/libs/vkd3d-shader/hlsl.c b/libs/vkd3d-shader/hlsl.c > > >>>>> index 26175008d..856fb0f9d 100644 > > >>>>> --- a/libs/vkd3d-shader/hlsl.c > > >>>>> +++ b/libs/vkd3d-shader/hlsl.c > > >>>>> @@ -1280,6 +1280,10 @@ static void dump_ir_resource_load(struct vkd3d_string_buffer *buffer, const stru > > >>>>> { > > >>>>> [HLSL_RESOURCE_LOAD] = "load_resource", > > >>>>> [HLSL_RESOURCE_SAMPLE] = "sample", > > >>>>> + [HLSL_RESOURCE_GATHER_RED] = "gather_red", > > >>>>> + [HLSL_RESOURCE_GATHER_GREEN] = "gather_green", > > >>>>> + [HLSL_RESOURCE_GATHER_BLUE] = "gather_blue", > > >>>>> + [HLSL_RESOURCE_GATHER_ALPHA] = "gather_alpha", > > >>>>> }; > > >>>>> > > >>>>> vkd3d_string_buffer_printf(buffer, "%s(resource = ", type_names[load->load_type]); > > >>>>> diff --git a/libs/vkd3d-shader/hlsl.h b/libs/vkd3d-shader/hlsl.h > > >>>>> index 2396adb40..49fa8d9d3 100644 > > >>>>> --- a/libs/vkd3d-shader/hlsl.h > > >>>>> +++ b/libs/vkd3d-shader/hlsl.h > > >>>>> @@ -378,6 +378,10 @@ enum hlsl_resource_load_type > > >>>>> { > > >>>>> HLSL_RESOURCE_LOAD, > > >>>>> HLSL_RESOURCE_SAMPLE, > > >>>>> + HLSL_RESOURCE_GATHER_RED, > > >>>>> + HLSL_RESOURCE_GATHER_GREEN, > > >>>>> + HLSL_RESOURCE_GATHER_BLUE, > > >>>>> + HLSL_RESOURCE_GATHER_ALPHA, > > >>>>> }; > > >>>>> > > >>>>> struct hlsl_ir_resource_load > > >>>>> diff --git a/libs/vkd3d-shader/hlsl.y b/libs/vkd3d-shader/hlsl.y > > >>>>> index 9b1e5c071..460ba44bb 100644 > > >>>>> --- a/libs/vkd3d-shader/hlsl.y > > >>>>> +++ b/libs/vkd3d-shader/hlsl.y > > >>>>> @@ -1930,6 +1930,105 @@ static bool add_method_call(struct hlsl_ctx *ctx, struct list *instrs, struct hl > > >>>>> list_add_tail(instrs, &load->node.entry); > > >>>>> return true; > > >>>>> } > > >>>>> + else if (!strcmp(name, "Gather") || !strcmp(name, "GatherRed") || !strcmp(name, "GatherBlue") > > >>>>> + || !strcmp(name, "GatherGreen") || !strcmp(name, "GatherAlpha")) > > >>>>> + { > > >>>>> + const unsigned int sampler_dim = sampler_dim_count(object_type->sampler_dim); > > >>>>> + enum hlsl_resource_load_type load_type; > > >>>>> + const struct hlsl_type *sampler_type; > > >>>>> + struct hlsl_ir_resource_load *load; > > >>>>> + struct hlsl_ir_node *offset = NULL; > > >>>>> + struct hlsl_ir_load *sampler_load; > > >>>>> + struct hlsl_type *result_type; > > >>>>> + struct hlsl_ir_node *coords; > > >>>>> + unsigned int read_channel; > > >>>>> + > > >>>>> + if (!strcmp(name, "GatherGreen")) > > >>>>> + { > > >>> > > >>> At some point we probably want to introduce an enum for intrinsics and > > >>> e.g. table-driven intrinsic_from_{function,method}() helpers to find > > >>> out which intrinsic a call is supposed to match, if any. Repeatedly > > >>> string-matching the function name like this is a bit ugly and it's > > >>> only going to get worse as we introduce more intrinsics. > > >>> The intrinsics currently in hlsl.y, intrinsic_functions[] sidestep the > > >>> problem but that's only going to apply to those that can be inlined > > >>> straight away. > > >> > > >> I agree that a table would help here. I'm not sure I understand the > > >> concern about intrinsics that can't be inlined, though; can you please > > >> elaborate? > > > > > > I'm referring to those intrinsics that shouldn't become expressions > > > but stay as function calls, to make sure they aren't reordered or > > > otherwise optimized (e.g. barriers). As we discussed earlier, they > > > could also be represented by a separate instruction type, in which > > > case they are sort of inlined anyway and, I guess, the existing > > > intrinsic_functions[] table could be a good place for the > > > string-to-enum conversion I'm proposing. > > > > That seems like an orthogonal problem; there's nothing about the way > > intrinsic functions are currently handled that is tied to EXPR types. > > I.e. there's no reason an handler from the intrinsic_functions table has > > to emit an HLSL_IR_EXPR; it could just as easily emit HLSL_IR_INTRINSIC > > or HLSL_IR_BARRIER or whatever it'd end up being called. > > Yeah. Just saying that that's what I meant with "intrinsics that can't > be inlined". To be clear, in my original comment I really don't care about the inlining or not aspect aka representing "atomic" intrinsics as a non-inlined call or in some other way. I guess I should have left the final sentence out, it only added to the confusion.

Jan. 26, 2022