Page 1 of 9 123 ... LastLast
Results 1 to 10 of 132

Thread: NVIDIA Developer Talks Openly About Linux Support

Hybrid View

  1. #1
    Join Date
    Jan 2007
    Posts
    15,138

    Default NVIDIA Developer Talks Openly About Linux Support

    Phoronix: NVIDIA Developer Talks Openly About Linux Support

    In late August we started asking our readers for any questions they had for NVIDIA about Linux and this graphics company's support of open-source operating systems. Twelve pages worth of questions were accumulated and we finally have the answers to a majority of them. NVIDIA's Andy Ritger, who leads the user-space side of the NVIDIA UNIX Graphics Driver team for workstation, desktop, and notebook GPUs, answered these questions. With that said, there are some great, in-depth technical answers and not the usual marketing speak found in many interviews. While Linux is our focus, Andy's team and his answers for the most part apply equally to NVIDIA drivers on Solaris and FreeBSD platforms too. There are many questions that range from the status of new features in their proprietary graphics driver to why it is unlikely there will be any official open-source support from NVIDIA to download percentages of their Linux driver.

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

  2. #2
    Join Date
    Oct 2007
    Location
    Poland
    Posts
    197

    Default

    Nice article !!


    btw.
    vim FTW ! :E

  3. #3
    Join Date
    Nov 2008
    Posts
    69

    Default

    Yeah good interview. It did just have the effect of making me more sure that I'll stick with AMD though

  4. #4
    Join Date
    Mar 2009
    Posts
    18

    Default Nothing new...



    Nothing new:
    - NO KMS
    - NO Gallium3D
    - NO EXA
    - NO SLI, NO All-Good-NVIDIA-Windowzer-Stuuf
    - NO everything to a Linux NVIDIA Customer

    I'm really thinking in changing to ATI, since I don't use this #$#@ they call Windows.

    Thanks NVIDIA for supporting us, Linux users

  5. #5
    Join Date
    Sep 2007
    Posts
    122

    Default

    Quote Originally Posted by Raine View Post
    - NO KMS
    Read again.

    - NO Gallium3D
    What for? NVidia's driver already has excellent acceleration w/ NVidia's own framework.

    - NO EXA
    Again, why? NVidia already provides fast 2D acceleration and did so before EXA saw the light of the day.

    - NO SLI, NO All-Good-NVIDIA-Windowzer-Stuuf
    I'm not sure what you mean. SLI works fine.

    That being said, I think it's a bit sad that NVidia won't be able to help the Nouveau guys. At least some hardware documentation under NDA would be pretty nice, if nothing else seems to be possible.
    Last edited by greg; 10-20-2009 at 12:55 PM.

  6. #6
    Join Date
    Mar 2009
    Posts
    18

    Default Re: Nothing new...

    [QUOTE=greg;96509]

    Hi greg!

    > Read again.

    Err...extracted from the article:

    Nothing definite, no, but we do get a lot of requests for it and it is something I hope we can pursue in the future.

    Hope is not a definite thing
    What I've meant was in near term. Not in a long possible term...

    > - NO Gallium3D
    > - NO EXA
    >> What for? NVidia's driver already has excellent acceleration w/ NVidia's own framework.
    >> Again, why? NVidia already provides fast 2D acceleration and did so before EXA saw the light of the day.

    Why? Standard/kernel developers/community approved way to do things inside the Linux kernel is not important here? Debugging facilities, very small term improvements (i.e. look KMS feature lack time frame on Nvidia), fast community driven bug fix response time, etc...

    Maybe the architecture inside nvidia's proprietary driver is really good even on 2D acceleration, but not on Linux's kernel way.

    How can the community help improving overall desktop experience performance without following the Linux's kernel ways?

    But, I respect (but not agree) the fact tha Nvidia has it's reasons (IP and financial ones) not do so

    > - NO SLI, NO All-Good-NVIDIA-Windowzer-Stuuf
    >> I'm not sure what you mean. SLI works fine.

    Sorry...my bad. I was half thinking on SLI and PhysX when writing.

    I was referring to SLI profiling and better control-settings-panel (like Windows has).

    On the other side, you haven't agree in the fact PhysX and other really interesting things from Windows drivers don't exists on Linux drivers

    >That being said, I think it's a bit sad that NVidia won't be able to >help the Nouveau guys. At least some hardware documentation under NDA >would be pretty nice, if nothing else seems to be possible.

    Unfortunately they can't help them. But fortunately we (community) have *always* other's ways to do so, like nouveau guys


    Quote Originally Posted by mtippett View Post

    The assumption that a single implementation is the *only* path to achieving a user visible feature usually ends up with comprimise. The composited desktop has many paths right now. XGL was an interesting idea, but ultimately went away. Same for EXA for intel (UXA).

    Regards,

    Matthew
    Hi Matthew!

    But no as Linux's kernel approved and correct way.


    Regards,
    Raine
    Last edited by Raine; 10-20-2009 at 04:26 PM.

  7. #7
    Join Date
    Jun 2006
    Posts
    311

    Default

    Quote Originally Posted by Raine View Post
    Nothing definite, no, but we do get a lot of requests for it and it is something I hope we can pursue in the future.

    Hope is not a definite thing
    What I've meant was in near term. Not in a long possible term...
    It's PR speak. "Hope" is nearly the exact opposite to "no plans". These are closer to neutral than "have plans" and "won't" respectively.

    I'd personally look to push the Unigine demos (Tropics, their upcoming ones) as great techdemos. It's cross platform, they have a commitment for Linux and it's great eyecandy. Get them as part of the staple for both Linux and Windows bencharking, and you won't need the demos.

    (If we can displace furmark for OpenGL testing with something cross-platform it helps keep the OS neutral technologies.)

    But no as Linux's kernel approved and correct way.
    The "approved way" is transient, there is no stable API under Linux. The "correct way" is even less realistic. TTM/GEM/etc, the churn is expensive for the components that hook into it. If you are out of tree, you get the cost of churn (in the kernel interface layers), but the stability in the areas that you care about.

    Realistically, the OSS drivers circulate and refactor out interfaces to improve maintainability. The binary drivers extract out functionality to provide stability and increase re-use. Different purposes triggered by different constraints.

  8. #8
    Join Date
    Sep 2007
    Posts
    122

    Default

    Quote Originally Posted by Raine View Post
    Why? Standard/kernel developers/community approved way to do things inside the Linux kernel is not important here? Debugging facilities, very small term improvements (i.e. look KMS feature lack time frame on Nvidia), fast community driven bug fix response time, etc...
    There is no "approved" or "correct" way, especially when it comes to Linux. APIs and interfaces change *all the time*. And there isn't just Linux, but FreeBSD and Solaris as well, which are interested in GPU support.

    On the other side, you haven't agree in the fact PhysX and other really interesting things from Windows drivers don't exists on Linux drivers
    PhysX will hopefully go away soon-ish and that's NVidia's fault. What else is missing in the Linux drivers?

  9. #9
    Join Date
    Jun 2006
    Posts
    311

    Default

    The main comments below are asking what is the usage of the tech, not what is the tech itself.

    Quote Originally Posted by Raine View Post

    Nothing new:
    - NO KMS
    KMS is an interesting one, where do you get value from this? There are a couple of areas that it might add vale.

    o BSOD equivalence - get the log messages on the screen with an oops. The joke of the Windows world applied to Linux. I would expect it'll feel just like the old Sun Workstations from 20 years ago.
    o "Flicker free" boot. Well, I don't really see too many problems with this. Sure Apple has it - but that is a closed system, top to bottom. But what value does it *really* provide?

    - NO Gallium3D
    - NO EXA
    These are implementation details. Let me translate

    o Gallium3D (or DRI2) - Full support for composited environments, OpenGL, OpenCL, xV client support. You already get that without it on NV and ATI drivers. Just a different model. Gallium3D is a refactoring of the architecture to easily support more clients without needing lots more developers.
    o EXA - increased 2D performance (and RENDER and dynamic framebuffer realocation). Again, EXA isn't needed. dynamic framebuffer reallocation doesn't need EXA, but it does need RANDR1.2+ to be useful).

    Start with the user or application facing features that you want and dive down from there. What are the features your *really* want.

    The assumption that a single implementation is the *only* path to achieving a user visible feature usually ends up with comprimise. The composited desktop has many paths right now. XGL was an interesting idea, but ultimately went away. Same for EXA for intel (UXA).

    Regards,

    Matthew

  10. #10
    Join Date
    Jun 2009
    Posts
    24

    Default

    Quote Originally Posted by mtippett View Post
    The main comments below are asking what is the usage of the tech, not what is the tech itself.



    KMS is an interesting one, where do you get value from this? There are a couple of areas that it might add vale.

    o BSOD equivalence - get the log messages on the screen with an oops. The joke of the Windows world applied to Linux. I would expect it'll feel just like the old Sun Workstations from 20 years ago.
    o "Flicker free" boot. Well, I don't really see too many problems with this. Sure Apple has it - but that is a closed system, top to bottom. But what value does it *really* provide?
    a large part of the benifit of switching to KMS is simplification. X.org is conenctrating on making this shift, and viewing kernel mode selection as the primary focus going forward.

    they will continue to support the legacy mode (for cards that don't do this, or for OS options that don't implement KMS), but it's going to be just that, legacy, and that means that over time you are better off not using it.

Tags for this Thread

Posting Permissions

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