5 ms·

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 depe

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
        Unless you are building your own custom kernel (ie gentoo) CPU specific optimizations are not worth it as they are worse for any other CPU even if the code is still run. Most software never had those micro optimizations applied, because most software wants to have one build that runs any many different CPUs, but if you want to make an exception it is still possible with compiled code. While you can write those micro optimizations for each CPU by hand, they not worth the human cost except in very rare situations. In most cases of course you can't measure the difference, as only a couple CPU cycles are saved.
  - mkl 3y ago
    What you are proposing is so terrible in practice that people have invented hundreds of programming languages to escape it. Millions of person-hours have been spent on getting away from what you say is desirable.
    - sylware 3y ago
      You are right in a legacy context where the mess of ISAs required an abstraction of the assembly language. But where you are wrong is, moving forward in a world with a modern worldwide standard ISA (RISC-V) is actually writing a kernel in assembly (without abusing any preprocessing).
      - mkl 3y ago
        People have had the ability to do that for decades, and they have almost always chosen not to when they had the option, because it's terrible. RISC-V is nothing revolutionary on that front, and doesn't magically make it better. Without preprocessing you won't have variable names or jump label names or strings, which is even more terrible. Please give us some actual evidence, instead of just saying "you're wrong", because the position you're taking seems extreme and, frankly, bonkers.
        sylware 3y ago
        I said without abusing the preprocessing, not without preprocessing at all. My opinion is this is wrong, and I did voice my disagrement and gave my own view on the matter. If there is something extreme here is the karma slash upon displeasing the pro rust people and AI bots on HN.
        jodrellblank 3y ago
        > "If there is something extreme here is the karma slash upon displeasing the pro rust people and AI bots on HN." It's refusing to backup your position with anything more than saying "you're wrong" "you're wrong" "you're wrong". You've repeatedly been asked to explain why RISC_V would be better, why RISC_V changes anything, what you propose for how it would work (e.g. emulators), and you haven't. That's annoying, timewasting, and downvoteworthy.
  - BatmanAoD 3y ago
    Are you proposing a kernel that would only run on risc-v hardware, or expecting that people would run some kind of emulator? ....or do you think that because RISC-V is "standard", assembly for RISC-V would run on any hardware?
    - sylware 3y ago
      The "right way" would be CPU vendors to support that standard. But I have thought about running a 64bits RISC-V interpreter on x86_64 (Mr Bellard, ffmpeg, tinycc, etc, wrote a risc-v emulator which could be as a based for that), and that in the kernel. Basically, you would have RISC-V assembly for x86_64 arch: at least, RISC-V here would be stellar more robust and stable that all the features creeps we have in the linux kernel because of the never ending gcc extensions addition and latest ISO C tantrums...
      - BatmanAoD 3y ago
        So the "right way" is to replace all hardware with new hardware, and the second-best solution is for CISC systems to emulate a specific RISC architecture? And you think this will be more maintainable, performant, etc? Do you have even a shred of evidence that this makes any sense at all, beyond "RISC is a good standard"?
        sylware 3y ago
        This would not happen overnight! It would a slow process. Of course you will need still RISC-V support in current compilers for legacy software. RISC-V is a modern "good enough" with "good balance" ISA, everything is about trade-off, hence "perfection" does not make any sense. What is really different with RISC-V: it is already there, moving forward, is worldwide PI lockfree (unlike x86_64 and arm). Ofc, without extremely performant implementations (micro-arch and silicium process), all over the board (server/mobile/workstation/"embedded") it will probably fail. And I do believe we could get a very good middle ground with very high level language interpreters (python/lua/etc) directly coded in RISC-V assembly. And I am thinking about RISC-V... as a computer language with some compilerS (not JIT). I may investigate how much out-of-the-box-thinking and disruptive this is, hopefully soon enough.
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.

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
        Unless you are building your own custom kernel (ie gentoo) CPU specific optimizations are not worth it as they are worse for any other CPU even if the code is still run. Most software never had those micro optimizations applied, because most software wants to have one build that runs any many different CPUs, but if you want to make an exception it is still possible with compiled code. While you can write those micro optimizations for each CPU by hand, they not worth the human cost except in very rare situations. In most cases of course you can't measure the difference, as only a couple CPU cycles are saved.
- mkl 3y ago
  What you are proposing is so terrible in practice that people have invented hundreds of programming languages to escape it. Millions of person-hours have been spent on getting away from what you say is desirable.
  - sylware 3y ago
    You are right in a legacy context where the mess of ISAs required an abstraction of the assembly language. But where you are wrong is, moving forward in a world with a modern worldwide standard ISA (RISC-V) is actually writing a kernel in assembly (without abusing any preprocessing).
    - mkl 3y ago
      People have had the ability to do that for decades, and they have almost always chosen not to when they had the option, because it's terrible. RISC-V is nothing revolutionary on that front, and doesn't magically make it better. Without preprocessing you won't have variable names or jump label names or strings, which is even more terrible. Please give us some actual evidence, instead of just saying "you're wrong", because the position you're taking seems extreme and, frankly, bonkers.
      - sylware 3y ago
        I said without abusing the preprocessing, not without preprocessing at all. My opinion is this is wrong, and I did voice my disagrement and gave my own view on the matter. If there is something extreme here is the karma slash upon displeasing the pro rust people and AI bots on HN.
        jodrellblank 3y ago
        > "If there is something extreme here is the karma slash upon displeasing the pro rust people and AI bots on HN." It's refusing to backup your position with anything more than saying "you're wrong" "you're wrong" "you're wrong". You've repeatedly been asked to explain why RISC_V would be better, why RISC_V changes anything, what you propose for how it would work (e.g. emulators), and you haven't. That's annoying, timewasting, and downvoteworthy.
- BatmanAoD 3y ago
  Are you proposing a kernel that would only run on risc-v hardware, or expecting that people would run some kind of emulator? ....or do you think that because RISC-V is "standard", assembly for RISC-V would run on any hardware?
  - sylware 3y ago
    The "right way" would be CPU vendors to support that standard. But I have thought about running a 64bits RISC-V interpreter on x86_64 (Mr Bellard, ffmpeg, tinycc, etc, wrote a risc-v emulator which could be as a based for that), and that in the kernel. Basically, you would have RISC-V assembly for x86_64 arch: at least, RISC-V here would be stellar more robust and stable that all the features creeps we have in the linux kernel because of the never ending gcc extensions addition and latest ISO C tantrums...
    - BatmanAoD 3y ago
      So the "right way" is to replace all hardware with new hardware, and the second-best solution is for CISC systems to emulate a specific RISC architecture? And you think this will be more maintainable, performant, etc? Do you have even a shred of evidence that this makes any sense at all, beyond "RISC is a good standard"?
      - sylware 3y ago
        This would not happen overnight! It would a slow process. Of course you will need still RISC-V support in current compilers for legacy software. RISC-V is a modern "good enough" with "good balance" ISA, everything is about trade-off, hence "perfection" does not make any sense. What is really different with RISC-V: it is already there, moving forward, is worldwide PI lockfree (unlike x86_64 and arm). Ofc, without extremely performant implementations (micro-arch and silicium process), all over the board (server/mobile/workstation/"embedded") it will probably fail. And I do believe we could get a very good middle ground with very high level language interpreters (python/lua/etc) directly coded in RISC-V assembly. And I am thinking about RISC-V... as a computer language with some compilerS (not JIT). I may investigate how much out-of-the-box-thinking and disruptive this is, hopefully soon enough.

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.