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

Re: [PATCH] include: Allow making Wine Server requests from C++ code

by Mahdi Tayarani

Thanks for the explanation. The concerns you raise are valid. To provide a bit of context. We have a Linux-like system without X11, so we've written our own driver to replace winex11.drv. It's written in C++ for various reasons to simplify integrating with the underlying platform. Considering this is part of an internal/proprietary system it will not be upstreamed. So we're not concerned about that. But we would like to keep our local modifications to Wine at a minimum. The existing input processing system in Wine is heavily built around X11 behaviour. So none of the helper methods winex11.drv uses help our case, and we've resorted to directly sending a message to the Wine Server. While that solution is working well, the only change we need to make to Wine is the patch I have submitted. Hope this helps clear up why we need it. As to why try to upstream it (aside from our motivation to minimize local changes). Any other project trying to interact with the Wine Server though C++ code could benefit from this. I've seen instances where Wine has made efforts to be C++ compatible even though the majority of the code is C (e.g. a bug I reported some time ago <https://bugs.winehq.org/show_bug.cgi?id=52787>). So it seems like a good decision to try and merge this. Mahdi On Mon, Jun 6, 2022 at 1:14 PM Alex Henrie <alexhenrie24(a)gmail.com> wrote: > On Mon, Jun 6, 2022 at 10:12 AM Mahdi Tayarani <tayarani(a)google.com> > wrote: > > > > We have an input processing system which requires us to directly send > input update information to the Wine Server. The existing helper methods > don't provide what we need. > > Does that mean that you're porting Wine to a new platform and writing > something like winex11.drv for that platform? Could your new code be > included in upstream Wine one day? If so, it would probably be better > to write it in C instead of C++ because the Wine project does not > currently accept C++ code. > > Or do you mean that you are writing cross-platform software that will > run on both Windows and on Wine? If that is the case, how does the > code work on Windows? Could the same functions that you call on > Windows be improved in Wine to do what you need? > > > Can you please elaborate why it will be a tough sell? The change > provides no sort of functional or behavioural change. It's just making the > cast that was already implicitly happening, explicit. > > Although the change itself is very small, it smells like a hack, and > the Wine community really does not like hacks. I think everyone would > prefer to identify the underlying problem here and, if possible, > resolve it instead of working around it. That said, I am just a > volunteer Wine developer trying to be helpful; other developers would > be able to speak more authoritatively. > > -Alex >

June 6, 2022

TestBot News

by Francois Gouget

New hardware ------------ The TestBot is getting two new VM hosts, gpu1 and gpu2. * Thanks to their i9-12900K processor they have much better multi-threaded performance: compiling Wine from scratch went from about 920 seconds on the old boxes to 220 seconds with 16 threads, and 190 seconds with 24 threads [1] (all numbers include the configure step). That should help with patches that touch Wine headers. * They also have much better single-thread performance. The first results indicate that they can run WineTest in Wine in about 20 minutes instead of 36 minutes. * They should support PCI-passthrough and each has an AMD RX 6600 and an Nvidia RTX 3050 graphics card. That means it should be possible to test every patch against these graphics cards (unlike the cw-rx460 and cw-gtx560 machines which only ran WineTest and were not fully part of the TestBot). * They should also be able to run Windows 11 in a VM. The sad news is that they literally replace cw-rx460 and cw-gtx560 so those two are no more. So PCI-passthrough is needed to provide continued tests against real GPUs. The current status: * gpu1 is in place and part of the TestBot but only runs 'vanilla' VMs. * gpu2 has now replaced cw-gtx560 but is not set up yet. I will first use it as a testbed to set up the PCI-passthrough and Windows 11 VMs. That way I'll be able to reboot gpu2 without impacting the TestBot. I will also document the result on the WineTestBot VMs page [2] in case anyone wants to do the same at home. VM updates ---------- * I updated debian11 and installed the fonts-arphic-uming package for the Chinese tests. I suspect the debian11 update caused a lot of new ddraw[12] failures. (950 failures / crash instead of 1 failure, qualitatively it makes no difference but it still needs to be investigated...) * I did a Windows Update on the w8 and w864 VMs. They are now fully updated and while going through the check list [2] I found items that probably were missing (e.g. not disabling defragmentation). * I changed the w8 CPU from kvm32 to core2duo because Windows would not boot otherwise; seemingly due to the lack of support for the NX bit. I suspect that's because the host CPU went from AMD to Intel and QEmu failed to insulate the guest from that despite the kvm32 virtual CPU type. w864 was already running with the QEmu CPU set to core2duo so that should be ok. VM reshuffling -------------- I moved the VMs around to take advantage of the new gpu1 box. * vm3 and vm4 are now dedicated to running w1064* and w10pro64* respectively (before they had one additional VM each). This should help reduce the period of time during which the TestBot is less responsive due to the nightly WineTest runs. * I moved debian11 and debiant to gpu1 so they benefit from the faster compilations and faster WineTest runs. (WineTest is much slower in Wine than on Windows so maximum benefit there) * I moved w864 to gpu1. The good thing is that this confirmed the old VMs work on the new boxes too (see the kvm32 issue above). * I moved all the other Windows VMs to vm1. * Next the plan is to move the build VM somewhere and to retire the vm2 host. There will be one more reshuffling once gpu2 is in place but what happens then will depend very much on how many test configurations use the PCI-passthrough, Windows 11, and GitLab. [1] Note: when building a Wine build server it seems one needs between 350 and 400 MB per compilation thread. For now I have allocated 16 threads to the VMs but, given that they currently still only run one VM at a time, giving them access to all 24 thread may make more sense. There is also the issue of performance vs efficiency cores. But making sure the VMs only use performance cores would require CPU-pinning and I don't want to go there unless proven necessary. [2] https://wiki.winehq.org/Wine_TestBot_VMs#Windows_configuration -- Francois Gouget <fgouget(a)codeweavers.com>

June 6, 2022