News Ampere Opens the Door for 192-Core Linux Gaming Machines

[Admin]

High Performance Computing (HPC) specialist Ampere has shared a guide on how users can eeke out a few hours of Linux-powered gaming from one of the company's high-core-count, Arm-based CPUs.

Ampere Opens the Door for 192-Core Linux Gaming Machines : Read more

 

[bit_user]

Ampere Opens the Door for 192-Core Linux Gaming Machines

Do you mean 384-cores, by using dual 192-core CPUs? Because AMD's Genoa already scales to 192 cores / 384 threads, in a dual-CPU system.

The problem with using server CPUs in gaming machines is that they don't clock as high as desktop CPUs. Workstation CPUs tend to clock a little higher, but you probably can't do better than a modern desktop CPU, for most games.

Even if you'd use the CPU to do software rendering, the popular and more feature-packed software renderers (e.g. LavaPipe) don't scale well to so many cores.

We'd expect the company's server CPUs to currently be staying far, far away from any gaming workloads.

I think the main reason they might be doing this is probably for automated CI (Continuous Integration) testing, that some of their customers want to do.

 

[RichardtST]

Linux gaming... Proton... Oh God.... Please... Stop! You're killing me!
ROTFLMAO...

 

[JamesJones44]

Linux gaming... Proton... Oh God.... Please... Stop! You're killing me!
ROTFLMAO...

I would support anything that moves gaming away from Windows, though this likely isn't it.

 

[JamesJones44]

I know we are talking about the emulation/translation layer largely, but unless a game gets optimized to pre-compute those translations I still think you will be at the mercy of under utilizing the processor by a large margin and not really boosting performance all that much. Especially since a lot of games still operate under a single game loop concept (especially FPSs).

All that being said, I would be happy for someone to build a test system to tell me I'm wrong 😀

 

[MobileJAD]

Nobody is going to ask how much that 192 core ARM server cpu costs and who would actually game on it?
I'm all for gaming on a ARM or RISC processor either under native code or x86 emulation, but to suggest people would actually game on a expensive server grade cpu?

 

[evdjj3j]

I don't believe Proton is considered an emulator.

Compatibility layers - Emulation General Wiki

emulation.gametechwiki.com

Proton (software) - Wikipedia

en.wikipedia.org

 

[mitch074]

I don't believe Proton is considered an emulator.

Compatibility layers - Emulation General Wiki

emulation.gametechwiki.com

Proton (software) - Wikipedia

en.wikipedia.org

Proton is a fork of Wine. Wine is originally a recursive acronym : Wine Is Not an Emulator.
So what is Wine (and by the same token, what is Proton) ? I'll cite the project's website (https://www.winehq.org) :

Wine [...] is a compatibility layer capable of running Windows applications on several POSIX-compliant operating systems, such as Linux, macOS, & BSD. Instead of simulating internal Windows logic like a virtual machine or emulator, Wine translates Windows API calls into POSIX calls on-the-fly, eliminating the performance and memory penalties of other methods and allowing you to cleanly integrate Windows applications into your desktop.

In short, provided it can get a 1-to-1 translation of NT calls to POSIX calls, it can work as fast as Windows. And, where the NT kernel is slower than Linux, an application running on Wine can run faster than native.

 

[NeoMorpheus]

Linux gaming... Proton... Oh God.... Please... Stop! You're killing me!
ROTFLMAO...

I ditched windows in my gaming PC for ChimeraOs and it has been the best move ever.

 

[russell_john]

A lot of good this will do when most game developers can't even make 8 cores thread correctly .....

 

[bit_user]

In short, provided it can get a 1-to-1 translation of NT calls to POSIX calls, it can work as fast as Windows. And, where the NT kernel is slower than Linux, an application running on Wine can run faster than native.

A lot of WinAPI calls don't have a 1:1 POSIX equivalent. For instance, the whole way that Windows' IO Completion Ports work is different than how you do efficient I/O multiplexing, on Linux. And, until very recently, Linux had no equivalent of WaitForMultipleObjects(). And I mean Linux, not POSIX, which still has no equivalent!

Then, you have parts of Windows like Direct3D, which requires a huge amount of machinery to run atop OpenGL or Vulkan, on Linux.

But, even far more basic parts of Windows, like the loader, have to be emulated on Linux. That's right, I used the "E" word, because Linux has a loader, executable and library formats, an ABI, calling conventions, etc. And they're all different than Windows. Even the filesystem hierarchy is different, and WINE handles that, too.

What WINE should really say, instead of this nonsense about mapping Win API calls to POSIX calls, is that it uses a native implementation of the WinAPI and the Windows runtime environment.

 

[mitch074]

A lot of WinAPI calls don't have a 1:1 POSIX equivalent. For instance, the whole way that Windows' IO Completion Ports work is different than how you do efficient I/O multiplexing, on Linux. And, until very recently, Linux had no equivalent of WaitForMultipleObjects(). And I mean Linux, not POSIX, which still has no equivalent!

Then, you have parts of Windows like Direct3D, which requires a huge amount of machinery to run atop OpenGL or Vulkan, on Linux.

But, even far more basic parts of Windows, like the loader, have to be emulated on Linux. That's right, I used the "E" word, because Linux has a loader, executable and library formats, an ABI, calling conventions, etc. And they're all different than Windows. Even the filesystem hierarchy is different, and WINE handles that, too.

What WINE should really say, instead of this nonsense about mapping Win API calls to POSIX calls, is that it uses a native implementation of the WinAPI and the Windows runtime environment.

That's their aim, yes, but you can still run native Windows DLLs on Wine instead of their own implementation, and there you do get the "simple" translation layer.
DirectX is a different beast, as it is mostly implemented at driver level, and Wine only provides a DirectX to OpenGL wrapper (similar to what we had with Glide a long time ago on Windows). There used to be an experimental project to implement DirectX directly over Gallium, but DXVK ended up being simpler to implement, with wider compatibility and similar performance; while it is technically a wrapper still, it is not part of Wine.

 

[bit_user]

DirectX is a different beast, as it is mostly implemented at driver level, and Wine only provides a DirectX to OpenGL wrapper

My point is that there's nothing simple about such a wrapper. The stuff you quoted about WINE makes it sound way simpler than it actually is. That statement is obsolete, misleading, and really ought to be reworded along the lines of how I said.

 

[mitch074]

My point is that there's nothing simple about such a wrapper. The stuff you quoted about WINE makes it sound way simpler than it actually is. That statement is obsolete, misleading, and really ought to be reworded along the lines of how I said.

The principle is simple, the actual implementation is far more complex - especially with OpenGL and DirectX being such different beasts, with widely differing support, implementations and abstractions. It's actually easier to implement DirectX over Vulkan (as proof, how fast it was to get functional support for Direct3D 9, 10 and 11 over Vulkan), but Wine's DirectX implementation (that covers Direct3D 5 to 9 as stable) predates Vulkan by a decade and a half.

 

[bit_user]

The principle is simple,

Its not, though. If it really worked according to that principle, it would be virtually useless for most real-world Windows programs, because that principle doesn't get you very far.

the actual implementation is far more complex - especially with OpenGL and DirectX being such different beasts, with widely differing support, implementations and abstractions. It's actually easier to implement DirectX over Vulkan (as proof, how fast it was to get functional support for Direct3D 9, 10 and 11 over Vulkan), but Wine's DirectX implementation (that covers Direct3D 5 to 9 as stable) predates Vulkan by a decade and a half.

This is saying a lot, without really saying anything. There's no simple mapping from any version of Direct3D to any version of OpenGL or Vulkan.

Direct3D is not a simple API, either. It has its own shader language, which WINE needs to provide special compilation support for. The main reason why it's easier to support Direct3D atop Vulkan is that Vulkan is such a low-level API. So, there are fewer things that get in your way. It's still a rather monumental undertaking.

 

[mitch074]

Its not, though. If it really worked according to that principle, it would be virtually useless for most real-world Windows programs, because that principle doesn't get you very far.


This is saying a lot, without really saying anything. There's no simple mapping from any version of Direct3D to any version of OpenGL or Vulkan.

Direct3D is not a simple API, either. It has its own shader language, which WINE needs to provide special compilation support for. The main reason why it's easier to support Direct3D atop Vulkan is that Vulkan is such a low-level API. So, there are fewer things that get in your way. It's still a rather monumental undertaking.

That's what I meant, but it didn't come through I guess. Yes, while GLSL and HLSL do differ, Mesa incluses several extensions that make transpiling HLSL to GLSL not as much of a pain... Still, results became far better when that process was changed from HLSL - GLSL to HLSL-SPIR-V.