Results 1 to 5 of 5

Thread: The Possibility Of Nouveau 1.0.0?

  1. #1
    Join Date
    Jan 2007
    Posts
    14,220

    Default The Possibility Of Nouveau 1.0.0?

    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

  2. #2
    Join Date
    Dec 2008
    Posts
    166

    Default 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.

  3. #3
    Join Date
    Jul 2007
    Posts
    403

    Default

    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.

  4. #4
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,379

    Default

    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.

  5. #5
    Join Date
    Sep 2008
    Location
    Netherlands
    Posts
    510

    Default

    Quote Originally Posted by bridgman View Post
    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.)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •