3 ms·

The openbsd situation is even worse. over there the driver is bigger than the rest of the kernel. Don't get me wrong I use the driver every day and AMD is defi

by somat 3y ago

The openbsd situation is even worse. over there the driver is bigger than the rest of the kernel. Don't get me wrong I use the driver every day and AMD is definitely one of the good guys for making an open source driver and them who ported it are absolute heros. However.... Sometimes I wish AMD had tied down the isa to their cards a little better. Narrowed the interface if you would. because as it is the driver is so big because there is this combinatorial explosion of generated header files. https://flak.tedunangst.com/post/watc https://flak.tedunangst.com/post/watc

Laaas 3y ago
The issue is that the generated code is checked in. Surely there's a better solution.
- tux3 3y ago
  They _could_ in theory post the (no doubt) Perl scripts that generate those headers from the HDL along with the relevant source files, but I imagine that would be a _very_ hard sell. And probably not much more helpful to the kernel, as no one reads those headers anyways, and the compile time will not improve by shuffling where the generation step happens. It may be more practical to rework the scripts to try to find ways to reduce the verbosity and redundancy. The actual .c driver code probably doesn't need every copy of every lines in all those .h files.
  - alfalfasprout 3y ago
    As long as it's deterministic there should be no issue checking in the generators right?
    - tux3 3y ago
      The generators themselves probably not, but the definition of all those registers is from hardware. These kind of code generators convert input source files that describe the hardware into C header files for the software. But I expect AMD would be skittish about open-sourcing anything that could even remotely be construed as HDL, even if it's just dry lists of registers. Open sourcing the drivers is one thing, but the hardware itself is another.
sroussey 3y ago
There is no business reason to restrict themselves on the ISA, and it would be make their hardware less performant compared to the competition which would not be so bound.
- dogma1138 3y ago
  The competition is very much bound to a rather narrow ISA which is why CUDA is forward and backwards compatible whilst ROCm isn’t. ROCm will be pointless until at least forward compatibility will be guaranteed by design.
  - nimish 3y ago
    CUDA is subsequently compiled to the hardware assembly at runtime isn't it? Like precompiled shaders. C++ -> PTX -> Hardware ISA
  - StillBored 3y ago
    How so? One of the ROCm layers is opencl which does runtime target compilation, and there is also the various intermediate language representations. So, presumably much of this is just lack of sufficient resources to assure that all the different combinations are optimally being compiled down on all the independent HW devices. This was always the OpenCL problem too back before everyone just started using CUDA rather than trying to use it. It worked in a lot of places but the higher level code needed to be adjusted for individual devices because each vendor would do a reasonable job maintaining optimal code generation for their target given code optimized for their target, but switching vendors (AMD<->nvidia) would result in needing two different versions of the code tuned for the individual vendors ideas of how code should be tuned for their platform. If that wasn't clear say you wrote and optimized code for vendor A's device X, when vendor A released device Y, things tended to work well, but moving that code to vendor B's devices basically required retuning/rewritting things.
  - mathisfun123 3y ago
    Someone else already said it but it beats repeating: this is wrong > The competition is very much bound to a rather narrow ISA which is why CUDA is forward and backwards compatible whilst ROCm isn’t. PTX isn't an ISA and it goes through another translation step before it hits the real ISA (SASS), which does change internally. Though you are right that PTX as intermediate is part of the reason for CUDA's success in that it makes the code portable across cards.

by somat 3y ago

Laaas 3y ago

The issue is that the generated code is checked in. Surely there's a better solution.

tux3 3y ago
They _could_ in theory post the (no doubt) Perl scripts that generate those headers from the HDL along with the relevant source files, but I imagine that would be a _very_ hard sell. And probably not much more helpful to the kernel, as no one reads those headers anyways, and the compile time will not improve by shuffling where the generation step happens. It may be more practical to rework the scripts to try to find ways to reduce the verbosity and redundancy. The actual .c driver code probably doesn't need every copy of every lines in all those .h files.
- alfalfasprout 3y ago
  As long as it's deterministic there should be no issue checking in the generators right?
  - tux3 3y ago
    The generators themselves probably not, but the definition of all those registers is from hardware. These kind of code generators convert input source files that describe the hardware into C header files for the software. But I expect AMD would be skittish about open-sourcing anything that could even remotely be construed as HDL, even if it's just dry lists of registers. Open sourcing the drivers is one thing, but the hardware itself is another.

sroussey 3y ago

There is no business reason to restrict themselves on the ISA, and it would be make their hardware less performant compared to the competition which would not be so bound.

dogma1138 3y ago
The competition is very much bound to a rather narrow ISA which is why CUDA is forward and backwards compatible whilst ROCm isn’t. ROCm will be pointless until at least forward compatibility will be guaranteed by design.
- nimish 3y ago
  CUDA is subsequently compiled to the hardware assembly at runtime isn't it? Like precompiled shaders. C++ -> PTX -> Hardware ISA
- StillBored 3y ago
  How so? One of the ROCm layers is opencl which does runtime target compilation, and there is also the various intermediate language representations. So, presumably much of this is just lack of sufficient resources to assure that all the different combinations are optimally being compiled down on all the independent HW devices. This was always the OpenCL problem too back before everyone just started using CUDA rather than trying to use it. It worked in a lot of places but the higher level code needed to be adjusted for individual devices because each vendor would do a reasonable job maintaining optimal code generation for their target given code optimized for their target, but switching vendors (AMD<->nvidia) would result in needing two different versions of the code tuned for the individual vendors ideas of how code should be tuned for their platform. If that wasn't clear say you wrote and optimized code for vendor A's device X, when vendor A released device Y, things tended to work well, but moving that code to vendor B's devices basically required retuning/rewritting things.
- mathisfun123 3y ago
  Someone else already said it but it beats repeating: this is wrong > The competition is very much bound to a rather narrow ISA which is why CUDA is forward and backwards compatible whilst ROCm isn’t. PTX isn't an ISA and it goes through another translation step before it hits the real ISA (SASS), which does change internally. Though you are right that PTX as intermediate is part of the reason for CUDA's success in that it makes the code portable across cards.