October 2023 - Wine-GitLab - list.winehq.org

[PATCH 0/5] MR4019: wined3d: Dynamic buffer maps without GL_ARB_buffer_storage
by Stefan Dösinger Oct. 5, 2023

Oct. 5, 2023

This patchset implements dynamic resource handling, and in particular NOOVERWRITE buffer maps, in situations where we don't have GL_ARB_buffer_storage. This is relevant e.g. on MacOS but probably also on some ARM CPUs where write combined memory has different performance characteristics than windows games expect [0]. Some benchmark results from hl2 (chosen because it is very CPU heavy on modern systems and heavy use of dynamic resources), tested on a MacBookPro14,3 on Linux with GL_ARB_buffer_storage disabled. "csmt usr" means with patch "wined3d: Avoid heap_alloc in update_sub_resource.", "heap usr" without this patch. "no dyn" means the current upstream code with buffer storage disabled. "sysmem dyn" means the entire patchset of this MR with buffer storage disabled. "BO dyn" is current wine code with GL_ARB_buffer_storage available. I also double checked that this patchset has no impact on this default case. "heapalloc dyn" means the current code in cs_map_upload_bo that returns HeapAlloc'ed memory, just enabled for dynamic buffer maps. This code is faster than sysmem dyn because it doesn't re-upload the entire BO after a DISCARD map. It also happens to be incorrect for non-DISCARD maps because we aren't allowed to throw away existing data, but I think it isn't ever used for maps in practise due to mutually exclusive flag checks in the callers and callee. Summary: This patchset improves performance measurably (240 fps to 327 fps). The patch that avoids HeapAlloc calls when setting shader constants has an impact, but it is relatively small - much smaller than I expected. Plus the ntdll heap code is pretty good by now. csmt usr heap usr no dyn 246 240 sysmem dyn 327 318 BO dyn 382 369 heapalloc dyn 344 335 0: https://gitlab.freedesktop.org/mesa/mesa/-/issues/8301 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4019

3 7

[PATCH 0/8] MR4016: ieframe: Implement error page on navigation error.
by Gabriel Ivăncescu Oct. 5, 2023

Oct. 5, 2023

This should implement error page navigation similar to native, which is unfortunately mostly undocumented. Briefly, native uses a local resource in some DLL (the exact one varies by Windows version and locale, so it's not reliable to test) which has a bunch of html error pages for various errors (404 is a different resource than 405, etc). In Windows XP this is in `shdoclc.dll` (which is where I placed it as well, because we already use it in Wine), in Windows 10 it's somewhere in `system32\en-US\ieframe.dll` (or something like that), for US locale at least. To keep it simple for now, this only adds one error page called `ERROR.HTM` though, which is generic and displays the error code (given via a query). That said, it should still probably be localized somehow, but I've no idea how to localize html resources… The error page is navigated with URL of the form `res://C:\windows\system32\.../NAME.HTM#original_url`, and some of the notifications are special cased to return the original_url from the fragment (on native as well, tests included). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4016

3 12

[PATCH 0/9] MR390: ci: Run tests using dxcompiler.
by Giovanni Mascellani (＠giomasce) Oct. 5, 2023

Oct. 5, 2023

This goes on top of !346. See [a pipeline example](https://gitlab.winehq.org/giomasce/vkd3d/-/pipelines/16064). -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/390

4 11

[PATCH 0/4] MR387: vkd3d-shader/tpf: Miscelaneous improvements.
by Francisco Casas (＠fcasas) Oct. 5, 2023

Oct. 5, 2023

Minor improvements that came up while upstreaming the patches from the `vkd3d-shader/tpf: Replace sm4 register structs with vkd3d-shader register structs` series. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/387

4 6

[PATCH v4 0/3] MR3876: Draft: Zero-width character handling in GetTextExtentExPoint[AW]
by Torge Matthies (＠tmatthies) Oct. 5, 2023

Oct. 5, 2023

Certain characters are considered by GetTextExtentExPointA/W to have no width, even if they have a non-zero width and a shape in the font. This MR attempts to bring Wine's implementation of these functions closer to native behavior, though I was not able to get it anywhere near perfect. -- v4: win32u: Handle glyphs that are marked by the font as zero-width in GetTextExtentExPoint. win32u: Handle characters that are hard-coded to have no width in GetTextExtentExPoint. gdi32/tests: Add test for width of carriage return and line feed. https://gitlab.winehq.org/wine/wine/-/merge_requests/3876

4 15

[PATCH 0/2] MR4021: Partial support for EMR_EXTCREATEPEN.
by Piotr Caban (＠piotr) Oct. 5, 2023

Oct. 5, 2023

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55606 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4021

3 3

[PATCH v2 0/1] MR381: vkd3d-shader/tpf: Handle "COLOR" semantic the same way as "sv_target" in the parser.
by Nikolay Sivov (＠nsivov) Oct. 5, 2023

Oct. 5, 2023

Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> -- v2: vkd3d-shader/tpf: Return usage for all known semantic names. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/381

2 4

[PATCH 0/4] MR4020: Add tests and implementation of FILE_{RENAME,LINK}_IGNORE_READONLY_ATTRIBUTE
by Joel Holdsworth (＠jhol) Oct. 5, 2023

Oct. 5, 2023

* Add tests for `FILE_RENAME_IGNORE_READONLY_ATTRIBUTE` and `FILE_LINK_IGNORE_READONLY_ATTRIBUTE`. * Disallow deletion of read-only files in `File{Rename,Link}Information{,Ex}`. * Added exception when `FILE_{RENAME,LINK}_IGNORE_READONLY_ATTRIBUTE` is specified. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4020

2 4

[PATCH v4 0/1] MR3967: mpr: WNetGetUniversalNameA() and WNetGetUniversalNameW() implemented
by Alexey Alyaev (＠aalyaev) Oct. 5, 2023

Oct. 5, 2023

- Implemented WNetGetUniversalName*() functions to correctly return universal/remote info levels -- v4: mpr: WNetGetUniversalNameA() and WNetGetUniversalNameW() implemented https://gitlab.winehq.org/wine/wine/-/merge_requests/3967

3 3

Re: [PATCH v6 0/1] MR3966: mpr: WNetAddConnection*() and WNetCancelConnection*() always return success
by Alexey Alyaev (＠aalyaev) Oct. 5, 2023

Oct. 5, 2023

On Thu Oct 5 09:29:00 2023 +0000, Zebediah Figura wrote: > I don't think we want this kind of hack in Wine. > > Allowing for manual configuration outside of wine. > What does this mean? Well, as it stands now, if we have an application that relies on wnet API to connect/disconnect remote disks, the application will fail no matter what, as WNetAddConnection() and WNetCancelConnection*() will error out. (#) If we then go to ~/.wine/dosdevices and setup a new drive sym-linked to some remote FS mounted in ~/.wine/dosdevices/unc/*, we still cannot get around the failures in WNet* api. While, this sort of work-around is not perfect, in a way it is a success-stub rather than a fail-stub, and at least it allows the application to proceed onto the access phase (read/write/...), and either work (if manual step (#) was completed), or fail unable to do i/o. It's understood that, the proper way would be to utilize the WNet provider tables and to actually implement a provider that will always succeed on connecting/disconnecting a network drive. But the latter is a much bigger change, which may be worth it, had there been a need for something more than just a SUCCESS-STUB. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3966#note_47668

1 0