Writing an open source GPU driver without the hardware

It may be easier if you do some electronics as a hobby since you can create the devices yourself with simple enough protocols. It gives you a good understanding of how the hardware works at a basic level.

There are thousands of tutorials out there on how to get started writing simple drivers, as well as the excellent book "Linux device drivers".

I don't do _complex_ drivers, but I've been able to write simple ones for my DIY electronic devices (keyboards, sensors, ...) and even a reverse engineered one for my BOSS RC5 guitar pedal.

https://github.com/isometimes/rpi4-osdev

There are other courses/projects for other boards. The keyword is usually “baremetal”.

For Linux drivers specifically there are training material from Bootlin etc. They definitely give you a kickstart—the kernel is so complex that most of the device driver knowledge is organizational and cannot be found on YouTube.

   Can be for old laptop (T420, etc with Intel GPU/Driver.) 
   Use FTRACE in kernel. 
   Setup ebpf trace for GPU acitivies.
   Write some doc/blog/medium pages on the process and show off your works.
   Understand, document and improve some opensource GPU API related utilities
   Understand and document interaction between GPU/GUI App and OpenSource driver.

One keyword is embedded programming. You can start out bare metal basically doing everything in a while(1) loop until you get to a point where different tasks (in the literal way) and peripherals get so much that you will end up doing exactly this, but on a much smaller (and comprehensible) scale.

For example, take something like (1) the simplest AVR microcontroller (the type used in Arduinos, hence there is a ton of third-party documentation and code floating around) and (2) your typical Hitachi HD44780 LED display.

To control the display, one needs to pull certain pins high and low, for specific intervals -- this is all in the HD44780's data sheet. Of course, you don't do this every time you send a character; you abstract this away into functions setchar(x, y, c), clearDisplay(), and so on.

Presto, your first driver!

Then you might think: let's print stuff that we receive via a serial connection. So how do you react to that data? Then you learn about interrupts and interrupt handling.

Then you might think: I could be doing stuff while I wait for I/O. Actually, I'd like to do a lot of stuff, in parallel, but the AVRs are single-core (so to speak). So you do what you've heard other OSes do: take available compute time, divide it into slices, and distribute slices to processes. And thus, you have learned about multi-tasking.

This was relatively simple to do on AVRs, and great fun.

The thing about NetBSD (and I can vouch for OpenBSD being much the same) is that it's so stinking well documented, if you go in knowing C you can learn how to write a simple device driver using just the man pages as your guide. Section 9 of the manual in particular documents every kernel API and most if not all internal types.

It's a great OS to practice developing low-level code with. Linux is a bit harder.

Sure, sometimes there is special sauce in the drivers too

But mostly it’s just culture. Hardware companies also don’t like cloud software…because they think on prem is safer or whatever

- driver can reveal internal workings of their “proprietary” hardware

- they use driver features to further differentiate their hardware product

But really it’s just old tradition and paranoia.

Because when you want to depreciate your old hardware and want to push your customers to new one, open source driver that is maintained, or even worse, add features that should be exclusive to your new hardware, you have a problem. Planned obsolescence is the name of the game in modern hardware industry. And even "open source" drivers like mwlwifi show similar pattern, good look fixing their ¢¢^√°^¢^° firmware.

Of course this also means there is potential for a competitor to gain competitive advantage when they dont have to rely on GPU for revenue and profits generation. I expect or hope that to be Intel. ( That is ignoring GPU's potential patents issues )

Closed source is the norm, no matter if it's a hardware company's driver/companion app or a service company's client app. It's rarely economical, but usually "makes business sense" as in there's one more proprietary thing that you own and that increases your apparent value to investors. Some reasons I've heard:

- opening it would lower the barrier to entry for competitors (as if software is the big barrier) - it could be licensed to other companies in different industries (that almost never happens) - closed source is more secure and therefore less risky (a classic fallacy)

https://rosenzweig.io/blog/asahi-gpu-part-1.html https://rosenzweig.io/blog/asahi-gpu-part-2.html https://rosenzweig.io/blog/asahi-gpu-part-3.html https://rosenzweig.io/blog/asahi-gpu-part-4.html

Hopefully that reaches retail quite soon.