Heavy CPU usage - DX9 related?

[Rivak]

I want to start off by saying thank you for such an awesome product. I appreciate what you folks have done, and are doing to help the VTT community thrive and move forward.

I am a recent purchaser of FGII and I have come to really enjoy the interface and the extensibility it offers. I feel like I have only scratched the surface of the options that are available to me. It is with this sense of wonder that I opened up the app for the first time. To my ultimate dismay, I saw an immediate and tremendous load on my CPU. I did some tracing and was able to find the cause:

fixme:d3d:IWineD3DSwapChainImpl_Present Unhandled present rects (0,0)-(1024,768)/(0,0)-(1024,768)

Admittedly, I do have this app installed under WINE, but loading the program in a VM appears to produce the exact same results. This is fairly alarming to me as my console is verily flooded with debug messages and the constant errors seem to be spiking one of the cores of my CPU to a full load ... which is causing my temps to get pretty hot. Has anyone else had this issue?

I'm running:
OS X 10.6.2
2.66Ghz Intel C2D
4GB DDR
nVidia GeForce 9600M GT video card

[ddavison]

Hello Rivak,

Can you give us the exact steps you followed and at exactly what point you noticed your CPU usage begin to spike?

When you say that your console is flooded with debug messages, what messages are you receiving and for which ruleset or module? It sounds as if you have a bugged piece of code in a custom ruleset which might be creating an infinite loop?? When you first open the ruleset, type in /console to open the console window. Any errors should be rendered to this window.

-Doug

[Rivak]

ddavidson, thanks for your prompt reply.

I figured I would exercise some additional initiative while waiting on your response and did some additional digging. I removed Wine Bottler from my computer, and all of it's associated config files. I downloaded and compiled a recent copy of Wine directly using MacPorts. After this freshly installed/compiled copy of Wine, I have had better results. I still see some CPU spiking from d3d, but it's not nearly as bad as before.

Attached please find three screenshots:

terminal.jpg : shows the wine command-line used to launch FGII in the upper-portion of the pane and the d3d error on the bottom portion of the pane.

combo.jpg : the combo screen shows the terminal window in the background with the errors stacking up, and the activity monitor shows a steady rate of around 80% of a single core while just sitting at the launcher screen.

combo_2_campaign_loaded.jpg : I loaded up the default module "A Tale of Dinor" and you can see the drop in the cpu load for the core in the activity monitor. However, FGII is still steadily throwing out errors to the terminal console in the background.

The interesting thing is that if you run the command you listed earlier (/console), no errors are output to that window. I can reproduce the symptoms when loading inside a VM (WinXP via Parallels), but I cannot get the same type of output like I can via a direct command line. If there is anything else I can help with, please let me know.

[Rivak]

After some additional playing around with config and a few other things, I was able to reproduce my original results of a full core being used. My MBP has a dual-video card in it. In "saver" mode, it reduces down to an nVidia geForce 9400M card, in "performance" mode, it bumps up to the nVidia geForce 9600M GT.

In performance mode is where I actually see the problem of chewing up an entire CPU core, which is causing high temps (upwards of 70*C) for a constant period of time.

I was able to pick this up out of the terminal buffer before the buffer_PreLoad error overloaded it:

fixme:d3d:query_init Unhandled query type 0x4.
fixme:d3d_surface:surface_load_ds_location (0x1a2978) Not supported with fixed up depth stencil
fixme:d3d_surface:surface_load_ds_location (0x1a2978) Not supported with fixed up depth stencil
fixme:d3d:buffer_PreLoad Too many declaration changes or converting dynamic buffer, stopping converting
fixme:d3d:buffer_PreLoad Too many declaration changes or converting dynamic buffer, stopping converting
.
.
.

[ddavison]

We don't actually make any calls to a buffer_PreLoad or surface_load function at all -- at least not directly. Therefore, I think this might be related to a problem with the specific Wine distribution you are using. Which version are you using?

Here are a few other things that might help from the FAQ on www.winehq.org

6.2. How do I disable the GUI crash dialog?
As of 1.1.20, Wine includes a GUI crash dialog that is turned on by default. Users of apps that work despite a background crash may find the GUI dialog annoying, and in some cases the dialog itself has been reported to prevent an app from working.

The easiest way to disable the crash dialog is with winetricks:
sh winetricks nocrashdialog

If you prefer to do it manually, copy the following key to a text editor:
[HKEY_CURRENT_USER\Software\Wine\WineDbg]
"ShowCrashDialog"=dword:00000000

Save the file with a .reg extension (e.g., crashdialog.reg), then apply it with regedit:
regedit crashdialog.reg

(You may need to specify the full path to the file, depending on where you saved it.)
To turn the GUI crash dialog back on, change 00000000 to 00000001 and reapply.
These changes can also be made by simply running regedit and adding/changing the appropriate key the point-and-click way.

Additionally, the Mac OS FAQ for Wine recommends installing xQuartz as well to provide better Direct3d support. It looks like the latest distribution of xQuartz can be found here:
https://xquartz.macosforge.org/trac/wiki/X112.4.0

[ddavison]

A few other suggestions to try:

1. With the 2.5 update, the previous black screen flashing problems in Fantasy Grounds can be avoided by executing the program with the -r modifier. If you add that suffix when you start the program, it will work perfectly in Wine. Alternatively, you can tick the box that says 'Cross-platform compatibility mode for Linux and Mac' in the installer.

2. If that does not work, you might try running it under version 1.1.38 of Wine, as it was reported to be running perfectly under that distribution.

[Rivak]

I'm on my third version of wine now. I was originally running Wine Bottler, which made life "easy" by doing all the difficult compilations for you. This is where I first discovered the spiking. I then tried macports and compiled the wine-devel port from there. I believe this runs from release 1.1.40, which is supposed to be compatible with snow leopard. This got me closer to where I wanted to be, but still the same d3d errors, but seemed less CPU intensive, for some reason. I tried the crossover games variant running 8.1.0 which branches from WINE 1.1.25. This, so far, seems to be the fastest and least prone to spiking the CPU.

I will try the full version of wine from their website. The problem with XQuartz is that I am running snow leopard. XQuartz is not fully compatible with SL until 2.5.1, according to their roadmap. I poked around, but I couldn't even find a developer release to play around with, unfortunately.

Thanks for your continuing help and suggestions!

[Callum]

One of my players has been using CrossOver Games 8.1 on his Mac without any problems for quite a while. I don't think he's running Snow Leopard, though.

[Vudo]

Hey Rivak, are you still using Crossover with 8.x or did you try 9.0.0 as well? I cannot set the "-r" switch on the 9.0.0 version, does it work with 8.x ?

--
cheers,

Vudo

[Etore]

The topic of this thread is misleading since the issues are not with DX9, but with Wine and how it implements DX9 to OpenGL wrapping. The fixme-messages are meant for Wine developers and do not in this case affect how FG works.

The hardware requirements are higher for running FG under Wine than native Windows because of the Linux/Mac compatibility mode, which redraws the entire screen on every refresh. If you're using VirtualBox for VM, it uses Wine under the hood and you can expect the same end result.

When seemingly nothing is happening on the screen, FG still runs its idle game loop, which "takes up" the available single core cycles, which is why the load peaks. CPU load is measured as a percentage of time the CPU spends running its own idle cycle and in this case this idle cycle is replaced by the idle cycle in FG, which means it's not really doing much and you can use that same core for multitasking while playing FG.

I never run Wine from command line except when developing Wine, because the fixme-spam is present with a large group of games. Why not just create a launcher on your desktop for FG or run the executable directly from your file manager? I'm sure you're aware, but it's worth mentioning that Exe-files can be run as is from file managers when you have Wine installed so you can just double click them.