Hi All,
In the wake of the new WOW64 implementation (recent explanation [1]),
there has been discussion in informal channels about how to we are going
to handle pointers to mapped graphics resource memory which we receive
from the graphics API, as the possibility exists that it will fall
outside of the 32-bit address space.
Over time, a few creative solutions have been proposed and discussed,
with a common theme being that we need changes in either the kernel or
the graphics drivers to …
[View More]do this properly. As we already know the
requirements for a solution to this problem, I think it would be
responsible to hash this out now and then work with the relevant project
maintainers earlier as to avoid blocking work on the wine side too long
and to possibly allow more users to test the new path earlier.
The solutions which I've seen laid out so far:
- Use the mremap(2) interface, allowing us to duplicate the mapping we
receive into the 32-bit address space. This solution would match what
is already done for Crossover Mac's 32on64 support using Mac's
mach_vm_remap functionality [2]. However, right now it is not possible
to use the MREMAP_DONTUNMAP flag with mappings that aren't private and
anonymous, which rules out there use on mapped FDs from libdrm. Due to
this, a kernel change would be necessary.
Pro: A uniform solution across all APIs, which could help in the
future with any unforeseen need to access host-allocated memory in
32-bit windows code.
Cons: Requires a kernel change, which of all the options may take
the longest to get up-streamed and in the hands of users.
- Work with Khronos to introduce extensions into the relevant APIs
enabling us to tell drivers where in the address space we want resources
mapped.
Pro: Wouldn't require going around the backs of the driver,
resulting in a more hardened solution. (Out there, but what if a
creative driver returns a mapping without read or write permission and
handles accesses through a page fault handler?)
Cons: The extension would have to be implemented by each individual
vendor for every relevant API. This would implicitly drop support for
those with cards whose graphics drivers are no longer being updated.
- Hook the driver's mmap call when we invoke memory mappings function,
overriding the address to something in the 32-bit address space.
Pro: Unlike the other solutions, this wouldn't require any
changes to other projects, and shares the advantage of the first solution.
Cons: Susceptible to breakage if the driver uses their own
mapping mechanism separate from mmap. (Custom IOCTL, CPU driver
returning something from the heap)
1: https://www.winehq.org/pipermail/wine-devel/2022-April/213677.html
2: https://www.codeweavers.com/crossover/source - see function
`remap_memory` in `wine/dlls/winemac.drv/opengl.c`
[View Less]
Commit 15483b1a126 (server: Allow calling async_handoff() with status
code STATUS_ALERTED., 2022-02-10) introduced the set_async_direct_result
handler which calls async_set_initial_status().
However, the async_set_initial_status() call does nothing since
async->terminated is set, leaving the async in a confusing state
(unknown_status = 1 but pending/completed).
So far, this issue is unlikely to have been a problem in practice for
the following reasons:
1. async_set_initial_status() would …
[View More]have unset unknown_status, but it
remains set instead. This is usually not a problem, since
unknown_status is usually ever read by code paths effectively
unreachable for non-device (e.g. socket) asyncs.
It would still potentially allow set_async_direct_result to be called
multiple times, but it wouldn't actually happen in practice unless
something goes wrong.
2. async_set_initial_status() would have set initial_status; however,
it is left with the default value STATUS_PENDING. If the actual
status is something other than that, the handler closes the wait
handle and async_satisfied (the only realconsumer of initial_status)
would never be called anyway.
For reasons above, this issue is not effectively observable or testable.
Nonetheless, the current code does leave the async object in an
inconsistent state.
Fix this by removing the !async->terminated check in
async_set_initial_status().
Signed-off-by: Jinoh Kang <jinoh.kang.kr(a)gmail.com>
---
Notes:
v1 -> v2: no changes
v2 -> v3: no changes
v3 -> v4: reuse async_set_initial_status() per feedback
server/async.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/server/async.c b/server/async.c
index 7d0ff10f7a4..e92d4583c1e 100644
--- a/server/async.c
+++ b/server/async.c
@@ -303,11 +303,8 @@ struct async *create_async( struct fd *fd, struct thread *thread, const async_da
void async_set_initial_status( struct async *async, unsigned int status )
{
assert( async->unknown_status );
- if (!async->terminated)
- {
- async->initial_status = status;
- async->unknown_status = 0;
- }
+ async->initial_status = status;
+ async->unknown_status = 0;
}
void set_async_pending( struct async *async )
--
2.34.1
[View Less]
Hi,
This last week-end I updated 5 of the test machines, impacting 29 test
configurations.
Here's the rundown:
* w1064*
w1064 is now called w1064v2009.
And w1064 and all the derived snapshots are now running on Windows 10
21H2 (upgraded through Windows Update).
* w10pro64v2004
This snapshot used to have some specific failures most likely because
Windows Update was still installing already downloaded updates when I
initially took the snapshot (see bug 52560). So I let the VM …
[View More]quiet
down and retook the snapshot. That seems to have improved things. I'll
know for sure in a few days.
* w10pro64_*
w10pro64 had the same issue as w10pro64v2004, plus I needed to install
some more languages which requires un-metering the network at which
time Windows Update kicks in...
So I applied all updates and retook this snapshot. It's now on the
latest 21H1; Windows did not offer installing 21H2 for some reason.
It's just as well, this way test.winehq.org can separate the results
from this VM with all its locale tests, from those of the w1064 VM
which is more about past Windows versions and other configuration
options.
Then I let the TestBot recreate all the snapshots for the locale
tests. Windows has a bunch of locales: formats, display language,
system locale, keyboard layout, country. The old snapshots mostly had
the display language right but sometimes the other locales were still
stuck on English. The new snapshots are all consistent on that front
(whenever possible see below).
In the process I lost w10pro64_pt_PT which the new SetWinLocale have
trouble with (yet this works on my test VM so I blame the latest 21H1
updates). I also wanted to add a 'mixed locales' test configuration
but the scripts failed this one too. I'll investigate and get those
online later on.
* w10pro64_hi_u8
Before Windows 10 it was impossible to set the the system locale to
some values. For instance it was impossible to set it to Hindi. So the
w10pro64_hi still has English as its system locale unlike the other
locale test configurations.
Windows 10 lifted this restriction but this comes with two caveats:
- Setting the system locale to values like Hindi is possible but it
requires setting the codepage to UTF-8.
- This is considered beta and requires checking an extra box in the
GUI.
w10pro64_hi_u8 is one such configuration: Hindi through and through
with UTF-8 as the codepage. And based on the test results I think they
were not kidding with the 'beta' aspect: I count at least 11 tests
with UTF-8-specific failures on Windows. Some of these may be because
of issues in the test but I'm pretty sure some are Windows bugs we
will have to work around.
I would have liked to add another UTF-8 test configuration if only to
tweeze out Hindi-specific issues from the UTF-8 ones. I planned to use
en-EA for that because it's an all English UTF-8-only locale which
could be nice in case there are any error message that need reading...
But that's another locale that requires a SetWineLocale tweak.
* cw-gtx560
This is one of the two not-really-TestBot machines with real graphics
cards.
I added a Windows 10 21H2 snapshot. Note that again Windows did not
want to update it to 21H2 so I used Windows10Upgrade9252.exe to force
it. As far as I know the Nvidia driver is unchanged (391.35 iirc).
That machine's other snapshots are unchanged.
* cw-rx460
I also added a Windows 10 21H2 snapshot (Windows10Upgrade9252.exe
again, the other snapshots are unchanged).
Windows was suggesting I upgrade the GPU driver so I upgraded to the
latest Adrenalin 22.4.1 driver. In the past I had trouble with some of
the AMD drivers where it would either interfere with the clipboard
(causing tests to fail), or crash entirely (causing WineTest to fail
entirely).
So consider this new driver to be on probation.
* w7u*
I moved this VM from one host to another on 2022-03-14 which is when I
found issues with the new LibvirtTool and SetWinLocale scripts so I
ended up having to create most snapshots by hand :-( I restored it
again from backup to test the corrected scripts and this time all went
well.
The last move coincided with some new failures in mf:mf (2qxl only),
user32:sysparams and user32:win (2qxl only). It's possible the 2qxl
issues are because the VM is powered on for each test instead of
starting from a live snapshot: I suspect Windows 7 did not correctly
handle the multi-monitor setup when restored from a live snapshot.
This will require some more investigation...
--
Francois Gouget <fgouget(a)codeweavers.com>
[View Less]
Folks,
Here's a description of the envisioned workflow for using Gitlab as the
primary platform for Wine development, should we decide to adopt it.
This will probably evolve as we experiment and find out what
works or doesn't work for us. All feedback/suggestions are welcome.
1. All patch series are submitted as Merge Requests, so that the
proper information can be captured. The usual rules apply (small
patches, small number of patches per MR, sign-off by submitter).
There …
[View More]are various methods available for creating merge requests:
- using the web interface
- directly when pushing: git push -o merge_request.create
cf. https://docs.gitlab.com/ee/user/project/push_options.html
- from the command line, eg. 'glab mr create'
cf. https://glab.readthedocs.io/en/latest/mr/create.html
- by email
cf. https://docs.gitlab.com/ee/user/project/merge_requests/creating_merge_reque…
2. The merge request will run through the CI pipeline, ideally
including a testbot run (not implemented yet).
3. The patches of the merge request will be forwarded to wine-devel
by the mail gateway, for people who prefer to use their existing
email tools to manage patches.
4. Reviewers will be automatically assigned to the merge request
based on the MAINTAINERS file (not implemented yet). Reviewers
can also be assigned manually. People assigned as reviewers
should receive a notification from gitlab.
5. When someone starts reviewing a patch, they can optionally assign
the patch to themselves, so that the submitter is aware that
someone is working on their patch.
6. Feedback on patches can be sent by replying to the wine-devel
email, or by adding a comment on gitlab. The mail gateway will
bridge things so that all comments are reflected both on gitlab
and on wine-devel.
Note: if you subscribe to gitlab notifications (recommended)
currently you'll get many duplicate emails. There are mail
headers that can be used for filtering, but we may want to
handle this differently, suggestions are welcome.
7. If there are comments, the submitter can address them and update
the merge request by pushing to the MR branch. The mail gateway
will send the new version of the patches to wine-devel (except
for trivial changes) for further review.
8. Once a reviewer approves a merge request, they should mark it
approved in gitlab. The idea is that this will replace the
existing "send a signoff by email" mechanism. Note that an
approval applies to the whole merge request, not to individual
patches. This should be one more reason to keep patch series
small.
Approvals can be sent by:
- using the approve button on the web interface
- replying to a gitlab notification with "/approve"
(note: replying to a wine-devel mail won't work, it needs the
magic gitlab headers)
cf. https://docs.gitlab.com/ee/user/project/quick_actions.html
- from the command line, eg. 'glab mr approve'
cf. https://glab.readthedocs.io/en/latest/mr/approve.html
9. Once a merge request has been approved by all reviewers, I'll
merge it into my tree, do a full testbot run to make sure it
doesn't break anything, then push the results and mark the merge
request as 'merged'.
10. If a merge request is no longer relevant, the submitter should
close it. We may want to add an auto-close process for stale
merge requests at some point.
--
Alexandre Julliard
julliard(a)winehq.org
[View Less]
On Radeon GPUs VK_IMAGE_LAYOUT_GENERAL images don't use Delta Color
Compression, but SRC/DST optimal images do. Transitioning from GENERAL
to SRC/DST causes a big performance hit.
As a next step we should try harder to avoid VK_IMAGE_LAYOUT_GENERAL.
Signed-off-by: Stefan Dösinger <stefan(a)codeweavers.com>
---
This improves Rocket League from 50fps to 67fps when it is GPU limited.
Using VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL instead of GENERAL
further improves it to 80 fps. …
[View More]Switching from COLOR_ATTACHMENT_OPTIMAL
to SRC/DST optimal seems cheap (it just stays compressed), but first we
need logic to transition BIND_RENDER_TARGET | BIND_SHADER_RESOURCE
textures between COLOR_ATTACHMENT_OPTIMAL and SHADER_READ_ONLY_OPTIMAL.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4
[View Less]