|
teagone posted:Which games. Far Cry 4, even though it turns out that it runs just fine on dual-core chips once people hacked out the check.
|
#
¿
Apr 1, 2015 02:47
|
|
|
|
| # ¿ Jan 16, 2025 07:45 |
|
|
Most operating systems do let you set thread priorities that will grind the system to a halt. REALTIME_PRIORITY_CLASS on Windows and using SCHED_RR or SCHED_FIFO on POSIX systems will let you make "realtime" threads that take priority over everything, even system tasks. I know that Linux and FreeBSD won't let you use those schedulers without being root as a security measure to prevent Joe Schmoe from hanging the whole system, but I don't think that Windows or OSX prevent a normal unprivileged program from doing this.
|
|
#
¿
Apr 3, 2015 17:10
|
|
|
mmkay posted:In Windows a user thread can't be given a priority boost above a kernel thread, also the scheduler will also temporarily boost a starved thread's priority. Is this something new? MSDN still says: quote:You should almost never use REALTIME_PRIORITY_CLASS, because this interrupts system threads that manage mouse input, keyboard input, and background disk flushing. Raymond Chen says the same thing: setting a thread to realtime priority basically means that it owns the processor until it stops itself.
|
|
#
¿
Apr 3, 2015 17:47
|
|
|
ehnus posted:A game cannot achieve 200 jobs per 16ms frame if you are using semaphores or condition variables to signal that new work is ready. Well it might be able to do 200 jobs using locking but those jobs won't have any time left to do actual work. Do you guys hit a lot of contention? Most OS provided locks these days are fairly lightweight and have less than 20ns of overhead when hitting an uncontended lock/unlock sequence.
|
|
#
¿
Apr 3, 2015 21:51
|
|
|
cat doter posted:Correct me if I'm wrong, but isn't the whole point of DX12 that it automatically multithreads draw calls? Or do those have to be manually programmed still? Because if so, AMD will continue to be screwed. No. Vulkan, Mantle and DX12 basically get rid of the massive, slow hack-filled black-boxes that make up current video drivers and give control over most of the minutiae to developers. Automatically threading anything would run counter to their design. It's up to the application developer to decide if they want to build command buffers across multiple threads or not. There is no magic number of threads for maximum performance since it will all depend on what the application is doing, CPU speed and the quirks of the particular GPU where ideal workloads can not only vary between manufacturers, but between different generations of chips from the same vendor. Bear in mind that those draw call submission tests are only valid for comparing the overhead of different APIs on the same hardware since they aren't putting the same kind of load on the GPU and hitting the other bottlenecks that a real application would. The_Franz fucked around with this message at 02:17 on Apr 23, 2015 |
|
#
¿
Apr 23, 2015 02:09
|
|
|
Paul MaudDib posted:That's the theory at least. I'm sure in the real world there will still be tons of patching happening behind the scenes and stuff, because game devs are under huge pressure to ship before their holiday deadline and GPU devs don't want to be the brand whose cards don't work with a AAA title on release day. I'd agree that handling the complexity is best done by the commercial engine people and anyone less than a AAA game studio probably doesn't want to wade into the intracacies of how to get Enviro Bear 2000's graphics to render properly on a Crossfire setup. I doubt that Nvidia will stop injecting their optimized shaders over the ones that ship with games, but I'm not sure how you patch problems with command buffers without tracking state and doing a validation pass over everything submitted which would cause a noticeable performance hit and run contrary to the intention of the new APIs which basically have the driver doing as little as possible. Plus, every driver on every platform would have to implement these hacks and I don't see a company like LunarG building ugly hacks into the Intel Vulkan driver for every jankey game out there. I don't know about DX12, but Vulkan will have a verbose validation layer to be used during development that should catch any misuse of the API and Valve and LunarG are working on a debugger that clearly shows you where where your slow calls are by highlighting them in bright red. At that point it's the developer's problem if things don't work since they had ample warnings. Most of these AAA developers manage to build console titles without things going sideways so a more verbose desktop API shouldn't be an issue. The_Franz fucked around with this message at 14:35 on Apr 24, 2015 |
|
#
¿
Apr 24, 2015 00:53
|
|
|
|
| # ¿ Jan 16, 2025 07:45 |
|
|
WhyteRyce posted:Always amused when people get miffed that Goodwill doesn't want them dropping off their ancient rear end 27" CRTs at the backdoor I honestly wouldn't know how to get rid of a CRT around here anymore. The local trash company won't take them anymore, the nearby electronics recycling drop-offs stopped taking them a couple of years ago and second-hand shops don't want them. If it's an old monitor for a specific system or a late model Sony TV you can pawn it off on someone who wants it for retro games or computers, but if it's crap and/or doesn't work the only option is to throw it in some random dumpster in the middle of the night. Which, of course, you shouldn't do.
|
|
#
¿
Jun 9, 2015 01:14
|
|