September 2016 - Wine-Devel

Re: dsound: Avoid using the COM method implementations directly.

by Henri Verbeet

On 2 September 2016 at 19:17, Andrew Eikum <aeikum(a)codeweavers.com> wrote: > I guess I'm not opposed to this, but are these changes useful? > It makes the code harder to follow and will generate worse code, if perhaps both only slightly. That's perhaps not in itself a reason not to do it, but I do think it makes it harder to justify. I'd be against this for any code I maintain.

Sept. 2, 2016

Re: dsound: Avoid using the COM method implementations directly.

by Andrew Eikum

I guess I'm not opposed to this, but are these changes useful? Andrew On Fri, Sep 02, 2016 at 10:37:33AM +0200, Michael Stefaniuc wrote: > Signed-off-by: Michael Stefaniuc <mstefani(a)redhat.de> > --- > dlls/dsound/capture.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/dlls/dsound/capture.c b/dlls/dsound/capture.c > index 30870ae..38e3045 100644 > --- a/dlls/dsound/capture.c > +++ b/dlls/dsound/capture.c > @@ -861,7 +861,7 @@ static ULONG DirectSoundCaptureDevice_Release( > LeaveCriticalSection(&DSOUND_capturers_lock); > > if (device->capture_buffer) > - IDirectSoundCaptureBufferImpl_Release(&device->capture_buffer->IDirectSoundCaptureBuffer8_iface); > + IDirectSoundCaptureBuffer8_Release(&device->capture_buffer->IDirectSoundCaptureBuffer8_iface); > > if(device->mmdevice) > IMMDevice_Release(device->mmdevice); > -- > 2.7.4 > >

Sept. 2, 2016

Re: Where is my address space?

by Henri Verbeet

On 2 September 2016 at 17:56, Snorri Sturluson <snorri.sturluson(a)ccpgames.com> wrote: > Hm, I’m now tracking only resources of type WINED3D_RTYPE_TEXTURE_2D - the numbers are slightly lower, but as expected, the bulk is coming from textures. > > I’m fairly certain I don’t have any textures loaded that are not actively used for rendering so it’s not clear to me why they would reside in system memory. > > I just want to rule out that the textures aren’t allocated still in system memory as well as by OpenGL. > Check the texture flags, textures with WINED3D_TEXTURE_RGB_VALID or WINED3D_TEXTURE_SRGB_VALID set generally shouldn't have system memory allocated. The "download_count", "sysmem_count" and "texture_rgb.name" fields are also potentially interesting.

Sept. 2, 2016

Re: Where is my address space?

by Snorri Sturluson

Hm, I’m now tracking only resources of type WINED3D_RTYPE_TEXTURE_2D - the numbers are slightly lower, but as expected, the bulk is coming from textures. I’m fairly certain I don’t have any textures loaded that are not actively used for rendering so it’s not clear to me why they would reside in system memory. I just want to rule out that the textures aren’t allocated still in system memory as well as by OpenGL. > On 02 Sep 2016, at 15:28, Henri Verbeet <hverbeet(a)gmail.com> wrote: > > On 2 September 2016 at 16:52, Snorri Sturluson > <snorri.sturluson(a)ccpgames.com> wrote: >> Thanks for these hints - been looking at this a bit more and would appreciate more input. >> >> I’ve added tracking in wined3d/resource.c to give me the total memory in use allocated via wined3d_resource_allocate_sysmem. >> >> In a very simple scene (hangar view in EVE) vmmap32 reports a total of 2.3G in use, with IOKit clocking in at 442M and VM_ALLOCATE at 1.4G. The system memory allocated in resource.c is 180M. >> >> Going into character customisation with a highly detailed character the total is 2.5G, IOKit at 498.8M and VM_ALLOCATE at 1.6G, with sysmem allocs at 360M. >> >> Presumably the sysmem allocs are a subset of VM_ALLOCATE. >> >> Is it normal that the sysmem sits this high? Shouldn’t the textures be managed by OpenGL? >> > It depends on the specific application, but I don't think it's > necessarily unusually large. It would perhaps be useful to split those > numbers out by resource type (buffers/textures) and pool > (sysmem/managed/default). > > There's of course not a lot we can do for sysmem resources, but for > managed and default pool resources we could perhaps be more aggressive > about evicting things from system memory. The way it currently works, > those resources initially get system memory allocated, which gets > freed once the resource gets moved to the GPU. It would perhaps be > possible to move resources to the GPU right after creation, and in > some cases avoid allocating system memory for them entirely. That > won't necessarily make things better though, depending on what the > OpenGL driver does internally it may just move allocations from > wined3d to the OpenGL driver.

Sept. 2, 2016

Re: [2/2] imm32: Set the default IME window title and styles as in native.

by Alexandre Julliard

Akihiro Sagawa <sagawa.aki(a)gmail.com> writes: > Signed-off-by: Akihiro Sagawa <sagawa.aki(a)gmail.com> > --- > dlls/imm32/imm.c | 6 ++++-- > dlls/imm32/tests/imm32.c | 9 +++++++++ > 2 files changed, 13 insertions(+), 2 deletions(-) It fails here: ../../../tools/runtest -q -P wine -T ../../.. -M imm32.dll -p imm32_test.exe.so imm32 && touch imm32.ok imm32.c:888: Test failed: got make: *** [imm32.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

Sept. 2, 2016

Re: Where is my address space?

by Henri Verbeet

On 2 September 2016 at 16:52, Snorri Sturluson <snorri.sturluson(a)ccpgames.com> wrote: > Thanks for these hints - been looking at this a bit more and would appreciate more input. > > I’ve added tracking in wined3d/resource.c to give me the total memory in use allocated via wined3d_resource_allocate_sysmem. > > In a very simple scene (hangar view in EVE) vmmap32 reports a total of 2.3G in use, with IOKit clocking in at 442M and VM_ALLOCATE at 1.4G. The system memory allocated in resource.c is 180M. > > Going into character customisation with a highly detailed character the total is 2.5G, IOKit at 498.8M and VM_ALLOCATE at 1.6G, with sysmem allocs at 360M. > > Presumably the sysmem allocs are a subset of VM_ALLOCATE. > > Is it normal that the sysmem sits this high? Shouldn’t the textures be managed by OpenGL? > It depends on the specific application, but I don't think it's necessarily unusually large. It would perhaps be useful to split those numbers out by resource type (buffers/textures) and pool (sysmem/managed/default). There's of course not a lot we can do for sysmem resources, but for managed and default pool resources we could perhaps be more aggressive about evicting things from system memory. The way it currently works, those resources initially get system memory allocated, which gets freed once the resource gets moved to the GPU. It would perhaps be possible to move resources to the GPU right after creation, and in some cases avoid allocating system memory for them entirely. That won't necessarily make things better though, depending on what the OpenGL driver does internally it may just move allocations from wined3d to the OpenGL driver.

Sept. 2, 2016

Re: Where is my address space?

by Snorri Sturluson

Thanks for these hints - been looking at this a bit more and would appreciate more input. I’ve added tracking in wined3d/resource.c to give me the total memory in use allocated via wined3d_resource_allocate_sysmem. In a very simple scene (hangar view in EVE) vmmap32 reports a total of 2.3G in use, with IOKit clocking in at 442M and VM_ALLOCATE at 1.4G. The system memory allocated in resource.c is 180M. Going into character customisation with a highly detailed character the total is 2.5G, IOKit at 498.8M and VM_ALLOCATE at 1.6G, with sysmem allocs at 360M. Presumably the sysmem allocs are a subset of VM_ALLOCATE. Is it normal that the sysmem sits this high? Shouldn’t the textures be managed by OpenGL? > On 22 Aug 2016, at 10:03, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: > > 2016-08-19 12:09 GMT+02:00 Henri Verbeet <hverbeet(a)gmail.com>: >> On 19 August 2016 at 11:56, Snorri Sturluson >> <snorri.sturluson(a)ccpgames.com> wrote: >>> I’m trying to understand the memory usage of Wine. My focus is to make EVE Online run on the Mac as smoothly as possible, and one of the issues I’m running into is that the game runs out of memory in heavy scenes, especially when running at high resolutions on Macs with Retina screens. >>> >>> On Windows, a scene with 300 ships in space may be running in 2.1GB of page file usage, but the same scene under Wine will show a Virtual Memory size of 3.5GB or more. Once the Virtual Memory size (as shown by the Activity Monitor) gets too close to the 4GB mark I start getting errors from Wine, failing to allocate memory, usually leading to a crash. >>> >>> There is a significant difference even when running at the same resolution on both Windows and Mac, and further pronounced if I run in the full 5k resolution of an iMac. >>> >>> Can anyone explain this big difference in memory use between the Windows and Wine sessions? Or give me ideas on how I can figure it out? Or better yet, have suggestions on how to reduce it? >>> >> >> I think Matteo most recently looked at this on OS X. IIRC the bottom >> line was that the biggest offender was the OS X OpenGL stack, but >> there may be some hacks that can free up some additional address space >> for specific applications. Careful profiling may find places where >> Wine itself can be improved. In the longer term though, even on Window >> a 32-bit address space is a bit tight for modern games, and you'd want >> to look into switching to a 64-bit application. > > That's pretty much it. I looked at this in particular for another game > but it's likely that the conclusions are general enough and the fact > that the screen resolution makes things worse for you strongly hints > towards the OpenGL drivers as the main culprit. > I couldn't find any obvious way to make macOS behave better in that > regard (for the game I was looking into, at least). The various other > macOS frameworks which end up being pulled into the process also took > a significant amount of addressing space, but way distant from the > OpenGL stuff. I also found some small room for improvements in wined3d > (specifically, IIRC, we might end up allocating system memory for d3d9 > "NULL" render targets) but it wasn't earth-shattering by any means. I > plan to fix that at some point though. > > I've found pmap to be pretty useful for profiling memory usage on > macOS. AFAIR, in my case the VM space used by the OpenGL stack was > mostly accounted under the "IOKit" name. > > Also FWIW, under Linux VM usage looked a lot better, with the specific > OpenGL driver in use not having a significant effect.

Sept. 2, 2016

Re: Implementing Fiber-Local Storage Callbacks: sharing data between DLLs

by André Hentschel

Am 02.09.2016 um 14:01 schrieb John Sheu: > On Thu, Sep 1, 2016 at 8:08 PM, Alexandre Julliard <julliard(a)winehq.org> wrote: >> John Sheu <sheu(a)google.com> writes: >> >>> The question is how we manage this. One option is to introduce >>> additional function call entry points to either ntdll or kernel32, >>> called by the other, to manages FLS lifetime. I see though that the >>> list of entry points is pretty tightly defined in the .spec files for >>> each DLL, and the convention may be (correct me if I'm wrong) not to >>> introduce "weird" private Wine-only APIs to the list. The other >>> option is to use some internal structs, pointed to by the PEB and TEB >>> structures. That's the approach I'd like to go with. >>> >>> My proposal would be: >>> >>> 1. Define a common struct to hold the FLS data array, that would be: >>> struct FlsSlots { >>> LIST_ENTRY fls_link; >>> void fls_slots[SLOT_COUNT]; >>> }; >>> 2. TEB.FlsSlots right now is a void** member; make this a struct >>> FlsSlots* member instead. >>> 3. Link the FlsSlots struct into PEB.FlsListHead. >>> >>> This would require that struct FlsSlots be defined somewhere -- either >>> in wine/include, as mentioned, or in <include/winternl.h>. Since it >>> isn't declared publicly in the win32 API, even as an opaque pointer -- >>> I'm leaning toward the former. Maybe in "wine/include/fls.h" ? >> >> In general adding private headers is reserved for things that are used >> across a wide range of modules, and cannot possibly be done through the >> Windows API. >> >> If you really have to share a private structure like this, you can >> duplicate the definition, but that should only be a last resort. In >> general if there's no equivalent structure on Windows, it means that >> it's supposed to work in a different way. >> >> I'll note that recent Windows versions export functions like RtlFlsAlloc >> and RtlFlsFree, which probably means it should all be handled inside >> ntdll. Of course it would first need some tests to find out what these >> functions do. > > I'm enthusiastic about putting it in <include/winternl.h>, since it > isn't a known Windows structure -- I don't doubt though that there's > an equivalent structure in Windows; we just don't know about it. But > duplicating the definition is just.. ick. So I'd just like to put it > in a private header, or perhaps in the Wine-private section of > winternl.h (and that is seeming like the better solution at the > moment). > > Of course the optimal solution is to implement the Windows APIs. In > ntdll I'm aware of three FLS-related functions: RtlFlsAlloc, > RtlFlsFree, and RtlProcessFlsData. Unfortunately they are all three > undocumented, even without information on their function signatures. > So writing conformance tests for these is outside the scope my > experience (fuzz testing maybe?). If you have some advice on how such > testing is usually done for Wine, I'd be glad to hear it. Otherwise I > think I'll just go with sticking it in the #ifdef __WINESRC__ section > of winternl.h > > -John Sheu The RtlFls* way seems the way to go... I found some hints on the signature and more in this file (from Google? from VMWare?): https://github.com/DynamoRIO/dynamorio/blob/master/core/win32/drwinapi/ntdl…

Sept. 2, 2016

Re: Implementing Fiber-Local Storage Callbacks: sharing data between DLLs

by John Sheu

On Fri, Sep 2, 2016 at 5:01 AM, John Sheu <sheu(a)google.com> wrote: > I'm enthusiastic about putting it in <include/winternl.h>, since it > isn't a known Windows structure -- I don't doubt though that there's > an equivalent structure in Windows; we just don't know about it. Correction: that should read, "I'm *not* enthusiastic about putting it in <include/winternl.h>" ... -John Sheu

Sept. 2, 2016

Re: Implementing Fiber-Local Storage Callbacks: sharing data between DLLs

by John Sheu

On Thu, Sep 1, 2016 at 8:08 PM, Alexandre Julliard <julliard(a)winehq.org> wrote: > John Sheu <sheu(a)google.com> writes: > >> The question is how we manage this. One option is to introduce >> additional function call entry points to either ntdll or kernel32, >> called by the other, to manages FLS lifetime. I see though that the >> list of entry points is pretty tightly defined in the .spec files for >> each DLL, and the convention may be (correct me if I'm wrong) not to >> introduce "weird" private Wine-only APIs to the list. The other >> option is to use some internal structs, pointed to by the PEB and TEB >> structures. That's the approach I'd like to go with. >> >> My proposal would be: >> >> 1. Define a common struct to hold the FLS data array, that would be: >> struct FlsSlots { >> LIST_ENTRY fls_link; >> void fls_slots[SLOT_COUNT]; >> }; >> 2. TEB.FlsSlots right now is a void** member; make this a struct >> FlsSlots* member instead. >> 3. Link the FlsSlots struct into PEB.FlsListHead. >> >> This would require that struct FlsSlots be defined somewhere -- either >> in wine/include, as mentioned, or in <include/winternl.h>. Since it >> isn't declared publicly in the win32 API, even as an opaque pointer -- >> I'm leaning toward the former. Maybe in "wine/include/fls.h" ? > > In general adding private headers is reserved for things that are used > across a wide range of modules, and cannot possibly be done through the > Windows API. > > If you really have to share a private structure like this, you can > duplicate the definition, but that should only be a last resort. In > general if there's no equivalent structure on Windows, it means that > it's supposed to work in a different way. > > I'll note that recent Windows versions export functions like RtlFlsAlloc > and RtlFlsFree, which probably means it should all be handled inside > ntdll. Of course it would first need some tests to find out what these > functions do. I'm enthusiastic about putting it in <include/winternl.h>, since it isn't a known Windows structure -- I don't doubt though that there's an equivalent structure in Windows; we just don't know about it. But duplicating the definition is just.. ick. So I'd just like to put it in a private header, or perhaps in the Wine-private section of winternl.h (and that is seeming like the better solution at the moment). Of course the optimal solution is to implement the Windows APIs. In ntdll I'm aware of three FLS-related functions: RtlFlsAlloc, RtlFlsFree, and RtlProcessFlsData. Unfortunately they are all three undocumented, even without information on their function signatures. So writing conformance tests for these is outside the scope my experience (fuzz testing maybe?). If you have some advice on how such testing is usually done for Wine, I'd be glad to hear it. Otherwise I think I'll just go with sticking it in the #ifdef __WINESRC__ section of winternl.h -John Sheu

Sept. 2, 2016