Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Graphics Open Source Programming Linux Hardware

Nouveau Open-Source NVIDIA Driver Achieves OpenCL Support 109

An anonymous reader writes "The Nouveau driver project that's been writing an open-source NVIDIA graphics driver via reverse-engineering has moved forward in their support. The Nouveau driver now has OpenCL acceleration support to do GPGPU computing on the open-source community driver for several generations of GeForce GPUs."
This discussion has been archived. No new comments can be posted.

Nouveau Open-Source NVIDIA Driver Achieves OpenCL Support

Comments Filter:
  • Great, but does it do 3D graphics yet? I've had an NV44A since 2006 and it's still not working very well. 3D support is there, but buggy and not "Done". At the time, this was a "new" nVidia card. And the Gallium came along (which is good BTW) and then NV50 and now nvC0. Only these latest 2 generation seem to be very active, and they don't even have full functionality, so it seems silly to be putting time into OpenCL. It seems AMD is better supported by open source these days, when it used to be nVidia was t
    • by jandrese ( 485 )
      If you want OpenGL support you pretty much need the nVidia binary blob drivers. These drivers seem to be more for people who absolutely cannot have binary blobs for one reason or another, not for people who just want to run games.
      • by gr8_phk ( 621180 ) on Tuesday February 07, 2012 @01:04PM (#38956737)
        I don't like the binary blobs for because they 1) break when I get automatic updates that include a kernel 2) don't support the new 3d architecture and hence will 3) not work with Wayland when it matures. OTOH nouveau is completely painless to use for 2D ( I run Fedora ) but sucks for 3D. I can't run blender. Gnome 3 is very laggy when it works. I can't run Neverball for very long. Yet they think this driver needs OpenCL? WTF? Between Gnome3 and nouveau I need to buy new hardware, and it won't be nVidia this time. I just want my desktop and some OGL apps to work out of the box.
        • I've had no significant binary blob driver issues with the desktop in Gnome 3, but I can't say I've timed it against using nouveau much since it just works.

          At any rate, I'm most happy with NV+Binary drivers on Linux these days, have been for a while. When ATI or someone else or Nouveau catches up, then great.

        • Not sure how you obtain blender - but if you nab the pre-build binaries (they run from wherever you extract them and store stuff in ~/.blender) they come with a mesaGL binary that does not require hardware OpenGL support. Debian has a seperate package for this as well, but I think Fedora only ships the "normal" binary.

          It can be a bit slow in complex scenes, but that's only at the UI level. The render output is the same, and now that nouveau supports OpenCL you will probably be able to continue to use the gr

        • I don't like the binary blobs for because they 1) break when I get automatic updates that include a kernel

          Install the rpmfusion repo and then

          yum install akmod-nvidia

          and never have to worry about a kernel update breaking the driver again. It's that easy.

        • by ifrag ( 984323 )

          I can't run blender. Gnome 3 is very laggy when it works. I can't run Neverball for very long. Yet they think this driver needs OpenCL?

          IMO, the motivation to have OpenCL working is completely separate from having functional accelerated video. Maybe it's just the people working on the driver are more interested in doing a compute project.

        • Have you tried reporting bugs to the nouveau developers about the 3D issues you have?

          The developers are very helpful and they helped me to resolve a few issues with nouveau in the past, they fixed the source of the problems I had.

          Please always file issues for any issues you have.

          Thanks.
        • will 3) not work with Wayland when it matures.

          Don't worry, few things will work with wayland when it matures. Like, for instance remote windowing, consistent window decorations, etc...

          • by gmhowell ( 26755 )

            will 3) not work with Wayland when it matures.

            Don't worry, few things will work with wayland when it matures. Like, for instance remote windowing, consistent window decorations, etc...

            Given that the temperature of the universe will be very close to absolute zero when Wayland matures, I suspect those aren't the only things that won't work.

        • I don't like the binary blobs for because they 1) break when I get automatic updates that include a kerne

          You must have a pretty off beat distro. dkms has been handling that problem for years.

        • I don't like the binary blobs for because they 1) break when I get automatic updates that include a kernel ...

          What about a distro with DKMS [wikipedia.org]? Wikipedia claims Fedora supports it these days...

      • That's a good reason as is the fact that many systems can't boot or boot and hang after loading X without acpi=off while using the Nouveau drivers.

    • Re: (Score:2, Informative)

      by Anonymous Coward

      AMD/ATI isn't really any better. The open source drivers suck just like Nouveau. So you have to use the binary AMD drivers if you want full support and performance. But then you're in a worse position than nVidia because the AMD drivers are terrible.

      The whole situation just sucks to be honest. The best choice is nVidia hardware with the closed-source nVidia drivers but they're far from perfect. I believe the AMD hardware may be better but their drivers suck so bad that you can't take advantage of it.

      An

      • by chrb ( 1083577 ) on Tuesday February 07, 2012 @02:26PM (#38958055)

        AMD/ATI isn't really any better. The open source drivers suck just like Nouveau.

        Not my experience. I've been using ATI with open source drivers for years now and have had very few issues. I did have problems with Nouveau though and ended up swapping out the card out for an ATI one.

        (the multiple monitor support is absolute shit compared to Windows or OSX).

        I have a dualhead DVI setup with an AMD DMS-59 card and it works fine. What exactly do you think is missing in Linux? Last time I installed, Ubuntu auto-detected the dualhead setup, and it was a single mouse click to swap from mirror image to left/right screen. I know that using multiple cards for a multiple monitor setup doesn't work very well in Xorg - but I've also heard the same about Windows.

        • by equex ( 747231 )
          Consider yourself lucky. Very few of us achieve one-click->100% working dual monitor setup. Well it did actually work for like 2 weeks before some update broke it. Indeed, my latest two mobo's wasn't even supported by the Linux kernel and related low-level device drivers. No, I could not load any drivers, because the damn thing can't even figure out how to handle my disk controllers. (SB600 and SB950 chipsets. Actually, the last Ubuntu I could run without major buggage was 8.04 and 8.10.) I tried all th
        • From my experiences with the AMD driver, it was extremely difficult to get a single X display that would span across multiple video cards. Xinerama just completely made the drivers fail. Nvidia on the other hand seems to support Xinerama just fine.
        • The proprietary AMD drivers are horrendous... I just tried installing over the weekend and had nothing but trouble with them. First, I tried the Ubuntu 11.10 fglrx packages. This gave me a single display (I have 3 1080p monitors, switch between separate and Eyefinity in Windows) and a single card (have 2 5870 reference boards in CF). I tried to enable the other displays and CrossFire and the machine got stuck on the next reboot (couldn't start X). I then tried the "updates" version from the repos, same

        • Open drivers with 3D acceleration and good performance is what's still missing in Linux.

          I'd buy all my video cards from whichever vendor has that. But none of them do. Not Nvidia, not AMD/ATI, and certainly not Intel or any of the others who have the additional problem that even if they had a great open source driver it wouldn't help because their graphics hardware performs so poorly. 2 years ago, I heard ATI was going to open up, and so my newest computer is an AMD with ATI graphics. But they haven't

        • Same here, my last two computers (an 11 inch laptop and a self-assembled desktop) were deliberately bought with AMD graphics cards because the radeon (Open Source AMD card driver) works so well out of the box. HDMI out, multiple monitors all just works.

          If I plug in HDMI to my laptop it pops up a dialog asking me to configure the 2nd monitor, which takes me to KDE's standard Display thing in its control panel. This works the same across distros (Opensuse and Kubuntu) and that's the way it should be.

          All that

      • Troll, give more details as to what is so bad exactly, file bugs or GTFO.
        • by sander ( 7831 )

          I think that it is you that is trolling here. Not only are you deliberately spreading FUD about the nvidia drivers :

          the nvidia blob is actually a half-assed port of their Windows drivers to Linux

          the only even marginally semi-constructive thing you appear capable of saying is "have you done some bug reporting?", while completely ignoring the fact that the support it provides is at the level where the only pertient bug report wording would be "when will you start planning to support the other 50%+ of the API?".

          • I wasn't trying to troll, I was only trying to encourage people to file bug reports, because the only thing I see here is people bitching about a FOSS and reverse-engineered project. Those people should at least submit bug reports.

            Sorry about the way I expressed myself though, and I wasn't ignoring anything, I just wasn't aware that there were things still left to implement. Sorry.
    • Of course.... (Score:5, Informative)

      by DrYak ( 748999 ) on Tuesday February 07, 2012 @01:14PM (#38956891) Homepage

      It seems AMD is better supported by open source these days, when it used to be nVidia was the obvious choice.

      Well, of course. AMD does publish documentation and put ressources behind the opensource development. NVidia doesn't.

      Only these latest 2 generation seem to be very active, and they don't even have full functionality

      For Nvidia cards, reverse-engineering is needed. So support will depend mostly on what the developper community has under their hand and can experiment the most with.
      Too old cards aren't used so much any more, and thus there isn't as much experimentaiton going on them.
      Too new cards haven't been around enough for enough reverse engineering to happen, so you won't see much support for them before a couple of year.

      so it seems silly to be putting time into OpenCL.

      Putting OpenCL in there doesn't divert that much ressources from Nouveau. Gallium3D is very modular (that's the main reason it's popular in the open source).
      You just have back-end exporting hardware functionnality on one hand, and front-end supporting various API on the other hand.
      You could in theory just freely slap any front-end on any back-end (and it's mostly that way in reality, hence the popularity of Gallium3D).

      So bringing OpenCL to Nouveau boils down to :
      - efforts in impoving the OpenCL state tracker until it can support enough of the OpenCL API. These are efforts done be people external to the Nouveau project. (Mostly the initial Clover project, then Google Summer of Code, etc.) And these are efforts done (mostly) independently of the back-end used (a lot is done on the CPU backends like LLVMpipe, but could also be used on Nouveau, AMD's R600g or the Gallium drivers for Intel developped by Google).
      - efforts to bring enough of the hardware functionnality into the Nouveau back-end. These are efforts done by the Nouveau team. But some of these effort benefit also the 3D API or any other front-end running on Gallium3D (in theory, even the Gallium3D powered DirectX 10/11 front-end could partly benefit of these efforts).

      That's also why OpenCL has been so quickly added to Nouveau: because it's cheap. OpenCL is mostly done (unlike OpenGL which is only currently achieving OpenGL 3.0 support in Mesa 8.0, whereas the current OpenGL implementation is 4.2 - so several versions behind). And GPGPU is mostly only uploading code to run on the chip (lots of functionnality which is used for 3D is not used for GPGPU), so as long as the the few OpenCL specific hardwaare functionnality is supported, OpenCL is ready to go.

      For an up-to-date 3D support, there's still a lot of work to go into the Gallium OpenGL state tracker so it supports all the API and functionnality necessary for OpenGL 4.2. And there's still lot of hardware functionnality that needs to be done in Nouveau. Which is, again done entirely by reverse engineering and without an help from NVidia.
      So, still a lot to go before having good 3D support.

      At least, AMD is giving out documentation and paying a few developpers, and overall trying to guarantee some opensource support in parallel to their closed source catalyst.
      And Intel and Google are actively developping opensource drivers as their main hardware support for Intel chipsets (with Intel developping classic Mesa and Google making Gallium3D drivers).

      • If Intel would bother actually putting some hardware behind those things, they may well be the 'best' solution.

        • Well, Sandy Bridge graphics aren't as bad as old Intel chips used to be, and I hear that Ivy Bridge will be much faster.
  • But does it run Flash?
  • Does this mean VDPAU support? That's all I really care about in a GPU beyond basic display at normal resolutions.
    • Re: (Score:3, Informative)

      by Desler ( 1608317 )

      No it doesn't.

    • There's a completely separate project which tries to bring support for video acceleration and video APIs on the Gallium3D.

      Now, these efforts are using the Gallium3D stack. That means that the video is getting decoded by the 3D hardware (by code running on the shader/kernel processors) and not by the separate video hardware that some chip feature.

      (In AMD's case that means that the decoding is done by the same units which does OpenGL/OpenCL and not by the UVD).

  • Burn it! (Score:1, Informative)

    by IronHalik ( 1568993 )
    Burn it with fire! For all the countless hours spent trying to make it work on my "supported" Ubuntu box - the bootsplash, the dual displays, the login display config, user display config... You fix one thing, another jumps right back in.

    And to be fair, proprietary nvidia drivers are far from flawless too - Most of the things work except one, kinda big thing - X server using one whole core, just to render the desktop. It's a "feature regression".

    • Oh, and to be clear - its not only a rant, its a testimony to current state of video support on one of the most used, and 'year of linux desktop' distro.Thats on my video card, that is one of the most popular geforces ever created.
    • Have you even done your part?

      That is, reporting bugs?
      • Sure, I got flamed for reviving a Transmission bug (torrents would not start from the watchdir, they would get added as started but no peers would connect). It was a "known bug". Known for about two years then. Must have been some really nasty thing, if nobody could fix it during two mayor versions.

        And for Ubuntu, I reported message indicator not working properly with Empathy - its one of the nicest features in Unity. "It regressed". They will fix it in 12.04. Maybe. A bug has to wait half a year, because

  • Not quite (Score:5, Informative)

    by KerrickStaley ( 2423808 ) on Tuesday February 07, 2012 @12:56PM (#38956615)

    From the article:
    Unfortunately this current Nouveau OpenCL work done by Francisco Jerez isn't in the upstream Nouveau code-base but rather a separate branched Git repository. This is still out-of-tree work and it's not clear when it will be merged, but is already out of the question for the soon-to-be-out Mesa 8.0. The next hope would be seeing Mesa 8.1 be more OpenCL compute friend when that arrives in the middle of 2012.

    Also, it only supports the older NV50 cards, not the newer NVC0 cards. I'm still keeping my fingers crossed, though: if OpenCV gets OpenCL support, then computer vision people could do GPGPU without needing the proprietary drivers.

    • From the article: I'm still keeping my fingers crossed, though: if OpenCV gets OpenCL support, then computer vision people could do GPGPU without needing the proprietary drivers.

      Why is it so wrong to use the proprietary drivers? I mean don't we want companies to write drivers for linux for their hardware. NVIDIA does this and has for many many years. Why are you so eager to drop the proprietary drivers when they work so well in linux? It's one reason I always buy NVIDIA, even in my Windows machines. Because they support linux with drivers. I mean even my old NVIDIA cards running my servers still work. Sure newer drivers don't work, but old drivers do and work very well. I just don

      • From the article: I'm still keeping my fingers crossed, though: if OpenCV gets OpenCL support, then computer vision people could do GPGPU without needing the proprietary drivers.

        Why is it so wrong to use the proprietary drivers? I mean don't we want companies to write drivers for linux for their hardware. NVIDIA does this and has for many many years. Why are you so eager to drop the proprietary drivers when they work so well in linux?

        There's a number of reasons to want the source: fix bugs, add features, build for a non-Intel architecture, you could be an optimization freak(ie. Gentoo user). The real question is what is the harm to Nvidia for releasing the source? They are a hardware company. I doubt that their secret sauce is in the driver, so why would it do anything but help their sales?

        • Not to mention that a free driver (as in free speech) also gives developers and users more freedom in the sense that if we want to create new display servers (e.g. Wayland) we can do so without having to worry that a corporation like NVIDIA will support us. Which they already said they won't.

          With proprietary drivers we lose a lot of control of our system.

          With FOSS drivers we have the control, and this is the way it should be.
        • by Desler ( 1608317 )

          The real question is what is the harm to Nvidia for releasing the source?

          The cost and time involved with properly auditing all the code, time and money spent trying to get licensors to allow source release and three time and effort to reimplement all the parts they won't be able to open source, etc. Unless the neckbeard market is going to make up for all the time and money spent, nvidia gains nothing.

          I doubt that their secret sauce is in the driver, so why would it do anything but help their sales?

          And you would be wrong. There is lots of optimizations and other technologies in the drivers that they don't want shared. Also, they won't gain any sales from it to warrant the effo

      • Re:Not quite (Score:5, Informative)

        by miknix ( 1047580 ) on Tuesday February 07, 2012 @02:49PM (#38958423) Homepage

        Why is it so wrong to use the proprietary drivers?

        I'm going to give you an example. My parents computer which is actually a laptop with a GeForce FX Go 5300 has GNU/Linux on it. The last official driver from nvidia supporting that card is nvidia-drivers-96.xx. Then if you read https://wiki.archlinux.org/index.php/NVIDIA [archlinux.org] :

        Note: Currently nvidia-173xx, nvidia-96xx and nvidia-71xx drivers do not support Xorg release 1.11, and therefore are not available in the Official Repositories. You can use the open source drivers (nouveau or nv) instead.

        I belive the drivers still worked under Xorg 1.10 under a compatibility layer. But my point is, if the vendor decides to stop supporting your hardware, you are left in cold waters if there isn't any opensource driver..

        Another example is the XRandR case. Nvidia bundles the nvidia-settings application which works fine if you use it. However if you want to use the KDE or gnome or whatever other software to change the screen resolution and multiple-screens, then you will notice how bad they work BECAUSE nvidia fails to properly implement the XRandR specification (instead they make some kind of wrapper to their own twinview). With nouveau, XRandR works beautifully.
        Because nvidia also emulates Xinerama, sometimes window managers fail to properly detect your multi-screen setup geometry and you will get strange window management results. This happened to me and that's why I perfectly happy with nouveau. Of course I still hit bugs when playing opengl games and sometimes the GPU even hardlocks but I honestly prefer having those localized bugs than the general inconsistencies I described above.

        BTW: cudos to everyone involved in nouveau. OpenCL support is indeed a very good thing :)

        • That's right. The nvidia blob is actually a half-assed port of their Windows drivers to Linux, that's why the blob sucks so badly.

          On the other hand, nouveau actually uses our existing Linux infrastructure. Nouveau does support KMS and XRandR properly. Also, XRandR uses KMS to change the resolution and stuff, since X is not in charge of handling resolution and depth anymore, KMS does that these days. So XRandR is just a wrapper to KMS these days.

          Nouveau already has Wayland support also which also uses KMS.

          I
        • BTW, if you get any GPU hardlocks or you hit bugs, please report them.

          I've reported a few and the nouveau developers were really kind and assisted me on fixing them, at the end we fixed them all. :-)

          Here is the issue I had, the nouveau developers rock (thank you so much guys):

          https://bugs.freedesktop.org/show_bug.cgi?id=40630
          • by miknix ( 1047580 )

            Yeah, I have this hard lockup (on a G86) that always happen when I suspend (s2ram) the laptop and it is connected to one screen other than the laptop internal. I've been willing to report this for quite some time now, but you know how it is, it is easier to avoid the problem than to fix it :P

            • Yeah just report it to the bug tracker or tell the devs about it on #nouveau. So someone else will look at it in the future (maybe) and so that the issue doesn't get lost. =D

              Thanks.
        • But there are counter-examples to that, too... I had to downgrade from RHEL6 because the latest OPEN SOURCE Intel video drivers (which require KMS) are completely unusable and ause the display to stop working within an hour or two. The drivers in RHEL5 worked perfectly well... Never any such problem with NVidia's binary blobs.

          In your case, the open source driver just HAPPENS to support something the binary doesn't. I'm sure there are MANY cases where the binary blob works better and supports more, as we

        • by sander ( 7831 )

          Another example is the XRandR case. Nvidia bundles the nvidia-settings application which works fine if you use it. However if you want to use the KDE or gnome or whatever other software to change the screen resolution and multiple-screens, then you will notice how bad they work BECAUSE nvidia fails to properly implement the XRandR specification (instead they make some kind of wrapper to their own twinview). With nouveau, XRandR works beautifully.
          Because nvidia also emulates Xinerama, sometimes window managers fail to properly detect your multi-screen setup geometry and you will get strange window management results. This happened to me and that's why I perfectly happy with nouveau. Of course I still hit bugs when playing opengl games and sometimes the GPU even hardlocks but I honestly prefer having those localized bugs than the general inconsistencies I described above.

          BTW: cudos to everyone involved in nouveau. OpenCL support is indeed a very good thing :)

          You see, the reality is that anybody doing any serious 3d work wants exactly the functionality that Twinview gives them, not the supposedly "correct" functionality from the OS drivers. What KDE and gnome should do is use the wrapper, not mess around on their own. And that is simply because everybody doing serious 3d cares about their application and the performance, not what abstraction of things the utterly boring and not terribly useful thing drawing window borders thinks of all of this.

      • Why is it so wrong to use the proprietary drivers?

        It's not wrong - it's just that open source drivers work out of the box, while proprietary drivers need some tinkering and only support the latest hardware. Compare with the experience you get with Linux on PCs with Intel graphics - almost everything just works and at full performance, with no need to hunt for drivers, download firmware blobs, etc. And Intel start updating their drivers to support new products months before they're released to the market.

        • by rec9140 ( 732463 )

          "- it's just that open source drivers work out of the box, while proprietary drivers need some tinkering and only support the latest hardware."

          I don't do any tinkering or searching for OEM drivers..

          a few commands to enable XSWAT PPA

          an apt get to install...DONE. I have not tweaked a setting for a thing, X or card. none.

          Other than re-enable desktop effects, so I can enable one thing transparency... (don't get me started on my rant on that in KDE4)

          Works great.

          As for the absolute stupidity of both nVidia and cr

      • by Cybah ( 444190 )

        Why is it so wrong to use the proprietary drivers?

        Here's an example. I bought a laptop with an Nvidia Quadro FX 3800M specifically for triple-head support (via docking station) and I can't even get dual-head to work properly due to an infinite loop somewhere in the binary drivers when mode-switching. I've done most of the investigation work, even running X through gdb and they're not interested in helping - not even some basic debug symbols.

        I've been completely ignored by Nvidia via both of their official support channels: (1) the nvnews.net forum [nvnews.net] and (2)

  • ...we can take advantage of the hardware in some way. Because it sure as fuck isn't being taken advantage of in 3D gaming on Linux. The state of graphics driver support in Linux is sad. We end up with abominations like nVidia Optimus, which they won't even support, forcing the open source community to bullshit their way through with hacked up work-arounds like Bumblebee. They just won't put the development dollars into Linux, and there doesn't seem to be any recourse.
  • But has it stopped creating constant kernel panics?
  • Apparently some NV2A stuff has gone into Nouveau but not the stuff for the TV Decoders. Haven't found any significant blog posts or mailing list updates newer than 2008...

  • by Anonymous Coward

    Until it passes the OpenCL conformance tests (which are a major PITA) it's not really useful. One of the major reasons OpenCL is valuable is that it provides a guaranteed level of accuracy for math operations. This has a lot to do with the libraries that vendors ship, and that is a decidedly non-trivial amount of engineering and testing to implement. (I've been involved in getting OpenCL to pass conformance for three platforms.) I'd say they are about 10% of the way there.

If you aren't rich you should always look useful. -- Louis-Ferdinand Celine

Working...