Add functions to detect the player's CPU hardware

[drwhut]

Describe the project you are working on:
OpenTabletop is a physics-based multiplayer 3D tabletop simulation game.

Describe the problem or limitation you are having in your project:
Right now, when the player first launches the game, the video settings are set to their lowest by default (e.g. MSAA is set to disabled). This is because there is no way to determine what hardware the player has to set the video options accordingly.

Describe the feature / enhancement and how it helps to overcome the problem or limitation:
Expose function(s) to GDScript that allows the programmer to determine either what hardware the engine is running on, or how powerful the hardware is. This way, I can set the video settings on startup based on the player's hardware.

Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:

var cpu = OS.get_hardware_model(OS.HARDWARE_CPU)
print(cpu.name)
if cpu.max_freq >= GOOD_CPU_FREQ:
    set_high_physics_clock()

var graphics = OS.get_hardware_model(OS.HARDWARE_DISPLAY)
print(graphics.name)
if graphics.max_freq >= GOOD_GPU_FREQ:
    set_high_video_settings()

If this enhancement will not be used often, can it be worked around with a few lines of script?:
Not really, this would most likely involve either making a C++ module or a NativeLibrary, with bindings to another library that already has this functionality. This would not be trivial for a majority of Godot developers.

Is there a reason why this should be core and not an add-on in the asset library?:
Most modern games pre-configure their settings based on the player's hardware. This is a fairly common feature, so many developers who are making games would also benefit from these functions, in more ways that what I have explained above.

[clayjohn]

For GPUs this is already implemented, see https://docs.godotengine.org/en/latest/classes/class_visualserver.html#class-visualserver-method-get-video-adapter-name

Not sure if we have it for all hardware though.

[mrjustaguy]

You can't just expect that a high frequency chip will be better then a low frequency one.. that's not the rule... in fact it is common for lower end cpus to be able to get higher frequencies because they've got fewer cores, so if you've got an expectation of 4 threads for "High quality" at 3GHz and the player has only 2 threads available but has 4GHz you'd set to High Quality, which wouldn't work out as expected because just the Frequency isn't 100% indicative of preformance... not to mention IPC (instruction per clock) which can vary depending mainly on the generation.

For that reason the best approach is to somehow benchmark the CPU/GPU preformance, get a number, and use that number to determine which settings are the best.

[Calinou]

As @mrjustaguy said, automatic graphics configuration is a very difficult task. Not even AAA games have mastered it today. Third-party solutions like GeForce Experience exist for that, but they're not quite as effective as one would hope.

Dynamic resolution is generally a smarter way to tackle this problem, as it adapts itself based on the effective frame time rather than on CPU/GPU specifications (which may be unreliable due to overclocked/underclocked/throttled components).

[FlykeSpice]

Also, to add, the pseudocode you put demonstrating where such features would be practical are very silly and impractical:

var cpu = OS.get_hardware_model(OS.HARDWARE_CPU)
print(cpu.name)
if cpu.max_freq >= GOOD_CPU_FREQ:
    set_high_physics_clock()

var graphics = OS.get_hardware_model(OS.HARDWARE_DISPLAY)
print(graphics.name)
if graphics.max_freq >= GOOD_GPU_FREQ:
    set_high_video_settings()`

First, you are off to a bad start by checking CPU/GPU "max frequency", it doesn't tells you any information at all about the cpu capabilities and is useless eitherway, because it will never reach the ideal frequency due to many factors like external temperature. A self-made programmer will never tune the settings to the user's machine with its "max frequency", there are many other difficult technical parameters that are evaluated combined(and even they aren't completely reliable)

Second, this is a high level modern game engine that abstracts all of the hardware concepts, and exposing CPU's information for the game developer is a very silly chemistry that will never work out, you won't do anything with it, pretty much useless.

Even if you could, it's just reiterating what has been said above: automatic tuning of games to the user's machine is a almost impossible task, it's highly difficult, even AAA games can't achieve that feat.

Stick with game settings, and let the user tune them on their own, just like other games has been doing forever.

[jamie-pate]

Obtaining the cpu model name would be very useful for analytics and qa reasons

Obtaining the core count to quickly select how many threads to run also seems practical/useful for analytics.

Clock frequencies could also be useful for analytics, but as mentioned above that is a moving target and a quick benchmark (run a simulation with ~16 threads and measure the duration) would probably be a more useful metric to determine real performance (or just one thread if that matches your workload)