Page 1 of 2 12 LastLast
Results 1 to 10 of 125

Thread: NVIDIA Talks Of Optimus Possibilities For Linux

Hybrid View

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

    Default NVIDIA Talks Of Optimus Possibilities For Linux

    Phoronix: NVIDIA Talks Of Optimus Possibilities For Linux

    A NVIDIA Linux engineer is trying to work on code that could lead to official Optimus support under Linux, but there's a catch... And it falls outside of NVIDIA Corp as the fate of this multi-GPU notebook feature could now fall with the Linux kernel developers...

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

  2. #2
    Join Date
    Nov 2009
    Location
    Italy
    Posts
    906

    Default

    No, it's sad having to use proprietary drivers.
    Nvidia, enjoy re-implementing the wheel.
    ## VGA ##
    AMD: X1950XTX, HD3870, HD5870
    Intel: GMA45, HD3000 (Core i5 2500K)

  3. #3
    Join Date
    Jun 2009
    Posts
    2,926

    Default

    That "patch" was cute.

    It amounted to a license change of the code (symbol) in question because an nvidia engineer thought this license to be better.

  4. #4

    Default

    Isn't that mean DMA-BUF may be used in Intel, nouveau and R600g drivers for implementation Optimus and AMD Dual Graphics in FOSS drivers?

  5. #5
    Join Date
    Dec 2007
    Posts
    2,320

    Default

    It's meant for sharing dma-able memory between drivers. That could be muxless hybrid laptops, zero copy video between v4l and drm, etc.

  6. #6
    Join Date
    Dec 2007
    Location
    Edinburgh, Scotland
    Posts
    574

    Default

    The whole point of Symbol GPL was to prevent non-GPL code using it as a derived work - the reason Nvidia's binary blob works is it's LGPL wrapper on symbols that don't have symbol GPL exported

    They've gotten away with this because Linus, quite rightly, points out that the Nvidia binary isn't using the interfaces as a derived work (they've already got it working on so many platforms that it can't be Linux Kernel secret sauce)

    This wouldn't be the case with dma-buf they would be clearly deriving something new and something they didn't help develop

    Perhaps if they were willing to create a binary Intel driver similar to AMD's work that could bypass all the open source work including dma-buf it would keep them in a safer place from a legal perspective

    As much as I'd like to see them adopt a standard Symbol GPL was added specifically for this reason

  7. #7
    Join Date
    Jan 2007
    Posts
    459

    Default

    Quote Originally Posted by RussianNeuroMancer View Post
    Isn't that mean DMA-BUF may be used in Intel, nouveau and R600g drivers for implementation Optimus and AMD Dual Graphics in FOSS drivers?
    Quote Originally Posted by agd5f View Post
    It's meant for sharing dma-able memory between drivers. That could be muxless hybrid laptops, zero copy video between v4l and drm, etc.
    AMBER GRANER of the
    Linaro vendors
    did a write-up of why ARM needs it
    http://www.linaro.org/linaro-blog/20...-linux-kernel/
    POSTED ON
    JANUARY 12, 2012
    BY
    AMBER GRANER
    Linaro’s Emphasis on dma_buf in the 3.3 Linux Kernel


    Jesse Barker, Graphics WG (Working Group) Tech Lead for Linaro shares with readers the importance and challenges in getting dma_buf inclusion for 3.3 Linux Kernel.Back in April, as we—a collective group of hardware vendors, software vendors, kernel developers and maintainers from across many areas of the Linux community—were preparing for the memory management mini-summit at Linaro Connect (still called Linaro Developer Summit at the time), and later during the event itself, identified three main areas within the kernel that would need explicit attention, if our “holy grail” use case of a zero-copy video to graphics to display pipeline were to be realized. There were user-space API considerations as well; however, we needed to focus on the kernel first.

    First, we needed to address the requirement of devices that lack ......
    ...
    ....
    Last, but not least, we needed a way for device drivers within the kernel to “share” buffers, that is to have the same buffer mapped for access by multiple devices. This is the crux of the zero-copy pipeline. The core piece of this mechanism is a kernel data structure called “struct dma_buf” which gives device drivers the interfaces they need to negotiate this sharing. Version 3 of the initial proposal for the basic plumbing (much more functionality is needed to fully support something like a modern GPU driver) was recently integrated into Dave Airlie’s DRM tree and pulled into Linus Torvalds’ kernel tree for 3.3 of the Linux kernel. .....


    https://wiki.linaro.org/OfficeofCTO/MemoryManagement
    Memory / Buffer Management

    Overview

    Architecture for hardware accelerators- efficient mechanism for memory sharing and plug-in. Currently, multiple methods used for memory sharing and SoC specific performance optimizations. Consolidation and upstreaming of the merged module is required. A common and efficient mechanism with the capability to use virtual memory for accelerators.
    • Share buffers across ARM, video hw and GPU
    • Similar to hwmem/UMP API but single widely adopted API across all
    • Relying on memory regions and hotplug
    Activity in kernel WG + MM experts from landing teams. Visibility into proprietary MM from each Vendor is required
    Project tracking for discrete work items can be found here


    Last edited by popper; 01-26-2012 at 10:17 AM.

  8. #8
    Join Date
    Dec 2008
    Posts
    82

    Default I don't understand...

    "but we for better or worse can't share much infrastructure like DRI."

    I don't understand why they can't do that ?
    They can't share the user space OpenGL driver, I can understand, but why the DRI ?
    The DRI part could be split from the user space OGL driver and could live in the kernel space, I believe that a number of SoC vendors already behave like this.
    Last edited by spykes; 01-25-2012 at 11:36 AM. Reason: typo

  9. #9

    Default

    Alan Cox is one of the developers objecting to the change.
    Should read as:

    Fuck Linux as a viable gaming platform.

    Fuck desktop Linux.

    We are quite content with semi-working dead slow open source drivers for ATI/NVIDIA (which don't support well power saving features thus no sane laptop user should ever use them).


    With such an attitude Linux will always have 1-1,5% market share. And don't even get me started on Stable API nonsense and lack of real backward libraries compatibility (it's just not there).
    Last edited by birdie; 01-25-2012 at 11:50 AM.

  10. #10
    Join Date
    Jun 2009
    Posts
    2,926

    Default

    Quote Originally Posted by birdie View Post
    Should read as:

    Fuck Linux as a viable gaming platform.

    Fuck desktop Linux.

    We are quite content with semi-working dead slow open source drivers for ATI/NVIDIA (which don't support well power saving features thus no sane laptop user should ever use them).


    With such an attitude Linux will always have 1-1,5% market share. And don't even get me started on Stable API nonsense and lack of real backward libraries compatibility (it's just not there).
    NVidia's binary blobs have been around for more than a decade, offer good performance, and still they didn't propell Linux to 90% desktop share. And now it's Alan Cox' fault?

    Why do you think it is exactly THIS license change which will bring all gaming to Linux and make it THE desktop for all (tm)?

Posting Permissions

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