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

Wine is "Community Choice" SourceForge Project of the Month

by Marcus Meissner

Hi, We are the "Community Choice" Project of the Month April 2016 at SourceForge. https://sourceforge.net/blog/april-2016-community-choice-project-of-the-mon… Ciao, Marcus

April 2, 2016

Re: [PATCH 1/2] t2embed: Implement TTIsEmbeddingEnabledForFacename()

by Dmitry Timoshkov

Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > + if (!strcasecmp(name, facename)) strcasecmp() is not suitable for strings in windows encodings. -- Dmitry.

April 2, 2016

Re: VRAM size autodetection on OS X

by Ken Thomases

On Apr 1, 2016, at 2:13 PM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > > On 1 April 2016 at 20:41, Theodore Dubois <tblodt(a)icloud.com> wrote: >> >> I would like to write a patch to fix this problem. I'm thinking of adding an >> implementation of WGL_WINE_QUERY_RENDERER to winemac.drv. There are 12 >> different things that can be queried about the renderer, but only >> WGL_RENDERER_VENDOR_ID_WINE, WGL_RENDERER_DEVICE_ID_WINE, and >> WGL_RENDERER_VIDEO_MEMORY_WINE are used to my knowledge, so I’d only >> implement those. I would have been happy if Henri had defined the WGL_WINE_query_renderer extension to be only the subset of GLX_MESA_query_renderer that wined3d actually needed, but given that he didn't, I think an implementation should strive to be complete. > I think Ken is working on supporting WINE_query_renderer in > winemac.drv, but I don't know when that will be done. Yes, I'm a good way through the implementation. wglQueryRenderer{Integer,String}WINE() are implemented, although not yet tested. wglQueryCurrentRenderer{Integer,String}WINE() should be relatively straightforward from there. I don't yet have an ETA as I switch off to do other things, too. -Ken

April 2, 2016

Re: ntoskrnl.exe: Make IoAllocateIrp not crash on negative values. (try 2)

by Bernhard Übelacker

Am 31.03.2016 um 05:46 schrieb Sebastian Lackner: > Thanks for the updated version. Could you maybe also add a couple of additional tests > with charge_quota = TRUE? Since you are changing both versions, I'm fearing a bit that > your changes could break other situations. If there are no unexpected test failures it > looks good to me. Thanks for your review. An updated version of test and change is attached to the bug [1]. With my crosstest exe this testbot run was started [2]. I tried to run the test in a 64bit VM but got just blue screens with MULTIPLE_IRP_COMPLETE_REQUESTS. Are the driver test framework patches supposed to succeed on 64bit windows? Kind regards, Bernhard [1] https://bugs.winehq.org/show_bug.cgi?id=39734 [2] https://testbot.winehq.org/JobDetails.pl?Key=21835

April 2, 2016

Re: VRAM size autodetection on OS X

by Henri Verbeet

On 1 April 2016 at 20:41, Theodore Dubois <tblodt(a)icloud.com> wrote: > I just had a look at the code. In dlls/wined3d/directx.c, > query_gpu_description uses wglQueryCurrentRendererIntegerWINE to obtain the > GPU vendor, device, and available VRAM. wglQueryCurrentRendererIntegerWINE > is part of the WGL_WINE_QUERY_RENDERER extension, which...is not implemented > in winemac.drv. It's only implemented in winex11.drv. I don't use X11 if I > can help it. So, with absolutely no information about what the graphics card > is, Wine defaults to an Nvidia Riva 128 with WINE_DEFAULT_VIDMEM (64MB) of > VRAM. This is not close. > > I would like to write a patch to fix this problem. I'm thinking of adding an > implementation of WGL_WINE_QUERY_RENDERER to winemac.drv. There are 12 > different things that can be queried about the renderer, but only > WGL_RENDERER_VENDOR_ID_WINE, WGL_RENDERER_DEVICE_ID_WINE, and > WGL_RENDERER_VIDEO_MEMORY_WINE are used to my knowledge, so I’d only > implement those. > > Does this sound correct? > Mostly. CARD_NVIDIA_RIVA_128 has 4 MiB of memory, but you're really unlikely to end up with that one. With an unrecognised card you'll get one of the "fallback" cards based on the feature level of the OpenGL implementation. On MacOS without OpenGL core contexts that's typically WINED3D_D3D_LEVEL_9_SM3, which would get you one of CARD_NVIDIA_GEFORCE_6800, CARD_AMD_RADEON_X1600 or CARD_INTEL_945G. The first two have 128 MiB, the Intel one has 64 MiB. Typical Linux OpenGL implementations will get you either WINED3D_D3D_LEVEL_10 or WINED3D_D3D_LEVEL_11, which would get you somewhere between 512 and 1280 MiB. I think Ken is working on supporting WINE_query_renderer in winemac.drv, but I don't know when that will be done. We're also like to start using the wglCreateContextAttribsARB() support for selecting a renderer at some point in the future if it becomes more common for implementations to expose multiple renderers. Regardless of WINE_query_renderer support, it's still a good idea to add support for your card to the detection code.

April 1, 2016

VRAM size autodetection on OS X

by Theodore Dubois

Sometimes, when I'm playing games on Wine, the game crashes, and then I look in the log and see "Out of adapter memory". Then I run `winetricks videomemorysize=1024`, and it runs fine. My graphics card has 1536 MB of total VRAM. It seems to me that Wine isn't correctly autodetecting the amount of VRAM I have. (DISCLAIMER: The following analysis is not based on any log output. It's based on my reading of the code, which may well be incorrect. If so, please correct me.) I just had a look at the code. In dlls/wined3d/directx.c, query_gpu_description uses wglQueryCurrentRendererIntegerWINE to obtain the GPU vendor, device, and available VRAM. wglQueryCurrentRendererIntegerWINE is part of the WGL_WINE_QUERY_RENDERER extension, which...is not implemented in winemac.drv. It's only implemented in winex11.drv. I don't use X11 if I can help it. So, with absolutely no information about what the graphics card is, Wine defaults to an Nvidia Riva 128 with WINE_DEFAULT_VIDMEM (64MB) of VRAM. This is not close. I would like to write a patch to fix this problem. I'm thinking of adding an implementation of WGL_WINE_QUERY_RENDERER to winemac.drv. There are 12 different things that can be queried about the renderer, but only WGL_RENDERER_VENDOR_ID_WINE, WGL_RENDERER_DEVICE_ID_WINE, and WGL_RENDERER_VIDEO_MEMORY_WINE are used to my knowledge, so I’d only implement those. Does this sound correct? ~Theodore

April 1, 2016

Re: [PATCH 5/5] wined3d: Alpha test emulation for core profile contexts.

by Henri Verbeet

On 1 April 2016 at 01:48, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: > The advantage is to avoid creating two shader variants for alpha test > enabled vs disabled and flipping between the two when the > WINED3D_RS_ALPHATESTENABLE state is toggled. I only have some limited > empiric evidence but it seems like changing the alpha test function is > very rare in practice while toggling the alpha test enabled / disabled > is relatively common. > Does that happen with a lot of different shaders though? I.e., if the draws with enabled alpha test use different shaders than the ones with disabled alpha test it doesn't really matter. Perhaps more importantly though, are you sure having discard() in the shader doesn't end up disabling HiZ/HiS in some cases?

April 1, 2016

Re: [PATCH] user32: Add stub for IsProcessDPIAware

by Alexandre Julliard

Louis Lenders <xerox.xerox2000x(a)gmail.com> writes: > Signed off: Louis Lenders <xerox.xerox2000x(a)gmail.com> This is still not a valid Signed-off-by header. Could you please use git to generate it, so that it matches the standard format? -- Alexandre Julliard julliard(a)winehq.org

April 1, 2016