How debug wine high load?

[lingtjien]

Hello,

I've been trying to get an old game working on Linux through wine. After a lot of trial and error I have a setup where the game runs on Linux using wine, but the only remaning struggle I have right now is that the game consumes 80% CPU in idle (it was even more than that before I disabled CSMT). I have also verified by running this game on windows that this does not occur on windows.

I've tried to use callgrind to profile it and I see one strong contender for a possible cause, I see 150k calls to

Code: Select all

_strcmp_avx2

which seems to be mostly called from an unknown function (149k) with address "0x48e13e0" (location unknown), while all the other calls are mostly around 1k or less calls. So that one is my main suspect now, but because callgrind does not seem to be able to tell me what this function is I'm a bit stuck.

I've tried to compile wine from source with

Code: Select all

-g -O0

in an attempt to maybe get some more information but callgrind is still not able to tell me more.

I've been going through the wiki where I found this

The usual way to recognize this kind of issue is a lot of CPU time spent in wined3d_resource_map, glMapBufferRange, glSubTexImage2D, Query::GetData or similar calls.

but I am unable to find how to see which wine functions are called most often.

So, is there perhaps another way to debug which functions in wine is called the most or consuming a lot of CPU cycles? Or perhaps you have a completely different suggestion?

Thank you for reading.

[lingtjien]

Seems like I made a mistake, I forgot to tell callgrind to trace child processes, but using that flag makes me unable to run the game at all. Is there a better way to determine which dll's are consuming the most CPU cycles?

[lingtjien]

Some more info, I went through all the dll's that the application loads and used WINEDEBUG=+<dll name> to see if I could gather some more info and I found that the mmdevapi.dll seems to spam a lot. In particular these 3 lines:

Code: Select all

01d8:trace:mmdevapi:client_GetCurrentPadding (019A8B48)->(07F2FF0C)
01d8:trace:mmdevapi:render_GetBuffer (019A8B48)->(480, 07F2FF14)
01d8:trace:mmdevapi:render_ReleaseBuffer (019A8B48)->(480, 0)

My guess was that this dll seems to handle audio? But I'm unsure if this behavior is normal or not.