https://bugs.winehq.org/show_bug.cgi?id=42592
--- Comment #62 from oiaohm oiaohm@gmail.com --- (In reply to Henri Verbeet from comment #61)
Well, the wined3d_pool enum no longer exists in current Wine git, so any hack based on that will run into issues. If you want to do a hack, I'd suggest starting with not setting WINED3D_RESOURCE_ACCESS_CPU in d3d11's d3d_buffer_init(), unless "Usage" is D3D11_USAGE_STAGING, in which case you don't want WINED3D_RESOURCE_ACCESS_GPU. This is also an area that's currently seeing active development though; any hack is likely to get broken again relatively soon.
I am guessing by this is retest with master to see if performance fault still exist or has been fixed by all the changes.
This was also something I was suspecting change way too many values.
So correct might only be turn on the WINED3D_RESOURCE_ACCESS_MAP flag and leave everything alone with like a ten foot barge pole and see if that fixes the performance problem.
Also from what you saying alteration should be outside wined3d and up in the direct x libraries? This would also limit area of effect.
Really this is why I was saying key part collect more data on what the program is doing to attempt to work out why in heck it so slow and possible make a test case that abuses wine that way so it can be fixed.