The Possibility Of Nouveau 1.0.0?

[phoronix]

Phoronix: The Possibility Of Nouveau 1.0.0?

Following the very heated kernel DRM discussion that came about as the result of a major interface break in the Nouveau DRM code, David Airlie has asked on the Nouveau mailing list about potentially releasing Nouveau 1.0.0. Right now the Nouveau interface is at 0.0.16 and is wondering if developers will accept just renaming the current code to version 1.0.0.This proposal is being considered so that all old user-space compatibility is gone, there is no more user-space mode-setting to support (the code is already removed), and so that there can finally be an officially released version that Linux distributions can utilize and support...

http://www.phoronix.com/vr.php?view=ODAzNQ

[sylware]

kludge

I just setup a nouveau stack on my workstation, with a 2.6.33. I had to downgrade libdrm 2.4.28.
From there, I have some rendering issue of fonts in xterm, but not in vte.

I had a look at the API breakage, and noticed that the new kernel graphic stack is turning into a gigantic kludge:
GEM on top of TTM? everything on top of DRM kernel abstration layer?

Maybe the main-branch inclusion will stimulate the cleanup of such stack:
- removal of kernel abstraction layer.
- GEM or TTM, for good.
- GNU GPL to get leverage in order to hunt optimal code.

I don't have brain time for this... but as soon as I have... I'm just around the corner.

But I have to congratulate all those coders for the work done (those without a secret NDA though). Indeed, what was achieved is amazing.

[TechMage89]

It's not a good idea generally to have a lot of DRM code licensed GPL. Remember that modern *BSD OSes also share this stack, so it must be licensed BSD (or something equally nonrestrictive) if they are to make use of it.

GEM is an API. TTM is a framework. GEM specifies only the API exposed to the outside world, and appears to work fine for that. TTM makes designing the internals to implement that API easier.

I'm not exactly sure how I feel about moving a larger part of the graphics stack in-kernel (especially when it seems that many OSes, eg. Windows Vista/7 are moving the _entire_ graphics stack into user-space), but there are good reasons for the way things are done.

[bridgman]

I believe all of the OSes are converging on more or less the same model -- low level code (including most or all hardware access) in the kernel, with higher level portions of the driver in user space.

Vista and Win7 have a "KMD" (Kernel Mode Driver) which handles roughly the same functionality as a KMS-enabled drm driver in a modern X/DRI stack.

[Remco]

I believe all of the OSes are converging on more or less the same model -- low level code (including most or all hardware access) in the kernel, with higher level portions of the driver in user space.

Vista and Win7 have a "KMD" (Kernel Mode Driver) which handles roughly the same functionality as a KMS-enabled drm driver in a modern X/DRI stack.

And let's not forget the good old MINIX, which has strict layering of the kernel for every part. (But it doesn't do GPU acceleration.)