Re: DRM/KMS

[PHO <pho%cielonegro.org@localhost>]

On 7/6/23 20:32, tlaronde%polynum.com@localhost wrote:
> So I'm proposing to go back to the fork (for this part starting by
> identifying what is immune, orthogonal to the thing) when the Linux
> DRM way was taken and to eject the Linux DRM/KMS.
>
> If DRM has to be addressed, it will be addressed after, but doing it
> our own way.
>
> And I'm proposing to help.

Wait, are you suggesting we should throw the Linux DRM/KMS away and 
build our framework and individual drivers?

Hmm... hmmmm...

I agree that it's a huge convoluted alien that is ridiculously hard to 
tame. I'm currently trying hard to make the half-ported vmwgfx driver 
work on NetBSD. In my local tree it now compiles and successfully 
initializes but fails to correctly update the framebuffer.

There are mainly four reasons why it's so hard to make it work:

1. The kernel API of Linux has too many differences from ours. NetBSD 
doesn't just assume that we can map pages in a DMA-coherent way and 
forget about synchronization. Linux scatter/gather and our bus_dma(9) 
have very different designs. Linux framebuffer and our wsdisplay(9) 
hardly share anything, and so on and so forth.

2. Linux DRM/KMS has accumulated a considerable amount of technical 
debts. Most notably it has two competing memory managers, TTM and GEM. 
TTM is especially hard to comprehend and to use correctly. It's huge, 
complicated, and is basically undocumented.

3. Linux DRM/KMS is written in a way that resembles object-orientation 
but in C. Its extensive use of container_of(), the "object inheritance" 
in DRM/KMS, makes it hard to track where and when an object is 
allocated. The lack of RAII like you do in C++ or Rust makes the code 
too cluttered for human brains. C is just not expressive enough for this 
monster.

4. And of course, GPU is hard. They have so many different operation 
modes, so many different ways to send commands and wait for results, and 
so many commands we have to support, in order for user-space programs 
(like X.org) to work correctly. Their host/device interfaces vary from 
model to model and we have to support all of them.

For 1 and 2, yes, we can get rid of these complexities by designing our 
own DRM/KMS. For 3 we could perhaps use C++, or at least a subset of it, 
like disabling exceptions and prohibiting static non-POD objects. But 
for 4 there's nothing we can do. Redesigning and reimplementing DRM/KMS 
would therefore take years. Are you... ready for it? I'm honestly scared.