Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Graphics Software Linux

NVIDIA Releases New Video API For Linux 176

Ashmash writes "Phoronix is reporting on a new Linux driver nVidia is about to release that brings PureVideo features to Linux. This video API will reportedly be in nVidia's 180 series driver for Linux, Solaris, and *BSD. PureVideo has been around for several nVidia product generations, but it's the first time they're bringing this feature to these non-Windows operating systems to provide an improved multimedia experience. This new API is named VDPAU, and is described as: 'The Video Decode and Presentation API for Unix (VDPAU) provides a complete solution for decoding, post-processing, compositing, and displaying compressed or uncompressed video streams. These video streams may be combined (composited) with bitmap content, to implement OSDs and other application user interfaces.'"
This discussion has been archived. No new comments can be posted.

NVIDIA Releases New Video API For Linux

Comments Filter:
  • Form follows code. (Score:3, Interesting)

    by Ostracus ( 1354233 ) on Friday November 14, 2008 @07:41PM (#25766857) Journal

    Fine. Now what programs use this API?

  • I was this close to just building an all AMD/ATI rig in the spring. ATI was opening up their drivers. The OSS drivers were working well, and Nvidia wasn't doing anything. Nvidia addressed their horrible Linux XRender support, and now this. I may just have to stick with Nvidia in the spring.

    • Re:ATI (Score:5, Informative)

      by Lorkki ( 863577 ) on Friday November 14, 2008 @08:21PM (#25767143)
      You might be interested to know that ATI's equivalent [phoronix.com] was also revealed a short while ago.
      • Perhaps a dumb and semi-unrelated question, but who has the better SLI/Crossfire support in their Linux drivers right now, ATI or Nvidia?

        • Re:ATI (Score:5, Funny)

          by Anonymous Coward on Friday November 14, 2008 @08:41PM (#25767275)

          who has the better SLI/Crossfire support in their Linux drivers right now, ATI or Nvidia?

          I'm guessing ATI has better Crossfire support right now, while Nvidia has better SLI support...

        • Re: (Score:2, Informative)

          by xyxvv ( 1261966 )
          Last I checked Nvidia did, but a single AMD HD4870 1Gb is quite powerful, and one of the few cards that does get a boost from the added ram, http://www.guru3d.com/article/amd-ati-radeon-hd-4870-1024mb-review/8 [guru3d.com] I don't know what the OC cap is though on the 1Gb version though, since I've seen the 512 go as high as 4.8Ghz, though 4.4Ghz is what most get stable at. the 4870X2 at release didn't have support for any of the open source games, I don't know the current drivers support though. I dunno about the Nvi
          • could only be had back in the days of 3Dfx, where it was really ScanLine Interleave.

            Today, you're NEVER getting a full 2X increase, because that type of video splitting/rendering/recombining is no longer used, even though it DID truly offer a 2x performance boost. (1024x768 was accomplished by each card rendering every other line.)

    • Comment removed (Score:5, Interesting)

      by account_deleted ( 4530225 ) on Friday November 14, 2008 @08:30PM (#25767213)
      Comment removed based on user account deletion
      • Here is to hoping that Wayland addresses some of these issues.

        • Re: (Score:3, Insightful)

          It is not yet the year of the linux desktop, we have time.

        • Comment removed (Score:4, Interesting)

          by account_deleted ( 4530225 ) on Friday November 14, 2008 @09:44PM (#25767757)
          Comment removed based on user account deletion
          • > A clean new implementation of x11 would probably benefit us a lot more than another Y windows, Wayward, Aqua etc

            Not really. KDrive was a clean implementation of X which had a few nice improvements. Those improvements were incorporated into Xorg and now there's just no advantage to using kdrive over xorg.

            I see no evidence that Xorg would benefit from a rewrite, compared to putting that energy into working on Xorg.

          • by Yfrwlf ( 998822 )
            Some of the programs you mentioned plan on being X.org-compatible from what I understand. If so, that'd basically be the same thing as making a "new" X.org. But, it would help adoption to keep the name.
            • Comment removed (Score:4, Interesting)

              by account_deleted ( 4530225 ) on Saturday November 15, 2008 @11:27AM (#25770603)
              Comment removed based on user account deletion
              • by Yfrwlf ( 998822 )
                Great, that's good, because that means the protocol can stay the same and other window servers can adopt it and hopefully be implemented in a better way. Of course, even if the protocol needed some new tweaks/features, it should be possible to maintain compatibility with programs using the older protocols. So I hope that developers working on X.org will continue tackling the issues and re-implementing sections that need to be redone. Otherwise, I hope new projects will succeed in it's place if they feel
        • elanthis at phoronix explained how Wayland was never intended for normal desktops running Gnome/KDE:
          http://www.phoronix.com/forums/showpost.php?p=51097&postcount=6 [phoronix.com]

          It will take something different to replace Xorg.

      • Re:ATI (Score:5, Interesting)

        by Jherek Carnelian ( 831679 ) on Friday November 14, 2008 @09:21PM (#25767587)

        You might want to read a blog post I wrote about why nVidia rocks when x.org does not. It's likely to give you more reasons to move over to nVidia over ATi.

        I don't find your arguments compelling.

        For one thing, you assert that "because of vocal powers in the foundation that demand that things should stay compliant to a specification and they should work around the architecture rather than strip out certain pieces and implement them, add proper new features (memory management and API functions to go with it)" -- yet my reading of the Xorg mailing lists suggests that is exactly what is being done with the GEM memory manager and API's [phoronix.com] previously there was the TTM memory manager, but the APIs were not satisfactory, so they ripped it out and started again.

        The bulk of your argument seems to be that Nvidia's got a much more complete OpenGL implementation than does anyone else. Nevermind that almost all of it is simply code duped from their MS Windows driver, your argument is really the ages-old "if it works, then who cares if it is closed source" argument we've heard time and time again.

        Of course the fallacy of that approach becomes obvious the second it stops working and you are helpless to do anything about it.

        That happened to a guy I know, he spent about $600 on a pair of top-end nvidia cards a few years back. All based on nvidia's highly touted support for linux. Except the cards did not work with his IBM T220 [wikipedia.org] monitor. It wasn't anything to do with the ultra-high resolution. It was a trivial bug in the nvidia drivers - if the card could not read an EDID, the drivers assumed the card had a single-link DVI transmitter. A stupid, stupid bug because the actual nvidia chip had the DVI transmitters onboard and they were always dual-link, there was no way for any card in that generation to even be single link, and of course no matter what directives we specified in the config file, the driver "knew better."

        He had to go out and spend another ~$150 for two Gefen DVI Detectives [gefen.com] just to enable the nvidia card to see an edid so that the driver would correctly turn on the chip's DVI transmitter.

        Nvidia's vaunted customer support? Totally clueless and useless, they completely dropped the ball, just ignoring the issue once they realized it was more than a "did you plug in the power cord" level issue.

        And don't think that problem was unique to an odd-ball monitor - the same lack of edid is an issue for anyone using unidirectional fibre DVI extender cables.

        So, while it is great for you personally that Nvidia's drivers work perfectly with the hardware you own, I'm pretty sure your tune would change right quick if you had to just bend over and take it due to such a trivial bug, the kind that could easily be fixed with a single line or two of code, if you just had the source.

        • ...So GEM is still alive!!! I knew it! Atari rocks!!!

      • Re:ATI (Score:5, Informative)

        by JohnFluxx ( 413620 ) on Saturday November 15, 2008 @05:06AM (#25769433)

        Ash-foxes blog post is close to being a troll.

        Of course X does direct rendering. It's called Direct Rendering Interface - DRI. And the new improved DRI2 being worked on now.

        His other argument is that Xorg will never be able to have a unified memory manager... which is exactly what TTM and its successor GEM do.

        And noone in the Xorg team claims that indirect rendering is as fast as direct rendering.

        Companies like NVidia just replace chunks of Xorg without contributing anything back. Whereas its companies like Intel that actually contribute to improving X for everything - pushing a unified memory manager (TTM/GEM) into the kernel etc.

        • Re: (Score:2, Interesting)

          Comment removed based on user account deletion
          • > It might being worked on, but the current state is that it isn't there and it isn't available right now.

            You're honestly saying that Xorg doesn't support DRI? Really?

            > Where did I say I talked to the Xorg team?

            You state on your 'People in the opensource community claim that there is no real performance penalty because of certain accelerated features, despite the fact 3D applications are just slowed down because they have to use non/semi-accelerated indirect rendering (depends on the driver).'

            > Wh

            • Comment removed based on user account deletion
              • by makomk ( 752139 )

                Read my journal post, DRI support is extremely limited unless you use nVidia.

                Nvidia doesn't even use DRI at all; it has its own replacement for it copied over from the Windows drivers. (This has... interesting security implications.)

                • Comment removed based on user account deletion
                  • by makomk ( 752139 )
                    Complicated. Firstly, as I understand it they give applications direct access to the graphics card and rely on it to enforce security restrictions. If there are any bugs in the graphics hardware itself, the results would be interesting. (Remember that the graphics hardware generally has access to all of system RAM.)

                    Secondly, some of the calls from the userland code into the driver are done via the card itself. (The userspace code writes to the card, which generates an interrupt into the kernel code). Thi
          • Comment removed based on user account deletion
            • by makomk ( 752139 )
              Your post is a troll because it's full of downright misinformation and FUD
              (a) You claim that only NVidia has direct 3D rendering. Most 3D under X.org has been via direct rendering for as long as X.org exists (and yes, this does support multiple apps using 3D at once). The reason so many people rave about AIGLX so much is because it allows things like Compiz - since the window contents are drawn by the X server, indirect rendering is the easiest way of doing a compositing window manager. The performance im
              • Comment removed based on user account deletion
                • by makomk ( 752139 )

                  The reason so many people rave about AIGLX so much is because it allows things like Compiz - since the window contents are drawn by the X server, indirect rendering is the easiest way of doing a compositing window manager.

                  Easiest? I don't know. Fixing x.org instead of having to use workarounds all the time seems easier in the long term to me.

                  Not really. Did you see how long it took for NVidia to get compositing window managers working reliably under their driver? That's just dealing with one card, and they can do things like break their kernel ABI at will which the open-source developers try and avoid.

                  You may have not played games under AIGLX, but I have, and when the FPS drops by 30FPS because of indirect rendering, I don't consider that a non-issue.

                  Yeah, you don't want to run games through AIGLX, but you have to manually do so and I'm not aware of any reason why you'd want to. Generally, unless direct rendering isn't working at all, DRI seems to be used by default even if you're running a co

  • by LingNoi ( 1066278 ) on Friday November 14, 2008 @07:45PM (#25766895)

    The summary confused me a little into thinking this was a new nvidia driver. It is in fact new features being added to their closed source driver.

    • Re: (Score:2, Informative)

      by Anonymous Coward

      Ahh. New gingerbread to get nice children all plump for the oven. The Nvidia binary installer destabilizes the X windows on Linux, because it simply replaces the Mesa libraries without telling your package manager. And it's even worse about uninstalling itself: if you use the wrong Nvidia blob's uninstaller, you blow away your Mesa libraries entirely and it won't let you re-install the newer or different NVidia installer.

      Of course, this what I expect from a company too stupid to use a consistent naming sche

      • Re: (Score:2, Interesting)

        by Yfrwlf ( 998822 )
        It's also what the open source community gets for not having at least one actual cross-distro packaging standard. With the push for ODF and other great standards that are available for use on Linux and other OSes, I'm very sick and tired of distro companies promoting that kind of lock-in. All package managers should be compatible with at least one packaging standard, but ideally all the standards/formats which exist, and any standards that exist which can't be easily adopted in all the most common package
        • Re: (Score:3, Interesting)

          by Ed Avis ( 5917 )

          It's one thing to have a packaging standard for third-party applications which install in their own directory and require well-known libraries defined in the Linux Standard Base. I agree, there should be a cross-distro standard for installing these programs (and there is: LSB defines a package format, the only problem is getting the third-party vendors to use it). But the Nvidia drivers are not just any old application; they want to overwrite standard system files and otherwise mess around with things. I

          • by Yfrwlf ( 998822 )
            Ha, I didn't even notice, it's not labeled "troll" now, but I'm not surprised someone modded it that way. Big difference between trolling and constructive criticism, and as a Linux user and promoter, have no other intention than the latter.

            I think a much better solution would be an internal packaging standard, then you wouldn't need so-called "third-party" packages, plus then they wouldn't have the problem of library overwriting, but for now that'd be better than nothing I guess. I'd really prefer it t
          • by Yfrwlf ( 998822 )
            Oh and one last thing, it's sad that the Linux solution to solve the problem of program interoperability is to have things hard coded into separate "distros". That's part of the problem. The solution they are using in order to get programs communicating with one another is to pre-configure them, which means that by doing so a program package now suddenly has to be "wise" to that specific configuration on that specific distro, which also means that any changes one might make can then break everything, henc
  • From TFA its a beta status driver that makes the api available. Is there any timeframe for when the release version comes out (Holding off on an upgrade O:-))
  • I'm glad to hear this news. It will be only a matter of time before others follow suit. Time to dust off the resume.. I think soon being a Linux coder will be a useful item on that list.

    Linux has suffered some lag with driver releases, and even manufacturer hostility toward Linux. This is the year that I start a side business based on Linux and support for it. Not simply because of this news, but news like this in general. I'm thoroughly impressed with Ubuntu and other distributions to get done what I want

    • by Yfrwlf ( 998822 )
      Just Google Linux games, there are several sites. Currently there are a few semi-decent Linux games out there, but of course the best ones are still close source. It's slowly becoming more commonplace for companies to start supporting Wine more, so they can release a Mac version which is just their Windows version bundled inside Wine/Cider, and at the same time also support Linux users as well. I can install and play Spore easily in Linux for instance, just had to make sure Pulse Audio wasn't running oth
  • VDPAU sounds like some sort of local hawaiian cure for venereal disease
    - VD Pau! Fo wen you ala-alas stay too itchy.

    Meanwhile, it is interesting that after many years, Nvidia finally starts to support video decode/playback acceleration just days after ATI ships a driver with similar hardware acceleration support. [phoronix.com] Of course neither vendor uses any sort of common standard - although ATI claims their stuff is almost identical to the Direct X Video Acceleration (DXVA) API that MS has enforced on Windows.

    • Re: (Score:3, Insightful)

      by Kjella ( 173770 )

      Meanwhile, it is interesting that after many years, Nvidia finally starts to support video decode/playback acceleration just days after ATI ships a driver with similar hardware acceleration support. Of course neither vendor uses any sort of common standard - although ATI claims their stuff is almost identical to the Direct X Video Acceleration (DXVA) API that MS has enforced on Windows.

      What standard would that be? VA-API that has a few headers and zero implementations? Intel doesn't even follow the DXVA specification [intel.com], and won't publish the interface or support video acceleration on XP. ATI is as you say a DXVA -> XvBA search&replace job, which might be good or just bring plenty DirectX luggage. If nVidia put some job into making a good public video acceleration interface for Linux, it might be the best of the bunch. Their implementation may be closed source but if it works well...

      • Re: (Score:3, Insightful)

        What standard? Well, they could have done it the way the internet was built - with an RFC like approach. Coopetition and all that.

        let's just say I can live very well with a 98% open source system.

        Yeah, people always say that, until a show-stopper bug comes along in the 2% that's closed and they can't do a thing about it.

        • Re: (Score:3, Interesting)

          by Kjella ( 173770 )

          Yeah, people always say that, until a show-stopper bug comes along in the 2% that's closed and they can't do a thing about it.

          As opposed to the 100% that's closed and not nearly as terrible as you make it out to be? Reality is that most open source bugs I can't do anything with either, for practical values of "can't". I could file a bug report, been there done that and often it falls into the same black hole as closed source software. I could try to dig around the code myself, but just getting all the build requirements and trying to figure out the code base usually takes hours of time I don't want to spend. Bonus points if it's w

          • Re: (Score:3, Interesting)

            usually takes hours of time I don't want to spend.

            But at least you have the option of spending that time.

            My personal example, from quite awhile ago -- Linux Kernel 2.4, which didn't have native support for AGP 3.0 / AGP 8x. No matter what I did, I couldn't force it back to an older standard, and I wouldn't have wanted to, anyway. Which was all fine -- ATI implemented AGP in their drivers to compensate, but it was broken -- detected my card as AGP2 instead of 3. So AGP didn't work -- I don't remember if this meant no hardware acceleration, or no X at all, b

          • Reality is that most open source bugs I can't do anything with either, for practical values of "can't"

            Pretty much your entire argument, including your previous posting, boils down to "The freedoms of Free software don't directly benefit myself, so they are useless for everyone."

            That's a terribly short-sighted viewpoint and if everyone held it, you would not have the option to run linux in the first place.

  • Why? (Score:3, Insightful)

    by MobyDisk ( 75490 ) on Friday November 14, 2008 @09:17PM (#25767545) Homepage

    Why would anyone use a proprietary video API provided by a closed source driver tied to a particular piece of hardware... on an open source platform? Huh?

    • Re:Why? (Score:5, Insightful)

      by arevos ( 659374 ) on Friday November 14, 2008 @09:41PM (#25767735) Homepage

      Maybe because there isn't a better open source alternative.

      • by MobyDisk ( 75490 )

        Alternative to what? This is an API that accesses a proprietary feature of a specific video card. Nobody was asking for one. Who would use it and why? I just don't get it.

        Now, if nVidia proposed an open standard video playback API, and implemented it in their video driver, and released the source - then I could see Linux devs using it.

        Or did I somehow misunderstand what they did?

        • by ADRA ( 37398 )

          Like implementing, oh maybe XVMC (completely) or VAAPI would've been a good start at coming out with an open API that isn't 'yet another poorly supported video API from vendor X'.

          Better yet, why not collaborate with all the other big fish in the pond to come out with an API that everyone is satisfied with instead of pissing on everyone requiring yet-another video API.

        • This is an API that accesses a proprietary feature of a specific video card. Nobody was asking for one.

          Yes, they were. I certainly was.

          It sucks to watch HD h.264 video lag, and be forced to use 720p -- even re-encode 1080p videos down to 720p, to help the issue -- knowing that there's a proprietary feature of a specific video card which I happen to own which would solve the whole issue.

          Now, if nVidia proposed an open standard video playback API, and implemented it in their video driver, and released the source - then I could see Linux devs using it.

          Unless they've somehow patented or restricted the API, I'm not really sure what's stopping their competitors from implementing it.

          And it seems inevitable that support for this will find its way into mplayer, gstreamer, maybe e

    • Re: (Score:3, Informative)

      From TFA:

      VDPAU is an X extension, and anyone can implement it. It's a competitor to the XvBA extension being developed by AMD, only it exists now, with hardware support, and is derived from an existing technology that has been tested on other OSes.

    • Re: (Score:3, Interesting)

      by AaronW ( 33736 )
      I use whatever works. For me, the nVidia closed source driver works better than any open source driver.

      I struggled for months with ATI and cursed it every few minutes when it would screw up the text in my editor (closed source driver). By the time the open source driver came out I had already dumped the computer for one with an nVidia card because the drivers just work, out of the box. Intel wouldn't recognize the monitor, ATI would constantly screw up, if I could even configure it for the monitor, but
      • Re: (Score:3, Insightful)

        by MobyDisk ( 75490 )

        I use whatever works. For me, the nVidia closed source driver works better than any open source driver.

        I use it too. But the question wasn't about who will use the driver. The question is who will use the API. APIs are used by developers, and Linux developers don't like closed APIs or closed drivers. So I don't see them being big supporters of this.

  • So can anyone comment on whether this API is good enough to implement in other video drivers?

    Or whether it's worth implementing the API in X, or even as part of Gtk/Qt/yourfavouritetoolkit, which would all seem to be more sensible places to put a video API than inside a single device driver. (â½)

    • It's an API into specific hardware features only found on nVidia graphics cards; seems to me nVidia's graphics drivers are the perfect place for it.

      Aikon-

  • Comment removed based on user account deletion
    • by ADRA ( 37398 )

      Recent PowerDVD installs an accelerated Directshow filter which offloads much of the CPU load to the GPU, which I've verified myself, but the bad side is that it replaces FFDShow in most of my pipelines, which I prefer to use simply based on the shear number of tweaks needed to get that picture 'just right'.

      Now that pretty much every CPU can decode any type of HD video without needing the GPU for any co-processing, I think that all GPU vendors dropped the ball in trying to move into that fragile niche.

      • by Grey_14 ( 570901 )

        As someone who wants to build an HTPC based on a low power CPU, I can say that I am definitely interested in offloading hi-def video decoding to the GPU, being able to toss a fanless 8500 into a system with an intel atom or underclocked amd-le cpu, and knowing that 90% of the video decoding will be offloaded to the GPU certainly sets my mind at ease when I'm looking at 1080p streams.

      • Comment removed based on user account deletion
        • Re: (Score:3, Informative)

          by GleeBot ( 1301227 )

          PowerDVD/WinDVD also support Blu-ray (and HD-DVD, not like anyone still cares about that), so yes, the video codecs they install (which are usable system-wide) support VC-1 (WMV9), H.264, 1080p, etc.

          PureVideo doesn't actually require the $20 NVIDIA DVD decoder (which I think they've deprecated anyway); the NVIDIA DVD decoder is just for people who want to use MCE, and don't already have an MPEG-2 decoder. PureVideo is just an umbrella name for NVIDIA's video acceleration features (with varying levels of su

Beware of Programmers who carry screwdrivers. -- Leonard Brandwein

Working...