View previous topic :: View next topic |
Author |
Message |
Gentoopc Guru
Joined: 25 Dec 2017 Posts: 383
|
Posted: Wed Jan 15, 2025 1:23 pm Post subject: dream of how a kernel for GPU will be written |
|
|
I would like to hear the opinion of guys who are familiar with GPU. If I suddenly decided to write an OS that runs on GPU and used a process tree called for example GTR_dinamic, whose number of leaves would be equal to the number of maximum possible threads on GPU, and the root would be a process that could only be terminated by the Power off command. That is, it would be a correct tree, the root of which would be at the bottom, and all processes would go to it. What problems would I encounter with such an approach?
Last edited by Gentoopc on Wed Jan 15, 2025 1:41 pm; edited 2 times in total |
|
Back to top |
|
|
Gentoopc Guru
Joined: 25 Dec 2017 Posts: 383
|
Posted: Wed Jan 15, 2025 1:34 pm Post subject: Re: the dream of how the Linux kernel would work on a GPU |
|
|
and any binary tree could simply be mounted to GTR_dinamic_ as a branch to such a tree. and such mounting could be done by the process scheduler
Last edited by Gentoopc on Wed Jan 15, 2025 1:42 pm; edited 1 time in total |
|
Back to top |
|
|
Genone Retired Dev
Joined: 14 Mar 2003 Posts: 9623 Location: beyond the rim
|
Posted: Wed Jan 15, 2025 1:41 pm Post subject: |
|
|
Quote: | If I suddenly decided to write an OS that runs on GPU |
You would run into an instant roadblock as a GPU isn't capable to host an OS. |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54706 Location: 56N 3W
|
Posted: Wed Jan 15, 2025 1:45 pm Post subject: |
|
|
Gentoopc,
How would you start such an operating system in today's hardware?
The GPU is not started until well after the CPU is running the kernel.
Then the GPU/RAM link is over PCIe, which is horribly slow compared to the CPU/RAM interface.
I think you will have the same problem as that which sank Intels Itanic :)
Lack of backwards compatibility.
There's more like that too. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
Gentoopc Guru
Joined: 25 Dec 2017 Posts: 383
|
Posted: Wed Jan 15, 2025 1:51 pm Post subject: |
|
|
NeddySeagoon wrote: | Gentoopc,
There's more like that too. |
no. the GPU already has everything it needs including the BIOS. I'm talking about the OS from the very beginning. and I think that such an approach to the process system could just make it compatible with the Linux kernel. that is, you need to write a meta kernel that will allow you to run the Linux kernel. it's possible that it won't even be needed. maybe there will be a GENTOO kernel. |
|
Back to top |
|
|
Gentoopc Guru
Joined: 25 Dec 2017 Posts: 383
|
Posted: Wed Jan 15, 2025 1:53 pm Post subject: |
|
|
Genone wrote: | Quote: | If I suddenly decided to write an OS that runs on GPU |
You would run into an instant roadblock as a GPU isn't capable to host an OS. |
you just need to write an operating system that can run on a GPU. you just need a different logic. if they could write an OS for a CPU, why can't they do it for a GPU? now people have an understanding of how things work. do you really think that people can't make a GPU display an interface similar to the bash interface? i'm talking about an OS from scratch. |
|
Back to top |
|
|
pingtoo Veteran
Joined: 10 Sep 2021 Posts: 1399 Location: Richmond Hill, Canada
|
Posted: Wed Jan 15, 2025 1:57 pm Post subject: Re: dream of how a kernel for GPU will be written |
|
|
Gentoopc wrote: | I would like to hear the opinion of guys who are familiar with GPU. If I suddenly decided to write an OS that runs on GPU and used a process tree called for example GTR_dinamic, whose number of leaves would be equal to the number of maximum possible threads on GPU, and the root would be a process that could only be terminated by the Power off command. That is, it would be a correct tree, the root of which would be at the bottom, and all processes would go to it. What problems would I encounter with such an approach? |
Usually you need to write a boot loader who in term can load OS binary (kernel) to GPU.
In other work you need to write a small program that will initialise BUS and possibly initialise some RAM and some I/O port to facilitate human communication (as you want to be able to understand what you small binary is doing). This program will be very hardware specific so you will need to know your target hardware. |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54706 Location: 56N 3W
|
Posted: Wed Jan 15, 2025 2:05 pm Post subject: |
|
|
Gentoopc,
The GPU has enough BIOS to initialise itself, that's it.
The CPU firmware does much more, like sets up memory timing and drive strengths, by trial and error from DDR3 or.
Looks around the system to see what is connected where and eventually, loads a boot loader/kernel.
The GPU can do none of that but its all required before the GPU can start.
If you are suggesting a whole new architecture, replacing the current CPU with a GPU, then maybe it can be made to work.
Then we are back to the Itanic. Nobody will use it because there is no software. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
Gentoopc Guru
Joined: 25 Dec 2017 Posts: 383
|
Posted: Wed Jan 15, 2025 3:03 pm Post subject: |
|
|
NeddySeagoon wrote: | Gentoopc,
The GPU has enough BIOS to initialise itself, that's it.
The CPU firmware does much more, like sets up memory timing and drive strengths, by trial and error from DDR3 or.
Looks around the system to see what is connected where and eventually, loads a boot loader/kernel.
The GPU can do none of that but its all required before the GPU can start.
If you are suggesting a whole new architecture, replacing the current CPU with a GPU, then maybe it can be made to work.
Then we are back to the Itanic. Nobody will use it because there is no software. |
I will say more, that it is possible. to write a real-time kernel for GPU is just terrifying. I was also interested in whether it is possible to run the existing Linux kernel on GPU and people say that it is possible, but the kernel needs strong modification, and there will be a problem with GPU registers. I think that the real-time kernel is the best option, it filled a niche that is empty now. and on CPU its filling is not so interesting. unfortunately people are wasting time, and this is something that cannot be replenished. people persist and do not understand that now corporations have more important things to do. but soon they will solve them, and then we will not have a single chance to do what we want. there is some time, we need to keep up. |
|
Back to top |
|
|
stefan11111 l33t
Joined: 29 Jan 2023 Posts: 948 Location: Romania
|
Posted: Wed Jan 15, 2025 10:36 pm Post subject: |
|
|
NeddySeagoon wrote: | the GPU/RAM link is over PCIe, which is horribly slow compared to the CPU/RAM interface.
|
Perhaps that would not be such a problem, as the GPU has it's own vram.
NeddySeagoon wrote: |
If you are suggesting a whole new architecture, replacing the current CPU with a GPU, then maybe it can be made to work.
Then we are back to the Itanic. Nobody will use it because there is no software.
|
Is that why it flopped and we are still running x86?
I know M$ now releases windows for arm laptops? How does it deal with the lack of software? Or is it also doomed to fail?
NeddySeagoon wrote: |
The GPU has enough BIOS to initialise itself, that's it.
|
Can't the GPU bios be modified to be made suitable to start the computer?
There are people who modify GPU bioses on ebay who sell older cards with a modified bios that makes is show up as a newer card.
Gentoopc wrote: |
and there will be a problem with GPU registers.
|
This got me thinking, how does GPU assembly look like?
How different is it from x86 assembly? _________________ My overlay: https://github.com/stefan11111/stefan_overlay
INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd /usr/lib/modules-load.d *udev* /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus /usr/bin/gdbus /lib/udev" |
|
Back to top |
|
|
wanne32 Tux's lil' helper
Joined: 11 Nov 2023 Posts: 78
|
Posted: Thu Jan 16, 2025 1:24 am Post subject: |
|
|
Quote: | This got me thinking, how does GPU assembly look like?
How different is it from x86 assembly? |
As for Processors this depends on the model. But also on the API you are using.
https://www.intel.com/content/www/us/en/developer/articles/technical/introduction-to-gen-assembly.html
https://github.com/daadaada/turingas/blob/master/examples/bench/smem/lds32.sass
Quote: | How would you start such an operating system in today's hardware?
The GPU is not started until well after the CPU is running the kernel. |
Quote: | The CPU firmware does much more, like sets up memory timing and drive strengths, by trial and error from DDR3 or.
Looks around the system to see what is connected where and eventually, loads a boot loader/kernel.
The GPU can do none of that but its all required before the GPU can start. |
Except if you have a RapberryPI 1 where the GPU firmware initializes the hardware and loads the code to run on the CPU.
As you see: It can be done but it doesn't change much.
Depending on what you define as an OS there are several Engines that can surely account as one depending on the definition.
In the Sense of an Linux Kernel this is a whole different thing. What does it do:
- Setting settings for hardware.
- Managing a coherent state between processes
- Managing Resources by providing an abstraction layer for processes to access them through the Kernel.
- Managing access privileges for processes
The last one is the most complicated. Usually this is done in a way that the Kernel is called every now and then and sets what the process afterwards is allowed to do and the Processor will then interpret/ignore the commands send afterward accordingly. A GPU has no such feature. But there are a lot of privilege models for GPUs. So you could rewrite that. But it wouldn't be Linux any more and for sure would feel different.
But now for the rest:
All four points are basically decision making. (Which hardware state is needed? wich process useses wich Hardware? Is that process allowed to do that?) Running the same decision on multiple cores doesn't make it faster in the best case and creates bullshit if every core comes to an other decision. But single core speed of GPUs is mostly way below CPUs. Even worse this are branches. This is a very complicated thing. On CPUs much of the chip area is dedicated to alone this purpose. Even the caches are more or less speedup for short loops wich are defacto branches after branches. That GPUs do not do this Optimization is the reason why you get so much more calculation for the same buck. So not only is the clock speed lower. It will also suck at this task making it even slower we will now talk about several magnitudes.
And while the Linux Kernel often does heavy lifting like for crypto, error correction, crcs it usually uses dedicated hardware like with AES-NI, TCP-offloading, wifi-chips or raid controllers. Negating the GPU higher calculation speeds into an disadvantage.
Now Point one:
To do that you need interfaces for that hardware. While processors consolidate more and more around PCIe, they still have several dozen others. A GPU has usually two: A 16xPCIe input and an DP/HDMI output.
So how would a system look like:
To do point 3 you would need all the hardware interfaces on the GPU. You can see at the Raspberry Pi that this is doable. And since point 3 is mostly moving data you do not want 16xPCIe 4.0 but something similar to the speed of 20 PCIe 5.0 (with double the speed of 4.0)+4xDMI+DP/HDMI+speedy but low throughput interrupts like a 13thgen Intel CPU. The next question will be do you want to connect that to all the shader processors? This can be done efficiently via a bus. But since the kernel doesn't profit from so much more cores since most of its code is single threaded, (Even so every dedicated task can have its own thread.) why bother and not just connect it to a few where the kernel has to run. And since we are there: GPUs where always about dedicated hardware. Why not just add all the accelerators we have on modern CPUs to the GPU. And maybe a little bit of branch optimization into these cores to negate the worst performance impacts? Oh. If I look into it: Sounds very much like a description of a modern day multimedia SoC with most of the Hardware dedicated to multimedia while there is a little area that ist more optimized for IO and one that is optimized for running the Code to control it. How do we call it there? CPU? Ah – and the Linux Kernel can run there already. |
|
Back to top |
|
|
stefan11111 l33t
Joined: 29 Jan 2023 Posts: 948 Location: Romania
|
Posted: Thu Jan 16, 2025 11:53 am Post subject: |
|
|
wanne32 wrote: |
Except if you have a RapberryPI 1 where the GPU firmware initializes the hardware and loads the code to run on the CPU.
As you see: It can be done but it doesn't change much.
|
Does the PI1 have a GPU?
It doesn't need to do much graphics except displaying a tty, so does it need a GPU?
Can't all drawing be done on the CPU and passed through the hdmi port?
And if it does have a GPU, why does the GPU firmware initialize the hardware instead of the regular bios?
Is there some advantage to doing that? _________________ My overlay: https://github.com/stefan11111/stefan_overlay
INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd /usr/lib/modules-load.d *udev* /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus /usr/bin/gdbus /lib/udev" |
|
Back to top |
|
|
pingtoo Veteran
Joined: 10 Sep 2021 Posts: 1399 Location: Richmond Hill, Canada
|
Posted: Thu Jan 16, 2025 12:20 pm Post subject: |
|
|
stefan11111 wrote: | wanne32 wrote: |
Except if you have a RapberryPI 1 where the GPU firmware initializes the hardware and loads the code to run on the CPU.
As you see: It can be done but it doesn't change much.
|
Does the PI1 have a GPU?
It doesn't need to do much graphics except displaying a tty, so does it need a GPU?
Can't all drawing be done on the CPU and passed through the hdmi port?
And if it does have a GPU, why does the GPU firmware initialize the hardware instead of the regular bios?
Is there some advantage to doing that? |
Yes, Pi1 (or all Raspberry PI so far) have GPU.
Rest of you question should be asked in Raspberry PI Forums, since they are questions about design. what we are dealing is result of design nothing can be altered at this point from hardware.
In general, I believe today's SoC design always include GPU, it is up to the Board designer choose to use it or not.
"why does the GPU firmware initialize the hardware instead of the regular bios?"
my guess is that Broadcom want to hide their IP. And in SBC (Single Board Computer) usually does not come with BIOS. |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54706 Location: 56N 3W
|
Posted: Thu Jan 16, 2025 12:30 pm Post subject: |
|
|
stefan11111,
The Pi1, in fact the Pi1 to Pi3 inclusive were mobile phone chips with ARM CPUs grafted on like a wart.
It's much more than a GPU.
The GPU does the startup as that's how mobile phones (without an ARM CPU) start up.
wanne32 wrote: | ... RapberryPI 1 where the GPU firmware initializes the hardware and loads the code to run on the CPU. |
Almost but not quite ...
The Raspberry Pis up to the Pi 4, all have some firmware fused into the GPU that cannot be changed. Hence you can't brick a Pi before the Pi4.
This firmware is akin to legacy grubs stage 1 on a BIOS based IBM clone. All it does is reads the next stage bootloader from a the first partition of a DOS partitioned volume, as long as the filesystem is VFAT. In no particular order' that's start*, fixup.* and bootcode.bin.
Between them, they do the heavy lifting of setting up the hardware and loading the code for the ARM CPU.
The Pi4 and Pi5 don't use bootcode.bin. They both have updatable SPI ROMs. They still can't be bricked even if the SPI ROM is full of junk but recovery is a more complex process than with earlier Pis. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
|