| Author |
Topic |
TransGaming |
Posted - 2009.03.21 19:51:00 - [ 1]
Greetings, EVE Mac players! TransGaming has been following the discussion of people's experiences playing Apocrypha on the Mac, and we wanted to provide some insight on a few issues that have recently been discussed on the forum:
1) Core gameplay issues
Some users have reported crashes on basic gameplay functionality such as exiting a station. Based on discussions with CCP, this appears to be correlated with a corruption of downloaded patches, especially if you patched soon after Tranquility was updated on March 10th. If you are still experiencing problems you may wish to download a fresh TQ client, delete your EVE Online Preferences directory, and run the fresh client.
2) System freeze in fitting window on MacBooks with Intel GMA X3100 chips
This has been tracked down to a driver bug which has been reported to Apple. We have found a workaround which should ship in the next update. That update will also lower the default shader level to low for these cards, which should help with performance there. Note that Intel GMA X3100 and GMA 950 video cards are not officially supported by CCP on the Mac, due to low performance in some cases, and driver instability issues such as this one and the item below.
3) Memory leak with Intel GMA X3100
We are not aware of any serious memory leaks at the Cider level. The memory leak in previous EVE clients that could happen when you used Command-Tab to switch between applications has been addressed in the Apocrypha release.
After reading through some reports of memory leaks in the forums, we did some additional investigation and tracked down a driver-level memory leak that occurs on Intel GMA X3100 systems. Unfortunately, we have not yet found a workaround for the problem, but we are in the process of filing a bug with Apple. We did find one way to 'avoid' the issue, which was to avoid calling the OpenGL function used to actually draw triangles on the screen. This method obviously leaves something to be desired though, so hopefully the root problem can be dealt with by the X3100 driver team
There may be another issue on the X3100 that we are investigating with CCP, which is the use of floating point textures. These are not supported by the Mac X3100 drivers, and we will work with CCP to ensure that the game doesn't try to go down these paths on Macs with these GPUs.
On the topic of memory management, note that it is normal for the 'Virtual Memory' size of the EVE process to be in the range from 2.5 GB to 3.25 GB when viewed in the Mac's Activity Monitor. This does not mean that the process is using this much memory, but simply that it has that memory 'reserved'. If you see the 'Virtual Memory' rising above 3.25 GB however, that may indicate an issue of some kind, and it is certainly worth reporting if you also experience a crash at that level.
4) Issues running MacOS X version < 10.5.6
A future update will include a startup message that makes explicit the fact that the game requires MacOS X 10.5.6 or later. Previous OS releases, especially in the 10.4 series, have numerous graphics driver issues, including ones on ATI HD2400/2600 and NVidia 8600 hardware that may hard lock your system. In general, Apple only upgrades video drivers with new builds of the OS, so you must get the latest drivers in order to avoid these kinds of problems. |
TransGaming |
Posted - 2009.03.21 19:52:00 - [ 2]
5) Graphics driver issues
If you are seeing extremely low frame rates (< 10 fps), there are several things worth checking for. Firstly, as above, make sure that you are using MacOS X 10.5.6 or later. If you have an ATI X1600 or X1900 card, note that there were substantial changes to the driver with the 10.5.5 release that avoids the potential for complex shaders to drop to software rendering. Apocrypha uses several sophisticated shaders which may have to fallback to software on older OS revisions on these cards. IE: You really want to be running the latest drivers if you have one of these ATI card.
Another thing to check for if you are seeing low frame rates and you have an NVidia graphics card is to ensure that you card has not suffered a "Graphics Channel Exception". You can look for this using the Mac's Console application, and searching for 'channel'. These errors indicate that a driver bug has been triggered. We are not currently aware of any issues in EVE which trigger a graphics channel exception, however we did work around a number of these during the development of Apocrypha. If you have experienced one, and can reproduce it reliably, please report it to both us as well as Apple.
If a graphics channel exception has occurred since you last rebooted, you should reboot your system. If you do not do so, you may see substantially lowered performance, incorrect rendering, and/or experience a hard lock.
Another issue that some users may experience is a corrupt texture from some other part of the game, or some other application appearing on-screen. Internally, we refer to this as the Avril Lavigne issue (see http://www.eveonline.com/ingameboard.asp?a=topic&threadID=728646 for why). This is a driver issue which can happen on NVidia 8xxx and 9xxx series cards, which can cause some textures to use other data that is in the VRAM of your graphics card instead of the correct data. A bug has been logged to Apple and NVidia on this for some time, but we do not currently have an ETA on a fix or a workaround. Fortunately, this is a very rare issue.
6) Warp tunnel pixelation
We have reproduced this on ATI R500 cards (X1600 and X1900), but have not seen this on other cards. Please include your graphics hardware details when you report any bug related to this.
7) Performance - Nonni system, POSes
We have attempted to reproduce results posted in this forum showing substantial performance deltas between Mac and Windows near player owned stations, but we have not seen any such difference. The station shown in Verite Rendition's screenshots at the Nonni 3-1 system are no longer there for comparison, but other test POSes we used did not show any such substantial difference. Based on the screenshots, we believe the likely culprit for the extreme performance difference seen is the number of 2D UI overlays for different objects in that scene.
The primary performance bottleneck for EVE on the Mac is CPU boundedness related to drawing UI overlay objects. This can be seen easily by pressing Ctl-F9 to hide all UI, then show it again - you will see a clear spike for the period when the UI is not shown. There are a number of causes for this bottleneck, and rest assured that both CCP and TransGaming are working to eliminate it.
We'd like to verify that Nonni system test case is indeed running into this UI bottleneck. Verite Rendition, can you please recreate the problem area in Sisi so that we can examine it in more detail?
|
TransGaming |
Posted - 2009.03.21 19:53:00 - [ 3]
Edited by: TransGaming on 22/03/2009 00:44:18
Edited by: TransGaming on 21/03/2009 23:54:51
8) Config file changes
Lastly, some users have been experimenting with Cider config file changes recently, but without knowing what some of the changes they are suggesting actually do. We do not recommend that users make modifications to this file, and future updates are likely to overwrite any changes that you make. That said, it is perfectly ok to experiment with config changes, so long as you recognize that they may cause unforeseen problems. You can always revert these changes later by simply deleting your 'EVE Online Preferences' folder and letting the game regenerate a new folder from scratch. Some explanations for the options being discussed in the forum can be found below:
[sdldrv]
The 'sdldrv' section contains config properties relating to the interface between Cider and the OS:
"Desktop" = "N"
Changing this to a value such as "1024x768" will force EVE to start in a Window instead of fullscreen.
"ShowFPS" = "0"
Changing this to "1" will show the Cider-side frame counter
"DisplaySettingsDialog" = "0"
This enables an obsolete settings dialog. This should never be enabled.
"MultithreadedGL" = "0"
Changing this to "1" will make the OS try to run all OpenGL operations on a separate thread. Currently not likely to improve performance, and will likely in fact decrease it right now. Once some of our further UI performance improvements are in place, this may change.
[x11dr]
The 'x11drv' section contains config properties related to the X11 UI system used in Linux with Cedega. These are not relevant on the Mac at all
[d3dgl]
The 'd3dgl' section contains config properties related to Cider's implementation of the Direct3D APIs
"AnisotropicTextureFiltering" = "Y"
Determines whether or not Anisotropic texture filtering is allowed. Not a significant issue on modern GPUs.
"DynamicVBO" = "Y"
When this option is enabled, vertex buffers with dynamic data (IE: UI data) are stored in VRAM using OpenGL's Vertex Buffer Object extension, along with relevant extensions for updating portions of this data when they change (GL_APPLE_flush_buffer_range, etc). With this off, dynamic vertex buffers are handled through system memory instead.
"IndexVBO" = "Y"
With this option enabled, index data is stored in VRAM using OpenGL's Vertex Buffer Object extension.
"FBO" = "Y"
Controls whether Cider can use the OpenGL FrameBuffer Object extension. This option should never be modified. Without this, Cider and EVE are unable to do any offscreen drawing calls. These are required for features such as shadows and environmental effects. Turning this off will result in incorrect rendering in a number of places in the game, depending on your selected detail level.
"FBOBackBuffer" = "Y"
This option controls whether Cider draws to an offscreen buffer for all rendering. This option is required for certain kinds of d3d operations relating to sharing depth buffers, and is on by default (and indeed, not shown by default). Disabling this forces rendering to go directly to the OpenGL back buffer, but should not have a big performance impact for the most part, except at high resolutions on mid-range cards when framerates are already relatively high.
|
TransGaming |
Posted - 2009.03.21 19:54:00 - [ 4]
Edited by: TransGaming on 22/03/2009 00:44:41
The config changes that appear to be getting the most recommendation in this forum are to disable both DynamicVBO and IndexVBO, along with FBOBackBuffer. This is a not unreasonable combination, and is likely to improve framerates somewhat in some circumstances. We will be evaluating this as we make other changes, and may make this the default in an upcoming release. Under no circumstances do we recommend disabling "FBO" however.
The reason that the DynamicVBO change may help goes back to the UI bottleneck. The UI system uses dynamic data extensively. When DynamicVBO is on, the way data is being flushed to the GPU (glBufferDataARB) appears to be causing the OpenGL drivers to allocate new VRAM space for the updated data, which can be a costly operation. Disabling DynamicVBO causes the driver to copy the data from system memory into GPU command buffers, which do not have any memory allocation overhead. With further modifications to the UI system to use a large ring buffer for output, the memory allocation overhead when using DynamicVBO should disappear. This may also allow the MultithreadedGL option to be useful in the future.
The IndexVBO extension should not have a negative impact on performance, even if the drivers are ignoring the option altogether, which may be the case with some OS versions and some cards. It will take up somewhat more VRAM, which could have an impact on systems with 128 MB of VRAM.
Disabling the FBOBackBuffer option is likely safe for EVE, as EVE does not appear to use the d3d calling sequence that FBOBackBuffer is required for. This may change in the future, however, and we are talking to CCP about this to ensure that the best options are chosen. That said, FBOBackBuffer is unlikely to provide more than a 10% performance boost at most, and that only when framerates are already above 40-50fps and at high resolutions.
- The TransGaming Team. |
Shane Darman
Gallente
The Scope
|
Posted - 2009.03.22 02:10:00 - [ 5]
Edited by: Shane Darman on 22/03/2009 02:25:00Edited by: Shane Darman on 22/03/2009 02:13:541st Edit: Woah first  !!!!!!!!!!!!oneoneone111!!!!!!one!!!!!11!!!!!!!!!!!!!oneone!!!!!1!! Oh thank you you masters of mac, you princes of C, for addressing this most vitally fatal issue! Wait a tick....! I'm on a MacBook Pro not a MacBook! (lol what did I just say - I do thank you for your hard work though fellas!) Serious Question though: I thought we were supposed to have greater FPS with Mac Premium Client, why do I have less? |
Fairhand
101st Covert Ops
C. O. R. E. |
Posted - 2009.03.22 08:58:00 - [ 6]
Thanks for the explanation, Transgaming - much appreciated.
Folks - I have updated my "Low FPS" thread to reflect the advice from Transgaming, so please read this post carefully then make sure you follow the config file advice. |
Verite Rendition
Caldari
F.R.E.E. Explorer
EVE Animal Control |
Posted - 2009.03.22 11:02:00 - [ 7]
Edited by: Verite Rendition on 22/03/2009 11:04:30 Originally by: TransGaming
7) Performance - Nonni system, POSes
We have attempted to reproduce results posted in this forum showing substantial performance deltas between Mac and Windows near player owned stations, but we have not seen any such difference. The station shown in Verite Rendition's screenshots at the Nonni 3-1 system are no longer there for comparison, but other test POSes we used did not show any such substantial difference. Based on the screenshots, we believe the likely culprit for the extreme performance difference seen is the number of 2D UI overlays for different objects in that scene.
The primary performance bottleneck for EVE on the Mac is CPU boundedness related to drawing UI overlay objects. This can be seen easily by pressing Ctl-F9 to hide all UI, then show it again - you will see a clear spike for the period when the UI is not shown. There are a number of causes for this bottleneck, and rest assured that both CCP and TransGaming are working to eliminate it.
We'd like to verify that Nonni system test case is indeed running into this UI bottleneck. Verite Rendition, can you please recreate the problem area in Sisi so that we can examine it in more detail?
Holy cow, someone actually read that? Anyhow, I'm sitting at the Nonni P3 M1 POS on Tranquility right now and it's still there, the same as it always has been. I appreciate the testing, and I'd encourage you to use this POS if at all possible. Setting up a similar POS is extremely time consuming, it takes me almost a full day of constantly fiddling with EVE to set up something similar on Sisi, which then gets wiped on a regular basis. It would probably be easier for a BH/dev to will a POS in existence on Sisi if you want to test it there because of the immense time factor. I suspect you're right about the cause, but I'll poke at it later when I get the chance. PS If you get the chance, ask CCP about bug report 73292. There's a long-standing issue with gamma on portraits that seems to only happen on a few NVIDIA hardware configurations that they haven't be able to adequately test |
Ami Nia |
Posted - 2009.03.22 12:41:00 - [ 8]
Thanks for posting. Despite what CCP may have told you  we DO want feedback from the developers. Personally I think posting with a personal alias instead of a "company wide moniker would have been better. But most important thing is that you posted. Originally by: TransGaming
Internally, we refer to this as the Avril Lavigne issue (see http://www.eveonline.com/ingameboard.asp?a=topic&threadID=728646 for why).
ZOMG, you actually adopted that name. I remember having to pee for laughting too hard when that message was posted. Originally by: TransGaming
Lastly, some users have been experimenting with Cider config file changes recently, but without knowing what some of the changes they are suggesting actually do. We do not recommend that users make modifications to this file, and future updates are likely to overwrite any changes that you make. That said, it is perfectly ok to experiment with config changes, so long as you recognize that they may cause unforeseen problems.
I fully understand that you do not recommend changing those settings (or any settings). But at the same time I must say one thing that I dislike is not having documentations for those. I do not like having to resort to the Wine documentation or to the (old?) Cedega documentation. Much less having to "guess" them from the names (I knew what OpenGL feature they referred to, but not how you used them. And I did not dig into the original Wine docs/code). I think this is Cider. Not Cedega nor Wine. I think YOU should provide some docs, even if generic/game agnostic. If there's something like that on your site, I did not find it and a pointer would be appreciated. I know you explained what some of those do in this very thread. But why did you wait for us to "poke" you with experiments? Originally by: TransGaming
"Desktop" = "N"
Changing this to a value such as "1024x768" will force EVE to start in a Window instead of fullscreen.
Is the string used for the resolution? Is it actually parsed somehow or is it just a binary toggle? What values are actually parsed/checked and have a real meaning? Also: what is the interaction between "Desktop" and "Fullscreen"? Is the latter now obsolete? What values are parsed/checked for the latter. It seems that they tend to override each other. Originally by: TransGaming
"MultithreadedGL" = "0"
Changing this to "1" will make the OS try to run all OpenGL operations on a separate thread. Currently not likely to improve performance, and will likely in fact decrease it right now. Once some of our further UI performance improvements are in place, this may change.
Apple is, AFAIK, the only OpenGl implementation that actually does support multithreading. There still are some problems but this is already usable and can potentially lead to great performance enhancements. I do not know Direct3D enought to be able to guess if it will let you exploit this or not, but it may be. And another very interesting thing to watch out for is the work Apple is doing with OpenCL. I really hope you have a workgroup that is focussing on that sort of "future". |
Ami Nia |
Posted - 2009.03.22 12:42:00 - [ 9]
Edited by: Ami Nia on 22/03/2009 13:11:36 Originally by: TransGaming
"DynamicVBO" = "Y"
When this option is enabled, vertex buffers with dynamic data (IE: UI data) are stored in VRAM using OpenGL's Vertex Buffer Object extension, along with relevant extensions for updating portions of this data when they change (GL_APPLE_flush_buffer_range, etc). With this off, dynamic vertex buffers are handled through system memory instead.
Just a curiosity: are you doing double buffered dynamic VBO? Originally by: TransGaming
The reason that the DynamicVBO change may help goes back to the UI bottleneck. The UI system uses dynamic data extensively. When DynamicVBO is on, the way data is being flushed to the GPU (glBufferDataARB) appears to be causing the OpenGL drivers to allocate new VRAM space for the updated data, which can be a costly operation.
This is why I asked if you use double buffered dynamic VBO. And a more complete question would be: how are you checking that the GPU is done with the old data? Could that be the reason the buffer is reallocated? Are you using fences? Double VBO buffering? Unless someone (Apple? ATI? nVidia?) is doing something very stupid it should be possibile to update a buffer without reallocating it (as long as the GPU is not using it). Edit: there's an issue with a call to a pure virtual function in Cider that has been reported but you did not mention at all. Any news on that front? |
Akasun |
Posted - 2009.03.22 17:24:00 - [ 10]
First of all, thank you for informing the mac users of the status of cider and eve online. Many of us want to have a robust mac client and are willing to provide any debug help we can. From your description of the problems, I see that you might be able to benefit from the increased sample size provided by us. In particular, would it be possible to provide us w/ debug versions of the client that enable us to provide you with more detailed logs of issues that might be occurring?
For example, the texture misload problem is very common on my system (early 2008 MBP w/ 128MB 8600M GT). I usually resolve it temporarily by changing a graphics option and forcing a reload that way. I am sure many of us would be perfectly fine with having a config option that lets us turn on a bit of extra debugging to help with figuring out what's triggering this.
Also, many of us experience repeated client crashes that require us to restart the window server/reboot the system to re-launch eve. In my case, this is with a full client download, not a patched copy. EVE runs fine for a number of hours and then will exit with a general exception. The system log is full of a variety of cider-related messages, including mmap failures, shmem out-of-range messages, and uncaught NSInternalInconsistencyExceptions. Some of these problems seem to be correlated with quiting the game normally and then relaunching it. Would debug options that provide more detailed information on the crash be helpful here?
Finally, have you thought about integrating a submit backtrace feature akin to Apple's "Send Report" feature to increase the number of useful logs sent to you? That way, you wouldn't have to rely on user's scrounging around for the relevant information and trying to figure out where to send it to. |
Ami Nia |
Posted - 2009.03.22 17:43:00 - [ 11]
Edited by: Ami Nia on 22/03/2009 17:44:52 Originally by: Akasun
For example, the texture misload problem is very common on my system (early 2008 MBP w/ 128MB 8600M GT). I usually resolve it temporarily by changing a graphics option and forcing a reload that way. I am sure many of us would be perfectly fine with having a config option that lets us turn on a bit of extra debugging to help with figuring out what's triggering this.
He already explained that the problem you are talking about is due to a bug in the Apple drivers. Transgaming knows exactly what is happening, there's nothing to debug any more about it. We have to wait for Apple/nVidia to fix the problem (uless Transgaming manages to find a workaround, but that is not a question of debugging). As for having more debug info, I agree that some more documentation on the available command line switches of Cider would be wonderfull. But we do not need any "debugging version". The version we have has all the needed debugging capabilities. Untill they provide more documentation, just run it with the switches that CCP Casqade provided us and attach the (zipped) log file to your bug reports. Originally by: Akasun
Would debug options that provide more detailed information on the crash be helpful here?
Hmm. You mean MORE detailed debugging options than those we get with "./cider -debugmsg +seh,+tid,+module,+debugstr" ? Well, I guess they'll tell us if they need more. Originally by: Akasun
Finally, have you thought about integrating a submit backtrace feature akin to Apple's "Send Report" feature to increase the number of useful logs sent to you? That way, you wouldn't have to rely on user's scrounging around for the relevant information and trying to figure out where to send it to.
They could do it if they wanted generic "runtime data". But it may be very hard to do for anything that results in a total crash of the system. Apple can do it for Applications, because Apple designes the Operating System (Transgaming cannot change the operationg system). Note that even Apple cannot "auto report" the operating system crashes (because there's no "super-operating-system to collect them). |
Akasun |
Posted - 2009.03.22 19:28:00 - [ 12]
Originally by: Ami Nia
He already explained that the problem you are talking about is due to a bug in the Apple drivers. Transgaming knows exactly what is happening, there's nothing to debug any more about it. We have to wait for Apple/nVidia to fix the problem (uless Transgaming manages to find a workaround, but that is not a question of debugging).
i understand that it's a driver problem. as i was saying, i was wondering if there were a way to get better information on the triggering mechanism to help with a workaround. providing additional information can potentially be useful in such situations. workarounds are very much a case of figuring out the exact sequence that causes a bad path to be followed and then carefully stepping around that. debugging is a critical component of finding out what that path is. Quote:
Hmm. You mean MORE detailed debugging options than those we get with "./cider -debugmsg +seh,+tid,+module,+debugstr" ? Well, I guess they'll tell us if they need more.
yes. it may be that specific debug information not provided by the generic cider logging facility can be useful in pinpointing a problem area. that's basically what i was asking about. Quote:
They could do it if they wanted generic "runtime data". But it may be very hard to do for anything that results in a total crash of the system. Apple can do it for Applications, because Apple designes the Operating System (Transgaming cannot change the operationg system). Note that even Apple cannot "auto report" the operating system crashes (because there's no "super-operating-system to collect them).
actually, panic backtraces are saved in nvram. you can then submit that on the subsequent reboot. while not 100% guaranteed, it usually works. it may be that the current application crash backtrace is good enough, but the default course is to submit that to apple. that introduces an intermediary into getting the information to transgaming. all the information is already there. it just currently requires the user to manually enable flags and then go searching around to find the relevant files/logs to package up for submission. that naturally increases the time and expertise barrier to helping resolve problems with the client. simplifying and automating the process of both the enabling of debug options and the subsequent submittal of a report means that more useful information can get generated to help with debugging and bug fixes. again, apple already does a similar more generic version of this for both application crashes and system panics. there's nothing that's preventing transgaming from doing something similar. i know i would find it immensely useful. hopefully, transgaming will also find it a useful avenue to pursue. |
TransGaming |
Posted - 2009.03.23 01:38:00 - [ 13]
Originally by: Fairhand
Folks - I have updated my "Low FPS" thread to reflect the advice from Transgaming, so please read this post carefully then make sure you follow the config file advice.
Note that your update gets it slightly wrong. The following changes should be reasonable: "DynamicVBO" = "N" "FBOBackBuffer" = "N" Disabling IndexVBO is most likely to make things slower if it has any effect at all, unless your system is somehow running into VRAM limits. If anyone can document a performance improvement with IndexVBO off, we'd be both surprised and interested in knowing details of what machine had that behavior. |
TG Maladara |
Posted - 2009.03.23 02:40:00 - [ 14]
Originally by: Verite Rendition
Holy cow, someone actually read that?
Well, there was a threat of violence. Always good to at least know *why* someone's coming at you with a frying pan before you take appropriate measures. Originally by: Verite Rendition
Anyhow, I'm sitting at the Nonni P3 M1 POS on Tranquility right now and it's still there, the same as it always has been. I appreciate the testing, and I'd encourage you to use this POS if at all possible.
My test character (TG Maladara) can't see the POS listed as a warp point in the system. Is the POS password required for that? CCP's GMs can probably move the character there at some point next week, but if you can provide whatever magic is required to allow us access the POS sooner that could be helpful. Originally by: Verite Rendition
PS If you get the chance, ask CCP about bug report 73292. There's a long-standing issue with gamma on portraits that seems to only happen on a few NVIDIA hardware configurations that they haven't be able to adequately test
I'll check that out; sounds a bit strange. |
TG Maladara |
Posted - 2009.03.23 03:20:00 - [ 15]
Originally by: Ami Nia
I do not like having to resort to the Wine documentation or to the (old?) Cedega documentation. Much less having to "guess" them from the names (I knew what OpenGL feature they referred to, but not how you used them. And I did not dig into the original Wine docs/code). I think this is Cider. Not Cedega nor Wine. I think YOU should provide some docs, even if generic/game agnostic. If there's something like that on your site, I did not find it and a pointer would be appreciated. I know you explained what some of those do in this very thread.
Modifying the config file is not something that an average Mac user should have to do, and is therefore not something that we document. For advanced users like you who know details down to the OpenGL level and want more info, it makes more sense to just have direct forum conversations like this one. In some cases, the details of what the settings do under the hood can change from one release to another. DynamicVBO is in fact one case of that, as we've recently made significant modifications to the code in question. Originally by: Ami Nia
But why did you wait for us to "poke" you with experiments?
We didn't, in fact. The usage of DynamicVBO and how the game is using dynamically generated geometry is one that we were already in the process of looking at closely for performance. To a certain degree, activating the DynamicVBO option may have been jumping the gun a bit for performance improvements that we're still working on, but our testing of the option did not reveal anywhere near the performance deltas that are being reported in the config thread here. In fact, these reported performance deltas from the config change are still rather confusing, and we'd really like to know more details for people who have experienced anything more than a 20-30% performance improvement for disabling DynamicVBO, IndexVBO, and FBOBackBuffer. IE: if you're seeing improvements like that, what is your hardware configuration (GPU, CPU, and VRAM), and what resolution and options are you running with. Originally by: Ami Nia
Originally by: TransGaming
"Desktop" = "N"
Changing this to a value such as "1024x768" will force EVE to start in a Window instead of fullscreen.
Is the string used for the resolution? Is it actually parsed somehow or is it just a binary toggle? What values are actually parsed/checked and have a real meaning?
This is parsed as Height x Width (no spaces), and when set it passes through to the game as the current desktop resolution. It does not add this resolution to the resolution list reported by the card, nor does it prevent the game from changing the window size to another resolution. It overrides the previously used 'Fullscreen' option, so "Fullscreen" = "N" and "Desktop" = "N" will still give you fullscreen mode, though "Fullscreen" = "N" with no "Desktop" line will give you windowed mode. Originally by: Ami Nia
Originally by: TransGaming
"MultithreadedGL" = "0"
Changing this to "1" will make the OS try to run all OpenGL operations on a separate thread. Currently not likely to improve performance, and will likely in fact decrease it right now. Once some of our further UI performance improvements are in place, this may change.
Apple is, AFAIK, the only OpenGl implementation that actually does support multithreading. There still are some problems but this is already usable and can potentially lead to great performance enhancements. I do not know Direct3D enought to be able to guess if it will let you exploit this or not, but it may be.
Multithreading GL has some potential for improving performance, but its effects are pretty complicated. More below. Originally by: Ami Nia
And another very interesting thing to watch out for is the work Apple is doing with OpenCL. I really hope you have a workgroup that is focussing on that sort of "future".
We are contributing members of Khronos, the group that defines both OpenGL and OpenCL and how they interact. |
TG Maladara |
Posted - 2009.03.23 04:01:00 - [ 16]
Originally by: Ami Nia
This is why I asked if you use double buffered dynamic VBO. And a more complete question would be: how are you checking that the GPU is done with the old data? Could that be the reason the buffer is reallocated? Are you using fences? Double VBO buffering?
For the most part, double (or other) buffering of dynamic data, and the use of fences is an app level choice that we do not have control over. The app passes various flags as it locks and unlocks vertex buffers, indicating the ranges of data that are being changed, whether the data is being read-back, or only written to, etc. Underneath Cider, the GL implementation and/or the driver has its own responsibilities for handling different kinds of buffer updates. That said, we do have some control over this in one area where we know there is a bottleneck, which is the D3DX Sprite system. Our implementation of D3DX Sprites uses the D3DLOCK_DISCARD flag when locking its output buffer each frame, indicating that it's providing an entire buffer full of new data. Underneath the D3DX layer, we then note the fact that the discard flag has been set, and fill the whole buffer using glBufferData. At the driver level, the driver is responsible for 'orphaning' any in-flight data from the buffer, and providing some GPU memory for the new data. Since the GL-level VBO has already been marked as being dynamic, one would have expected the driver to be able to handle this efficiently with, but that seems to not be the case. Note that the 'allocation' I'm speaking of here is the driver-level allocation of GPU memory, not the creation or deletion of high level VBO objects. To avoid the driver level inefficiency here, we will likely be moving to a ring buffer approach at the D3DX Sprite level, using fences to avoid overwriting in-flight data. That will then translate into a ranged buffer flush on a mapped VBO at the GL level. Once this is in place, enabling Multithreaded GL should provide some performance improvement, as there should be fewer (hopefully no) 'sync points' that require the calling thread to wait for the GL thread. With DynamicVBO off, or when using glBufferData, the calling thread has to marshall the changed data over to the GL thread, which requires a large data copy, and/or a sync point. Hopefully Apple has fixed things such that simply testing a fence doesn't require a sync point, as it has previously. We'll see. Originally by: Ami Nia
Edit: there's an issue with a call to a pure virtual function in Cider that has been reported but you did not mention at all. Any news on that front?
We've seen that error a couple of times as well. Cider does not itself use C++, and the error is coming from the C++ runtime system, which means that it is game-level code that is hitting this error. There do appear to be other reports in the forums of this being hit on Windows too. |
TG Maladara |
Posted - 2009.03.23 04:31:00 - [ 17]
Originally by: Akasun
i understand that it's a driver problem. as i was saying, i was wondering if there were a way to get better information on the triggering mechanism to help with a workaround. providing additional information can potentially be useful in such situations. workarounds are very much a case of figuring out the exact sequence that causes a bad path to be followed and then carefully stepping around that. debugging is a critical component of finding out what that path is.
We have a frame recorder/replayer system that we use as much as possible when submitting bugs to Apple/ATI/NVidia so that they can look at the problem in relative isolation, and we already have a multi-frame snapshot recording that shows the bad-texture issue in a fully reproducible way. We've stepped through it draw-call by draw-call with Apple's GL Profiler attached. The GL profiler shows the correct data in the texture (and it's correct if we read it back from GL at the app level), but the wrong texture is somehow drawn on screen. At this point, there's not much more that even we can do with this. Originally by: Akasun
actually, panic backtraces are saved in nvram. you can then submit that on the subsequent reboot. while not 100% guaranteed, it usually works. it may be that the current application crash backtrace is good enough, but the default course is to submit that to apple. that introduces an intermediary into getting the information to transgaming.
Anything that takes down the machine is, by definition, an issue that Apple needs to deal with. Nothing that happens at the user application level, where Cider executes, has the ability to directly take down the system. That can only happen when there is a driver-level problem. That problem may be provoked by something at the application level though, and when that happens it's usually more useful to have a reproducible case for what triggered the problem than a panic log afterwards. Certainly there's little or nothing that we can do with a panic log, since these show the Kernel-level stack trace For application-layer level crashes, Apple's standard crash reporter is not particularly useful for us, as it can't show a Win32-side stack crawl. Thus we've spent quite a bit of effort improving the DbgHelp library to provide information on both the Win32 and Mach sides of a crash in a minidump. Eve uses this system already, and in some cases it can provide useful feedback in crash log files that the game writes deep inside the preferences directory. There are of course some things that we'd like to do to make this better and more user-friendly in the future, including changing where the debug dumps are written to. Some of that we can do ourselves, and others will require some detailed coordination with CCP. |
Ami Nia |
Posted - 2009.03.23 07:29:00 - [ 18]
Originally by: TG Maladara
Originally by: Verite Rendition
Anyhow, I'm sitting at the Nonni P3 M1 POS on Tranquility right now and it's still there, the same as it always has been. I appreciate the testing, and I'd encourage you to use this POS if at all possible.
My test character (TG Maladara) can't see the POS listed as a warp point in the system. Is the POS password required for that? CCP's GMs can probably move the character there at some point next week, but if you can provide whatever magic is required to allow us access the POS sooner that could be helpful.
I did not try to go there but ... POSes are not warp in points. Passwords are used to *enter* the POS forcefield, but are not needed to go close to it (and an hisec POS should not fire on you unless you are at war with the corp tha holds the POS). Nonni P3 M1 is player shorting for Nonni Planet III moon 1, aka Nonni III-1. Nonni is in northwestern caldari empire (in Lonetrek) on a flattened map. Set course to Nonni and then warp to the first moon of planet 3 and you should be able to see it (enable all brackets in overview if needed). Disclaimer: I did not try to go there as I'm a bit far, but if Verite says that's where it is, I guess it is there. |
Ami Nia |
Posted - 2009.03.23 07:51:00 - [ 19]
Originally by: TG Maladara
Originally by: Ami Nia
I do not like having to resort to the Wine documentation or to the (old?) Cedega documentation...
Modifying the config file is not something that an average Mac user should have to do, and is therefore not something that we document. For advanced users like you who know details down to the OpenGL level and want more info, it makes more sense to just have direct forum conversations like this one.
Sure it's not for average user. But even if Cider is "personalized" on an app-by-app basis, the cider use of those should be more or less the same across apps. What I suggest is that you document the basis of those on your own site. It would even benefit as a technical overview for potential customers that has not yet benn in contact with you. As for "direct forum conversations" ... we players are ALL for those. It's not that CCP/TG have been too chatty (forumy?) in the past, however. Suppose I asked questions about these settings 18 months ago, would have someone responded (except maybe some CCP saying: leave them alone)? If you say yes ... prepare for question threads in the upcoming months, from more than one "tech savvy" user. Originally by: TG Maladara
In some cases, the details of what the settings do under the hood can change from one release to another. DynamicVBO is in fact one case of that, as we've recently made significant modifications to the code in question.
Of course. And while most tech savvy people know what "Dynamic VBO" means, how much (or what for) you are using it in Cider (in the different versions of Cider) is what is missing. But frankly, Dynamic VBO is pretty much self explanatory anyway, there are a lot of settings that are less obvious (like the fullscreen settings, for example). Originally by: TG Maladara
Originally by: Ami Nia
But why did you wait for us to "poke" you with experiments?
We didn't, in fact. The usage of DynamicVBO and how the game is using dynamically generated geometry is one that we were already in the process of looking at closely for performance. To a certain degree, activating the DynamicVBO option may have been jumping the gun a bit for performance improvements that we're still working on, but our testing of the option did not reveal anywhere near the performance deltas that are being reported in the config thread here.
In fact, these reported performance deltas from the config change are still rather confusing, and we'd really like to know more details for people who have experienced anything more than a 20-30% performance improvement for disabling DynamicVBO, IndexVBO, and FBOBackBuffer. IE: if you're seeing improvements like that, what is your hardware configuration (GPU, CPU, and VRAM), and what resolution and options are you running with.
I think we should make a separate thread with a list of what should be tested. And I think this sort of things should be done on SiSi (expecially after you tweaked some code). This time around there was a hard schedule (aren't them all?). But a SiSi patch with a post "please test these and these settings", while probably not getting as much feedback as a troublesome TQ deployment, may actually get you some early feedback. |
Fairhand
101st Covert Ops
C. O. R. E. |
Posted - 2009.03.23 08:02:00 - [ 20]
Originally by: TransGaming
Originally by: Fairhand
Folks - I have updated my "Low FPS" thread to reflect the advice from Transgaming, so please read this post carefully then make sure you follow the config file advice.
Note that your update gets it slightly wrong. The following changes should be reasonable:
"DynamicVBO" = "N"
"FBOBackBuffer" = "N"
Disabling IndexVBO is most likely to make things slower if it has any effect at all, unless your system is somehow running into VRAM limits. If anyone can document a performance improvement with IndexVBO off, we'd be both surprised and interested in knowing details of what machine had that behavior.
I will make time today to clean out my preferences directory and repeat the testing using a clean rebooted machine - it shouldn't take long. |
Verite Rendition
Caldari
F.R.E.E. Explorer
EVE Animal Control |
Posted - 2009.03.23 08:33:00 - [ 21]
Edited by: Verite Rendition on 23/03/2009 09:19:10 Originally by: TG Maladara
Originally by: Verite Rendition
Holy cow, someone actually read that?
Well, there was a threat of violence. Always good to at least know *why* someone's coming at you with a frying pan before you take appropriate measures.
Originally by: Verite Rendition
Anyhow, I'm sitting at the Nonni P3 M1 POS on Tranquility right now and it's still there, the same as it always has been. I appreciate the testing, and I'd encourage you to use this POS if at all possible.
My test character (TG Maladara) can't see the POS listed as a warp point in the system. Is the POS password required for that? CCP's GMs can probably move the character there at some point next week, but if you can provide whatever magic is required to allow us access the POS sooner that could be helpful.
Originally by: Verite Rendition
PS If you get the chance, ask CCP about bug report 73292. There's a long-standing issue with gamma on portraits that seems to only happen on a few NVIDIA hardware configurations that they haven't be able to adequately test
I'll check that out; sounds a bit strange.
I suspect you don't play EVE, which is okay. It's also why you'd seem to be so confused. POS stands for Player Owned Structure. The S is not Station, so it's not going to show up on the station list because it's not a station; it's more like a giant protective bubble floating in space. POSs can only be set up at fixed locations - that is in orbit of a moon. So whenever we talk about POSs, we're talking about the planet and moon they are anchored in orbit of. And they don't directly show up on any menu, the only way you know if they are there is if you warp to the moon that a POS may be anchored at. If you bring up the Planet list and then the Moon sublist for Planet 3, you can warp to the 1st moon of Planet 3. The POS is anchored at where you warp in. I'll have one of my alts (The Pilgrimage) contract you a bookmark, just in case you can't find your way around. --- As for the matter at hand, I stopped by the POS quickly and took your advice about ctrl-F9. Reading the FPS chart from the game immediately after turning the UI back on, it's reading 46fps or so. More to the point, CPU usage while the UI is off drops to 80% of a core. Clearly you are right in that drawing the UI elements is causing a good deal of CPU overhead. As for the bug report on gamma levels in portraits, I've finally gotten around to filing an update to it, if you ever get around to it. I'm starting to suspect it's a driver bug, so I'm not sure if you'll be able to do anything about it. Here are the Windows and Mac portrait captures I attached to the report, if you want an early preview. |
Ami Nia |
Posted - 2009.03.23 08:39:00 - [ 22]
Originally by: TG Maladara
This is parsed as Height x Width (no spaces), and when set it passes through to the game as the current desktop resolution. It does not add this resolution to the resolution list reported by the card, nor does it prevent the game from changing the window size to another resolution. It overrides the previously used 'Fullscreen' option, so "Fullscreen" = "N" and "Desktop" = "N" will still give you fullscreen mode, though "Fullscreen" = "N" with no "Desktop" line will give you windowed mode.
Gotta test if EvE is going to change the resolution to one of those reported by the card or not. Probably yes. You do know a lot of people is been crying for a way to have variable resolution windowed mode, right? For the moment it seems the best bet it to try tweaking the system with SwitchResX. Originally by: TG Maladara
Originally by: Ami Nia
And another very interesting thing to watch out for is the work Apple is doing with OpenCL. I really hope you have a workgroup that is focussing on that sort of "future".
We are contributing members of Khronos, the group that defines both OpenGL and OpenCL and how they interact.
Good. And I assume you are looking closely to the Apple LLVM ideas to go beyond GLUT. I expect all that to be a PITA to begin with (as multithreaded OpenGL is). But the ideas are still very very promising. Originally by: TG Maladara
<tecnical stuff abut Direct3D sprite implementation>
As I wrote, I'm not familiar at all with Direct3D. Now that you mention it, it makes sense that they do have fencing too, so for the most part you cannot control it but obey the end-app code (except of course evaluate the code paths with your client and eventually suggest alternatives that are better on Mac and still good on Win). But sometimes (sprite?) you do have more room for choice. Me too suspect the driver is simply internally ramapping the VBO handle to a new chunk of VMEM when you do the glBufferData flush. But that is not totally unreasonable: if you are rewriting the whole buffer content of a dynamic buffer while the GPU is still using the old content, remapping the handle to a new buffer and leaving the old data to the GPU (will be freed up when it's done, if there's no driver level bug) is generally the best thing to do for the driver. In these cases preallocating two buffers and using them alternatively (double buffering) will generally let you access one while the GPU accesses the other. The driver does not need to reallocate each time (of course an inefficiant driver may still reallocate, but this time it needn't to). The alternative is the MapBufferARB ring buffer with fences and partial flushes, which is what you are thinking of. Only you know which of the two ideas is easier to implement in your case. It's been a while since I actually did any OpenGL, but I'd experiment a bit with both MapBufferARB ring buffer, STREAM_DRAW_ARB marked double VBO buffering, and DYNAMIC_DRAW_ARB marked double VBO buffering (as the buffer is not updated every frame, there may be differences in stream/dynamic marking behaviour). |
Fairhand
101st Covert Ops
C. O. R. E. |
Posted - 2009.03.23 09:02:00 - [ 23]
Transgaming - I repeated my config file test for you and here are the results. The only differences between today and the last time I ran the tests are that I was in a different system and ship and have upgraded the RAM on my iMac.
===
Test System : Mid-2007 iMac 24" 2.8GHz dual core, 4Gb, ATI HD2600PRO 256Mb running OS X Leopard 10.5.6. All user applications closed.
Game Settings : 1920x1200, Display Setup all options default. Effects all on. Miscellaneous Use LOD and Sun Occluded on, others off. Graphics Content all disabled, cache off. Shaders Medium, Textures Medium.
I deleted the Eve preferences folder before starting the test AND between each test so that there were no cache issues. I took readings zoomed in behind the ship as it undocked and again slightly zoomed out panning round to give a range of FPS values. Local traffic was VERY light.
===
Default : 30-32 FPS
IndexVBO = "N" : 45-55 FPS
DynamicVBO = "N" : 50-55 FPS
FBOBackBuffer = "N" : 35-45 FPS
All three settings together : 70-75 FPS
I hope these results help you (and other Mac users) work out default config file settings for the short term, and then identify code changes in the long term. |
Verite Rendition
Caldari
F.R.E.E. Explorer
EVE Animal Control |
Posted - 2009.03.23 09:32:00 - [ 24]
Edited by: Verite Rendition on 23/03/2009 09:44:44 Originally by: TransGaming
Originally by: Fairhand
Folks - I have updated my "Low FPS" thread to reflect the advice from Transgaming, so please read this post carefully then make sure you follow the config file advice.
Note that your update gets it slightly wrong. The following changes should be reasonable:
"DynamicVBO" = "N"
"FBOBackBuffer" = "N"
Disabling IndexVBO is most likely to make things slower if it has any effect at all, unless your system is somehow running into VRAM limits. If anyone can document a performance improvement with IndexVBO off, we'd be both surprised and interested in knowing details of what machine had that behavior.
This is more of a comment than feedback, but the idea that a system is running in to VRAM limits is actually a pretty reasonable idea. Mac OS X is a VRAM hog, and hardware review sites like AnandTech have noted that this can occur in particular when a lot of windows are open. I would not be shocked if the base VRAM usage of Mac OS X is high enough that it's absolutely mauling 128MB setups, and leaving a less than ideal amount of VRAM free for 256MB cards. --- As for some actual benchmark feedback, even on my high-end Mac Pro '08 with an 8800GT, for the POS test disabling DynamicVBO gets the frame rate up from 36fps to 44fps (22% improvement) or so with the UI on, and no effect with the UI off. Disabling IndexVBO is inconclusive - if there is a difference, it's hard to tell from experimental variation. |
Ami Nia |
Posted - 2009.03.23 12:24:00 - [ 25]
|
Ami Nia |
Posted - 2009.03.23 12:25:00 - [ 26]
Originally by: TG Maladara
We have a frame recorder/replayer system that we use as much as possible when submitting bugs to Apple/ATI/NVidia so that they can look at the problem in relative isolation, and we already have a multi-frame snapshot recording that shows the bad-texture issue in a fully reproducible way.
You are talking of a GL calls level recorder, I guess, not a "movie" recorder. This is totally unrelated, but one thing that I've been always puzzled about is this: why not embedding a GL level recorder in the game engines? Compared to an external screen recorder it should be able to "dump" a pretty small file while using much much less resources, leaving more to the actual game engine. It would be very usefull in several ways: 1) post mortem debugging of some critical cases. 2) a player capable of replaying on the same machine should be easy to do. 3) a player capable of rendering it to whatever video format on the same machine should also be easy to do (maybe even a codec!). 4) depending on how "specific" the saved data is, it may be possible to make it playable on other machines or to render it at non-original resolutions. But I do understand this is more complicated, expecially because most games would have actually done things differently on different machines. Given the peculiar position of Transgaming, I'd seriously consider this as a possible feature of your products (and even open up a market for a separate product). Originally by: TG Maladara
Anything that takes down the machine is, by definition, an issue that Apple needs to deal with. Nothing that happens at the user application level, where Cider executes, has the ability to directly take down the system.
Sure. Applications like Parallel's and VMWare do install kernel drivers/extensions, and are a different story alltogether. But you only operate at user level and a total lockdown should not be possible. However ... this is both true and false for several reasons. Including the fact that a locked up system may not be really a locked up system (in the sense that IF there was a high priority server process in the background that process may be still able to run and potentially able to kill user processes that are misbehaving). However the most important point is that if Cider+EvE regularly end up in some sort of lockup or do manage to leave the system in an unstable state, even if the OS and drivers DO have bugs and that should not have been possible, you still need to address the problem from your side and try to pinpoint where the problems are and avoid the codepaths that bring the system there. Originally by: TG Maladara
For application-layer level crashes, Apple's standard crash reporter is not particularly useful for us, as it can't show a Win32-side stack crawl. Thus we've spent quite a bit of effort improving the DbgHelp library to provide information on both the Win32 and Mach sides of a crash in a minidump. Eve uses this system already, and in some cases it can provide useful feedback in crash log files that the game writes deep inside the preferences directory. There are of course some things that we'd like to do to make this better and more user-friendly in the future, including changing where the debug dumps are written to. Some of that we can do ourselves, and others will require some detailed coordination with CCP.
Yes, I know you do this. It's not actually too deep in the preferences folder: I found it and have atached it to at least one bug report I did sometime last year  What I do not understand is why the hell CCP never pubblically documented the existance of that file and never requested us to attach it to bug reports. It may be related to the fact the file is not cleared up and many users would end up attaching the dump of an unrelated crash or somethig like that. Which is why when I find a way to reliably reproduce a problem, I reproduce it with a brand new installation and manually cleaned preferences before reporting it. |
Zakgram
POW ZAP THWAPP
|
Posted - 2009.03.23 13:03:00 - [ 27]
Other suggestions:
Interval one. Anything other than Interval immediate! Is there any point having the cpu race to 100% all the time rendering more frames than the graphics card is displaying?
Can we get a fully supported window mode? Cmd-enter is fine and adjusting the resolution once done works but various objects don't get redrawn to cope with the changed screen size, specifically the sections at the bottom of the screen (undock and corp hangar access, for example), even with window mode screen resolution adjusted.
|
Blind Aggression |
Posted - 2009.03.23 13:56:00 - [ 28]
Seems to be simpler to wait which problem solutions the community brings out and then a topic to open in that all the information of the last weeks to be gathered also a few additional technical information are however not really helpful.
We hope...
We hope...
We hope...
I hope u know that we already hope longer. A little more real support and clear announcements would be probably more helpful.
Thanks to all, which thought in the last weeks on it. Thanks also at CCP, for the wonderful support in this time.
|
Ami Nia |
Posted - 2009.03.23 15:03:00 - [ 29]
Originally by: Zakgram
Other suggestions:
Interval one. Anything other than Interval immediate! Is there any point having the cpu race to 100% all the time rendering more frames than the graphics card is displaying?
I too do not see a reason for Interval Immediate. But I think this is something for CCP not for TG: that's not a Cider setting, it's EvE. Originally by: Zakgram
Can we get a fully supported window mode? Cmd-enter is fine and adjusting the resolution once done works but various objects don't get redrawn to cope with the changed screen size, specifically the sections at the bottom of the screen (undock and corp hangar access, for example), even with window mode screen resolution adjusted.
The problems with object positioning (if I understand what you are talking about) is something that CCP should take care of, not TG. TG has written that the value we set for "Desktop" in the [sdldrv] section of their config file is reported to EvE as the currently active resolution. Unfortunatelly EvE ignores it and queries the available fullscreen settings then setup itself to one of those. Reporting non-existing resolutions from Cider is not a good idea because they must handle the calls for those they report (yes, I know something like what the ResX tool does could be done, but that has its own problems and I doubt TG/CCP want to open that sort of pandora box). I've been thinking what Cider could do in this regard to improve the situation without having to radically change the way things are done now and without forcing EvE code to be redone (one problem here is that Cider cannot easily change the resolution itself unless EvE actually processes full screen resolution changes from the operating system). If EVE does parse those windows messages, then windowed Cider could use them to enable resizable windowed mode. But if it does not ... ... the next best way would be to enable some sort of personalized fake resolutions. One idea that should not be too complex to implement would be to add a "AdditionalDesktops" key to a setting file, supporting a list of resolutions. Those would then be reported to EvE as if they were actual full screen resolutions (filtering out those bigger than the actual maximum one). They would then be used as they are for windowed mode. In actual fullscreen mode the next highter resolution would be used and the rendering done in a reduced area with black bands filling up the rest. Not ideal, but probably somewhat easy to implement. However ... CCP reported that they are working on better multimonitor support. And that means they are going to rewrite a lot of code that has to do with resolution management and similar stuff. I'd reccomend CCP and TG to closely review the options here so that both Windows and Mac users can get the best possible implementation of the redesigned client. |
Serpents smile |
Posted - 2009.03.23 15:44:00 - [ 30]
Originally by: Blind Aggression
Thanks for the fish... BS.
You know the phrase; 'damned if they do and damned if they don't'? If you don't have anything constructive to add why don't you just stay silent. This is by far the best thing that has happened since the release of the Mac EVE cider client. Transgaming actually corresponding with the Mac community. The last thing we need is unfounded rabble like yours. They TG & CCP are working on it. If you think CCP just uploaded latest expansion and then went for a vacation.... Well, sux to be you. |
|
All Channels
Macintosh
