Jump to content

Worrazen

Members
  • Posts

    1786
  • Joined

  • Last visited

About Worrazen

  • Birthday 05/05/1994

Personal Information

  • Location
    Slovenia
  • Interests
    many!
  • Website
    http://www.techpowerup.com

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Yeah false alarm, I was opening it in LibreOffice Draw which took 1.8GB RAM, I think because it loads the whole PDF as an editable document and fully caches it into RAM, not just quick view. Opening in Okular or Foxit PDF Viewer on Windows takes less than 100MB.
  2. It does look like one yeah but, it open a page with a loading icon that spins forever and there's a small icon in right upper corner for download. It's Firefox for OpenSUSE (linux) Tumbleweed currently. ADD: Same thing happens on a much older Firefox on Windows 10
  3. Btw, perhaps replacing the PDF download with a direct file link, the preview link right now tries to open the PDF which at this huge size and complexity it'll probably never do in-browser, or it'll take a lot of RAM and lag a lot.
  4. Indeed, access to the airframe and/or cockpit would make it a lot more attractive because the 3D scanning can be imported into the 3D visual modelling software to speed up the process, taking less time and cost, and probably being more accurate than even what the blueprints would have explained.
  5. Yeah there is room for improvement in garbage collection, but it's general problem due to programming it self, C++ is such a programming language that requires manual garbage collection, it has to be programmed in, every bit of it. Don't worry about the "Standby Memory" or "RAM Cache", that's not the memory that will cause crashing, this is kept intentionally uncleaned by the OS or applications so that the next reads are faster. It get confusing if you try to dig deeper, it's a lot more complicated and the terminology doesn't mean what you'd first think it means, and it isn't consistent across the back-ends and GUI which adds to the confusion. If you fire up something else it'll drop unnecessary things automatically (it has some kind of an algortightm and rules which things to dump first, but I don't know how that is determined). If you get an actual crash you should report it, and record it or screenshot it, preferrably have multiple diagnostic utilities opened (process explorer, process hacker, task manager memory) while taking the screenshot when it crashed, and any error messages DCS might show. For DirectStorage, it's only for newer HW with updated Win10 and Win11, you don't need to turn it off, but you can't enabled it on games that don't support it, the developers have to patch games to add DirectStorage support. Either way DirectStorage won't work at full speed on Windows 10.
  6. https://www.khronos.org/events/vulkanised-webinar-february-2022
  7. When we say "The Vulkan API" we don't actually mean the raw API code alone, perhaps we're all not really using these terms correctly perhaps, but I think everyone out there uses the term API to refer to the whole pipeline with the drivers and all, so saying "Xyz API" does this and that, I'm talking about the whole environment, not just the raw API code. I guess perhaps the proper term would be to referr to it: "In a Vulkan API based environment" or "In a Vulkan API based application", but that's a mouthful. When you run a Vulkan based application, or in Vulkan mode, it won't use the same drivers as it does in DX11 or DX12. DX11 and OpenGL drivers where by because of the API it self, they have a completely different approach and require a lot more overhead from the start, and weren't designed for multi-threading the graphics backend (the graphics code that runs on the CPU). Vulkan's approach uses a "thin" driver that apparently does far less things under the hood and under the developer's radar, therefore also far more predictable and transparent in the stuff that it does, this is why it's harder to develop because many responsibilities shift to the application. https://www.intel.com/content/www/us/en/developer/videos/introduction-to-the-vulkan-graphics-api.html https://www.intel.com/content/www/us/en/developer/articles/training/api-without-secrets-introduction-to-vulkan-part-1.html One of the other things why legacy high-level APIdrivers are so bloated and require more CPU is because they run validation at all times for all end-users, with Vulkan API validation is optional. --------------------------------- As of right now, disclaimer I'm not a real Vulkan API or C++ programmer for that matter, I'm more of an analyst of the developer resource circles, going over the documentation and indeed spending hours reading it sometimes, various presentations, I spent many hours on reading up on Vulkan over the years. I don't completely agree with the earlier posts that the standard Vulkan API implementation out of the box does nothing without multi-threading. So CPU bound situations should definitely get some kind of a boost even if DCS wouldn't be getting the extensive multi-core enhancements across the board. The thin driver would immediately demand much less CPU resources by default, AFAIK. I can't find those slides right now but I distinctly remember that from the early presentations (That could have been Mantle API slides, but it should still apply to Vulkan). We would need a specific apple-to-apple comparison of an example Vulkan API implementation in single-threaded mode to a DX11 (ST) implmentation and compare just the driver overheads, which is what 3DMark "API Overhead" test might be all about. As far as games and sims go, who would bother going all the way to switch or add Vulkan API based rendering engine only to remain in single-threaded mode, so yeah, combining all of these things gets you some serious results in the end and it is very welcome that ED is taking a wholesome approach, multi-threading not only the graphics backend, but pretty much all the other major DCS components, and this is where a lot of the CPU improvements are. However as far as I know, again the cost of each draw-call is fundamentally much smaller with Vulkan API environment "it self", so hypothetically if you had all of this application multi-threading and kept "using" DX11 level of driver overhead and all of it's behaviors minus having that driver overhead stuck on one thread, maybe you could push much higher draw calls than standard DX11, but all of the CPU cores would get busier and thus less room to add other CPU work that the rest of the application could use. ----------------------------------- However, It remains to be seen to how much ED managed to split the various serial type of workloads, how much can be multi-threaded. I hope the AI logic calculations of each AI unit could have it's own thread or even threads, tho if they are expected to use very little CPU on their own for most of any kind of busy session, perhaps that wouldn't be necessary and a Unit Group could be it's own thread for example. That would get tricky when you have 100 units in one Unit Group tho, but I won't speculate on this right now, the approach could be totally different under the hood that takes care of my concerns here, dynamically spawning threads where needed, packing smaller jobs into threads, etc. Let's remember that many simulation type calculations cannot be parallelized, they will remain serial workloads even after all of the DCS multicore enhancements, a stream of calculations where the next one depends on the result of the previous one. Stuff like missile tracking, ballistic trajectory calculation and physics I think are serial and will remain serial workloads, but I suppose they don't all have to be on the same thread right, each weapon is independent and their tracking and physics simulation calculations could, but then there's the question of sync with the core engine for consistency and multi-player, so it's tricky how much of this can be independent. There surely would still need to be a kind of parent/main thread that connects all of this together otherwise you wouldn't have a working game, but it would have far less workload to do. I would appreciate if future reports would cover these questions as well. Would I be able to spawn 300x S-300 AA batteries and each unit would have it's own thread as per standard, then each missile launched would have it's own thread as well. Would that even matter in the end or would the engine always stall on something else first? But all of these small things could make a difference for really getting to be able to support those large dedicated server use cases, with a 128-core CPU and as much threading as possible maybe you could squeeze things out for a big mission, but then there are other things that are/would be parallelizable but may be too minor to make any difference in any kind of large scale mission, which would make that setup an overkill.
  8. Except Web is one hell of a platform to maintain, browsers keep changing things at a fast rate, generally Web and it's scripts are incredibly unreliable, depends on the skills and the environments, major sites may have no issues, simple sites either, but it's a very volatile environment. If it's all simple html then I guess it might work, but Mission Editor is going to go 3D, and that would mean trying to run DCS inside Browser, nah, possible, but it would be very impractical and inefficient for ED to deal with that on top of everything they have going on in terms of DCS codebase, legacy spaghetti code and stuff.
  9. I hope the modern displays/computer have an option for general font color, I still like green better over white for now.
  10. Appreciate the dirt airfields, that kind of auxiliary / emergency backup stuff is the stuff I like very much. Got a damaged A-10C, we probably won't make it back, but look there's that abandoned airfield there, might make a difference, if not rescuing the whole airplane anyway versus landing on pure raw dirt, it should increase chances of pilot survivability, more systems and cargo surviving, leftover fuel surviving, electronic cargo such as image or film perhaps etc. And to put these emergency gameplay use cases into actual use, the new DCS ground RTS systems part of the big so called Dynamic Campaign, has to support systems with such features in mind, so you could have several actions on the emergency landed aircraft in a dirt or otherwise runway, should be able to extract ammunition and use them elsewhere, extract fuel and use it elsewhere, extract undamaged cargo and finally even extract parts of the surviving aircraft fuselage or systems. You have a broken Jammer system on A-10C ... use the one from that stuck A-10C on that abandoned airfield, DCS Dynamic Campaign system AI commands an utility/repair truck to location (with escort) and you already have a logistics mission right there which can be a little side-story to the overall campaign, then get the spare Jammer and bring it back ... ofcourse you as a Pilot probably wouldn't participate in that if you're waiting for replacement, or maybe you as a player would be, so whether Dynamic Campaign will allow for swapping which pilots you control so you as a player could be at multiple roles in one session (Kinda like GTA5 character select, interesting?) Also DCS Multiplayer would have to extend support for game modes where fuel, ammo, spare parts are limited and ejections and pilot deaths and respawns cactually do count in the final score or some kind of a gameplay affecting factor. Partially it's already doable with scripts and warehouse rules AFAIK, perhaps not simple enoguh due to manual work by mission designer. Furthermore on the map and aircraft physics level, these abandoned airfields should be officially supported physically, not just esthetical graphics on the terrain. The terrain underneath and the tires contacting it should be supported so that appropriate terrain behavior would be observed. It's a bit hard to do it accurately for aircraft which were never meant to be used on offroad runways so real documentation of the performance is most likely not existent or rare. Aircraft not designed for offroad runways should at least be able to land in DCS and that would count toward the stuff I was mentioning. Perhaps only some of them being able to take off again if they're barebone and light enough. in a limited ammo type of scenario it would matter, or perhaps important intel or cargo onboard, and perhaps only take-off if they're empty. So the actual use of these things beyond esthetics, would give options for player comeback and open up strategies for a greater overall DCS experience. However depends how deep the Dynamic Campaign base-building RTS component is planned to go and whether ED needs documented cases in real-life to justify simulating these rare emergency uses, like salvaging engine parts, extracting fuel, which I think don't really have a problem with reality, it's something a military would do if presented with the challenge, but there hasn't been a large scale war in real-life of that kind where these cases would manifest and get documented. It would be a feeling of pity if DCS wouldn't be able to simulate these very probable possibilities just becuase they never happened to occur in real life military history. Might be somewhat more work tho, crash-model or damage-model would need more variations, but might not be that hard if you just hide the parts that get salvaged(extracted). Pretty animations would need more work tho, the military utility/repair vehicles with several engneers around the aircraft extracting the engine is very complicated animation if you want to do it in great detail, but for DCS, really don't need the esthetics, any simple approach should be fine at first. If lacking documentation I think a group of SMEs that specialize in mechanics, rescue, repair from general fields too as well as the military engineers, and the SMEs that were ex or even active mehanics that repair the very aircraft we're talking about, I think that's a topic they would love to brainstorm, they could advise ED on the feasibility and likelyhood of something working or not or how would it work, so that we can enjoy these things in DCS which do not happen often in real life.
  11. It's all about VRAM first and foremost, VRAM amounts are lagging behind due to the DRAM industry production bottlenecks, otherwise we'd already have 32GBs on these cards as per standard, and that would be enough to basically put one of the DCS maps fully into VRAM, but heavily depends on maps, with 32GB perhaps you could do that (I'm not on a system with DCS installed right now, so I can't have a quick check) RAM usage for gaming is in many cases as cache for VRAM data, graphics and texture data that the system needs in VRAM, but they either can't fit there, or aren't immediately necessary. So a high or low RAM usage isn't of a concern, there's no need to unnecessairly cache more unneeded graphics data into RAM, while VRAM is already being 100% utilized. The OP's GPU has 8GB VRAM and this isn't that much anymore, I have 8GB too and DCS's maps and everything would like to have much more if it could. Ofcourse VRAM alone doesn't mean that's the only blame for the OPs stuttering, we all know DCS is of a dire need to take advantage of modern software approaches in terms of multi-threading, resource management and graphics, which would enable a smoother experience even with not so optimal hardware resources. Most of the stuttering is actually more to do with CPU stuff than memory in my opinion. But yes, generally, we all know that software really should not stutter under a bit of resource constrain, if it's built to scale, if it has the ability to dynamically adjust it's output, but in a simulator you can't just not display an airplane or piece of land, it would look totally unrealistic, not to mention multiplayer unfairness if low-end users would see a less-detailed world and get some kind of an advantage, like seeing through forrest area or for, various environmental effects, etc. It might be interesting to see the comparison if for example you'd have game (DCS) debug and the OS too and disable RAM caching and just let the system deal with limited VRAM. However it be much worse on HDD and slow SSD storages than it would be today with fast NVMe SSDs, so either way it's not so bad like in the old days, but still ofcourse much less playable, any kind of stuttering can ruin the experience 10 fold. Either way RAM exchange has to happen on PCs because when you read new texture data from Storage, it has to go to RAM first, decompressed/converted by CPU before it can go to VRAM, but that's what DirectStorage is for, the data still has to go through RAM but the transport stack is apparently new and highly optimized for that VRAM upload to be much faster and the cost of GPU decompression is apparently much lesser as GPUs chrunch through that like nothing.
  12. Khronos Strengthens Vulkan Ecosystem with Release of Vulkan 1.3, Public Roadmap and Profiles https://www.khronos.org/news/press/vulkan-reduces-fragmentation-and-provides-roadmap-visibility-for-developers I wouldn't be upset if 1.3 is the new target for DCS and we suffer a delay for that Let it be a blast when it finally comes. Actually 1.3 is more about officialy confirming many of the existing optional extensions (features) as part of the core and required, so DCS could have already been using some of these extensions already. Dynamic rendering is highlighted, but how useful to DCS at this point it is, is out of my experience to speculate and guess. https://www.khronos.org/blog/streamlining-render-passes On the other hand, some of the extensions are mainly about making it easier for development, not necessairly improving performance or adding new features, but it would mean with less hassle a speedier development can mean we would get the final result faster. https://www.khronos.org/blog/vulkan-1.3-and-roadmap-2022 https://www.phoronix.com/scan.php?page=article&item=vulkan-13-2022&num=1
  13. Yes, youtube videos often seem to look better, tho I realized as well the creators probably enhcance things with Reshade which I think should be noted, but the video compression that youtube does also has it's side-effects that make it seem look better even tho it's technially not, they impose chroma-subsampling from 4:4:4 to 4:2:2 which loses color and pixels and should look worse than full RGB you get on the monitor. Other things the compression codec makes may indeed smoot things out in terms of aliasing so yeah, it's not 1:1 to what you see on the monitor.
  14. Yes, I made a new year (2022) commitment to not post any half-assed posts anymore and if it takes me a month to do a proper post then so be it.
  15. Haha, unrelated but sort of interesting timing, Age of Empires II Definitive Edition seems to have something very similar to I've just suggested, Enhanced Logging Build. Noticed this today while reading October's changelog. https://www.ageofempires.com/news/aoeii-de-update-54480/
×
×
  • Create New...