Results 1 to 7 of 7

Thread: Radeon VM, DMA-BUF Will Go Into Linux 3.3 Kernel

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

    Default Radeon VM, DMA-BUF Will Go Into Linux 3.3 Kernel

    Phoronix: Radeon VM, DMA-BUF Will Go Into Linux 3.3 Kernel

    The Radeon virtual memory (VM) support -- part of the Radeon HD 7000 series upbringing -- is now in the DRM next tree for landing in the Linux 3.3 kernel. Separate from the expected 3.3 graphics pull request, Linaro's "dma-buf" has already been sent to Linus Torvalds for merging into the mainline tree...

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

  2. #2
    Join Date
    Nov 2008
    Location
    Madison, WI, USA
    Posts
    881

    Default

    Quote Originally Posted by phoronix View Post
    Phoronix: Radeon VM, DMA-BUF Will Go Into Linux 3.3 Kernel

    The Radeon virtual memory (VM) support -- part of the Radeon HD 7000 series upbringing -- is now in the DRM next tree for landing in the Linux 3.3 kernel. Separate from the expected 3.3 graphics pull request, Linaro's "dma-buf" has already been sent to Linus Torvalds for merging into the mainline tree...

    http://www.phoronix.com/vr.php?view=MTAzODQ
    If I'm reading all of the mailing list messages correctly, this is the buffer sharing support that will eventually be needed for sharing/transferring buffers between separate hardware drivers, which could have direct applications with things like Optimus and crossfire-like setups.

  3. #3
    Join Date
    Mar 2009
    Location
    in front of my box :p
    Posts
    828

    Default

    Ah I love these previews. Watering my mouth for the next kernel.
    Yeah that buffer sharing sounds kinda neat. I guess that would also work then between completely different GPUs, a constellation you might find on a bunch of machines.

    On the legal review side on radeons I wish we would soon have a real utilization of the UVD ASICs.

  4. #4
    Join Date
    Mar 2009
    Posts
    86

    Default

    Yeah, this would be great for optimus and crossfire, if it weren't using the user-hating EXPORT_SYMBOL_GPL:
    Code:
    $ git diff -M origin/master a125a3945c950caef001f22055bf201a36568533 | grep +EXPORT_SYMBOL
    +EXPORT_SYMBOL_GPL(dma_buf_export);
    +EXPORT_SYMBOL_GPL(dma_buf_fd);
    +EXPORT_SYMBOL_GPL(dma_buf_get);
    +EXPORT_SYMBOL_GPL(dma_buf_put);
    +EXPORT_SYMBOL_GPL(dma_buf_attach);
    +EXPORT_SYMBOL_GPL(dma_buf_detach);
    +EXPORT_SYMBOL_GPL(dma_buf_map_attachment);
    +EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment);

  5. #5
    Join Date
    Nov 2008
    Location
    Germany
    Posts
    5,411

    Default

    Quote Originally Posted by md1032 View Post
    Yeah, this would be great for optimus and crossfire, if it weren't using the user-hating EXPORT_SYMBOL_GPL:
    Code:
    $ git diff -M origin/master a125a3945c950caef001f22055bf201a36568533 | grep +EXPORT_SYMBOL
    +EXPORT_SYMBOL_GPL(dma_buf_export);
    +EXPORT_SYMBOL_GPL(dma_buf_fd);
    +EXPORT_SYMBOL_GPL(dma_buf_get);
    +EXPORT_SYMBOL_GPL(dma_buf_put);
    +EXPORT_SYMBOL_GPL(dma_buf_attach);
    +EXPORT_SYMBOL_GPL(dma_buf_detach);
    +EXPORT_SYMBOL_GPL(dma_buf_map_attachment);
    +EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment);
    maybe the GPL isn't the problem maybe optimus(nvidia) and crossfire(amd) are the problem!

  6. #6
    Join Date
    Sep 2007
    Location
    Connecticut,USA
    Posts
    974

    Default

    Quote Originally Posted by Qaridarium View Post
    maybe the GPL isn't the problem maybe optimus(nvidia) and crossfire(amd) are the problem!
    Thought AMD's Crossfire was similar to nVidia's SLI?

  7. #7
    Join Date
    Oct 2011
    Location
    Toruń, Poland
    Posts
    160

    Default

    I wonder. Is AMD's CrossFire locked by third-party licences? I mean, is there any chance of seeing it implemented in the free driver?

Posting Permissions

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