Jump to content

janwas

WFG Retired
  • Posts

    2.733
  • Joined

  • Last visited

Everything posted by janwas

  1. We appreciate your enthusiasm However, the technical infrastructure for translation also isn't ready yet. We used to have a rather complex system, which is in need of revamping/redoing.
  2. Ah, thanks for looking into this. I did double-check everything was up to date, as reported by SVN. Looks like the SVN state was indeed garbled, since it now works after a full checkout. The previously mentioned Windows fixes are now in.
  3. Let's not rush things, guys I'm seeing tons of in-game error messages when loading death canyon on Windows with a debug build fresh from SVN. From interestinglog.html: ERROR: JavaScript error: simulation/components/interfaces/Identity.js line 1 Error: Registering interface with already-registered name ()@simulation/components/interfaces/Identity.js:1 ERROR: CXeromyces: Parse error: in_memory_buffer:1: Element choice is empty [...] ERROR: RelaxNGValidator: Failed to compile schema ERROR: Can't find component type AIInterface ERROR: Invalid component id 0 [...] ERROR: GUI page 'page_session.xml': Failed to call init() function ERROR: JavaScript error: gui/session/session.js line 73 TypeError: g_Players[Engine.GetPlayerID()] is undefined init([object Object],(void 0))@gui/session/session.js:73 reallyStartGame()@gui/loading/loading.js:99 ERROR: JavaScript error: gui/session/session.js line 191 TypeError: simState is undefined checkPlayerState()@gui/session/session.js:191 onTick()@gui/session/session.js:153 __eventhandler91 (tick)([object Object])@sn tick:0 There is also an error reported by the self-test: TypeError: global["IID_" + name] is read-only ("Identity")@simulation/components/tests/setup.js:16 ()@simulation/components/interfaces/Identity.js:1 ()@simulation/components/tests/test_UnitAI.js:6 Other self-test issues (mostly related to mixing path separators) are fixed by the attached patch, which I'd rather not commit until the other things are sorted out. fix_test_and_refactor_status.patch
  4. I'm seeing this as well after a successful update - it looks like Ben just forgot to SVN add the file (an easy omission to make; after all, it works on the local machine ). Hopefully he'll see this thread soon.
  5. Wow, a treasure trove of comments Should be enough to keep us busy for quite a while, hehe. Can't confirm this one - the mouse is successfully captured in fullscreen mode here. Maybe they were running in windowed mode? (But the whole point of that is NOT to capture the mouse) Oops, that was probably due to some rather dodgy code in the name of "saving some time". Turns out to have been only ~150 us, so I've made it less dodgy locally. Will commit later once the LibError/Status thing is ready.
  6. Hi and thanks for looking into this! I've just committed a fix based upon your first proposal (it's sometimes nice to have a separate local variable to display its value when debugging - more convenient than shift+F11 and adding a watch on RAX). While at it, I've combined both functions into a template to avoid duplication.
  7. Agreed. My main concern here is the thesis and stuff at work that very much cares about throughput. However, I'd like to avoid forking the code. Nah, POSIX and Windows have scatter/gather IO, but that's for a single-file only (think DB). aio would enable such an optimization, but we dont't know the maximum number of pending IOs, so that's not workable. Yep, still on the wishlist. This is actually moving closer to done - our own (block) caching is one of the bigger obstacles. After removing them as planned here, I think we'd only need scoped locks in each of the vfs.cpp member functions. That begs the question which flavor of locks is to be used today. OpenMP doesn't allow scoped lock syntax, the SDL stuff is slow (not just a CRITICAL_SECTION), which leaves pthread_mutex (plus a mini scoped_lock wrapper). waio.cpp is now thread-safe; so is the new io.h, since it doesn't use global data. Sounds right to me. Adding those locks would be a matter of minutes; finding any remaining bugs, maybe longer But it'll have to wait until the other major changes are integrated in ~2 weeks (so, too, the ENSURE/ASSERT stuff). Agreed in principle, but we're currently only talking about the block cache. The file cache currently does satisfy some dozens of requests, so we should ensure those are cached somewhere else before removing it.
  8. Certain circumstances motivate further changes to our I/O foundation. i) the development of a new compression algorithm at work that runs circles around LZ / Huffman / arithmetic coders has greatly diminished my interest in using Zip archives for compression (they remain useful for reducing small-file overhead and seeks, though) ii) measurements made while writing the thesis chapter on image I/O indicate our code currently lags behind HD write benchmarks to an unreasonable degree. In particular, there is a decent bit of overhead due to splitting I/Os into blocks and adding caching functionality. The latter is most useful for Zip archives, and now provides little gain vs. the OS file cache because aio is disabled on Linux, and we're not doing any decompression in parallel with IO anymore. iii) Sector sizes are moving towards 4K and larger, and the optimal block size/queue depth parameters have definitely changed. What I have done and propose to integrate is: 1) pull out all the stops, completely rewrite waio.cpp, including several crazy (in the sense of "who would actually bother to do this") but legal and documented optimizations. This enables a HIGHER (3..10%) throughput than reputable benchmarks such as ATTO and AS SSD on hard and solid state disks. 2) also completely rewrite io.cpp, which is the OS-independent wrapper on top of POSIX aio or waio that splits I/Os into chunks. Remove support for caching (aio doesn't need it, and sync I/O should rather use the OS cache), allow variable sector size/alignment/block size/queue depth, and add support for template based callbacks/hooks when IOs are issued (required for generating data on the fly) and complete (for overlapped decompression - used at work). IOs are described via io::Operation classes passed to io::Run. Unless non-default io::Parameters are prescribed, the IO will run synchronously. 3) update the remaining code to match the new interface; also changing the IO buffers from shared_ptr (which seems to trigger ANOTHER compiler bug in ICC 12.0) to a nifty new UniqueRange smart pointer. This is similar to C++0x unique_ptr with the addition of a size() member; the implementation provides simplistic but useful emulation of rvalue references in C++03. This should have the benefit of solving (by avoiding) the what-cache-size-should-we-use problem, probably increasing performance (synchronous I/Os can use FastIO driver entry points and are faster when the major benefit of aio - overlapping computation with IO - isn't needed) and stripping out some rusty, no longer used code. Unfortunately, new software usually includes bugs, though I will have tested the I/O logic at work beforehand. The interesting question is whether anyone foresees any problems with this approach, or disadvantages for 0ad or maybe even other codebases. I welcome comments here and will hold off from committing until back from vacation in 2 weeks (to leave time for discussion and be able to investigate any issues that might arise after integration).
  9. OK. But it's just like detective work - we've got to rule out the obvious stuff first. Duude! I can't hold your hand at every step of the way. AssociatedsubDirectory doesn't exist anywhere in the project, and as mentioned, we need to replace all occurrences of `directory' (the whole word) with subdirectory. The 2nd spot should read: if(!skipPopulate) { PRealDirectory rd; rd = subdirectory->AssociatedDirectory(); debug_printf(L"populating %ls\n", rd? rd->Path().string().c_str() : L"(0)"); RETURN_ERR(vfs_Populate(subdirectory)); rd = subdirectory->AssociatedDirectory(); debug_printf(L"populated %ls\n", rd? rd->Path().string().c_str() : L"(0)"); } Unfortunately, at this rate, the bug isn't going to be found *sigh*
  10. OK, but one additional source of errors is if the SVN checkout failed and didn't get everything. It's better to just update SVN normally unless the working copy is totally corrupted. Both the vfs_Populate and AssociatedDirectory calls there should reference subdirectory, not directory. Really?! The shaders are loaded in the same fashion as the hardware detection script - a path relative to the VFS root that contains exactly one directory. Can you verify binaries/mods/public/shaders/program.rng exists? There should be 27 regular files there plus the hidden .svn folder. What are these hardware detection script errors you're seeing - hopefully not "Failed to load hardware detection script"?
  11. Thanks, that one looks good except for maxError. Not sure why it's getting past the comparison against numeric_limits min and max. Could you add a if(!strcmp(name, "maxError")) debug_break(); before line 584 and verify 1) that that's the function from which it is displayed (static analysis, cued by the '%', says either that or the Handle specialization are the only possibilities) 2) check why the min/max comparison fails?
  12. (@Philip: Sorry about that crash - I've just changed it to always return a valid Structures, which I think was the original intent) hrm. I've double-checked the SystemSlot structure definition and a field was indeed missing. That explains the device/function numbers = 31 and 7, but the usage enum is not affected. Looks like we can't trust the in_use indicator, which is a major bummer.
  13. hrm. It looks like EFI is much less common than hoped, and I agree memory scanning (as root) is bad. Thanks for trying, though! Incidentally, it looks like Windows got this one mostly right. The GetSystemFirmwareTables API was expressly added to avoid the need for /dev/mem accesses. Update: historic_bruno: thanks for your log! Looks good - however, do you really have FIVE PCIe slots in use PLUS 2 PCI?
  14. OK, thanks. The "lookup: " information is helpful - it tells us the VFS path is valid. That particular file should exist - assuming you've recently done a successful SVN update on the entire repository, including binaries/. Now the question is: why are those files not being found? In the absence of a debugger, we can continue with printfs Please replace both instances of if(!skipPopulate) RETURN_ERR(vfs_Populate(subdirectory)); with if(!skipPopulate) { PRealDirectory rd; rd = directory->AssociatedDirectory(); debug_printf(L"populating %ls\n", rd? rd->Path().string().c_str() : L"(0)"); RETURN_ERR(vfs_Populate(directory)); rd = directory->AssociatedDirectory(); debug_printf(L"populated %ls\n", rd? rd->Path().string().c_str() : L"(0)"); } (in the second spot, you'll need to rename instances of "directory" to "subdirectory") Do these newly output paths exist on your machine?
  15. hm, I don't think this is worth additional complexity in the build system. As noted above, this only hurts if you're wanting to do some computation while waiting for the previous asynchronous I/Os to complete. We (and most other) applications don't, but stuff at work that shares this codebase does. However, it's Windows-only and not affected by the disabling, so I don't feel any pressing urge to change things.
  16. Greetings! I've added code to access the System Management BIOS information in r9195. Among other things, this tells us the approximate CPU frequency (required during timer initialization), memory clock and the exact size (the value reported by the OS is usually slightly off because some memory isn't reported). If you're curious as to what all this can report (and what hidden wonders lurk in your computer case), have a look at the bottom of %appdata%\0ad\logs\system_info.txt. I'd also appreciate if you would post your file here so I can sanity-check the values. Unfortunately this currently only works on Windows - it requires a small platform-specific part to retrieve the SMBIOS table. It looks like the address of the table is given in /sys/firmware/efi/systab ; the dmidecode project contains some code to peek at (can't be copied, though, due to GPL). Anyone up for implementing the equivalent of GetTable? It'd be nice to have access to this information on non-Windows systems as well.
  17. Use [ php ] insert_code_here [ /php ] tags (without the whitespace after [ and before ]). You really need to update the code from SVN - both timer and vfs_lookup have changed. In particular, subdirectoryName used to be a string but is now a VfsPath, which fixes your compile error.
  18. Thanks for editing the post These are generally bad news, so I've fixed it here. As to the compile error: I just noticed that you added the "not found" debug_printf to the wrong spot. We want to add it before the "return ERR::VFS_DIR_NOT_FOUND; // NOWARN" that is in the else branch of the if-statement that does "subdirectory = directory->AddSubdirectory(subdirectoryName);" That would be line 111 in the original SVN version.
  19. As you note, that'd be due to the fact that you're not using an archive, which aren't compressed in 0ad anyway. However, neither is true at work, so disabling AIO would hurt. As discussed, aio is now disabled (as if that patch were applied) on Linux.
  20. A temporary workaround is available in the other thread (http://www.wildfiregames.com/forum/index.php?showtopic=14561). Closing this one to avoid any confusion
  21. A patch for disabling aio is attached. Performance is going to suffer, but it should at least work (tested on Windows). disable_aio.patch
  22. Interesting to look at, thanks for that! I'm surprised only 50% have 2 GB of memory (vs. > 80% of Macs on the Steam survey). It's kind of silly that Linux is excluding paging overhead AND the kernel, but Windows also deducts non-paged pool. I've been wanting to get my grubby hands on the SMBIOS tables anyway, which include exact memory module sizes. There's a Windows 2003 SP1 and later API to retrieve them; amusingly enough, previous Windows versions can use Aken. We'd need something like http://cpan.uwinnipeg.ca/htdocs/DMI-Decode/DMI/Decode.pm.html on Linux (get the address via /proc/efi/systab and mmap). Would you be interested in writing/adapting that?
  23. Thanks for this report. I see the same thing - the first aio call announces itself with sched_getparam, and boom. Interestingly, this is preceded by "ERROR: Error initializing FAM" on stdout (our output). Do you have gamin installed?
×
×
  • Create New...