linux kernel running on GPU without CPU

[Ironmask]

it's certainly possible but from a performance and efficiency perspective it seems like a step backwards. You would basically have to put at least a simplified GPU driver in the SBIOS/UEFI code in order to get things running, and a lot of the OS and application code would end up running on either a single element of a 32-way SIMD (aka vector processor) or running on the scalar processor if the GPU cores have them (might be AMD-only).

Quite a bit of the hardware in a CPU goes to providing a simple programming model for the developer on top of very complex hardware, while GPUs expose the complexity but semi-hide it behind high level driver APIs. I don't see any obvious way around exposing that complexity to OS developers, since running an OS on top of a driver abstraction model would be very inefficient.

That said, perhaps 70% of the problem boils down to figuring out how OS and application code can make good use of SIMD hardware and most of the rest boils down to managing the trade-offs associated with a "dirty write" memory consistency model. Both of those appear to be big gnarly problems, however.

I'm getting Itanium flashbacks from your post.
I wonder if OP worked at Intel?

[bridgman]

I just read through this thread again and I'm still not seeing what the benefit of eliminating the CPU would be. You still need "persistent code" and "per-data-element code"... the only difference would be that the persistent code would move to the GPU. It is certainly possible to run persistent threads on the GPU but it tends to be either not particularly efficient or not particularly simple (you get to choose).

GPUs have a few major differences from CPUs... list below is simplified a bit but enough for discussion:

#1 - SIMD architecture with large number of ALUs but very simple implementation, either in-order or very close to it

#2 - inconsistent (but faster) memory model where writes are not immediately visible to reads unless you explicitly flush or bypass cache

#3 - dedicated hardware to spawn a large number of threads, one per data element, driven by structures such as "vertices in a triangle strip", "pixels in a triangle", "elements in a matrix" etc...

#4 - dedicated hardware to efficiently coordinate large numbers of threads (barriers, atomic operations)

GPUs tend to be much less efficient than CPUs if your code can not take advantage of SIMD or MIMD processing. When doing "GPU things" this is usually not an issue because the dedicated hardware from #3 above automatically loads up the SIMDs with a set of threads, each working on a different data element from the driving structure (eg triangle strip) but it's very hard to make efficient use of GPU hardware when running the typical persistent threads that make up an application.

Anyways, it's certainly possible but from a performance and efficiency perspective it seems like a step backwards. You would basically have to put at least a simplified GPU driver in the SBIOS/UEFI code in order to get things running, and a lot of the OS and application code would end up running on either a single element of a 32-way SIMD (aka vector processor) or running on the scalar processor if the GPU cores have them (might be AMD-only).

Quite a bit of the hardware in a CPU goes to providing a simple programming model for the developer on top of very complex hardware, while GPUs expose the complexity but semi-hide it behind high level driver APIs. I don't see any obvious way around exposing that complexity to OS developers, since running an OS on top of a driver abstraction model would be very inefficient.

That said, perhaps 70% of the problem boils down to figuring out how OS and application code can make good use of SIMD hardware and most of the rest boils down to managing the trade-offs associated with a "dirty write" memory consistency model. Both of those appear to be big gnarly problems, however.

There were a few examples of hardware that split the difference between CPU and GPU with a large number of simple cores but keeping a CPU-like programming model and so were able to boot a standard OS. Those would be a better candidate for what I believe you have in mind, however I don't believe any of them survived in the marketplace. Thinking of products like Knights Landing... I thought they showed promise but they required a massive rework of existing GPU drivers in order to make good use of the hardware and AFAIK that never came together in time.

https://www.alcf.anl.gov/files/HC27.25.710-Knights-Landing-Sodani-Intel.pdf

[Limit]

I haven't read so much ignorant nonsense in a very long time. The facts don't change because you are of a different opinion. GPUs are just not suited for that task no matter how much you want them to be. That's why nobody is wasting time or money to make Linux run on a GPU.

[Ironmask]

You're the one who doesn't understand my messages. I have already talked many times about algorithms for solving problems on the GPU. Today, a programmer needs to solve a problem by thinking simultaneously on GPU algorithms and CPU algorithms. they will switch to only one algorithm, and they will improve it well. as for changes in GPU architectures, that's up to the compiler. The programming language will remain the same for all architectures and algorithms as well.

I can definitely tell you don't program, because nobody splits up algorithms between processors. When people have a highly parallel workload, they put it on the GPU, simple as. This is like saying we should freeze all our food because you're not sure if you should refrigerate something or not.
I really don't see any more point in this conversation, you don't even seem to understand what computers are, you sound like a politician trying to pass an IT law. I really recommend actually learning what each component in a computer is and how to perform GPU workloads in code, because I 100% know you know nothing about either.

[Ironmask]

the most important thing is that it will become easy to develop software. you will not need to write code for the CPU. there will not be such a mess as with a huge number of aarch64 processors. This is a huge plus for the Linux kernel. The Linux kernel will be able to move from chaos to order.

... Have you even read my post? I specifically pointed out, almost needlessly, that GPU architectures are entirely proprietary and tend to radically change between generations. If you think ARM architectural differences are bad, GPU architectures are a thousand times worse. GPUs don't even remotely resemble each other between generations, they have no standards to adhere to like CPU architectures do.
This really points out that you have no idea what a CPU or GPU even is. I don't even mean that insultingly, you're genuinely making statements about things you know nothing about.

[Ironmask]

Okay, I think I at least understand you a little better. So this is political and not technical.

Adapt the Linux system for implementation in the core of neural networks, no NPU can compare with the GPU for these purposes.

I'm not sure why you assume this, NPUs are specifically designed to be better than GPUs at this purpose.
Again, this seems to tie in with your misunderstanding of what a compute core is. CPU cores are entirely general-purpose, GPU cores are meant for simpler mathematical operations, but perform them faster than CPU cores, NPU cores are built specifically for ML-specific matrix operations, and are even better than GPU cores at it. This is why we have the different processor types; the more general-purpose a core is, the worse it is at specific tasks. Countering that, the better a core is a specific task, it becomes far worse as general-purpose ones. It's specifically why we don't throw everything at the GPU, because a lot of computational tasks would be horrible to perform on a GPU compared to a CPU, for a variety of reasons. The CPU is the safe default for computation because it's simply the best component for general purpose computing, people only go to the GPU ("GPGPU") when they have a computational workload that can specifically take advantage of the capabilities in GPU cores without suffering their downsides.

NVIDIA has made a move into the AI sector.. AMD and Intel will never be able to compete with them in this industry. The only way out is if People start buying GPUs from Intel and AMD instead of CPUs. Then they will be saved from collapse and people will in turn receive a base for realizing their needs and requirements. Everyone will be fine. Shitty GPUs from Intel and AMD that are not even good for games will be able to satisfy the demand instead of the CPU. Together, we will all enter the future without losing anyone. Linux systems can save AMD and Intel and become the only first system suitable for scientific work and entertainment. I think that Linux systems will become as popular as Windows. This is a chance for everyone. It is stupid to lose it.

I fully agree with your sentiment that we absolutely need competition for nvidia, but, this solution has nothing to do with it. AMD and Intel's GPUs don't suck because they're under-utilized, they suck because they simply don't care. AMD neglects it's GPU division for it's CPU division (a very stupid move, but not one that will be solved by somehow magically making GPUs work autonomously), and Intel is outright incompetent and losing market value by the day because of it (people are comparing them to Boeing). As much as I dislike nvidia, they are quite literally the only company competently making advanced GPUs.

Everything has already reached a dead end with the CPU. People are tired of lies. Nothing is being done to improve the lives of the masses.

I find this particularly ironic, personally, because I vividly remember watching a video from JayzTwoCents a few months ago where he said "It's funny CPUs are exciting now while GPUs are boring, because in the past it was the GPUs that were exciting while the CPUs were stagnant." referring to how both Intel and nvidia don't innovate much because their competition simply isn't threatening. CPUs were boring because AMD didn't have the resources to compete with Intel, but now they're exciting because their CPUs are being massively innovated and it's quite exciting. Meanwhile, now GPUs are boring because AMD is as slack with their GPUs as they were with their CPUs before they finally invented the Zen architecture.

[Ironmask]

that it is time to make the transition. CPU time is up.

You still haven't given a reason - or responded to my counter-reasons - as to why this is in any way desirable.
So far you just sound like a ~2008 AMD marketing executive demanding more cores without any regards as to how well they perform.
And, no, nobody wants to kill CPUs. To be frank, I'm actually not convinced you're even aware of what a CPU or GPU actually is.

[Ironmask]

Guys, you are wrong. I know that it is possible. It is difficult but possible. Let's in this case each of us stick to our own opinion.

But, this isn't a matter of opinion, you're literally asking what are the functional capabilities of a piece of hardware, it is by definition non-opinionated. You're asking how a machine works.
If you *know* a standard GPU can run by itself, then, how? I'm genuinely asking.
Otherwise, if you don't know, why don't you accept our answers? As far as I know from how GPUs work, they can't run by themselves, because they literally weren't built to do that, they are designed from the ground up to be a co-processor. Aside from being extremely proprietary and essentially entirely different architectures between generations, they don't have any hardware capabilities like networking, disk control, probably don't even have an MMU, I'd assume the CPU or Southbridge handle that. Again, it's totally fair to ask for a CPU with thousands of cores, but you are literally asking for an existing co-processor to perform all systems work, that's like saying you can rip out the 8086 of an IBM PC and only use the 8087, when that's physically impossible.

Also I'm still not sure why you hate CPUs so much. I did just explain they're not only perfectly fine at what they do, but they actually offload work from the GPU, the GPU performs better because it doesn't have to do all of the serial non-parallel work the CPU is doing. You could easily turn your (frankly insane) argument around and say we should all stop using GPUs because technically you can render on the CPU. Both arguments don't work because current computer architecture designs of having a single workload workhorse and a highly parallel processor optimized for tiny mathematical operations fits perfectly in our modern computing paradigm, computers need to do both expensive non-parallel tasks as well as highly parallel micro-tasks, which CPUs and GPUs are perfect for, respectively. What you propose is either to bog down the GPU with expensive non-parallel workloads it isn't optimized for, or to have a CPU with thousands of multi-purpose compute cores that are a jack of all trades but a master of none.

[Ironmask]

I think what you want is a CPU with thousands of cores, rather than a GPU. GPUs are entirely designed to be co-processors, they don't have any of the general-purpose machinery in place to operate by themselves, they're basically designed to process many small equations at once, and don't have any of the hardware orchestration abilities CPUs perform. You could probably design a CPU with thousands of cores, but at that point it wouldn't look anything like x86/ARM/RISC-V, and the cores themselves would probably be slower than the dedicated GPU cores. On the flip side, standard GPU architectures can't run by themselves, you can't simply program an OS to run without the CPU, the computer's physical architecture doesn't support it, the computer literally will not turn on.
Also, why would you even want this? It might be interesting from a manufacturing perspective, but there's nothing really wrong with having a CPU with a GPU as the co-processor. Even if the GPU is doing most of the work, you can still have the CPU perform general system management functionality, which is pretty much how it works now anyway. In fact, modern GPU architectures are bypassing the CPU and RAM entirely to perform work more efficiently, but they're not going to replace the CPU because that would be a huge waste of time (both to invent it, and a waste of the GPU's own processing time) when it's easier to simply split up simple tasks and parallel tasks into two separate dedicated processors.

[EmptyMenagerie]

[T]here are no algorithms for solving standard problems using GPU. everything [sic] is CPU-oriented.
...
deep [sic] parallelization will help solve the stupid killing of processes in the Linux kernel, solve the problem with queues and other diseases that seem incurable when using the CPU.

You talk a big game. Sometimes an annoyed developer makes an (arguably) better solution than what's come before like systemd, pipe wire, or Linux. If you think you can solve some of the complexities of programming through GPU programming, go ahead and show us how it's done. You'll have lots of folks eating their words and buying you beers if you can come up with a few more general purpose GPU algorithms. I'd highly recommend looking at some CUDA or opengl resources first.

https://developer.nvidia.com/cuda-education-training

https://learnopengl.com/