World of Warcraft - Test Results

[IngeniousDox]

commit: https://github.com/acomminos/wine-pba/commit/0ca7edba117f5c91c75623880caf8e4d1eeb117b0ca7edba117f5c91c75623880caf8e4d1eeb117b specs:

• CPU: Intel i5-4670K OCed @ 4Gz
• GPU: NVidia 970GTX OCed @ 1565Mhz
• RAM: 16gb @ 2400Mhz

Testing Spot: Suramar, on top of Astravar Harbor Graphic settings: Preset 7 Test Reults:

Staging 2.21 DX11: 42 fps (no csmt - lowers fps)
Staging 3.2 DX11: 18 fps (no csmt - lowers fps)
wine-pba 2.21 DX11: 67 fps 

Staging 2.21 DX9: 48 fps (no csmt - lowers fps)
Staging 2.0 DX9: 82 fps
wine-pba 2.21 DX9: 97 fps

Amazing results for DX11!! DX9 is also a bit faster then before (7 fps higher then your first build). But the improvement is DX11 is amazing. Eyeballing the CPU% from HTOP and the GPU-Util from nvidia-smi, I get:

DX9: 275% CPU / 67% GPU for 97 fps
DX11: 256% CPU / 51% GPU for 67 fps

Way higher then before. Looking forward to your upcoming improvements.

Dox

[mirh]

with and without PBA

And that's it. If you really want to sport "best case" results, reboot in Windows and check it.

If you care about vulkan (which again, has nothing to do with this repo), discuss that on https://github.com/doitsujin/dxvk/issues/14

[TRPB]

Assuming dxvk works with WoW (last I heard they hadn't implemented dx10 so it doesn't) it would still be interesting to compare dxvk vs wine-pba performance. I'm sure nobody here really cares whether wine is using vulkan or opengl for its renderer, we just want the best fps we can get.

[mirh]

Yes, sure, but even assuming DXVK was perfect, even though it uses the noblest® of the APIs, I don't think it could surpass native dx10/11 windows drivers (which I'll just want to remember everyone: have undergone decades of optimizations - more often than not even with game-specific hacks)

In this sense, once you benchmarked X scene of the Y game on Z hardware once, you are done with your "setting a goal" aim. (and tbh, it's really sad nobody hasn't still reported such results)

[yaomtc]

Took me a while to get around to editing this, but I tried a more recent build (34a2a05 I think) and got some decent frame rate improvements this time, compared to Staging. Here you go.

https://www.youtube.com/watch?v=sYMb4ZXqSbI

[SveSop]

The benchies i have done with Unigine benchmarks comparing DXVK vs. wine-pba, shows wine-pba slightly ahead. (API set to DX11 in Unigine Valley and Heaven).

Using wine-staging-pba + dxvk makes no difference it seems, as "pba" patches wined3d, and afaik dxvk kinda skips using functions from wined3d?

@SteveEbey73742 You can post the output from vulkaninfo when running wine (from the VulkanSDK) to "prove" you are able to run vulkan apps under wine-staging-pba-3.3.

Its not enough to just change a registry setting to get DirectX to render over Vulkan instead of OpenGL.

[ardacam]

Specs

• CPU: AMD FX-8350@4.0GHZ
• GPU: AMD R9 380 2GB
• OS: Solus OS Budgie
• RAM: 8GB
• Graphics Preset: 7
• AddOns: AdvancedInterfaceOptions ArtifactPowerUser AskMrRobot BagBrother Bagnon BigDebuffs BigWigs flyPlateBuffs LittleWigs NiceDamage nPlates OmniBar OmniCC RSA Scrap SUI WorldQuestTracker

I removed modules from list since they are situational.

I did greater invasion point, dungeons, world quests, random bgs and 2v2 arenas. Lowest fps was in greater invasion point which was around 15-20. View Distance seems to be the most effecting option in open world. Setting it to 4 and everything else on default gives 50+ fps in Suramar. Compared to gallium-nine (which is the superior choice for AMD GPUs most of the time) wine-pba is definitely better for WoW.

[Saroufim]

That makes me wonder, is it not possible to use pba and gallium nine together?

El mié., 14 mar. 2018 1:14 PM, Arda notifications@github.com escribió:

Specs

• CPU: AMD FX-8350@4.0GHZ
• GPU: AMD R9 380 2GB
• OS: Solus OS Budgie
• RAM: 8GB
• Graphics Preset: 7
• AddOns: AdvancedInterfaceOptions ArtifactPowerUser AskMrRobot BagBrother Bagnon BigDebuffs BigWigs flyPlateBuffs LittleWigs NiceDamage nPlates OmniBar OmniCC RSA Scrap SUI WorldQuestTracker

I removed modules from list since they are situational.

I did greater invasion point, dungeons, world quests, random bgs and 2v2 arenas. Lowest fps was in greater invasion point which was around 15-20. View Distance seems to be the most effecting option in open world. Setting it to 4 and everything else on default gives 50+ fps in Suramar. Compared to gallium-nine (which is the superior choice for AMD GPUs most of the time) wine-pba is definetly better for WoW.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/acomminos/wine-pba/issues/7#issuecomment-372985911, or mute the thread https://github.com/notifications/unsubscribe-auth/AEfnYGglHCj8w6b2ubHUNoQDQIFGE4aOks5tePuRgaJpZM4SUrNi .

[SveSop]

@Saroufim I suspect this is possibly the same reason why there is no change when using DXVK with or without "pba"... cos DXVK uses its own threading++. Not looked at gallium-nine, but i guess it has its own wined3d/d3d9.dll++, that does this differently than regular wine? DXVK replaces dxgi.dll and d3d11.dll and uses its own vulkan render path, and is not "affected" by pba it seems.

I can do some more testing with DXVK and PBA when wine-dev gets all the vulkan patches implemented. Tested with staging-pba-2.21 and dxvk, but was no difference between that and regular wine-staging-2.21. As of late, pba is based on 3.3, and wine-vulkan-3.3 is using its own set of patches atm, so not too easy to test, although i guess it should not be too hard to implement pba patches on that sourcetree tho. (Might even patch straight up.. i dunno)

EDIT: Thinking stuff like Unigine benchmarks.. DXVK does not work with WoW, as WoW requires some DX10 stuff to run in DX11.

[Dehir]

Ill agree with @SveSop with this idea. DXVK and Gallium propably have their own code on direct3d and wine-pba doesnt directly affect those. But it would be great thing for both of those projects to take look at what wine-pba is trying to do and figure out would implementing wine-pba approach/patches improve their performance too if they are lacking these improvements?

[mirh]

That makes me wonder, is it not possible to use pba and gallium nine together?

Not sure how much they "relate" to this, though they already have https://github.com/iXit/Mesa-3D/issues/297 And none of these patches have anything to do with threading, anyway.

Also, for the love of god, instead of mentioning vk, why don't you benchmark windows already?

[SveSop]

@mirh

Also, for the love of god, instead of mentioning vk, why don't you benchmark windows already?

I plainly refuse to dual-boot windoze! :)

[acomminos]

I've made GL_CLIENT_STORAGE_BIT a mesa-only thing in 87307b1b9093c769d21d0803bb122b9866bb887c for now. Using DMA CACHED memory for buffers streaming on NVIDIA appears slower, so this should be a win for everyone.

[acomminos]

Also, given the earlier discussion, I should probably chime in and mention that DXVK will not benefit from any of my patches. DXVK implements D3D11 independent of wined3d (which is what the PBA patches apply to).

[mirh]

By the way, did you got to check whether AMD_pinned_memory is indeed faster than buffer_storage? I have seen on mesa-dev that it might even be supported by intel hardware.

[IngeniousDox]

commit: https://github.com/acomminos/wine-pba/commit/87307b1b9093c769d21d0803bb122b9866bb887c

I don't think I had issues with GL_CLIENT_STORAGE_BIT. At least not during timetest.

Timetest Crimson Thicket (Suramar) -> Vengeance Point (Broken Shore) - Min/Max/Avg fps:

CSMT+NV: 11 / 115 / 86
CSMT: 18 / 121 / 89
Prev Build: 18 / 120 / 88

And back:

CSMT+NV: 14 / 142 / 87
CSMT: 18 / 156 / 97
Prev Build: 18 / 162 / 97

I did each time 3 times, first to fill shadercache 2 and 3 to confirm I get the same results.

However, I have to note from eyeballing "watch nvidia-smi", I'm reaching 100% gpu usage from time to time during timetest. Which means I'm testing GPU bound there. Seems ok to compare builds I guess, but not really representative for actually playing the game.

Raiding is CPU bound, I have around 50% GPU usage then. And there fps is more important. I'll test mythic raiding tonight.

[SveSop]

@IngeniousDox So, with the latest commit, you have to turn off __GL_THREADED_OPTIMIZATIONS to get "back" to the performance you had before?

[IngeniousDox]

Not just the last commit, it was already before that __GL_THREADED doesn't help, it just adds CPU overhead you can't use anymore.

EDIT: In my case / setup. And only in WoW / Diablo III. WIth HotS / SCII I still use both together.

[SveSop]

@IngeniousDox I'm not seeing the same degradation with __GL_THREADED as you do in wow (or Unigine Benchmarks for that matter). Tested the same flightpath you described over, zoomed character all in (1st person), and pressed ctrl+z to turn off UI elements.

Results:

Crimson Thicket (Suramar) -> Vengeance Point (Broken Shore) - Min/Max/Avg fps:
NV=1    28.2/153.6/93.6
NV=0    35.9/133.7/63.9
Vengeance Point (Broken Shore) -> Crimson Thicket (Suramar) - Min/Max/Avg fps:
NV=1    32.9/192.7/98.9
NV=0    32.2/179.1/75.8

Not sure why you get worse performance with __GL_THREADED_OPTIMIZATIONS=1 tho.. Had the same decline in performance with Unigine Valley aswell.. Although i got a wee bit higher max fps in Unigine with NV=0, i lost average fps.

The only difference i can immediately think of (besides hardware like motherboard and gpu manufacturer) is that i use a different kernel perhaps? The distro SHOULD not have anything to say on this nVidia option, as i think we both use 390.25 driver...

PS. Updated pba-git today, and recompiled with wine-3.3 + wine-staging-3.3

[IngeniousDox]

Like I said, it is with my PC setup. I noticed I dropped in FPS, instead of gaining fps. So I tested. And in my case disabling __GL_THREADED gave me more fps during timetesting. I think it basically was due to my 4 CPU cores already being fully loaded. The extra CPU it takes to setup another thread for the driver, and the CPU time it takes to sync with that thread ended up costing me fps.

I encourage people to test for themselves.

I'm also going to restate that a /timetest isn't really a good test, but it is the best we have. Real playing happens in raids/bgs/arenas/dungeons. It might be that it helps me there. Atm I just don't play enough to really test it.

[SveSop]

I agree.. It is not that easy to come to a 100% conclusion from timetests alone.

I have done some testing with 4 vs 8 cores - ie. 4 "real" and 4 HT threads, and found that i got a bit better performance with 8 threads. I also run the wow binary with taskset -c 0-3, so that the 4 "real" cores gets the most of the load. There is something fishy going on with threads in wine vs. driver and whatnot, but doing that MIGHT leave the GL_THREADED option to offload on threads that are not in use by wine somehow.. i dont know. Disabling HT in bios, and running only on the 4 real cores made for a bit worse performance, but then again, i did not test this with GL_THREADED 0 vs 1 at that time, and it might be something that effect this.

I did (not with pba tho) quite a few tests comparing kernel with PDS cpu scheduler vs. MuQSS, and found that MuQSS divides loads among threads more equal, but that is not really beneficial, as threads 0-3 is the "real" cores, and 4-7 is HT threads sharing off the real cores.. And i found that having cores 0-3 loaded 80+%, and 4-7 10-15% yielded more fps than all threads loaded 40-50%. I concluded then that PDS was more "sane" when distributing load amongst threads, as it would prioritize loading the actual real cores rather than treating all threads seemingly equal. This "function" is something related to "smt-nice", where the kernel is made aware of what cores is "real" vs. "ht", and it might just be that this is included in 4.15 kernel for all cpu schedulers.. dunno.

[IngeniousDox]

Ok, had some time to test raiding Coven Mythic tonight. Using __GL_THREADED_OPTIMIZATIONS gave me slight lower fps, mostly between 35 ~ 45 fps. Without that I ended up 40 to 55, and without it it just felt smoother.

Tested this build, and the previous 1. Didn't notice much difference once shadercaches were filled.

[SveSop]

A bit off-topic here, but since the wine-staging git repo does not have any "issues" ability.. how does one get in touch with the ppl doing the staging patches now really? wine-staging-3.4 does not fix vsync, and it seems its back to wine-dev version of vsync - ie. its on no matter what you do, and locked at 60 fps (for a 60hz monitor i guess).

[mirh]

They.. still seems to recommend using the normal bug tracker? In your case, I think this should be it.

[SveSop]

@mirh Hmm.. It does not seem as the patches from https://bugs.winehq.org/show_bug.cgi?id=44623 has made it to submission.. I see Mr. Kucia posted this on the patches list to winehq.

Reporting vsync bug in staging on the bugtracker? I dunno... This vsync bug has been there for, well years, and wine-staging fixed this years ago. So its nice if this gets implemented some day, but for now, it does not work with staging either, so i guess ill test some more.

Might be me that is a dick, but "bugzilla" should honestly be studied by scientists.. especially now that Stephen Hawking is gone.. cos where else can you study a huge black hole up close..

[mirh]

Vsync bug is in wine first and foremost - and having bugs in a patch for a bug.. Still makes it related to the latter. Then it may have been there since ages, but for magic to happen somebody doing the right report with the right info is needed. (and I hope I don't have to remember you about what means "being unpaid and freelance")

Then it was questioned on the mailing list, and it might re-land next month, or tomorrow, who knows. If you want further info ping them directly on #winehq or #winehackers.

[SveSop]

Well.. functions not present in wine i think is not considered a "bug". Staging implemented a fix that probably did not pass some test = not implemented, and as you can see on that link you posted with comments on Kuzia's patch, they don't agree on the implementation. (Wine dev's that is).

Bug-reporting this on bugzilla when others already have AND wine-devs already have suggested patches = fruitless.

Suggesting i try to reach someone on IRC is the best bet, and should have been suggestion in your first post @mirh Thx.

[mirh]

Well.. functions not present in wine i think is not considered a "bug"

Everything they are missing from actual windows is bug. And bumping threads with newer information is not pointless. ...

Back on topic: has anybody even the slightest clue on whether current pba is good enough for perfection (aka performance parity) or not?

[SveSop]

Got a tip on #winehackers, and if anyone else is interested in forcing vsync off for 3.4, you can either edit dlls/wined3d/swapchain.c yourself and change:

-    swap_interval = swapchain->desc.swap_interval > 4 ? 1 : swapchain->desc.swap_interval;
+    swap_interval = 0;

Or, you can patch the attached patch after the pba patches :)

0001-vsync-disable-hack.patch.gz

[AndersDala]

Just curious, but is the patch in https://source.winehq.org/patches/data/142465 not also solving the same issue as above? (nevermind if it is "beautiful code" or not - ref to mailing list discussion). Seems to work fine for me at least. :)

curl -Ls https://source.winehq.org/patches/data/142465 | git apply

[SveSop]

@AndersDala That is more or less the same code as "staging" uses, but for 3.4 i could not get vsync disabled. The patch https://github.com/wine-staging/wine-staging/blob/master/patches/wined3d-dxgi_swapchain_Present/0001-wined3d-Implement-updating-swap-interval-through-win.patch is from staging, and its very similar.

I don't really know why it did not work for me tho, if you have compiled wine-staging-3.4 without doing anything, and test a DX11 (DX9/OpenGL/Vulkan have no problems) benchmark/game and get 60+ fps without troubles.

[AndersDala]

I have only tried the patch against wine master, there it works fine for me using DX11 in TW3. Note that you can only really test it in the menus, as in TW3 wine master only gives ~20FPS otherwise. But in menus it is clear 60 vs 1000 FPS.

Tried various build between 3.0 and 3.3, haven't tried on 3.4 as I now get ~80-100FPS using DXVK instead so quite happy. :-) Haven't used wine-staging lately.

[SveSop]

@AndersDala Yeah, i know it works with 3.3 and lower with staging. It have not worked with "release" in DX11 "ever" i think. The staging patches for vsync in dx11 started around 2.16 or so i think.

DXVK uses Vulkan, so is not in any way affected by this.

Are you saying you have had the possibility to disable vsync and get 80-100 fps in DX11 in regular non-staging wine since 3.0? Cos.. if you get 45 fps with "wine-master", then you dont really test the problem :)

[AndersDala]

"Are you saying you have had the possibility to disable vsync and get 80-100 fps in DX11 in regular non-staging wine since 3.0? Cos.. if you get 45 fps with "wine-master", then you dont really test the problem :)"

Maybe I was not clear, but the way I confirmed that the patch I referenced worked in wine-master was.

• Build wine master at various points from 3.0 to 3.3+
• Launch TW3 with vsync etc disabled - notice that the FPS in the menus is 60FPS despite vsync off etc. Clear indication that something is wrong.
• Rebuild same commit but with patch applied
• Relaunch game and notice that now the FPS is ~1100 in the menus => problem solved.

As can be seen in the original bug report the game play is also more fluid between 18-24FPS instead of being artificially "semi-capped" at 15 or 20 (and 30 etc) FPS.

Regarding the DXVK part: yes, obviously. :-)

[SveSop]

Yeah, sunday morning, and i guess missunderstandings is in place of a hefty night out yesterday...

1. That patch is ALMOST identical to the "staging" patch, that has been included since.. well.. the "new" staging started.. 3.0'ish.
2. That patch (AND the staging one) works on 3.0, 3.1, 3.2 and 3.3, but NO LONGER works on 3.4.
3. Test that patch with 3.4, and tell me if it works or not.

And to quote myself:

wine-staging-3.4 does not fix vsync, and it seems its back to wine-dev version of vsync - ie. its on no matter what you do, and locked at 60 fps (for a 60hz monitor i guess).

[AndersDala]

Haha! Sure, I can try it on 3.4 as well. :-)

EDIT: Yup, doesn't apply cleanly on 3.4. So something changed for sure.

[IngeniousDox]

Very off topic to talk about VSync (with TW3) in "World of Warcraft - Test Result" thread. Has nothing to with WoW or Wine-PBA. Please take it somewhere else.

[SveSop]

TestResults = Benchmark = need to disable vsync. I asked if ppl knew how to get hold of "staging" ppl to fix vsync not being disabled in staging-3.4

It all escalated from there....

[SveSop]

And to get back on topic. I tested with wine-staging-3.4+pba + the hack to disable vsync.

Crimson Thicket (Suramar) -> Vengeance Point (Broken Shore) - Min/Max/Avg fps:
28.0/148.5/90.8
Vengeance Point (Broken Shore) -> Crimson Thicket (Suramar) - Min/Max/Avg fps:
30.4/193.4/96.6

Slightly less than wine-staging-pba-3.3, but not sure what causes that.

[SveSop]

Seems as there was a typo in dlls/wined3d/swapchain.c that did not give "0" as an option to swap_interval setting. 0 being "vsync off". Edited this, and added staging+++, and i could turn on/off vsync in Unigine benchmarks again :)

Posted on a recent bug with a patch, so lets see if its picked up, or if im totally off here hehe. https://bugs.winehq.org/show_bug.cgi?id=44623#c6

[isugimpy]

@SveSop What hardware are you running on to get numbers like that? At preset 7, with a stock i5-4690k, 24GB of RAM, a GTX 1080, wine-staging-pba-3.3, nvidia-390.42, I'm getting ~45 FPS average out in the world. I'll do a proper test of it tonight, and see about the vsync patch as well, but that seems like a drastically different performance profile than I'm seeing.

[IngeniousDox]

@isugimpy Quick question, do you have CSMT enabled? Your numbers feel like non csmt/non pba numbers for that hardware.

For the record: I have the same cpu as you, but with 970gtx.

[isugimpy]

I enabled CSMT last night, but now that I'm looking at my registry files (I'm not at home right now to pull up winecfg) it looks like I enabled it on my default wineprefix instead of the one I'm actually running out of. That would be a silly mistake. I'll go toggle it on when I get home and retest. I'm definitely running pba, though. I have pba installed in general, and also intentionally had Lutris install it separately to be absolutely sure when I still wasn't getting great performance.

Edit: I did enable it on the default wineprefix instead of the one I'm using for the game. After toggling CSMT on for the correct prefix, my performance actually got worse, sitting at about 32 FPS at precisely the same location in the world. While I understand that's not a great benchmark, it's what I've been doing to gauge relative performance, because it's a way I can log in, spend a minute validating, and log back out to adjust something else.

Edit 2: Disregard. It was the area I was in. I did the same timetest as you guys, flying between Crimson Thicket and Vengeance Point, with the following results.

Crimson Thicket (Suramar) -> Vengeance Point (Broken Shore) - Min/Max/Avg fps:
20.7/129.12/98.68
Vengeance Point (Broken Shore) -> Crimson Thicket (Suramar) - Min/Max/Avg fps:
13.28/152.42/96.13

Shame on me for not doing the test the right way to begin with.

[ghost]

@IngeniousDox Huh, that certainly cleared up some things for me regarding the intermittent stuttering. I had a hunch it was due to shader caching. Though performance does tank no matter what when using maxed out view distance in stormwind.

[SveSop]

@isugimpy Yeah, its no problem to get wow to take a fps nosedive no matter what hardware you have, or if running natively in windows.

Timetest have its own issues with getting stable consistent results, BUT the results are atleast somewhat indicative to performance, and as you can see you have slightly better than me with slightly better hardware :)

Wine performance is very dependant on cpu clockspeed tho, so a stock i5-4690K running at 3.9Ghz(default?) might not speed ahead of my crappy old i7-2600K running at 4.2Ghz

[IngeniousDox]

3.4ghz default. I'm running it at 4k Ghz on Air 24/7, could increase it when I increase voltage, but I like to stay below 80 degrees on full load.

[mrdeathjr28]

@SveSop

Yeah for disgrace wine in most cases depend of higher frecuencies and higher ipc in few cores

For example you can have i5 4690K at 3.9ghz (similar core ryzen performance) in all cores but a i3 8350K (with only 3 cores enabled) at 5.1ghz must be up so much

[IngeniousDox]

Staging 3.5 + Firerat Rebase & GEO/CB envvars patch @ GEO 1532, CB 256. This means using mainline CSMT:

(Latest Liq kernel + Nvidia 390.48 driver)

Timetest Crimson Thicket (Suramar) -> Vengeance Point (Broken Shore) - Min/Max/Avg fps:

CSMT: 18 / 121 / 89
CSMT+NV: 17 / 116 / 89

And back:

CSMT: 18 / 160 / 99
CSMT+NV: 18 / 161 / 96

CPU usage is lower, and I don't think I'm hitting 100% gpu either anymore. So I decided to test __GL_THREADED_OPTIMIZATIONS=1 aswell. Still gives me slightly lower fps, so I'm leaving it off for now.

Max VRAM was 1450 MB ish, so I don't think I ever got near the max of heaps, but it didn't hurt to increase the values.

Conclusion: I think I gained a bit of fps compared to the last time I tested. So I advise people to build and test 3.5 for themselves.

[SveSop]

Did some testing today, and as usual, not really that conclusive in wow when it came to results, as i could not always get higher result with 1532/256 value... but it DID seem a bit better tbh.

Crimson Thicket (Suramar) -> Vengeance Point (Broken Shore) - Min/Max/Avg fps:

31.0/149.4/90.3 - default
33.4/151.5/93.2 - 1532/256
30.4/147.6/93.7 - 256/64

Vengeance Point (Broken Shore) -> Crimson Thicket (Suramar) - Min/Max/Avg fps:

22.8/188.7/96.1 - default
34.5/193.3/99.0 - 1532/256
30.4/196.7/98.3 - 256/64

I also did some tests in Unigine Valley, and there the highest setting of 1532/256 showed a huge drop in fps... Valley:

92.5 fps (3870) 34.6/170.5 - default
75.9 fps (3175) 30.7/113.8 - 1532/512
92.6 fps (3874) 34.2/173.5 - 256/64

Slight increase by lowering the value.. Not really sure what this means..

Another knob to tune i guess :)

[ghost]

@SveSop your not likely to see any real performance gains tweaking the geo heap size, the defaults are probably just fine to illustrate , try setting geo heap to something very low say, 5mb you should see something like this

0009:fixme:d3d_perf:buffer_resource_sub_resource_map Failed to allocate new buffer, falling back to sync path.
0030:fixme:d3d_perf:wined3d_buffer_map Fences not used for persistent buffer maps on CS thread, using glFinish (flags: 40002000)
0009:fixme:d3d_perf:wined3d_buffer_heap_alloc Forcing coalesce, not enough free space in buffer heap.
0009:fixme:d3d_perf:wined3d_buffer_heap_deferred_coalesce Performed 0 coalesces.

and WoW will stutter

unless you are seeing msgs like that under normal conditions, upping the heap is not going to help you any

[SveSop]

@Firerat Still.. it was quite a performance degradation setting this value "too high" in Unigine Benchmark :)