I saw a gameplay of Atomic Heart on YouTube and during the game the player had a layout displayed with data about the CPU, GPU and RAM:
You can easily calculate FPS and CPU usage yourself, but what about the rest of the data? Will SDL3 have any API to read such information, e.g. regarding CPU temperature, clock speed and power consumption?
For now, I don’t know whether this layout is generated by the game engine or by external software, but it would be nice to have access to such data and be able to display it independently, as part of the functionality of the game engine.
I have a suspicion that they are using something like Conky or MangoHud to provide that overlay, so the RAM and VRAM, CPU Load, and power utilization on display may not exactly be tied to the single game but rather to what the entire system is using in total. (I haven’t looked too deeply into MangoHud though, and I am surprised at some of its capabilities so far.)
In SDL there are functions to check the machine’s hardware capabilities, like checking the number of CPUs and total RAM on the system, but I don’t see anything that checks on the operating parameters of the current running program or of current utilization.
I don’t think those functions exist in SDL 2 or 3 yet, but I do agree that it would be nice to have access to that data. Many users are benchmark nerds, myself included.
Here’s a stack overflow link that shows examples and ways to get that information on Windows, Mac, and Linux, but not phones or consoles just yet.
I don’t think you need a separate API for benchmarking and testing when there are third-party solutions with great support for various drivers and hardware.
Honestly, fuck third-party solutions. I am working on the engine without creating any unnecessary dependencies and I also do not want to force its potential users to install additional programs, since I can display such data myself. In fact, not only can I do this, but I can also choose which data should be displayed, where on the screen and how they should be rendered, so that they are useful and not disturbing. Thanks to this, every user will be able to see this data, not only those who know which program to install.
What I’m asking for is basic information about the hardware. Even SDL2 allows you to check, for example, which CPU instruction sets are available and how many cores are available, so why not extend this data set with other useful ones, such as the current clock frequency or RAM consumption by the process?
What I’m interested in would be something like what the Minecraft debug screen has (right column), but with a bit more useful hardware data:
@yataro: I understand your point of view, but I am of the opinion that if we have an API to read such data (the beginning already exists), we should have access to everything useful. Besides, if I can do something myself, I prefer to do it myself and adapt it to my own requirements.
If SDL3 doesn’t have a full API for reading hardware data, I’ll still implement it myself using the system API.
GPU stats are pretty cursed, depends on the driver and (sometimes) hardware, to maintain such a component would require a lot of effort. I believe nobody wants to mess with that…
I too would love to have such an API but it looks more like a separate SDL module (like ‘SDL_Image’ and others). The problem isn’t that no one is interested in it, it’s that the complexity is too much.
As @GuildedDoughnutpointed out, reading data about the CPU and RAM is fairly easy on various platforms, so reading them should be added to the main SDL library.
Even if Minecraft sticks with OpenGL, it still does not change the fact that SDL manages the backends on its own, so it can read such data. Finally, it is known which backend is currently used by the renderer, so the API of that backend can be used to read all the useful information about the GPU. It’s not impossible, it just might require a lot of work (considering how many platforms and backends are currently supported), so it’s not a consideration for now.
I agree that CPU/RAM is very easy to measure. I was mainly talking about GPU clocks. Information like GPU name/driver is pretty easy to get too.
Rendering backend doesn’t export any API to get clocks (only driver/hardware extensions in case of OpenGL). You have to query the driver to get these values.
I would like to remind you that your original question was about “CPU temperature, clock speed and power consumption”. Minecraft does not show GPU clocks information at all. If I get anything wrong I’m sorry. If you are only interested in CPU/RAM, then of course such an API can be easily integrated on all platforms that SDL supports, as it only uses the OS/platform APIs.
It’s quite challenging to show numbers that express what a CPU is actually doing in a cross-platform manner, and not just because of trouble getting information from the system.
For example I have a new laptop that has some fast cores and some slower but more power efficient cores (it has a heterogeneous architecture). Apps may run some threads on the fast cores and some threads on the slower cores, depending on what’s going on. There isn’t one single number that can express that, and trying to represent it with a per process Mhz number would be totally misleading.
RAM and GPU usage has similarly complex interactions once you try to account for more than one type of hardware.
An overlay or other measurement tool developed with specific hardware in mind will be more effective at conveying meaningful information than something that tries to be cross-platform.
This is known as NIH syndrome: anything that is “Not Invented Here” does not go in the project. It’s been recognized for decades now as a serious problem in software development. Please don’t fall into this well-understood trap.
@Mason_Wheeler: in this day and age where a typical project’s dependency tree is longer than the source code itself, I say a big no — NO TO DEPENDENCIES. If I need something, I do it myself and thanks to that I know exactly how it works, I have full control over the implementation and if I need to change/add something, I do it right away, the way I want. No problems with licenses, wasting time until patches or new features go into production, learning someone else’s API and sticking with someone else’s coding style and project requirements.
If we take into account the long term, avoiding unnecessary dependencies is an investment and, contrary to appearances, it allows me to save time. The only thing I rely on is SDL — because it would take me a decade to implement what it has. My code will never disappear, and the libraries you use may evaporate in the future (like left pad) or be no longer supported. Good luck, dependency slaves.
I agree, but I very much support the moves in recent times to incorporate into the core SDL libraries things that used to be dependencies. For example SDL_ttf now includes FreeType and Harfbuzz as core components, meaning they are always available without being dependencies.
For the same reason I’d love to see OpenSSL brought into core SDL_net so it’s available everywhere rather than being a dependency.
