AMD Pushes Back 3rd Gen Threadripper & Ryzen 9 3950X Until November

[coder]

If the "driver" (including kernel, mesa, gpu kernel and vulkan drivers) was this small, it would probably fit in L3 cache.

Interesting, but I think it would continually get evicted by games' own code & data.

If, instead of thread scheduler, it only had one thread per CPU core and fibers as user mode threads, the engine could probably shave off few % of context switching overhead, especially now with all those mitigations. I'd also turn off all gr security patches etc.

Yeah, that's sort of like how I was talking about removing system call overhead. Basically, just put the whole game in the kernel, maybe implementing it as a kernel module.
; )

It's as if you're trying to turn a PC into a games console, meanwhile games consoles are trying to be more like PCs.

Anyway, work-stealing schemes like what TBB supports can already load-balance work without relying on context-switching.

https://www.threadingbuildingblocks....algorithm.html

The downside might be a bit more thrashing of L2, if related tasks operating on some shared data get handled by threads on different cores. I guess TBB has some notion of affinity, and you could also potentially mitigate this by tuning the granularity of said tasks.

[caligula]

Unless you're talking about removing the kernel/userspace boundary, I don't see any big wins from that. I don't believe there's a whole lot of overhead weighing down Linux gaming, beyond the sort of stuff that's already addressed by Game Mode.

Hard to tell. At least one advantage is that a small kernel could be further optimized (e.g. LTO). If the "driver" (including kernel, mesa, gpu kernel and vulkan drivers) was this small, it would probably fit in L3 cache. If, instead of thread scheduler, it only had one thread per CPU core and fibers as user mode threads, the engine could probably shave off few % of context switching overhead, especially now with all those mitigations. I'd also turn off all gr security patches etc.

[coder]

Said hardware lives in a Wintendo box, so I haven't fiddled with underclocking in Linux.

Okay, no prob. I just took my own advice[1] and got a Radeon VII - that's why I asked.

I'm debating acquiring a used RX 580 for Linux use, since it's better supported than my ageing HD 7970 GHz Ed. card.

Mine will replace a HD 7870. It's a XFX-brand 2-heatpipe card that sounds like a lawnmower if subjected to a stressful workload! I don't know if the thermal compound degraded or if it was always that bad, because I didn't really stress it when I first got it.

Anyway, I picked up a cute, little RX 550, a while back, that I was going to use for that box, but the VII will be much more fun. Still, I want to keep its heat & noise in check.

1. https://www.phoronix.com/forums/foru...ue-gpu-compute

[ermo]

What did you use for underclocking, in Linux?

Said hardware lives in a Wintendo box, so I haven't fiddled with underclocking in Linux.

I'm debating acquiring a used RX 580 for Linux use, since it's better supported than my ageing HD 7970 GHz Ed. card.

[coder]

coder What I mean is: nobody cares about software optimization when a half-assed optimization for the lowest common denominator (Intel/NVIDIA) is simpler and reduce the time to market.

Targeting lowest-common-denominator is definitely a factor, but also some game developers are sometimes effectively bribed by GPU makers to optimize games for their GPUs, potentially to the disadvantage of their rivals'.

[angrypie]

coder What I mean is: nobody cares about software optimization when a half-assed optimization for the lowest common denominator (Intel/NVIDIA) is simpler and reduce the time to market.

"What do you mean, our game stutters in your PC? Just throw more hardware at it. Hardware is cheap."

No one is giving a single fuck about chiplets and fabric interconnects until Intel does the same.

[coder]

handwritten Assembly scales poorly once you want to do something more complex than a Super Mario clone. John Carmack is one of a kind.

Um, he codes in mostly C++, AFAIK. And I doubt he's that exceptional, apart from the fact that the games industry probably burns out too many coders or doesn't pay them as much as other employment options available to most of them.

Engine	Initial Release	Languages
Doom	1993-12-10	C, Asm
Quake	1996-06-22	C, Asm
Quake II	1997-12-09	C, Asm
id Tech 3	1999-12-02	C
id Tech 4	2004-08-03	C++
id Tech 5	2011-10	C++, AMPL, Clipper, Python
id Tech 6*	2016-05	C++

* Carmack probably started this, but left for Oculus in 2014.

According to this post from 1.5 years ago, he still has a fondness for C, though it's clearly not his primary working language:

In hindsight, I should have just gone full retro and done everything in ANSI C. I do have plenty of days where, like many older programmers, I think “Maybe C++ isn’t as much of a net positive as we assume...”. There is still much that I like, but it isn’t a hardship for me to build small projects in plain C.

It should be noted this is right after he got done complaining about the lack of C++11 support, on his chosen platform. Perhaps if he'd had that, he wouldn't have harbored such misgivings about sticking with C++.

[coder]

Well I wasn't implying they should use ancient legacy systems. The system could run a modern 64-bit OS. It's just that the typical OS features bring unnecessary overhead for games.

Hence, Vulkan. That was about giving rendering engine developers the low-level access to the GPU that they really wanted.

Imagine a Linux with most subsystems cut off. It mainly needs to support modern GPUs (latest generation Radeon and Geforce), DDR4 RAM, Core i7/i9/Ryzen CPUs, 1 or 2 file systems, generic NVMe disks, wired ethernet (Intel), a single sound card driver (e.g. Intel HDA).

Unless you're talking about removing the kernel/userspace boundary, I don't see any big wins from that. I don't believe there's a whole lot of overhead weighing down Linux gaming, beyond the sort of stuff that's already addressed by Game Mode.

[angrypie]

Well I wasn't implying they should use ancient legacy systems. The system could run a modern 64-bit OS. It's just that the typical OS features bring unnecessary overhead for games. Imagine a Linux with most subsystems cut off. It mainly needs to support modern GPUs (latest generation Radeon and Geforce), DDR4 RAM, Core i7/i9/Ryzen CPUs, 1 or 2 file systems, generic NVMe disks, wired ethernet (Intel), a single sound card driver (e.g. Intel HDA).

I wasn't implying that either. I was pointing out that a close-to-metal, single-task OS for single-core CPUs already exists, but people migrated from it for some reason. Probably because handwritten Assembly scales poorly once you want to do something more complex than a Super Mario clone. John Carmack is one of a kind.

Unless you want to pay like $3k for a game, which is likely the price of a game that isn't just slapping textures to a bloated game engine made by underpaid code monkeys.

(Forgot to add that hardware for high-level languages is... not a good idea. Just ask Sun and Intel.)

[caligula]

They'd be pretty satisfied with old DOS games if it weren't for the wanking over graphics quality. I mean who the hell still plays games for fun amirite.

Well I wasn't implying they should use ancient legacy systems. The system could run a modern 64-bit OS. It's just that the typical OS features bring unnecessary overhead for games. Imagine a Linux with most subsystems cut off. It mainly needs to support modern GPUs (latest generation Radeon and Geforce), DDR4 RAM, Core i7/i9/Ryzen CPUs, 1 or 2 file systems, generic NVMe disks, wired ethernet (Intel), a single sound card driver (e.g. Intel HDA).