Page 4 of 5 FirstFirst ... 2345 LastLast
Results 31 to 40 of 44

Thread: There's Hope For DMA-BUF With Non-GPL Drivers

  1. #31
    Join Date
    Feb 2012
    Posts
    7

    Default

    I guess we could say that this would be nice+convenient for the short term, but most likely damaging for the long term. So thanks, but no thanks. We can live perfectly well with the blob as-is for a few more years until the OSS drivers will be able to handle this (assuming they will...).

  2. #32
    Join Date
    Jun 2009
    Posts
    582

    Default

    Quote Originally Posted by robclark View Post
    The current situation on all the major ARM platforms (TI/OMAP included) is GPL kernel driver for GPU and closed userspace. So you could argue, "well, GPL kernel module, so you're ok to use EXPORT_SYMBOL_GPL()". But morally, because in the world of GPU the userspace and kernel parts are tighly coupled, that seems to me like following the letter of the law without following the spirit... so I don't think you can really argue that this situation is any better than with nvidia on the desktop.

    ...

    Furthermore, we do really want for nvidia to use dma-buf instead of inventing their own proprietary mechanism which wouldn't interop with the opensrc drivers. Currently the choice seems to be between those two options. One of the main purposes of dma-buf is to have a common solution to replace non-upstream vendor specific solutions for buffer sharing, and not opening up the dma-buf interface prevents that. The fact that dma-buf is mostly an interface, rather than an implementation, plus the fact that we want to get rid of vendor specific buffer sharing solutions with a common upstream mechanism, leads me to the conclusion that using EXPORT_SYMBOL() is the best choice.
    If you put it like this I suppose there is little way we can argue otherwise, can we?

    Still, I believe many others will have doubts about whether this will affect Linux in the long run. No one is going to argue about the short-term advantages, that's for sure. Again, I'm sure many will argue that this may encourage hardware vendors to 'pretend' to play nice with Linux by shipping closed driver blobs, although it can also be counter argued that these future blobs will at least be capable of using Linux's graphics stack implementation, which I suppose is still better than having said blobs replacing those system bits with its own proprietary mechanism. Like you said, following the letter of the law and not the spirit, but then again, wasn't this Linux Torvalds' principle all along? About 'using the tool that works best, and not giving a damn whether it's free or not'.

    Just out of curiosity, since im'm very ignorant about the technicalities of the Linux graphics stack (i only know that 3D is handled by Mesa and Gallium 3D and that 2D is handled by the xfree drivers), if NVIDIA brings optimus support to Linux via DMA-BUF in its driver, will it conflict with Bumblebee's implementation of using VirtualGL? Currently, the only way to get primitive support for Optimus in Linux is to compile VirtualGL, install Bumblebee and perform some config file editing to activate the dedicated NVIDIA card as and when needed, or set it as the main rendering device in the notebook. If NVIDIA gets the go ahead to use DMA-BUF in its blob, will it mean the end of using the blob in Bumblebee and that only Nouveau will become the only driver that can be used with Bumblebee?

  3. #33
    Join Date
    Jun 2009
    Posts
    582

    Default

    Quote Originally Posted by Janell6754 View Post
    I guess we could say that this would be nice+convenient for the short term, but most likely damaging for the long term. So thanks, but no thanks. We can live perfectly well with the blob as-is for a few more years until the OSS drivers will be able to handle this (assuming they will...).
    Sure...like, when Radeon / Nouveau finally achives 70-80% of the latest shipping fglrx's / NVIDIA ForceWare's performance?

  4. #34
    Join Date
    May 2011
    Posts
    1,599

    Default

    Quote Originally Posted by Sonadow View Post
    Because

    - Binary drivers break stuff? (you don't need to be a Linux power user to see how AMD's and NVIDIA's binary driver cause a whole load of problems and replace parts of the standard graphics stack with their own proprietary bits)
    - Binary drivers always break every time a kernel patch is pushed out by a distro? (eg: kernel patch from 2.6.27-20 to 2.6.27-30; this driver breakage 100% guranteed to happen)
    - Open drivers mean that what is not supported officially by NVIDIA / AMD can be done so by the community? Remember that we had no chance with Optimus switchable graphics technology until only recently with the open Bumblebee project
    - Installing binary drivers sets a tainted flag on the kernel, so your bug reports to the kernel guys become thrown down to lowest priority (if at all)?
    1) That's true... they do on occasion break stuff. But in my experience OSS isn't above this problem either. And often times bugs are filed and never resolved... ever. Just look at GNOME to see how imperfect the situation can be. Though, yes, to get in the kernel requires a much higher standard than user space stuff like GNOME. But, just as an anecdote, so far I've only had one driver that hard crashed my system, and that's the kernel Realtek NIC driver, which hard crashes the system so consistently that I had to go to Realtek's site and compile their own driver. My only point here is that OSS is just as much a victim of buggy code than proprietary stuff that's sold on the market.

    2) Okay, now that would piss me off. I've been very fortunate that every time Ubuntu has pushed out a kernel update I have never had any glitches from the process. That could be just because the kernel patches weren't dramatic enough to break something.

    3) That is definitely a major advantage... and I can see why NVIDIA and AMD would like to keep their drivers closed if they can cut off certain functionality based on GPU model (GeForce vs. Quadro, e.g.).

    4) meh. Some of that is kinda petty though. If I have a kernel panic that can clearly be traced back to the NIC driver, are they going to ignore a bug report just because I have VirtualBox or the nvidia driver installed? That doesn't instill a lot of confidence in me.


    Quote Originally Posted by quintesse View Post
    One word: control. If you don't have the source available under an open/free license you're completely at the mercy of your provider. Sure, NVidia has a nice track-record of supporting all their latest and quite a bit of their older gfx card. Good for them, but what happens if they go out of business tomorrow, or just decide Linux is not worth it anymore? Or, as they have done, that older gfx cards are not worth the trouble maintaining?
    Yeah, if nvidia evaporated tomorrow that would definitely fall into the suck category. It's a small risk though, all things considered. I purchased a video card with a particular driver and even if they went under I would still have at least the functionality that they guaranteed me. I'm not saying it would be pleasant, but there are alternative options, and it seems like such a small likelihood as to not be too concerning. (AMD, on the other hand... I don't know about them lasting much longer quite frankly.)

    Then look at all the people on this forum -- especially some of the most vocal OSS proponents -- who are so eager to throw all the old hardware / software "cruft" over the boat at the first chance. I mean damn... the news about KWin dropping support for *current* AMD hardware using Catalyst was met with rounds of applause. "It's time to move on!"

    I mean... you can still get drivers that work for the GeForce 3 or whatever... you just won't be able to run them in the latest Ubuntu or the like. But I see that as trying to fit a carburetor on an EFI engine. You have to kinda keep the components matched up.

    there are some important things that the NVidia driver does not support like KMS. Which comes back to not having any control: NVidia just refuses to support this all-important new development in the Linux kernel.
    My understanding is that most of the KMS functionality is "there" but they implemented it in their own way... sans the snazzy framebuffer support, which they said they could add that in if they wanted to, but it's at the bottom of the list of things to do. I thought supporting KMS was more of a legal problem than a pure obstinacy?

  5. #35
    Join Date
    Oct 2008
    Posts
    3,219

    Default

    Quote Originally Posted by johnc View Post
    Then look at all the people on this forum -- especially some of the most vocal OSS proponents -- who are so eager to throw all the old hardware / software "cruft" over the boat at the first chance. I mean damn... the news about KWin dropping support for *current* AMD hardware using Catalyst was met with rounds of applause. "It's time to move on!"
    It's not like you couldn't use KWin anymore, you just wouldn't get wobbly windows and blur. In fact, you could still run the XRender compositing backend to get some effects. Also, by the time this change could come out (10 months minimum) fglrx could fix it's Direct Rendering + TFP problem. I assume they will do this sooner or later to get Gnome Shell working, the only question is how long it takes them.

  6. #36
    Join Date
    Jan 2007
    Posts
    459

    Default

    Quote Originally Posted by robclark View Post
    The current situation on all the major ARM platforms (TI/OMAP included) is GPL kernel driver for GPU and closed userspace. So you could argue, "well, GPL kernel module, so you're ok to use EXPORT_SYMBOL_GPL()". But morally, because in the world of GPU the userspace and kernel parts are tighly coupled, that seems to me like following the letter of the law without following the spirit... so I don't think you can really argue that this situation is any better than with nvidia on the desktop.

    I'm optimistic that the situation of opensrc userspace stack improves on ARM, but it won't happen overnight. Nothing would make me happier than to be able to work on a fully opensrc graphics stack. (Please feel free to petition IMG on that topic ;-)... given the permission, I'd quite happily hack on an opensrc sgx driver on weekends and evenings.) But even when you reach the first (long) milestone of a fully functioning opensrc userspace, it will still take a long time to reach the performances levels of the proprietary driver, and when it comes to handsets/tablets, performance is everything.. so even on mali it will be the closed src driver that is shipping on devices from the factory.

    Furthermore, we do really want for nvidia to use dma-buf instead of inventing their own proprietary mechanism which wouldn't interop with the opensrc drivers. Currently the choice seems to be between those two options. One of the main purposes of dma-buf is to have a common solution to replace non-upstream vendor specific solutions for buffer sharing, and not opening up the dma-buf interface prevents that. The fact that dma-buf is mostly an interface, rather than an implementation, plus the fact that we want to get rid of vendor specific buffer sharing solutions with a common upstream mechanism, leads me to the conclusion that using EXPORT_SYMBOL() is the best choice.
    HI rob, nice to see Texas Instruments come to talk to the lowly end users and independent phoronix devs as the only real viable linux message board to get some reasonably up to date linux ARM info and performance specs in one place so far...

    you probably already know about the mali/Lima open stack development http://www.phoronix.com/scan.php?pag...tem&px=MTA1NjI so that would be our preference gfx kit to buy rather than IMG if you were to pick a base ARM Gfx soc to hack on in the coming months; to help it progress as fast as possible, there's no sign or real hope that IMG or an independent dev will bother to reverse engineer any of their Gfx blocks, as it stands mali/Lima seems the right choice this year.

    i forget, do Texas Instruments have any Mali 400 + SOC block in this years existing SOC refreshes ( we have to wait for
    Mobile World Congress next week to know for sure i guess) to give you and all the other professional TI devs some incentive to hack lima or even help get ARM directly involved in writing and submitting GIT code patches, giving info and helping this lima initative to make the first ever fully functional open ARM driver this year, OC if all the Linaro devs with mali kit releases were to help out lima too that would be even better

    anyway thanks for posting and dont be a stranger, invite all your other devs to come and contribute and correct any info contributors might get slightly wrong now and then here, and remember to have fun
    Last edited by popper; 02-22-2012 at 03:01 AM.

  7. #37
    Join Date
    May 2008
    Posts
    73

    Default

    Quote Originally Posted by johnc View Post
    and it seems like such a small likelihood as to not be too concerning. (AMD, on the other hand... I don't know about them lasting much longer quite frankly.)
    Wouldn't you have said the same about AMD only a couple of years ago? Things change and sometimes very rapidly. And like I said it's not always about going under or disappearing, they could just decide tomorrow they have had enough of supporting Linux. Then what?

    Quote Originally Posted by johnc View Post
    Then look at all the people on this forum -- especially some of the most vocal OSS proponents -- who are so eager to throw all the old hardware / software "cruft" over the boat at the first chance. I mean damn... the news about KWin dropping support for *current* AMD hardware using Catalyst was met with rounds of applause. "It's time to move on!"
    Well maybe they were all in favor of KWin dropping support for a proprietary driver
    Still, for any starry-eyed youngster that spends his monthly earnings on the latest Gfx card and gushing about it on the forums are a dozen moms and dads with kids to take care of who are silently happy that their stuff keeps working as long as it ain't broke.

    Quote Originally Posted by johnc View Post
    I mean... you can still get drivers that work for the GeForce 3 or whatever... you just won't be able to run them in the latest Ubuntu or the like.
    If open source GeForce 3 drivers are available they would be part of Ubuntu and you wouldn't have to do anything to just have it work. It's exactly the closed NVidia drivers that have stopped working.

    Quote Originally Posted by johnc View Post
    My understanding is that most of the KMS functionality is "there" but they implemented it in their own way... sans the snazzy framebuffer support, which they said they could add that in if they wanted to, but it's at the bottom of the list of things to do. I thought supporting KMS was more of a legal problem than a pure obstinacy?
    It's missing quite a number of things like frame buffer support, seamless VT switching, allowing kernel oops display in X etc

  8. #38
    Join Date
    Sep 2011
    Posts
    292

    Default

    Quote Originally Posted by popper View Post
    HI rob, nice to see Texas Instruments come to talk to the lowly end users and independent phoronix devs as the only real viable linux message board to get some reasonably up to date linux ARM info and performance specs in one place so far...

    you probably already know about the mali/Lima open stack development http://www.phoronix.com/scan.php?pag...tem&px=MTA1NjI so that would be our preference gfx kit to buy rather than IMG if you were to pick a base ARM Gfx soc to hack on in the coming months; to help it progress as fast as possible, there's no sign or real hope that IMG or an independent dev will bother to reverse engineer any of their Gfx blocks, as it stands mali/Lima seems the right choice this year.

    i forget, do Texas Instruments have any Mali 400 + SOC block in this years existing SOC refreshes ( we have to wait for
    Mobile World Congress next week to know for sure i guess) to give you and all the other professional TI devs some incentive to hack lima or even help get ARM directly involved in writing and submitting GIT code patches, giving info and helping this lima initative to make the first ever fully functional open ARM driver this year, OC if all the Linaro devs with mali kit releases were to help out lima too that would be even better

    anyway thanks for posting and dont be a stranger, invite all your other devs to come and contribute and correct any info contributors might get slightly wrong now and then here, and remember to have fun
    yup, I am aware of lima project. Note that arm mali developers (and I *ass*ume this applies to developers working for different SoC vendors who use mali) are not permitted to look at the opensrc code. I would guess the situation is the same within, for example, AMD where they have separate teams working on opensrc and closedsrc driver stacks. You do need to be careful to prevent IP contamination in either direction.

    I'm quite sure I'm not allowed to comment on future TI products which haven't been announced yet ;-), but I think the GPU that is in omap54xx is already announced. It isn't quite like the desktop PC world where you can just pull on gfx card out and plug a different one in. In general, though, IMG cores are still very good for a given power budget.. which is basically why they exist. (I can assure you that it isn't because of how plesent their code is to deal with or their fondness for the opensrc community.) But maybe the lima project will start to put some renewed pressure on IMG.

    Anyways, standard disclaimers about how all of this is just one hackers opinions, etc, etc.

  9. #39
    Join Date
    Jan 2007
    Posts
    459

    Default

    Quote Originally Posted by robclark View Post
    I'm quite sure I'm not allowed to comment on future TI products which haven't been announced yet ;-), but I think the GPU that is in omap54xx is already announced. It isn't quite like the desktop PC world where you can just pull on gfx card out and plug a different one in.
    ....
    Anyways, standard disclaimers about how all of this is just one hackers opinions, etc, etc.

    yea ,the OMAP5 ARM Cortex-A15 processor [omap54??] running at “only” 800Mhz compared to a 1.3Ghz ARM Cortex-A9 Quad-core processor looks to have nice potential on the surface,for Trim-Slice type box etc
    http://armdevices.net/2012/02/22/web...ap5-vs-tegra3/


    i do wonder what official memory bandwidth and dual or single channel etc they are using there, as it is key to getting better overall data throughout today, any clue what that might be given TI have gone public with that SOC now, say hi to Charbax if your going to MWC this year and remember to collect up the data sheets and give him the full specs and speeds not just the PR stuff/fluff please LOL
    Last edited by popper; 02-22-2012 at 08:25 PM.

  10. #40
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,801

    Default

    Quote Originally Posted by Qaridarium View Post
    i vote to make the linux kernel ---> AGPLv3+
    You don't have a vote in this since you didn't even write a single line of kernel code. So there goes your daydream.

    And even if you had written kernel code, you'd need permission from everyone who ever wrote kernel code that is still included in the kernel, since Linux does not have a copyright assignment policy. That means, the kernel is stuck with GPLv2 forever. According to the kernel devs, this is not a bad thing though, since they're very hostile to Stallman and his Freeness crusade.

Posting Permissions

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