December 2021 - Wine-Devel - list.winehq.org

Re: [PATCH] server: Store PE image info in process structure.

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=104702 Your paranoid android. === w1064_tsign (32 bit report) === kernel32: loader.c:2834: Test failed: attached thread count should be 2 === w10pro64 (32 bit report) === kernel32: loader.c:2834: Test failed: attached thread count should be 2 === w1064_tsign (64 bit report) === kernel32: loader.c:720: Test failed: 1219: wrong status c000011b/c0000130 loader.c:720: Test failed: 1224: wrong status c000011b/c000007b loader.c:720: Test failed: 1229: wrong status c000011b/c000007b loader.c:720: Test failed: 1234: wrong status c000011b/c000007b loader.c:720: Test failed: 1239: wrong status c000011b/c000007b loader.c:720: Test failed: 1244: wrong status c000011b/c000007b loader.c:720: Test failed: 1260: wrong status c000011b/0 loader.c:720: Test failed: 1264: wrong status c000011b/0 loader.c:720: Test failed: 1269: wrong status c000011b/0 loader.c:720: Test failed: 1273: wrong status c000011b/0 loader.c:720: Test failed: 1277: wrong status c000011b/0 loader.c:720: Test failed: 1431: wrong status c000011b/c000007b loader.c:720: Test failed: 1439: wrong status c000011b/c000007b loader.c:720: Test failed: 1444: wrong status c000011b/0 loader.c:724: Test failed: 1444: failed with c000011b expected fallback loader.c:720: Test failed: 1450: wrong status c000011b/0 loader.c:724: Test failed: 1450: failed with c000011b expected fallback loader.c:720: Test failed: 1456: wrong status c000011b/0 loader.c:724: Test failed: 1456: failed with c000011b expected fallback loader.c:720: Test failed: 1463: wrong status c000011b/0 loader.c:724: Test failed: 1463: failed with c000011b expected fallback loader.c:720: Test failed: 1469: wrong status c000011b/0 loader.c:720: Test failed: 1478: wrong status c000011b/0 loader.c:720: Test failed: 1482: wrong status c000011b/0 loader.c:720: Test failed: 1486: wrong status c000011b/0 loader.c:720: Test failed: 1490: wrong status c000011b/0 loader.c:720: Test failed: 1494: wrong status c000011b/0 === w10pro64_he (64 bit report) === kernel32: loader.c:720: Test failed: 1219: wrong status c000011b/c0000130 loader.c:720: Test failed: 1224: wrong status c000011b/c000007b loader.c:720: Test failed: 1229: wrong status c000011b/c000007b loader.c:720: Test failed: 1234: wrong status c000011b/c000007b loader.c:720: Test failed: 1239: wrong status c000011b/c000007b loader.c:720: Test failed: 1244: wrong status c000011b/c000007b loader.c:720: Test failed: 1260: wrong status c000011b/0 loader.c:720: Test failed: 1264: wrong status c000011b/0 loader.c:720: Test failed: 1269: wrong status c000011b/0 loader.c:720: Test failed: 1273: wrong status c000011b/0 loader.c:720: Test failed: 1277: wrong status c000011b/0 loader.c:720: Test failed: 1431: wrong status c000011b/c000007b loader.c:720: Test failed: 1439: wrong status c000011b/c000007b loader.c:720: Test failed: 1444: wrong status c000011b/0 loader.c:724: Test failed: 1444: failed with c000011b expected fallback loader.c:720: Test failed: 1450: wrong status c000011b/0 loader.c:724: Test failed: 1450: failed with c000011b expected fallback loader.c:720: Test failed: 1456: wrong status c000011b/0 loader.c:724: Test failed: 1456: failed with c000011b expected fallback loader.c:720: Test failed: 1463: wrong status c000011b/0 loader.c:724: Test failed: 1463: failed with c000011b expected fallback loader.c:720: Test failed: 1469: wrong status c000011b/0 loader.c:720: Test failed: 1478: wrong status c000011b/0 loader.c:720: Test failed: 1482: wrong status c000011b/0 loader.c:720: Test failed: 1486: wrong status c000011b/0 loader.c:720: Test failed: 1490: wrong status c000011b/0 loader.c:720: Test failed: 1494: wrong status c000011b/0 === w10pro64_zh_CN (64 bit report) === kernel32: loader.c:720: Test failed: 1219: wrong status c000011b/c0000130 loader.c:720: Test failed: 1224: wrong status c000011b/c000007b loader.c:720: Test failed: 1229: wrong status c000011b/c000007b loader.c:720: Test failed: 1234: wrong status c000011b/c000007b loader.c:720: Test failed: 1239: wrong status c000011b/c000007b loader.c:720: Test failed: 1244: wrong status c000011b/c000007b loader.c:720: Test failed: 1260: wrong status c000011b/0 loader.c:720: Test failed: 1264: wrong status c000011b/0 loader.c:720: Test failed: 1269: wrong status c000011b/0 loader.c:720: Test failed: 1273: wrong status c000011b/0 loader.c:720: Test failed: 1277: wrong status c000011b/0 loader.c:720: Test failed: 1431: wrong status c000011b/c000007b loader.c:720: Test failed: 1439: wrong status c000011b/c000007b loader.c:720: Test failed: 1444: wrong status c000011b/0 loader.c:724: Test failed: 1444: failed with c000011b expected fallback

Dec. 31, 2021

[PATCH] server: Store PE image info in process structure.

by Paul Gofman

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=51829 Signed-off-by: Paul Gofman <pgofman(a)codeweavers.com> --- The effect of the blamed commit 7ef35b33936682c01f1c825b7d1b07567a691c12 is that before the commit a process was failing to create due to NT image path passed to RtlCreateUserProcess(). That was wrong, NT path are what actually works on Windows and DOS paths do not. When the process creation working after the commit the new process started failing early in initialization due to the parent process unmapping the image section and remapping that as an anoymous mapping before the user part of process was initialized (build_main_module() needs correct image info from NtQueryInformationProcess( ProcessImageInformation ). The process failure at that stage makes parent process wait for 20 sec until timeout. dlls/kernel32/tests/loader.c | 15 +++++++++++++++ server/mapping.c | 1 + server/process.c | 13 ++----------- server/process.h | 1 + 4 files changed, 19 insertions(+), 11 deletions(-) diff --git a/dlls/kernel32/tests/loader.c b/dlls/kernel32/tests/loader.c index c5857174403..f990d632f73 100644 --- a/dlls/kernel32/tests/loader.c +++ b/dlls/kernel32/tests/loader.c @@ -1931,9 +1931,11 @@ static void test_section_access(void) char temp_path[MAX_PATH]; char dll_name[MAX_PATH]; SIZE_T size; + SECTION_IMAGE_INFORMATION image_info; MEMORY_BASIC_INFORMATION info; STARTUPINFOA sti; PROCESS_INFORMATION pi; + NTSTATUS status; DWORD ret; /* prevent displaying of the "Unable to load this DLL" message box */ @@ -2084,6 +2086,19 @@ static void test_section_access(void) ok(!memcmp(buf, section_data, section.SizeOfRawData), "wrong section data\n"); } + status = NtQueryInformationProcess(pi.hProcess, ProcessImageInformation, + &image_info, sizeof(image_info), NULL ); + ok(!status, "Got unexpected status %#x.\n", status); + ok(!(image_info.ImageCharacteristics & IMAGE_FILE_DLL), + "Got unexpected characteristics %#x.\n", nt_header.FileHeader.Characteristics); + status = NtUnmapViewOfSection(pi.hProcess, info.BaseAddress); + ok(!status, "Got unexpected status %#x.\n", status); + status = NtQueryInformationProcess(pi.hProcess, ProcessImageInformation, + &image_info, sizeof(image_info), NULL ); + ok(!status, "Got unexpected status %#x.\n", status); + ok(!(image_info.ImageCharacteristics & IMAGE_FILE_DLL), + "Got unexpected characteristics %#x.\n", nt_header.FileHeader.Characteristics); + SetLastError(0xdeadbeef); ret = TerminateProcess(pi.hProcess, 0); ok(ret, "TerminateProcess() error %d\n", GetLastError()); diff --git a/server/mapping.c b/server/mapping.c index bc9ed5bdcb9..c421bd9961d 100644 --- a/server/mapping.c +++ b/server/mapping.c @@ -408,6 +408,7 @@ static void add_process_view( struct thread *thread, struct memory_view *view ) process->image = NULL; if (get_view_nt_name( view, &name ) && (process->image = memdup( name.str, name.len ))) process->imagelen = name.len; + process->pe_info = view->image; return; } } diff --git a/server/process.c b/server/process.c index 0cc7f6b60ee..a14950e456b 100644 --- a/server/process.c +++ b/server/process.c @@ -680,6 +680,7 @@ struct process *create_process( int fd, struct process *parent, unsigned int fla process->trace_data = 0; process->rawinput_mouse = NULL; process->rawinput_kbd = NULL; + memset( &process->pe_info, 0, sizeof(process->pe_info) ); list_init( &process->kernel_object ); list_init( &process->thread_list ); list_init( &process->locks ); @@ -1502,17 +1503,7 @@ DECL_HANDLER(get_process_info) reply->session_id = process->session_id; reply->machine = process->machine; if (get_reply_max_size()) - { - client_ptr_t base; - const pe_image_info_t *info; - struct memory_view *view = get_exe_view( process ); - if (view) - { - if ((info = get_view_image_info( view, &base ))) - set_reply_data( info, min( sizeof(*info), get_reply_max_size() )); - } - else set_error( STATUS_PROCESS_IS_TERMINATING ); - } + set_reply_data( &process->pe_info, min( sizeof(process->pe_info), get_reply_max_size() )); release_object( process ); } } diff --git a/server/process.h b/server/process.h index 22ee8178368..d14df38a13f 100644 --- a/server/process.h +++ b/server/process.h @@ -89,6 +89,7 @@ struct process const struct rawinput_device *rawinput_mouse; /* rawinput mouse device, if any */ const struct rawinput_device *rawinput_kbd; /* rawinput keyboard device, if any */ struct list kernel_object; /* list of kernel object pointers */ + pe_image_info_t pe_info; /* image info */ }; /* process functions */ -- 2.33.1

Dec. 31, 2021

Re: [PATCH] d2d: Suppress last empty segment also for D2D1_FIGURE_END_OPEN

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=104686 Your paranoid android. === debian11 (32 bit report) === d2d1: d2d1.c:6688: Test failed: Figure does not match. d2d1.c:6729: Test failed: Figure does not match. d2d1.c:10390: Test failed: Test 33: Got unexpected result 0. d2d1.c:10390: Test failed: Test 34: Got unexpected result 0. d2d1.c:10390: Test failed: Test 37: Got unexpected result 0. d2d1.c:10390: Test failed: Test 38: Got unexpected result 0. d2d1.c:10390: Test failed: Test 41: Got unexpected result 0. d2d1.c:10390: Test failed: Test 42: Got unexpected result 0. d2d1.c:10390: Test failed: Test 44: Got unexpected result 0. d2d1.c:10390: Test failed: Test 45: Got unexpected result 0. d2d1.c:10390: Test failed: Test 47: Got unexpected result 0. d2d1.c:10390: Test failed: Test 54: Got unexpected result 0. d2d1.c:10390: Test failed: Test 57: Got unexpected result 0. === debian11 (32 bit Chinese:China report) === d2d1: d2d1.c:10390: Test failed: Test 33: Got unexpected result 0. d2d1.c:10390: Test failed: Test 34: Got unexpected result 0. d2d1.c:10390: Test failed: Test 37: Got unexpected result 0. d2d1.c:10390: Test failed: Test 38: Got unexpected result 0. d2d1.c:10390: Test failed: Test 41: Got unexpected result 0. d2d1.c:10390: Test failed: Test 42: Got unexpected result 0. d2d1.c:10390: Test failed: Test 44: Got unexpected result 0. d2d1.c:10390: Test failed: Test 45: Got unexpected result 0. d2d1.c:10390: Test failed: Test 47: Got unexpected result 0. d2d1.c:10390: Test failed: Test 54: Got unexpected result 0. d2d1.c:10390: Test failed: Test 57: Got unexpected result 0. === debian11 (32 bit WoW report) === d2d1: d2d1.c:10390: Test failed: Test 33: Got unexpected result 0. d2d1.c:10390: Test failed: Test 34: Got unexpected result 0. d2d1.c:10390: Test failed: Test 37: Got unexpected result 0. d2d1.c:10390: Test failed: Test 38: Got unexpected result 0. d2d1.c:10390: Test failed: Test 41: Got unexpected result 0. d2d1.c:10390: Test failed: Test 42: Got unexpected result 0. d2d1.c:10390: Test failed: Test 44: Got unexpected result 0. d2d1.c:10390: Test failed: Test 45: Got unexpected result 0. d2d1.c:10390: Test failed: Test 47: Got unexpected result 0. d2d1.c:10390: Test failed: Test 54: Got unexpected result 0. d2d1.c:10390: Test failed: Test 57: Got unexpected result 0. d2d1.c:6664: Test failed: Figure does not match. === debian11 (64 bit WoW report) === d2d1: d2d1.c:10390: Test failed: Test 33: Got unexpected result 0. d2d1.c:10390: Test failed: Test 34: Got unexpected result 0. d2d1.c:10390: Test failed: Test 37: Got unexpected result 0. d2d1.c:10390: Test failed: Test 38: Got unexpected result 0. d2d1.c:10390: Test failed: Test 41: Got unexpected result 0. d2d1.c:10390: Test failed: Test 42: Got unexpected result 0. d2d1.c:10390: Test failed: Test 44: Got unexpected result 0. d2d1.c:10390: Test failed: Test 45: Got unexpected result 0. d2d1.c:10390: Test failed: Test 47: Got unexpected result 0. d2d1.c:10390: Test failed: Test 54: Got unexpected result 0. d2d1.c:10390: Test failed: Test 57: Got unexpected result 0.

Dec. 31, 2021

Re: [PATCH v2] darwin: Fix non-Metal build

by Brendan Shanks

> On Dec 28, 2021, at 8:22 AM, Dean Greer <gcenx83(a)gmail.com> wrote: > > Tested this on an actual 10.9 install (10.8 is harder to get setup) and still the same issue nothing gets displayed other than the bar as shown in one of the prior emails. I built and ran Wine on 10.13, and I get the same result. The regression commit is "winemac.drv: Remove now unused -[WineContentView drawRect:].”, 3f845b34deada0dd58e3674119af47ce85851c24. The problem seems to be that WineContentView updateLayer isn’t being called for some reason. What’s weird is, if I add back an empty implementation of drawRect: like this, it does work. diff --git a/dlls/winemac.drv/cocoa_window.m b/dlls/winemac.drv/cocoa_window.m index d0672b7fb06..1ee582e6b59 100644 --- a/dlls/winemac.drv/cocoa_window.m +++ b/dlls/winemac.drv/cocoa_window.m @@ -477,6 +477,10 @@ - (BOOL) isFlipped return YES; } + - (void) drawRect:(NSRect)rect + { + } + - (BOOL) wantsUpdateLayer { return YES /*!_everHadGLContext*/; Dean, does this change make a difference for you on 10.9? And Chip, any idea why this would make a difference or if this is the right thing to do? drawRect: isn’t even being called, it’s existence alone seems to make things work. (Note that this is on a 2010 MacBook which is about as old a machine as 10.13 supported. In particular, it has a GeForce 320M which doesn’t support Metal, but I don’t think this should make a difference. I’ll test out a 10.13 machine with Metal to be sure.) Brendan

Dec. 31, 2021

[PATCH] d2d: Suppress last empty segment also for D2D1_FIGURE_END_OPEN

by Stefan Brüns

When the last vertex is coincident with the first vertex, the last segment should be suppressed for both END_OPEN and END_CLOSED. When the last, zero length segment is not omitted d2d_geometry_intersect_self will add invalid segments. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=51139 Signed-off-by: Stefan Brüns <stefan.bruens(a)rwth-aachen.de> --- dlls/d2d1/geometry.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/dlls/d2d1/geometry.c b/dlls/d2d1/geometry.c index a7074899fda..95aaf199ad2 100644 --- a/dlls/d2d1/geometry.c +++ b/dlls/d2d1/geometry.c @@ -2917,8 +2917,9 @@ static void STDMETHODCALLTYPE d2d_geometry_sink_EndFigure(ID2D1GeometrySink *ifa { ++geometry->u.path.segment_count; figure->flags |= D2D_FIGURE_FLAG_CLOSED; - if (!memcmp(&figure->vertices[0], &figure->vertices[figure->vertex_count - 1], sizeof(*figure->vertices))) - --figure->vertex_count; + } + if (!memcmp(&figure->vertices[0], &figure->vertices[figure->vertex_count - 1], sizeof(*figure->vertices))) { + --figure->vertex_count; } if (!d2d_geometry_add_figure_outline(geometry, figure, figure_end)) -- 2.34.1

Dec. 30, 2021

Re: [PATCH vkd3d] vkd3d-shader/hlsl: Support casts between all numeric types on constant folding.

by Zebediah Figura (she/her)

On 12/30/21 15:55, Francisco Casas wrote: > I agree. And if we do that, maybe we can do functions like these: > >> /* This macro is just to illustrate the similarity among the functions */ >> #define CONSTANT_OP2_FUNCTION(function_name,operator) \ >> void function_name(struct hlsl_ir_constant *res, struct hlsl_ir_constant *arg1, \ >> struct hlsl_ir_constant *arg2, enum hlsl_base_type type) \ >> { \ >> for(int k=0; k<4; k++) \ >> { \ >> switch (type) \ >> { \ >> case HLSL_TYPE_FLOAT: \ >> case HLSL_TYPE_HALF: \ >> res->value[k].f = arg1->value[k].f operator arg2->value[k].f; \ >> break; \ >> case HLSL_TYPE_DOUBLE: \ >> res->value[k].d = arg1->value[k].d operator arg2->value[k].d; \ >> break; \ >> case HLSL_TYPE_INT: \ >> res->value[k].i = arg1->value[k].i operator arg2->value[k].i; \ >> break; \ >> case HLSL_TYPE_UINT: \ >> res->value[k].u = arg1->value[k].u operator arg2->value[k].u; \ >> break; \ >> case HLSL_TYPE_BOOL: \ >> res->value[k].u = !!((!!(arg1->value[k].u)) operator (!!(arg2->value[k].u))) * 0xffffffff; \ >> break; \ >> default: \ >> assert(0); \ >> break; \ >> } \ >> } \ >> } >> >> CONSTANT_OP2_FUNCTION(constant_value_sum,+) >> CONSTANT_OP2_FUNCTION(constant_value_sub,-) >> CONSTANT_OP2_FUNCTION(constant_value_mult,+) >> CONSTANT_OP2_FUNCTION(constant_value_neg,* (-1) + 0 *) /* horrid? */ >> CONSTANT_OP2_FUNCTION(constant_value_div,/) /* horrid? */ > > And call one of these on each case of the switch. > > As using macros this way is too ugly, I think we should consider creating > a new "constant_ops.c" file to define all these boilerplate functions for > constant values. They may get even larger if we support matrices. Maybe. I'd prefer to avoid preprocessor macros, though, and defer any sort of code generation until it becomes necessary. > >>> + { >>> + if (instr->data_type->dimx != arg1->node.data_type->dimx >>> + || instr->data_type->dimy != arg1->node.data_type->dimy) >>> + { >>> + WARN("Cast from %s to %s.\n", debug_hlsl_type(ctx, arg1->node.data_type), >>> + debug_hlsl_type(ctx, instr->data_type)); >> >> Why remove the "return false" from this? Also, why change it from a FIXME? >> > > Casting to a vector type with a smaller dimension works in the native compiler, > albeit with a warning. Since hlsl_cast_constant_value() copies all 4 values even > if they are not used, these cases should be covered now. > However, yes, casting to a type with a larger dimension should result in an error, > unless it is from a scalar. > I recognize I didn't think it too much, I will handle these cases better. Sure, but we should handle that elsewhere. In fact we already have lower_narrowing_casts() for this. > >>> + } >>> + memcpy(res->value, arg1->value, sizeof(res->value)); >> >> What's the point of copying to the value if we're just going to overwrite it? >> > > hlsl_cast_constant_value() expects the original value to be in the same constant > on which the result is written, so it has to be copied on the new node first. > The alternative would be receiving both a source and target hlsl_ir_constant... > maybe it is better that way. Eh, indeed, I skimmed and misread it. I'm inclined to specify source and target separately, yes.

Dec. 30, 2021

Re: [PATCH vkd3d] vkd3d-shader/hlsl: Support casts between all numeric types on constant folding.

by Francisco Casas

December 30, 2021 3:06 PM, "Zebediah Figura (she/her)" <zfigura(a)codeweavers.com> wrote: > On 12/29/21 08:51, Francisco Casas wrote: > >> Signed-off-by: Francisco Casas <fcasas(a)codeweavers.com> >> --- >> This is a proposal to handle all numeric constants in the same way. >> Signed-off-by: Francisco Casas <fcasas(a)codeweavers.com> >> --- >> Makefile.am | 1 - >> libs/vkd3d-shader/hlsl.c | 54 ++++++++++++++++++++++++++++++++ >> libs/vkd3d-shader/hlsl.h | 3 ++ >> libs/vkd3d-shader/hlsl_codegen.c | 48 ++++++++++------------------ >> 4 files changed, 73 insertions(+), 33 deletions(-) > > The approach seems sensible to me. I don't see a need to put the function in hlsl.c, though. > Okay, I am moving it to hlsl_codegen.c then, before fold_constants(). >> diff --git a/libs/vkd3d-shader/hlsl.c b/libs/vkd3d-shader/hlsl.c >> index d2ea4c34..a44b638e 100644 >> --- a/libs/vkd3d-shader/hlsl.c >> +++ b/libs/vkd3d-shader/hlsl.c >> @@ -1663,6 +1663,60 @@ unsigned int hlsl_combine_swizzles(unsigned int first, unsigned int second, >> unsi >> return ret; >> } >>> +void hlsl_cast_constant_value(struct hlsl_ir_constant *con, enum hlsl_base_type current, >> + enum hlsl_base_type target){ >> + uint32_t u; int32_t i; float f; double d; > > Please try to avoid putting multiple statements or declarations on one line. > Okay, I felt that this function was a special case, but I will follow these standards more rigorously from now on. >> + >> + assert(con); > > This assert seems unnecessary. > Ok >> + for (int k = 0; k < 4; k++) >> + { >> + switch (current) >> + { >> + case HLSL_TYPE_FLOAT: >> + case HLSL_TYPE_HALF: >> + u = con->value[k].f; i = con->value[k].f; f = con->value[k].f; d = con->value[k].f; >> + break; >> + case HLSL_TYPE_DOUBLE: >> + u = con->value[k].d; i = con->value[k].d; f = con->value[k].d; d = con->value[k].d; >> + break; >> + case HLSL_TYPE_INT: >> + u = con->value[k].i; i = con->value[k].i; f = con->value[k].i; d = con->value[k].i; >> + break; >> + case HLSL_TYPE_UINT: >> + u = con->value[k].u; i = con->value[k].u; f = con->value[k].u; d = con->value[k].u; >> + break; >> + case HLSL_TYPE_BOOL: >> + u = !!con->value[k].u; i = !!con->value[k].u; f = !!con->value[k].u; d = !!con->value[k].u; >> + break; >> + default: >> + assert(0); >> + break; >> + } >> + switch (target) >> + { >> + case HLSL_TYPE_FLOAT: >> + case HLSL_TYPE_HALF: >> + con->value[k].f = f; >> + break; >> + case HLSL_TYPE_DOUBLE: >> + con->value[k].d = d; >> + break; >> + case HLSL_TYPE_INT: >> + con->value[k].i = i; >> + break; >> + case HLSL_TYPE_UINT: >> + con->value[k].u = u; >> + break; >> + case HLSL_TYPE_BOOL: >> + con->value[k].u = (!!u) * 0xffffffff; >> + break; >> + default: >> + assert(0); >> + break; >> + } >> + } >> +} >> + >> static const struct hlsl_profile_info *get_target_info(const char *target) >> { >> unsigned int i; >> diff --git a/libs/vkd3d-shader/hlsl.h b/libs/vkd3d-shader/hlsl.h >> index 57acf3a0..a07ccf17 100644 >> --- a/libs/vkd3d-shader/hlsl.h >> +++ b/libs/vkd3d-shader/hlsl.h >> @@ -755,6 +755,9 @@ unsigned int hlsl_combine_writemasks(unsigned int first, unsigned int second); >> unsigned int hlsl_map_swizzle(unsigned int swizzle, unsigned int writemask); >> unsigned int hlsl_swizzle_from_writemask(unsigned int writemask); >>> +void hlsl_cast_constant_value(struct hlsl_ir_constant *con, enum hlsl_base_type current, >> + enum hlsl_base_type target); >> + >> bool hlsl_offset_from_deref(const struct hlsl_deref *deref, unsigned int *offset); >> unsigned int hlsl_offset_from_deref_safe(struct hlsl_ctx *ctx, const struct hlsl_deref *deref); >> struct hlsl_reg hlsl_reg_from_deref(struct hlsl_ctx *ctx, const struct hlsl_deref *deref, >> diff --git a/libs/vkd3d-shader/hlsl_codegen.c b/libs/vkd3d-shader/hlsl_codegen.c >> index 75716bdf..ef627f2b 100644 >> --- a/libs/vkd3d-shader/hlsl_codegen.c >> +++ b/libs/vkd3d-shader/hlsl_codegen.c >> @@ -656,7 +656,7 @@ static bool fold_constants(struct hlsl_ctx *ctx, struct hlsl_ir_node *instr, >> voi >> { >> struct hlsl_ir_constant *arg1, *arg2 = NULL, *res; >> struct hlsl_ir_expr *expr; >> - unsigned int i, dimx; >> + unsigned int i; >>> if (instr->type != HLSL_IR_EXPR) >> return false; >> @@ -670,48 +670,32 @@ static bool fold_constants(struct hlsl_ctx *ctx, struct hlsl_ir_node *instr, >> voi >> arg1 = hlsl_ir_constant(expr->operands[0].node); >> if (expr->operands[1].node) >> arg2 = hlsl_ir_constant(expr->operands[1].node); >> - dimx = instr->data_type->dimx; >>> if (!(res = hlsl_alloc(ctx, sizeof(*res)))) >> return false; >> init_node(&res->node, HLSL_IR_CONSTANT, instr->data_type, instr->loc); >>> + if (expr->op == HLSL_OP1_CAST && instr->data_type->base_type <= HLSL_TYPE_LAST_SCALAR) > > Frankly we may want to consider swapping the "switch" block order then. Especially considering that > we might want to add other operations that aren't typed. > I agree. And if we do that, maybe we can do functions like these: > /* This macro is just to illustrate the similarity among the functions */ > #define CONSTANT_OP2_FUNCTION(function_name,operator) \ > void function_name(struct hlsl_ir_constant *res, struct hlsl_ir_constant *arg1, \ > struct hlsl_ir_constant *arg2, enum hlsl_base_type type) \ > { \ > for(int k=0; k<4; k++) \ > { \ > switch (type) \ > { \ > case HLSL_TYPE_FLOAT: \ > case HLSL_TYPE_HALF: \ > res->value[k].f = arg1->value[k].f operator arg2->value[k].f; \ > break; \ > case HLSL_TYPE_DOUBLE: \ > res->value[k].d = arg1->value[k].d operator arg2->value[k].d; \ > break; \ > case HLSL_TYPE_INT: \ > res->value[k].i = arg1->value[k].i operator arg2->value[k].i; \ > break; \ > case HLSL_TYPE_UINT: \ > res->value[k].u = arg1->value[k].u operator arg2->value[k].u; \ > break; \ > case HLSL_TYPE_BOOL: \ > res->value[k].u = !!((!!(arg1->value[k].u)) operator (!!(arg2->value[k].u))) * 0xffffffff; \ > break; \ > default: \ > assert(0); \ > break; \ > } \ > } \ > } > > CONSTANT_OP2_FUNCTION(constant_value_sum,+) > CONSTANT_OP2_FUNCTION(constant_value_sub,-) > CONSTANT_OP2_FUNCTION(constant_value_mult,+) > CONSTANT_OP2_FUNCTION(constant_value_neg,* (-1) + 0 *) /* horrid? */ > CONSTANT_OP2_FUNCTION(constant_value_div,/) /* horrid? */ And call one of these on each case of the switch. As using macros this way is too ugly, I think we should consider creating a new "constant_ops.c" file to define all these boilerplate functions for constant values. They may get even larger if we support matrices. >> + { >> + if (instr->data_type->dimx != arg1->node.data_type->dimx >> + || instr->data_type->dimy != arg1->node.data_type->dimy) >> + { >> + WARN("Cast from %s to %s.\n", debug_hlsl_type(ctx, arg1->node.data_type), >> + debug_hlsl_type(ctx, instr->data_type)); > > Why remove the "return false" from this? Also, why change it from a FIXME? > Casting to a vector type with a smaller dimension works in the native compiler, albeit with a warning. Since hlsl_cast_constant_value() copies all 4 values even if they are not used, these cases should be covered now. However, yes, casting to a type with a larger dimension should result in an error, unless it is from a scalar. I recognize I didn't think it too much, I will handle these cases better. >> + } >> + memcpy(res->value, arg1->value, sizeof(res->value)); > > What's the point of copying to the value if we're just going to overwrite it? > hlsl_cast_constant_value() expects the original value to be in the same constant on which the result is written, so it has to be copied on the new node first. The alternative would be receiving both a source and target hlsl_ir_constant... maybe it is better that way. >> + hlsl_cast_constant_value(res, arg1->node.data_type->base_type, instr->data_type->base_type); >> + list_add_before(&expr->node.entry, &res->node.entry); >> + replace_node(&expr->node, &res->node); >> + return res; > > fold_constants() returns bool. If you're not compiling with -Werror already I'd recommend it. > Sorry, I missed that because I initially wrote this on another branch, thanks for the tip. >> + } >> +

Dec. 30, 2021

[PATCH] winex11.drv: Call XRaiseWindow during WM_TAKE_FOCUS handler.

by Ethan Searl

In the case where the original hwnd rejects the focus and we search for something else, raise the window because it may not be on top. This prevents showing modal windows on top of non-modal. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=26503 Signed-off-by: Ethan Searl <internetethansearl(a)gmail.com> --- dlls/winex11.drv/event.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/dlls/winex11.drv/event.c b/dlls/winex11.drv/event.c index 170111e9c28..183efe17d3a 100644 --- a/dlls/winex11.drv/event.c +++ b/dlls/winex11.drv/event.c @@ -722,7 +722,16 @@ static void handle_wm_protocols( HWND hwnd, XClientMessageEvent *event ) if (hwnd) hwnd = GetAncestor( hwnd, GA_ROOT ); if (!hwnd) hwnd = GetActiveWindow(); if (!hwnd) hwnd = last_focus; - if (hwnd && can_activate_window(hwnd)) set_focus( event->display, hwnd, event_time ); + if (hwnd && can_activate_window(hwnd)) + { + Window win = X11DRV_get_whole_window(hwnd); + if (win) + { + TRACE("will raise window %p", hwnd); + XRaiseWindow(event->display, win); + } + set_focus( event->display, hwnd, event_time ); + } } else if (protocol == x11drv_atom(_NET_WM_PING)) { -- 2.27.0

Dec. 30, 2021

Re: [PATCH resend 1/2] ddraw: Use WINED3D_SWAPCHAIN_NO_WINDOW_CHANGES only with DDSCL_NOWINDOWCHANGES or if window inactive.

by Gabriel Ivăncescu

Sorry, forgot to actually test normal d3d9, I've only tested the extended before, so what I wrote is for d3d9ex. Normal d3d9 is the same as dxgi: it doesn't care if it's active or not. Which is kinda interesting, didn't expect it to be that different.

Dec. 30, 2021

Re: [PATCH vkd3d] vkd3d-shader/hlsl: Support casts between all numeric types on constant folding.

by Zebediah Figura (she/her)

On 12/30/21 12:06, Zebediah Figura (she/her) wrote: >> @@ -670,48 +670,32 @@ static bool fold_constants(struct hlsl_ctx *ctx, >> struct hlsl_ir_node *instr, voi >> arg1 = hlsl_ir_constant(expr->operands[0].node); >> if (expr->operands[1].node) >> arg2 = hlsl_ir_constant(expr->operands[1].node); >> - dimx = instr->data_type->dimx; >> if (!(res = hlsl_alloc(ctx, sizeof(*res)))) >> return false; >> init_node(&res->node, HLSL_IR_CONSTANT, instr->data_type, >> instr->loc); >> + if (expr->op == HLSL_OP1_CAST && instr->data_type->base_type <= >> HLSL_TYPE_LAST_SCALAR) > > Frankly we may want to consider swapping the "switch" block order then. > Especially considering that we might want to add other operations that > aren't typed. > FWIW, this should be a separate patch, and can be deferred until later anyway.

Dec. 30, 2021