![[H]ard|Forum](/styles/hardforum/xenforo/logo_dark.png){kind=logo}
Umm how about bypassing the CPU bottleneck?
Too true lol!
There are videos up of the 3080 playing the new doom at 4K max settings and holding down numbers in 150s. Flopping back and forth between it and the 2080TI. So while not a great indicator it’s better than nothing?
They answered those questions in their Q&A. For all their benchmarks they used an Intel system.
No it would not. A normal hard drive isnt fast enough to bother with this tech and since it was already said this is for NVME only, that means it is only accessing the NVME drivers and not basic sata drivers.
But I mean if a developer implements this and based most of the game design around it. And somebody tried to play it on a slower SSD or HDD would the game run or just straight up dive right into a dumpster fire.
Not all tasks and decryption techniques are capable of SMP or multi-threading, and the tasks may be more limited by the disks themselves or be optimized for the lowest common denominator (HDDs).
I would agree if only he didn't say both his CPU and GPU and DISK are all close to idle
. It honestly sounds like it's loading using a single core. I find it hard to believe that they couldn't at least load up 2 cores if they really tried. I don't know if you remember when zip programs started getting multi-threading. Made a huge difference. My bet is they had more important things to focus on and didn't bother. Sometimes they write a quick implementation (quick to code) that works so they can get the rest of the project done with intentions of optimizing later, then realize the other 99% of the application is much more priority and never get back around to it and are moved to another project or w/e. Sure, there are some things that can't be hugely threaded, but there are very few that can't use more than a single thread, but as you say, sometimes there just isn't a great way to do it and the effort isn't worth it for something that is currently working.
There are quite a few compression techniques used that are still strictly single-threaded - it has nothing to do with the compression tool being used having SMP support.I would agree if only he didn't say both his CPU and GPU and DISK are all close to idle
Very unlikely with the amount of files they need to decompress that it's due to anything besides lack of doing it. I know what you're saying, and it does happen sometimes, but the fact that so many other games/appears able to load with multiple threads leads one to wonder if they're doing something that different or just didn't bother. Most zip applications are able to be threaded, I doubt it's some new form of compression they are using, wouldn't make much sense. The synchronization between threads can sometimes be a pita, so to put a bunch of effort towards something with no impact on actual gameplay or app usage (aka, no difference in frame rates after it loads) it just isn't a huge priority a lot of times. Not many review sites compare how quickly a game or levels load unless they're doing a disk benchmark, as they aren't really comparable game to game. That said I've seen plenty of room for optimization, take rainbow six siege for example, why does it need to compile shaders every time it runs? Why not just store a cache and check that the GPU/driver version hasn't changed? This kind of stuff is why AMD/Nvidia have a shader cache built into their drivers, because games don't/won't do it themselves (and one could argue, the driver knows better if its updated whether the cache is still good or requires rebuild).