21–30 of 77 posts
Should someone decided that they'd start working through the code, removing duplicate code and clean up headers, functions and abstraction, they work would either be rejected, or undone with the next AMD code dump?
It's not completely clear from the article, but: are the files generated 'on-the-fly' during the build process (and therefore not in git), or generated once (by AMD), and then committed?
So while the AMD driver is open source, the community is basically excluded from contributing? Should someone decided that they'd start working through the code, removing duplicate code and clean up headers, functions and abstraction, they work would either be rejected, or undone with the next AMD code dump?
"Of course, much of that is auto-generated header files... A large portion of it with AMD continuing to introduce new auto-generated header files with each new generation/version of a given block. These verbose header files has been AMD's alternative to creating exhaustive public documentation on their GPUs that they were once known for." So what's the point of saying that it's large?
Because it's large and large is difficult to maintain. AMD maintains it but do we know how they are generated? Probably not. It's like a gift that stinks but you can't complain about because it's a gift.
Basically those files are generated from AMD GPU register data files where majorify of registers are documented, but there of course bunch of magic numbers as well probably because they belong to HDCP or other cases where documentation only available under NDA.
There been a number of leaks of AMD internal documentation so anyone who is into GPU drivers can really find a lot of information on their GPU internal workings.
I've archieved some of it many years ago and it's was never DMCA*ed:
https://github.com/ArseniyShestakov/rai-bonaire
Source was a talk on CCC.
I'm not sure I get why the comparison to the Kernel is needed. GPUs are wildly complex. Rendering is wildly complex. Managing memory and data is complex. Managing connected hardware is complex. I am not sure why anyone would expect a GPU Driver to be small while also doing a billion things and playing games as well as mature gaming platforms.
I raised an eyebrow but I have only the vaguest notion of how the hardware works and what a driver might have to manage.
Earlier quoted context omitted.
>but do we know how they are generated? Probably not Having worked in the semi industry, I can fathom a guess: It's a spaghetti mess of cascading Perl scripts that parse the Verilog/VHDL design files, with their development going back 20+ years, full of comments like "don't touch this line because it breaks another line, nobody knows why", and maintained by a team where a gray-beard "Gandalf" engineer wearing an ATI…
Having too worked in the semi industry, this is spot on
So while the AMD driver is open source, the community is basically excluded from contributing? Should someone decided that they'd start working through the code, removing duplicate code and clean up headers, functions and abstraction, they work would either be rejected, or undone with the next AMD code dump?
A lot of open source projects work that way. Open source means you get access to the source and get to make changes for your own use. It doesn't mean you get to force anyone else to merge your code.
Sure, you can fork the code if you really feel that strongly about it. My main "issue" is that it basically removes one of the big benefits of open source, that we can collaborate and do better as a collective. If it's just a big code dump that other kernel developers can't really touch it's more "source code is available" than actual open source.
I'm not sure I get why the comparison to the Kernel is needed. GPUs are wildly complex. Rendering is wildly complex. Managing memory and data is complex. Managing connected hardware is complex. I am not sure why anyone would expect a GPU Driver to be small while also doing a billion things and playing games as well as mature gaming platforms.
If you're not intimately familiar with GPU drivers and what goes on this gives you a very quick, back-of-the-envelope of the size and complexity of the work involved. 1/7th the size and complexity of the kernel for this one driver. I raised an eyebrow but I have only the vaguest notion of how the hardware works and what a driver might have to manage.
Probably if AMD wanted to spend the time, they could compress it down to a fraction of it's current size.
Earlier quoted context omitted.
A lot of open source projects work that way. Open source means you get access to the source and get to make changes for your own use. It doesn't mean you get to force anyone else to merge your code.
> It doesn't mean you get to force anyone else to merge your code. Sure, you can fork the code if you really feel that strongly about it. My main "issue" is that it basically removes one of the big benefits of open source, that we can collaborate and do better as a collective. If it's just a big code dump that other kernel developers can't really touch it's more "source code is available" than actual open source.
Earlier quoted context omitted.
A lot of open source projects work that way. Open source means you get access to the source and get to make changes for your own use. It doesn't mean you get to force anyone else to merge your code.
> It doesn't mean you get to force anyone else to merge your code. Sure, you can fork the code if you really feel that strongly about it. My main "issue" is that it basically removes one of the big benefits of open source, that we can collaborate and do better as a collective. If it's just a big code dump that other kernel developers can't really touch it's more "source code is available" than actual open source.
When you send someone a PR, you are demanding that they do work for you to review and merge. Open source licensing does not mandate that they do this. Heck, most open source licenses even disclaim warranty to avoid obligating the authors of even doing work that the law would otherwise require them to do. Now yes, some people will help you with problems. This is because they're nice, not because it's open source.