7 ms·

I love it and hope it will catch on. I reminds me of what Linus Torvalds once said when asked about fearing competition, though. From my memory his answer was

I love it and hope it will catch on. I reminds me of what Linus Torvalds once said when asked about fearing competition, though. From my memory his answer was something like: I really like writing device drivers. Few people like that and until someone young and hungry comes along who likes that I'm not afraid of competition.

sylware 3y ago
But GPU drivers require a fairly big team. We must have a GPU hardware programming "standard" first. And I would favor a risc-v kernel instead to avoid the dependency on a super complex syntax (rust) compiler and do gcc-dependency-like mistake all over again. For this reason, eating the bullet and moving on a modern worldwide standard ISA would actually be the real move forward. We have already linux and others tied to gcc extensions and very recent ISO tantrums (porting to not-inline assembly and back to c89/99 is carefully made not reasonable, not to mention assembly code paths tied to specific stack alignment features from the compiler). Namely there is a serious imbalance between the compiler complexity and what it is actually bringing on the table.
- Snow_Falls 3y ago
  What do you mean a risc-v kernel? One written in RISC v assembly? Because that would be terrible. Risc-v is the instruction set architecture, rust is a programming language. You can port languages to target ISAs. Linux can already run in riscv. The ISA of the hardware and the language the software it runs are completely different issues.
  - sylware 3y ago
    Well, I think you are wrong, and that would actually be the real way forward: an assembly written kernel using a worldwide standard ISA, aka RISC-V. Of course, it would have not to abuse any preprocessor, because moving the issue which is the complexity of the compiler dependency to a preprocessor complexity dependency would nullify everything. Doing that in rust, is just doing the mistake of linux all over again, actually even worse, since rust syntax is much more complex than C with gcc extensions.
    - vkazanov 3y ago
      You can get your assembly-written kernel right now for every OS out there: just compile Linux using a RISC-V backend of your favourite compiler.
      - sylware 3y ago
        This is severely wrong: you cannot compare hand written and properly commented assembly with compiler generated one.
        bluGill 3y ago
        Compare in what way? Handwritten and commented assembly will be much easier for a human to maintain. However modern optimizers are much more likely to apply the correct micro optimization tricks to get the best performance - and they can output different assembly for different variations of the same instruction set with ease, something that would make the hand written assembly much more complex.
        sylware 3y ago
        "Handwritten and commented assembly will be much easier for a human to maintain" It seems some people here have issue acknowledging that. But where you are wrong: for modern micro-archs, everything mostly happens at runtime. Specific micro-archs optimizations are not done anymore, the linux kernel do not bother anymore and is compiled for "generic" x86_64 for instance, it is not worth it (and may cause more harm in the end). Usually, you only just care of basic static optimizations, like cache line, fetch code window, alignment, which are more writing "correct" assembly code than anything else. And even with that, in the worst case scenarios, one could write some specific micro-arch code paths, not an issue while thinking long term of many software components life cycle, which would be "installed"/"branched to" at runtime. At least that knowledge would not be hidden deep in the absurd complexity of an optimizing compiler...
        bluGill 3y ago
- madushan1000 3y ago
  What do you mean? most complicated parts of the gpu driver are in userland and handled by Mesa or equivalent. Kernel drivers expose a standard interface(DRM) which userspace drivers use to upload compiled gpu programs and manage gpu memory. Also, linux is not tied to gcc extensions, it can be compiled with llvm(clang) for a long time now.
  - sylware 3y ago
    What you said is mostly wrong. The kernel part of the GPU driver is massive. It is well known, maybe you were misguided: for instance the AMD GPU drivers are gigantic compared to the actual kernel. clang(llvm) is playing cat and mouse with gcc extensions and recent ISO C tantrums which creeps into the kernel:Linus T. does not resist those, he does resist only the linux useland ABI(syscalls) breakers.
    - madushan1000 3y ago
      It's also well known the driver is massive because there are hundreds of thousands of lines of auto-generated register access code in there. Not because it's inherently very complex.
      - sylware 3y ago
        And again you are wrong. It was debunked not a long time ago, and I think it was here on HN. The AMD drivers, kernel side, are still gigantic even excluding the generated register descriptions. Is this what we call a AI lie? But where you may be right: it seems nvidia hardware programming interface is much cleaner than AMD one and may require much much less code.
- vmfunction 3y ago
  >We must have a GPU hardware programming "standard" first. Isn't that what WebGPU has become?
  - flohofwoe 3y ago
    The WebGPU API is very far removed from the hardware. It's the common subset of Vulkan, D3D12 and Metal, each of those APIs also being fairly high level abstractions over different GPU architectures.
    - sylware 3y ago
      I don't know about webGPU, but it seems you missed the word "hardware" in "hardware programming interface", like NVMe is for non volatile memory device.
      - flohofwoe 3y ago
        I was replying to the "Isn't that what WebGPU has become?". The WebGPU programming model is already too high level for a "hardware programming interface". WebGPU is designed to sit on top of other 3D APIs, which in turn sit on GPU vendor drivers, and most of the complexity and 'hidden magic' is in those drivers.
        sylware 3y ago
        oops! wrong reply button, my bad.
deleted 3y ago
[deleted]

sylware 3y ago

But GPU drivers require a fairly big team. We must have a GPU hardware programming "standard" first. And I would favor a risc-v kernel instead to avoid the dependency on a super complex syntax (rust) compiler and do gcc-dependency-like mistake all over again. For this reason, eating the bullet and moving on a modern worldwide standard ISA would actually be the real move forward. We have already linux and others tied to gcc extensions and very recent ISO tantrums (porting to not-inline assembly and back to c89/99 is carefully made not reasonable, not to mention assembly code paths tied to specific stack alignment features from the compiler). Namely there is a serious imbalance between the compiler complexity and what it is actually bringing on the table.

Snow_Falls 3y ago
What do you mean a risc-v kernel? One written in RISC v assembly? Because that would be terrible. Risc-v is the instruction set architecture, rust is a programming language. You can port languages to target ISAs. Linux can already run in riscv. The ISA of the hardware and the language the software it runs are completely different issues.
- sylware 3y ago
  Well, I think you are wrong, and that would actually be the real way forward: an assembly written kernel using a worldwide standard ISA, aka RISC-V. Of course, it would have not to abuse any preprocessor, because moving the issue which is the complexity of the compiler dependency to a preprocessor complexity dependency would nullify everything. Doing that in rust, is just doing the mistake of linux all over again, actually even worse, since rust syntax is much more complex than C with gcc extensions.
  - vkazanov 3y ago
    You can get your assembly-written kernel right now for every OS out there: just compile Linux using a RISC-V backend of your favourite compiler.
    - sylware 3y ago
      This is severely wrong: you cannot compare hand written and properly commented assembly with compiler generated one.
      - bluGill 3y ago
        Compare in what way? Handwritten and commented assembly will be much easier for a human to maintain. However modern optimizers are much more likely to apply the correct micro optimization tricks to get the best performance - and they can output different assembly for different variations of the same instruction set with ease, something that would make the hand written assembly much more complex.
        sylware 3y ago
        "Handwritten and commented assembly will be much easier for a human to maintain" It seems some people here have issue acknowledging that. But where you are wrong: for modern micro-archs, everything mostly happens at runtime. Specific micro-archs optimizations are not done anymore, the linux kernel do not bother anymore and is compiled for "generic" x86_64 for instance, it is not worth it (and may cause more harm in the end). Usually, you only just care of basic static optimizations, like cache line, fetch code window, alignment, which are more writing "correct" assembly code than anything else. And even with that, in the worst case scenarios, one could write some specific micro-arch code paths, not an issue while thinking long term of many software components life cycle, which would be "installed"/"branched to" at runtime. At least that knowledge would not be hidden deep in the absurd complexity of an optimizing compiler...
        bluGill 3y ago
madushan1000 3y ago
What do you mean? most complicated parts of the gpu driver are in userland and handled by Mesa or equivalent. Kernel drivers expose a standard interface(DRM) which userspace drivers use to upload compiled gpu programs and manage gpu memory. Also, linux is not tied to gcc extensions, it can be compiled with llvm(clang) for a long time now.
- sylware 3y ago
  What you said is mostly wrong. The kernel part of the GPU driver is massive. It is well known, maybe you were misguided: for instance the AMD GPU drivers are gigantic compared to the actual kernel. clang(llvm) is playing cat and mouse with gcc extensions and recent ISO C tantrums which creeps into the kernel:Linus T. does not resist those, he does resist only the linux useland ABI(syscalls) breakers.
  - madushan1000 3y ago
    It's also well known the driver is massive because there are hundreds of thousands of lines of auto-generated register access code in there. Not because it's inherently very complex.
    - sylware 3y ago
      And again you are wrong. It was debunked not a long time ago, and I think it was here on HN. The AMD drivers, kernel side, are still gigantic even excluding the generated register descriptions. Is this what we call a AI lie? But where you may be right: it seems nvidia hardware programming interface is much cleaner than AMD one and may require much much less code.
vmfunction 3y ago
>We must have a GPU hardware programming "standard" first. Isn't that what WebGPU has become?
- flohofwoe 3y ago
  The WebGPU API is very far removed from the hardware. It's the common subset of Vulkan, D3D12 and Metal, each of those APIs also being fairly high level abstractions over different GPU architectures.
  - sylware 3y ago
    I don't know about webGPU, but it seems you missed the word "hardware" in "hardware programming interface", like NVMe is for non volatile memory device.
    - flohofwoe 3y ago
      I was replying to the "Isn't that what WebGPU has become?". The WebGPU programming model is already too high level for a "hardware programming interface". WebGPU is designed to sit on top of other 3D APIs, which in turn sit on GPU vendor drivers, and most of the complexity and 'hidden magic' is in those drivers.
      - sylware 3y ago
        oops! wrong reply button, my bad.

deleted 3y ago

[deleted]