tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]


On 7/6/23 20:32, 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 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.

Home | Main Index | Thread Index | Old Index