August 2016 - Wine-Devel - list.winehq.org

Re: [v1 1/5] winejoystick.drv: Add functionality to disable joystick via registry

by DavidL

Fixed and resent, thanks! David On Sat, Aug 27, 2016 at 11:28 PM, Bruno Jesus <00cpxxx(a)gmail.com> wrote: > On Sun, Aug 28, 2016 at 3:18 AM, David Lawrie <david.dljunk(a)gmail.com> > wrote: > > Adds device_disabled_registry, helper functions to shared joystick code > > Hi, thanks for working on this. The problem with this series is that > you are introducing dead code in patches 1, 2 and 3. As the code is > not used anywhere until patch 5. > Patch 4 also adds dead code that is only used in patch 5. > > IMO you should merge patches 1,2,3 into a single patch and also 4 and > 5 into second patch. This will make the dead code will last a single > commit. > > Best wishes, > Bruno >

Aug. 29, 2016

Re: [PATCH 1/2] rbtree.h: Store parent in each entry and use that to manipulate the tree without a stack.

by Henri Verbeet

On 25 August 2016 at 17:01, Jacek Caban <jacek(a)codeweavers.com> wrote: > Agreed ;) I still hope that my patches will get in. After last Henri's > reply I was expecting a sign off, but it's still not there. Henri? > You may have misread my reply somewhat. Bottom line, and what I told Alexandre a while ago, is that while these changes aren't something I'd put my Signed-off-by on, I don't care enough to do it myself or to want to block them from going in.

Aug. 29, 2016

Re: Experimental gcc optimization for 64-bit wine

by André Hentschel

Am 29.08.2016 um 05:18 schrieb Daniel Santos: > It's probably also worth mentioning that the ideal long-term solution is to find ways eliminate the register save/restores through various means-- static analysis, better evaluation of branch costs, and other optimizations in Wine its self. For example, there are many WINAPI functions who's only sysv call is to wine_dbg_log() via a TRACE(). Just marking this function as __attribute__((__cold__)) should reduce the number of unneeded register save/restores in the function's main path by a great amount. (I haven't actually tested it yet.) For others searching for the meaning of this attribute: > cold > The cold attribute on functions is used to inform the compiler that the function is unlikely to be executed. The function is optimized for size rather than speed and on many targets it is placed into a special subsection of the text section so all cold functions appear close together, improving code locality of non-cold parts of program. The paths leading to calls of cold functions within code are marked as unlikely by the branch prediction mechanism. It is thus useful to mark functions used to handle unlikely conditions, such as perror, as cold to improve optimization of hot functions that do call marked functions in rare occasions. > > When profile feedback is available, via -fprofile-use, cold functions are automatically detected and this attribute is ignored. It would be interesting to see some numbers on this, and what it acutally does with the assembler output. I'm leaving for a few days in a couple of hours, otherwise I'd test it

Aug. 29, 2016

Experimental gcc optimization for 64-bit wine

by Daniel Santos

Over the last two weeks I've been working on an experimental gcc optimization for wine that out-of-lines the expensive prologues & epilogues required for an ms x64 abi function to call a 64-bit sysv function. The theory is that the added expense of each function executing a few extra instructions to facilitate this will be offset by the reduction in instruction cache misses. As far as I can tell, gcc's ix86 back end has never supported any type of out-of-line pro/epilogue stubs, so adding this support has been somewhat tedious as it tends to get broken by subsequent optimization passes. It currently works in many cases, but in other cases produces bad code so this is a work in progress. None the less, I thought it was interesting enough to post the current results in terms of .text size reduction. On gcc 5.4.0 (with the 8-byte aligned stack assumption flaw corrected), the total .text size of all dlls on my build was 45.2MiB while the out-of-lined build was 35.9MiB, a reduction of 20.5%, so it looks promising so far. I presume it will be a little while before all of the flaws are worked out so that it always produces good code, but once there I can start to produce some real performance numbers. It's probably also worth mentioning that the ideal long-term solution is to find ways eliminate the register save/restores through various means-- static analysis, better evaluation of branch costs, and other optimizations in Wine its self. For example, there are many WINAPI functions who's only sysv call is to wine_dbg_log() via a TRACE(). Just marking this function as __attribute__((__cold__)) should reduce the number of unneeded register save/restores in the function's main path by a great amount. (I haven't actually tested it yet.) Daniel

Aug. 29, 2016

Re: Maximum OpenGL version

by Fabian Maurer

On Monday, August 29, 2016 12:00:46 AM CEST you wrote: > Yes, wined3d uses legacy OpenGL in a few places. AFAIK there is not a > lot of work left. The main offender is probably blitting code (see > e.g. SetupForBlit()). Generally, it should be quite easy to find > remaining issues when you run d3d/ddraw tests with "MaxVersionGL" set > to 3.2 or higher version (you'll get some GL errors or test failures). > Matteo has done most of the work related to fixing this issue. He > might be able to provide an exact list of remaining parts. Ah, thanks for the information. Fabian Maurer

Aug. 28, 2016

Re: Maximum OpenGL version

by Józef Kucia

On Sun, Aug 28, 2016 at 11:24 PM, Fabian Maurer <dark.shadow4(a)web.de> wrote: > You mean wine relies on legacy api that is removed in the core context? > Is there a list which parts would need to be reworked? Yes, wined3d uses legacy OpenGL in a few places. AFAIK there is not a lot of work left. The main offender is probably blitting code (see e.g. SetupForBlit()). Generally, it should be quite easy to find remaining issues when you run d3d/ddraw tests with "MaxVersionGL" set to 3.2 or higher version (you'll get some GL errors or test failures). Matteo has done most of the work related to fixing this issue. He might be able to provide an exact list of remaining parts.

Aug. 28, 2016

Re: Maximum OpenGL version

by Fabian Maurer

> Wined3d doesn't fully support OpenGL core profile yet. This is a > problem when your drivers expose higher OpenGL version only for core > profile. See bug 38648 [1]. > > [1] - https://bugs.winehq.org/show_bug.cgi?id=38648 You mean wine relies on legacy api that is removed in the core context? Is there a list which parts would need to be reworked?

Aug. 28, 2016

Re: Maximum OpenGL version

by Józef Kucia

On Sun, Aug 28, 2016 at 10:49 PM, Fabian Maurer <dark.shadow4(a)web.de> wrote: > Currently looking at the directx11 implementation, and I noticed I first need > to set a "MaxVersionGL" in the registry to enable creation of 4.3 context and > so DX11 support. > What's the reason behind this? Wined3d doesn't fully support OpenGL core profile yet. This is a problem when your drivers expose higher OpenGL version only for core profile. See bug 38648 [1]. [1] - https://bugs.winehq.org/show_bug.cgi?id=38648

Aug. 28, 2016

Maximum OpenGL version

by Fabian Maurer

Currently looking at the directx11 implementation, and I noticed I first need to set a "MaxVersionGL" in the registry to enable creation of 4.3 context and so DX11 support. What's the reason behind this? The change is from a1e718ccabc7c330dd16c7face78022965b03e20 (wined3d: Add a setting for the maximum OpenGL version to use). Why do we need to set the maximum version instead of just using the highest context we can get (and still use) ? Fabian Maurer

Aug. 28, 2016

Re: dxdiagn: Do fill DMI information on Linux

by Ruslan Kabatsayev

On 8/28/16, Chris Robinson <chris.kcat(a)gmail.com> wrote: > On 08/28/2016 02:50 AM, Ruslan Kabatsayev wrote: >> This patch makes previously empty fields szSystemManufacturerEnglish, >> szSystemManufacturerEnglish and szBIOSEnglish in DxDiag filled with the >> DMI information. This is the same information I get on my test Windows >> system. >> Currently this is only implemented for Linux, on other platforms >> the fields remain empty. > > Are there functions to get this info in the Windows API? If so, it may > be worth using/implementing those API calls, instead of reading it > directly from the host like this. I think you're right. There's WMI class Win32_BIOS, which seems not implemented in Wine. This seems to be the right place to implement this instead of this patch's approach. Then dxdiag should just use this interface as it does for CPU queries.

Aug. 28, 2016