janwas

Interesting, thanks for the data. Looks like 9 people with the TSC (though the 1.5 GHz one is quite a low frequency). The vast majority is apparently running Linux, which reports 1 GHz. Also interesting - they probably scale the TSC. 4 are using the HPET - unsure whether on Linux or via Aken (and one of them has the frequency hopping thing enabled, which is why it doesnt exactly hit the frequency of the classic PC master clock). 2 using PMT, which is rather buggy and bad. It'd really be good to combine this data with OS. Then we've got (most likely) 4 Windows users where QPC is returning TSC/1024. 2 poor guys are most probably using our TGT fallback - that's the one with miserable millisecond resolution and the falling-behind bug. This is regrettable - I'd love to ask them what hardware they are on. Can we get at that data? Finally, we have 4 people with 1 MHz (why aren't they combined into one bin) - not sure what that one is, probably Linux again. It looks like 2(PMT)+4(scaled TSC)+2 TGT out of ~15-20 Windows users would benefit from HPET (the ones with scaled TSC only slighty). Does seem worthwhile for them. Interestingly, the majority is running Linux (or Mac, I have no idea what they report). Really do need the OS info to draw a conclusion

True. It's on the back burner for now as I've already left for Singapore; we'll see what the new employer's policy is. And yes, naming is especially hard for this kind of miscellany. jwlib isnt so bad, cbloom appararently reached the same conclusion with cblib Cool, thanks! I am looking forward to seeing this data.

Yes, just to expand on this a bit - there would probably be some additional pain due to byte alignment and endianess (PPC is stricter/different on both counts). That's why we have always assumed only x86/x64 would be supported.

To expand a bit more on Philip's entirely correct reply: The message just means the platform/BIOS does not provide a HPET, so activating it understandably fails r10858 will indeed stop this from appearing, because we would no longer even check for the HPET (unless the user takes additional action by invoking aken_install.bat). I am not sure why the error code isn't resolved into an error string - that's worrisome and will be investigated tomorrow.

Cool, glad you fixed it I am a big believer in symbol information in general. It is apparently possible to force a PDB to match: http://stackoverflow.com/questions/744870/how-can-you-change-an-age-mismatched-pdb-to-match-properly That looks too crazy even for my taste, though, so it'd be nicer to always commit PDBs of any code of ours that might possibly crash I don't think the AtlasUI symbols depend on wxW - did you have any particular problem in mind?

Thanks for mentioning so. That is indeed the expected behavior on Win7 x64. The error message is misleading or false in that the driver is not unsigned - it is just not signed with a special Microsoft certificate. You can work around it by enabling test mode (see aken_install.bat) or launching the game with the -wNoMahaf command line switch or updating the game to the most recent SVN revision, which no longer attempts to start the driver. (It will still be accessible if you have used aken_install, though.)

OK. If it's difficult to repro, perhaps we can see the problem from this crashdump once the symbols are available. It's great that you posted it

Bummer, sorry to hear that. Presumably you were running with the latest binaries from SVN? Unfortunately we don't have symbols for AtlasUI.dll in SVN. @Philip - would you please add them?

I think it would be enough to just report timer_Resolution. (Incidentally, a colleague asked to namespacify timer.h, turning it into timer::Resolution etc - any objections?) The current code only allows choosing one timer (the best available) and it'd be a spot of a bother to get them all. However, we can still deduce a lot from that - presence of an HPET can be gleaned from the chipset (i.e. CPU), and I would recognize the other timers based on their frequency (because the CPU frequency is also known). Let me expand on the 1 ms. That's only if somewhat calls timeSetPeriod and speeds up the timer interrupts to 1 kHz, which can slow down the entire system by 10-15% and reduce "battery run time on mobile systems by as much as 25 percent" [http://download.microsoft.com/download/3/0/2/3027D574-C433-412A-A8B6-5E0A75D5B237/Timer-Resolution.docx] Certainly not an ideal solution, but it's still better than the default of 15 ms (!), which is just terrible. And I suppose the driver, while evil, may still be an attractive option on WinXP laptops with semi-decent graphics cards. As to falling behind, here's someone mentioning > 5 s slippage in about 30 minutes play (= 2777 ppm), which apparently took down their network protocol: http://osdir.com/ml/games.devel.windows/2002-09/msg00000.html That's FAR worse than thermal drift, which is on the order of 200 ppm for a really grungy oscillator, and maybe 20 ppm for a decent quartz. However, if the network protocol is quite robust to such things, then we can maybe forget about the slippage. I have no idea why the previously mentioned game had that problem, but doubt it was because the developers were idiots. Good point about the spirit of the GPL. As you can tell, I really hate the new driver signing hoops, especially because it's to prevent circumventing DRM (which is truly something that removes user control). As is, the driver was designed to provide all the requisite possibilities and therefore not require changes. Unfortunately that does bring the security issues with it :/ Changes to the driver are actually still possible - the current signature is no better (actually apparently worse) than some self-signing thing that could fairly easily be managed. aken_install would still need to enable test mode, and additionally just install a certificate. That said, I agree about the insecurity and scariness. Again, it comes down to how we balance that vs. battery life or timer problems. Maybe we'd be best served with some kind of opt-in thing, which is basically what aken_install already is. I have therefore disabled StartDriver by default in mahaf.cpp. Anyway, it certainly would be interesting to get that data on the number of people with bad timers. Would you please add timer_Resolution to the hwreport?

Thanks for joining the forum to post your concern! I imagine the similar winring0 library also removed most of its functions after version 1.3 for these same reasons. Let's begin with the signature. You will find it to be basically OK and trusted by a root certificate, so the driver's integrity and source can at least be established. However, Vista and Win7 have apparently started requiring an additional bit in the certificate, and I'm not clear on which. "Basic Constraints" and "Key Usage" are marked with an exclamation point, so those are probably the culprits. "Digital Signature (80)" looks OK - maybe they also want an additional one for kernel-mode drivers, but I haven't come across mention of this and don't see which of the other possibilities it would be. Basic Constraints is AFAIK used to limit the chain length, and I can't do anything about that. Indeed one problem we are facing is that the certificate is from Fraunhofer, but I will be leaving their employ within 2 weeks, having finished my PhD. We therefore cannot count on changes to the certificate or driver. Now let's look at the situation concerning driving loading. Due to the above issue, x86 Windows Vista and later will refuse to start the Aken service. The x64 versions of Windows are even more restrictive - they require signing with a additional "cross certificate". On all of these systems, the driver will not load unless the user disables CodeIntegrity checks (resulting in a warning ever time such drivers load) or enables test-signing mode (which aken_install.bat is equipped to do). The latter is also a security hazard in that it allows anything with a semi-decent (even self-signed) certificate to load. Ironically enough, the bone-headed attempts at securing the system by effectively disallowing independent drivers lead to less security. You will find a similar approach here: http://www.freeotfe.org/docs/Main/impact_of_kernel_driver_signing.htm On WinXP x86, the driver will actually load without user intervention - unless the command-line argument -wNoMahaf is given. That system is also where normal users' need for the driver is greatest, because the time source may only have a resolution of 1 or more ms (too low for game usage) and even fall behind over time. So, where to go from here? On the one hand, we could argue that WinXP is totally insecure anyway because everything basically runs as Admin. mahaf.cpp could easily examine the Windows version and act accordingly. We can also throw up our hands and say we'll do timing as badly as other games - though problems have been reported, at least we won't be alone. For example, -wNoMahaf could be made the default by means of a windows shortcut. It could also be done from within the game code, but hopefully in such a fashion that the apps at work don't need an EnableMahaf() call to be added. On that point - again, I will soon be switching jobs, and the new employer is quite careful with IP rights. It is possible that I will no longer safely be able to contribute to 0ad - that will need to be discussed with them first. (It would be a shame, because then the codebase - which I am sure will continue to see use - would fork and no longer be updated.) One final point - the driver is also used at work to provide access to the performance counters, some of which are not available in VTune/Parallel Amplifier (e.g. Nehalem uncore for bandwidth/memory controller measurements). This requires write access to the MSRs. Moving all the logic into the driver would be possible, but another huge change that won't happen quickly, i.e. within the next 2 weeks. So - what's y'all's opinion? How shall we proceed?

Hi! Unfortunately you'll need more than an integrated graphics card to run the game. It's most likely a video-related crash, possibly because the driver is erroneously reporting support for an extension we require. Please give it a try on a system with a dedicated graphics card and ensure your driver is up to date. If it still crashes, please also upload the .dmp file (very important for analyzing other types of crashes) and we'll have a look.

These questions are all directed at Philip, but maybe I'll save him some time IIRC, the shaders were intended to simplify the code and reduce the number of combinations that had to be implemented. Shaders sometimes decreased the performance, but can also lead to improvements vs. equivalent fixed-function stuff. I do not know the rationale for the OpenGL3+ extensions. They're not currently in use - perhaps only for completeness or for other applications. We could print the extensions, but I am wondering as to the intended application. It would be possible already to grep for ogl_HaveExtension and gather the list, and then match that against those reported in logs/system_info.txt . The capabilities database requires an analysis tool to be run on the server; that needs to be triggered manually, and I guess it hasn't been done in some time.

Let me add to that a little bit. The one-time conversion to DDS/S3TC is actually rather compute intensive if you care about quality, because it involves finding the optimal 2 colors for every 4x4 block, which is quite a bunch of combinations. If you suspect or would like to probe for other slowdowns, you use the TIMER_ACCRUE functionality documented at http://trac.wildfiregames.com/wiki/EngineProfiling . Anything that gets into the gigaclock range after a minute or two is something we should look at

A minor note on telling whether apps are 32-bit: you can see the Task Manager process listing. If "Image Name" ends in "*32", it's running in 32-bit mode. That applies to about half of the processes I currently have running, so we're in good company

That's a very good point. I don't see a way to get commented-out names into Doxygen. There are not THAT many unused parameters, but I agree they should be mentioned in Doxygen. The commenting-out idea is dead in the water as far as I'm concerned. Any ideas for better (but still short) names for the macros?