NVIDIA Releases New Video API For Linux

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.'"

Comments

Documentation here

[3.1415926535]

ftp://download.nvidia.com/XFree86/vdpau/doxygen/html/index.html

Form follows code.

[Ostracus]

Fine. Now what programs use this API?

Re:Form follows code.

[mandelbr0t]

TFA mentions that patches for MPlayer to use VDPAU on Linux are already available. Hopefully Xine follows shortly.

Re:Form follows code.

[3.1415926535]

Fine. Now what programs use this API?

mplayer (sort of, it's still pretty rough around the edges):

ftp://download.nvidia.com/XFree86/vdpau/mplayer-vdpau-3076399.tar.bz2

It'll probably take a while before complete, stable support for all of VDPAU's features (like timestamp-based presentation) are fully supported by the common video players.

Re:Form follows code.

[Hatta]

Hey, they just released it. Give it time and everything that plays video on Linux will support it.

Re:Form follows code.

[RedWizzard]

nVidia have released patches for libavcodec, libavutil, and ffmpeg. So most Linux software should pick up support in pretty quick time.

Re:Form follows code.

[BrunoUsesBBEdit]

There is no Linux port for QuickTime. I suggestion you try VLC. ;-)

Re:Form follows code.

[Atti K.]

Oh, this PrettyQuickTime must be some open source QuickTime clone!

ATI

[Enderandrew]

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

[Lorkki]

You might be interested to know that ATI's equivalent was also revealed a short while ago.

Re:ATI

[Enderandrew]

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

[Ash-Fox]

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.

It is actually quite far from the truth.

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.

The only thing nVidia is not doing, is making their enhancements opensource.

Re:ATI

[Anonymous Coward]

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:ATI

[Enderandrew]

Here is to hoping that Wayland addresses some of these issues.

Re:ATI

[mrsteveman1]

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

Re:ATI

[Jherek Carnelian]

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 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 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 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.

Re:ATI

[Ash-Fox]

Here is to hoping that Wayland addresses some of these issues.

Wayland is not a new x11 implementation, it's a completely new windowing implementation, similar to Aqua as it would have widgets built into the server among other things.

Personally, I love x11, it's great - Majority of the issues currently with x.org and xfree86 are not x11 related, but architecture problems in x.org itself. A clean new implementation of x11 would probably benefit us a lot more than another Y windows, Wayward, Aqua etc.

Re:ATI

[Jherek Carnelian]

Sorry, I don't know of any tech company that has decent support. My own experience with all companies, including AMD and ATi is similar.

Precisely. If the vendor can't fix it, they should not get in the way of you fixing it yourself, or of that smart guy who always posts to your favorite web forum.

Re:ATI

[xyxvv]

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 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 Nvidia 9800GX2 though. But ether way I can't see the point in going multicard when one card can do the job for less cash, power and heat, since I've never seen where a dual card can get 2x performance, it only makes sense at 2560x1600 with everything turned up using cards in the top 2-3 models from either Nvidia or AMD to make it worth it, since often the slower cards can be outperformed by a single top of the line.

Re:ATI

[xyxvv]

I keep seeing sentiments like this on the Phoronix forums and elsewere, italways seems to e Nvidia Zealotry, at least AMD is releasing docs for their older hardware, and has done allot to make the Catalist drivers actually work since they bought ATI. What has Nvdia done? Any docs released beyond the bare minimum for newcards to just get basic 2d in Nouveau and now this which as has been stated is already going on AMD/ATI cards. How long will it be till they release any docs for their long discontinued hardware? even as crap as ATI's drivers where they did release docs for the R200 series and under cards, yet I still need the Nvidia binary blob to get the now ancient Riva TNT2 M64 in my mom's Ubuntu web browser comp, let alone my 3+ year old Gforce 6200. Color me unimpressed with this latest release from Nvidia, they're the ones falling behind from their once defacto standard. the open source drivers may suck at this time, but at least they're being fed documentation , which is more then you can say for Nvidia. Now if only Intel would release a decently powerful GPU card while holding their consistency of releasing docs and code to x.org.

Re:ATI

[RMingin]

Replying to the intent and not the awkward wording:

Neither.

Multi-GPU on Linux works, but doesn't have the profiling and per-app settings that make it really work. If you look back over Windows driver releases, you'll see that multi-GPU performance is generally crap right after a game is released, unless it's really major A studio stuff. It takes ATI/NV a while to profile and tweak the settings to get multi-GPU really moving. It's mostly abstracted from the end user, but the results are undeniable.

Neither ATI nor NV has any sort of equivilent profiling under Linux so far. There's a global setting and you can do some gross per-app tweaking, but it's user-intensive and the results are nowhere near what you get under Windows.

Multi-GPU is just not a good sell for any gaming under Linux, and likely will not be for quite some time, if ever.

If you look at the FOSS ATI stuffs, they don't have *any* multi-GPU support at the present time, and that's unlikely to change. The closed-source ATI and NV stuff may eventually implement it, but it's unlikely. By then any currently shipping GPUs will be irrelevant.

I had one of the dual GPU single slot GeForce 7950GX2s for quite some time. I got a rather ridiculous speedup by upgrading to a single 8800GT, simply because ~99% of the time under Linux, only one of my GPUs was doing ANYTHING at all.

Re:ATI

[Anonymous Coward]

I don't use Linux because it's opensource, I use it because I find it technically superior.

You don't realize that the reason it's technically superior is because it's open source...

Re:ATI

[ion.simon.c]

No, the bulk of my argument is the fact that nVidia's driver replaces the bulk of x.org. Because what x.org provides is not good enough.

What about xorg is failing to meet expectations?

Re:ATI

[Ash-Fox]

So when you need to trust your system, how do you check the driver for quality? For adherence to standards? How do you know the driver contains no malicious code? No incompetent code? Inspection is impossible

If I thought like you, I would never of been able to reverse engineer all the driver issues, ACPI DSDT table issues, various software issues in the past. It might be harder, but it certainly is not impossible.

And when it breaks, you have no idea why.

If I can't figure out where something breaks without the sourcecode, sourcecode is not going to be that helpful to me, is it?

I agree with the fact that binary drivers are harder to support and in most cases, people just don't bother trying when they break. But don't exaggerate the issue by claiming it's impossible.

Re:ATI

[Ash-Fox]

What about xorg is failing to meet expectations?

Check my previous posts.

Re:ATI

[Ash-Fox]

You don't realize that the reason it's technically superior is because it's open source...

I wouldn't be using Linux right now if I had to use only opensource software and opensource components on it. Without the proprietary bits I am using, it is technically inferior for my uses.

Re:ATI

[Sterling Christensen]

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

It will take something different to replace Xorg.

Re:ATI

[JohnFluxx]

> 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.

Re:ATI

[JohnFluxx]

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:ATI

[Yfrwlf]

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.

Re:ATI

[Yfrwlf]

Not that you can't have shitty close and open source software, but yes, it has more opportunity for success given the pool size of potential developers.

I just think it's so lame of Nvidia and AMD both to keep supporting their close source drivers. The only reason doing so helps them to sell hardware is because they can artificially limit and control their cards and specific game title performance via the easily-updateable driver. They just aren't willing to lose that source of income quite yet and compete more directly. Of course, even if they did, they can still artificially limit their cards on the hardware itself, and now that fully-programmable GPUs are coming out, drivers are going to lose most of their control over the cards any way I'd guess, but hopefully I'm wrong and the opposite will happen. Already though, for AMD cards, the drivers have shifted over to using the on-board software stack instead of accessing the frame buffers and such directly, which gives up that control.

Re:ATI

[ion.simon.c]

If I can't figure out where something breaks without the sourcecode, sourcecode is not going to be that helpful to me, is it?

Never discount the value in having source code and debugging symbols for some faulty module handy. ;)

Having said that, I doubt that even 1% of the folks on this site who bring up the debugging-enhancing power of The Source would be able to use it.

And, having said that... having the source available is an absolute *must* for any software project's long term viability. What happens when a mfgr decides that they're no longer going to support $WICKED_SICK_CLOSED_SOURCE_SOFTWARE_PROJECT ? Why, over the long term, everyone's SOL. ;)

Re:ATI

[ion.simon.c]

I found the post in this thread that points to your LJ entry. Are there others that are topical?

If so, can you give a guesstimate as to when they were posted?

Thanks!

Re:ATI

[m50d]

You'd think that, but actually the level of Crossfire support in both is the same.

Re:ATI

[Ash-Fox]

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

I just see the fact that x.org is not in good shape at the moment when it should be. I don't care if a new server is written from scratch, huge chunks of x.org are rewritten, something needs to be done.

Re:ATI

[Ash-Fox]

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

It might being worked on, but the current state is that it isn't there and it isn't available right 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.

You are putting words in my mouth, I never stated it will never have a unified memory manager, I was saying that there are conflicts within the management of x.org to get this done. I'm aware of Gem, are you aware of how it got implemented and stripped out a few times already?

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

Where did I say I talked to the Xorg team?

Companies like NVidia just replace chunks of Xorg without contributing anything back.

nVidia replace chunk of Xorg to make it work properly without making their changes opensource. We can't really say "contributing anything back" because they aren't really getting anything in the first place, other than a properly working X11 setup.

Whereas its companies like Intel that actually contribute to improving X for everything - pushing a unified memory manager (TTM/GEM) into the kernel etc.

Where is it? I don't see it in Ubuntu intrepid.

Re:ATI

[Ash-Fox]

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.

The thing is, I don't see anything wrong with the current X11 protocol. I see plenty of things wrong with the current architecture provided by x.org and xfree86.

We don't need yet another windowing system, as the current limitations we have are purely due to implementation, not by protocol design.

Re:ATI

[master_p]

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

Re:ATI

[JohnFluxx]

> 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).'

> Where is it? I don't see it in Ubuntu intrepid.
Because it's not done. If every company did it NVidia's way, we'd a have reimplementation of a manager manager for every driver. Are you really arguing that this is the best solution?

Re:ATI

[Ash-Fox]

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

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

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).'

Indeed, where did I state this was Xorg developers? These are people in the opensource community, who are going around promoting Linux everywhere etc.

Because it's not done. If every company did it NVidia's way, we'd a have reimplementation of a manager manager for every driver. Are you really arguing that this is the best solution?

At the moment, nVidia is working, nothing else is, so at the moment, the best solution is nVidia.

I am talking practically, at the moment. I am fedup of waiting for things progress, most of the time they don't progress, take different turns (this problem was supposed to be solved five years ago and look, it still hasn't) etc. I live in the now.

Re:ATI

[Ash-Fox]

Wait a sec, because I defend myself from being called a nVidia zealot (I'm not, I just choose the best solution on technical merit) when in reality the other person is being a opensource zealot, implying anything that isn't opensource is useless and my post is deemed flamebait?

Sure, there are different sides to the argument, but this is by no means flamebait.

Re:ATI

[Ash-Fox]

How is my post troll? So far nobody has managed to give working refutable information.

So far, the most opposition I've had was stuff that was discussed, not implemented, was implemented and removed, vapourware etc. nothing that could refute the current state that X.org and various opensource projects are in.

Re:ATI

[Yfrwlf]

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 the need to re-implement the entire thing. Not a problem as long as the protocol/standards are followed so that users of the new windowing servers can continue to run their favorite programs, desktop environments, and windowing managers.

Re:ATI

[makomk]

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.)

Re:ATI

[Ash-Fox]

Nvidia doesn't even use DRI at all

nVidia provides a DRI interface that provides everything, that is what is important.

it has its own replacement for it copied over from the Windows drivers. (This has... interesting security implications.)

Such as?

Re:ATI

[makomk]

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 impact isn't an issue since the compositing operations are really simple.

(The issue with Compiz is that currently you can't use 3D apps at the same time reliably, since they can't render to an offscreen buffer. This is what DRI2 is intended to solve, and it's tricky to get right since it involves multiple apps with access to the same buffers. Support would be here already, but there were issues with some of the driver developers.)

(b) It is possible to do offscreen buffers without a proper memory manager, it's just not a good idea. (I'm unclear on why precisely). Besides, the memory manager issue was pretty much done and dusted by the time you wrote this - everyone agrees GEM is the way forward, the initial version has been merged already and will be in the next kernel/X.org releases, and drivers are in development.

Also, I think ATI may have their own memory manager and some support for offscreen rendering/pbuffers in the closed source driver. There's just no support for using a compositing WM and OpenGL apps, since that does require DRI2.

Re:ATI

[makomk]

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). This means that just auditing the obvious userland-system interfaces isn't enough (not that it would be anyway).

Re:ATI

[Ash-Fox]

(a) You claim that only NVidia has direct 3D rendering.

Wrong, I never said "only NVidia has direct 3D rendering". I've stated nVidia provides all the options simultaneously, where other drivers do not provide all due to the various issues mentioned. I've also mentioned nVidia (besides mesa's software renderer) is the only driver that can do things like redirected rendering.

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.

The performance impact isn't an issue since the compositing operations are really simple.

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.

(The issue with Compiz is that currently you can't use 3D apps at the same time reliably, since they can't render to an offscreen buffer. This is what DRI2 is intended to solve, and it's tricky to get right since it involves multiple apps with access to the same buffers. Support would be here already, but there were issues with some of the driver developers.)

I'm fully aware of these issues, which was why there are terrible AIGLX/mesa 'hacks' involved to get around this with people in the middle of it, claiming that there is no performance loss and infact you get better performance - what a load of crap.

(b) It is possible to do offscreen buffers without a proper memory manager, it's just not a good idea. (I'm unclear on why precisely). Besides, the memory manager issue was pretty much done and dusted by the time you wrote this - everyone agrees GEM is the way forward, the initial version has been merged already and will be in the next kernel/X.org releases, and drivers are in development.

Everybody agreed GEM was the way forward before, merged it, then at the last minute stripped it out and decided to rewrite it. Until it's actually part of a Linux distro, it's just vaporware to me - I have heard it all before and not only once, but numerous times. These were issues that were supposed to be resolved five years ago, I might add.

Also, I think ATI may have their own memory manager and some support for offscreen rendering/pbuffers in the closed source driver. There's just no support for using a compositing WM and OpenGL apps, since that does require DRI2.

ATi have a hack with fglrx, but they don't 'hook' into x.org, remapping the majority of functions like nVidia does.

Re:ATI

[Ash-Fox]

Complicated. Firstly, as I understand it they give applications direct access to the graphics card and rely on it to enforce security restrictions.

Sort of, it permits the use of certain functions directly to the graphic card, however certain features are blocked in such a way that only applications running as root are capable of sending those opcodes (such as x.org).

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.)

This is not really much different from errata in regular processors that allow exploiting a given operating system, in which user-mode applications are generally able to fully exploit. Exploitable hardware is exploitable hardware.

The only difference is that with graphics hardware, it's possible to load a special graphics firmware that fixes potential issues when starting the graphics system, while with processors, you need to do somewhat risky microcode updates or write some kind of workaround in the OS.

Of course, the amount of abstraction provided by X/OGL/GLSL calls tends to be enough to prevent applications from exploiting the majority of vulnerabilities, since the driver tends to limit the more dangerous calls to root processes.

However, yes, I agree, there is a risk.

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). This means that just auditing the obvious userland-system interfaces isn't enough (not that it would be anyway).

I fail to see how this is any different from FGLRX running in ring-0? I don't see how this a nVidia specific issue.

Re:ATI

[makomk]

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 compositing window manager. (This causes nasty flickering in windowed OpenGL apps, but I'm not sure if using AIGLX helps with this.)

Everybody agreed GEM was the way forward before, merged it, then at the last minute stripped it out and decided to rewrite it. Until it's actually part of a Linux distro, it's just vaporware to me - I have heard it all before and not only once, but numerous times. These were issues that were supposed to be resolved five years ago, I might add.

Nope, that's not quite accurate - what happened is that everyone agreed that TTM was the way forward, then Intel decided to do their own thing (GEM) and TTM got stripped out and replaced. GEM is, at this point, basically final - it's merged into the kernel, something TTM never managed, and the main players are working on support for it. (I believe there's already working support for Intel graphics.) Expect it to be available to users around January-time.

Re:too late, I won't buy nvidia now

[QuantumG]

For some reason I don't think they're sweating over the loss of a customer who can't even start sentences properly.
 

This isn't a new nvidia driver

[LingNoi]

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:This isn't a new nvidia driver

[3.1415926535]

I think the confusion stems from the fact that there's also a new beta driver release that supports this, 180.06.

Re:This isn't a new nvidia driver

[LingNoi]

Indeed however the summary says,

"Phoronix is reporting on a new Linux driver nVidia is about to release"

It's not really a new one, it's the old one just updated.

Re:This isn't a new nvidia driver

[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 scheme for their installers so that you have to go manually poking through their FTP site to find the latest, and still don't know where they might have hidden it. And someone expects their API to their binary blob to be usable to those who haven't signed employment contracts with them? I think not.

Re:This isn't a new nvidia driver

[vally_manea]

I understood that they replace the Mesa libraries due to stupid design decisions in X(sorry but I lost the link). To be honest my current nvidia blob is the most stable X video driver I've ever ran so keep up the good work NVIDIA. Now if they added support for XrandR 1.2...

Re:This isn't a new nvidia driver

[Yfrwlf]

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 managers and be made cross-distro need to just die off until they are more friendly to the community which should be all about getting along and interoperability, especially within open source platforms.

Re:This isn't a new nvidia driver

[Ed Avis]

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. It's unreasonable to expect all distributions to support that.

BTW, the moderation of your comment as 'Troll' is a sad reflection on the Linux-groupthink around here.

Re:This isn't a new nvidia driver

[Yfrwlf]

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 though if I could install both RPMs and DEBs for example on my distro. If both formats need an update so that's possible, great, do it. Coming up with a system to deal with name collisions and making it so multiple libraries can be installed side-by-side so there is no overwriting, etc etc, all that should have been done long ago. All Linux distros should be modular and intelligent enough to install any package provided it contains a minimum amount of information. Supplying this information would not be difficult, and package managers could still put the files where ever they preferred to provided there is a way for programs to get to the libraries and such that they need (i.e. using special paths, or whatever solution you want to for that).

What I'm trying to say is that it's completely possible, it's just software, and with software nothing is impossible, and a system which is designed to use intelligent APIs to allow for future improvements and as long as things are designed so that interoperability can take place, there's no problem. It's all very possible, and I wish the standards groups luck in coming up with systems to solve these problems and make things truly modular so that Linux/BSD/OpenSolaris/others open source software users will have true and total freedom that's also not limited by intelligence in command line and compilation know how, as long as you know how to use a mouse to click on something, and hell, in the future shouldn't even be limited by that.

Re:This isn't a new nvidia driver

[Yfrwlf]

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, hence distros like Gentoo being extremely paranoid when it comes to configuration file changes. That is not the solution and not a good solution. You don't use brute force to get programs to play nicely with one another, you use intelligence, smart programming, APIs, systems that allow that communication to take place.

The keyboard is mightier than...the lock-in?

But seriously, it's stupid. The Free Desktop Foundation and others try to help make sure programs have this interoperability, and thanks to developers who give a shit about things like that and actually care about their users and care about seeing their programs actually adopted (even though sometimes it's more because they're the only solution around and not because the program is actually a good one or feature rich) I can run both Gnome and KDE apps at the same time, and I can load up any desktop environment, etc etc. So, you know, anyone saying that interoperability is impossible and you have to hard code a million apps into one giant non-modular stack of doom and call it a "distro" or whatnot needs to get out more and take a deep breath of real software freedom.

Re:XVID or DivX

[Narishma]

TFA says it supports MPEG, H264 and VC1.

Release Date

[pinkocommie]

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:-))

Re:Release Date

[drdanny_orig]

From what I've seen, nVidia never releases non-beta code. that way they can do without a QA team.

Re:is jesus real?

[Reikk]

Plus, it is well documented that Jesus was black. Barack Obama is also black. Coincidence? I think not.

Re:too late, I won't buy nvidia now

[martinw89]

Or maybe, just maybe, an attempt to clean up what you write gives a better impression to whomever reads the post. And I'm not saying we all need to appease grammar nazis.

Re:too late, I won't buy nvidia now

[HappySmileMan]

Yeah, the money English scholars spend is worth much more than that monopoly money spent by TheGratefulNet

Does this mean...

[Anonymous Coward]

that my linux media box can now do video decoding on the video card instead of processor?

VDPAU? A new Vulcan emmisary?

[zappepcs]

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 to get done.

Anyone (not I have not Googled extensively yet) know of any good sites that detail gaming on Linux? If you do, what is your take on this news?

Re:VDPAU? A new Vulcan emmisary?

[Yfrwlf]

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 otherwise I'd get crackles. So, currently it seems that since the Windows API is now a mostly cross-platform API, even though it's still a closed one and controlled by Microsoft, that it's the single API of choice for simplified game development. Of course I hope that changes in the future and it will eventually since it's silly loading lots of duplicate libraries that do the same thing on a system, but whatever works. Not like porting to Linux is all that difficult any way if you're already using OpenGL to begin with.

Any way, so yeah gaming on Linux does exist, even for some of the commercially pushed big/common/popular/trendy/bleeding edge titles, but it still has a lot of catching up to do of course, and it's happening slowly. I'd just like certain things to be implemented to speed things up like a general further improvement of the desktop and desktop apps, and easy cross-distro app installation.

Cure for Venereal Disease

[Jherek Carnelian]

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. 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:Cure for Venereal Disease

[Kjella]

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, 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... let's just say I can live very well with a 98% open source system.

Re:Cure for Venereal Disease

[Jherek Carnelian]

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:Cure for Venereal Disease

[Kjella]

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 written in a language I don't know well. Or I could hire someone to do it, but I'd have to negotiate, make some reproducable cases (real fun if it happens randomly or specific to my hardware) and follow up with testing and payment. If nobody gives a shit about my problem and don't want to fix it to improve the application but only for the money, then hiring your personal developer gets real expensive real quick. None of my home PCs run anything mission critical, the solution to 99% of my issues is to simply roll back or not upgrade, if I've wisely tested something in advance.

I think open source is really great in that other people can borrow code from other projects, applications can fork, groups can develop specific functionality independently and so on which makes it possible for development teams to work with everything that's been done before rather than starting from scratch. That process I think in the end creates very mature software, but to be honest I really don't see it being that much help with fixing acute problems. Open source means there's competition on being support, and that you can hire people to do custom development, but unless you're paying very well there's no guarantee at all your problem will be solved in a timely fashion. Which is like closed source support in my experience, some bugs get fixed while others can be largely ignored. I suppose the escalation options are better with open source but really I don't see a situation where I in capacity of being a home user would ever use them.

Re:Cure for Venereal Disease

[SanityInAnarchy]

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, but it did suck.

So I cracked open the source -- that AGP stuff was in the open part, at the time -- found the detection algorithm, commented the whole block out, and hardcoded it to AGP3.

Now, granted, there's no reason I should have to dig into the source for that. The detection should just work, and failing that, it should be possible to override that autodetection without recompiling your kernel.

But either way, I was able to work around the issue in a way which would have been impossible if it was closed source. My only alternative was to either buy new hardware (and hope it was compatible this time), or go back to Windows.

I was 16 at the time. I'm paid more now, but still not enough to keep buying new hardware until something works. I always lean towards open source, unless there's a compelling reason not to.

That said, I'd be a hypocrite if I didn't mention -- I'm typing this on a Dell which came preloaded with Ubuntu. It's got an nVidia chip in it, which actually works fairly well. I do use Skype to talk to my brother in Taiwan.

But for things like that to happen, the proprietary version has to be sufficiently better that I'm willing to give up the ability to fix things myself. I'd be very wary of buying a car with the hood welded shut -- but if it's, say, an affordable Porche, it might bother me less.

Re:Cure for Venereal Disease

[Jherek Carnelian]

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.

Re:Cure for Venereal Disease

[JasterBobaMereel]

99.9% or issues I have ever had with OpenSource software have already been solved/worked around by the time I find them, perhaps I am not close enough to the bleeding edge to get problems, but most of the issues I have with closed source software are still problems when I have moved on ...

Mac OS X feels so 1990's

[SimonTheSoundMan]

When will any decent video/GPU support come to Mac OS X?

Apple have only just managed .h264 decoding using the GPU on the latest MacBook and Air series.

My current MacBook Pro with 8600M GT can now do such decoding in Linux, and has been able to with Windows for years.

Re:Mac OS X feels so 1990's

[Ash-Fox]

When will any decent video/GPU support come to Mac OS X?

When Apple gets serious about it. Apple is the one creating the APIs on OS X for OEMs to provide, unlike in the Linux/Windows world where it goes both ways.

Re:too late, I won't buy nvidia now

[spazdor]

It's grammer. Get it rite.

Re:too late, I won't buy nvidia now

[Alien Being]

QuantumC

There, I fixed that for you.

Why?

[MobyDisk]

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?

[arevos]

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

Re:Why?

[erikharrison]

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:Why?

[AaronW]

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 the nVidia one just worked. They provide better features than any other driver I've seen, both open and closed source, and their performance has always been better.

Similarly with photo software. I use the Linux version of Bibble Pro because I have yet to find an open source equivalent that is anywhere close. Gimp doesn't come close in its RAW handling or ease of use for workflow processing.

I've tried to use ATI but I had way too many problems and terrible performance. Similarly with the open source Intel drivers which did not work at all.

Open Source has many benefits, but when it doesn't do what I need, I'll pay for something that does.

I write software, both open and closed source and am currently hacking on the Linux kernel. I think both have their place and neither side is perfect.

Re:Why?

[MobyDisk]

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?

Re:Why?

[MobyDisk]

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.

Re:Why?

[ADRA]

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.

Re:Why?

[SanityInAnarchy]

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 even xine -- especially considering that if I recall, mplayer can use gstreamer plugins, and gstreamer can use ffmpeg. Maybe, if we're really lucky, Flash will support it, too.

I mention these things because any one of them could have been the API. It seems the most coherent effort is gstreamer -- but that seems to be failing so miserably that KDE4 even has a meta-API called Phonon, which wraps gstreamer, xine, or whatever's available.

Since the situation is so chaotic, it really doesn't seem to matter which they chose. So they wrote their own. Doesn't matter -- the result is the same.

Re:Why?

[cjb110]

oh I don't know, simple practicality maybe? A general user possibly just wants the features of their paid for hardware to work, without all this meaningless bitching about open, closed, slightly holey, source crap.

Video API inside a single device driver?

[Karellen]

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. (â½)

Re:Video API inside a single device driver?

[AikonMGB]

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-

Re:XVID or DivX

[Wesley Felter]

It supports MPEG-1, MPEG-2, H.264, and VC-1. No MPEG-4 (aka XVID/DIVX).

ftp://download.nvidia.com/XFree86/vdpau/doxygen/html/group___vdp_decoder.html

maybe the 'rite' didn't properly convey my intent

[spazdor]

sigh.

VAAPI !!!

[mmu_man]

Exactly, can't they just instead use an open standard (pleonasm, if it ain't open it doesn't deserve the name standard) like VAAPI ? And eventually submit extensions to it... That's what standards are for!

http://www.freedesktop.org/wiki/Software/vaapi - http://en.wikipedia.org/wiki/Video_Acceleration_API

Re:VAAPI !!!

[mmu_man]

Plus it's not bound to X11 so it can even later be used on other OSes like Haiku ;)

Let me say this to you Linux guys

[hairyfeet]

I sincerely hope you have better luck with Purevideo than we Windows users have. As someone who has been buying Nvidia cards since the days of the Geforce 2 I can say that trying to get Purevideo to work is the biggest exercise in frustration I have ever seen. Frankly after trying just about every video player and forum I just gave up.

And how can Nvidia claim you get all these advantages from Purevideo when the only way that they have to access it that I have seen is with 3rd party apps that they don't give you with the card and they don't support? I mean they can claim the latest Geforce can decode 4 HD streams while playing Crysis and cooking your breakfast in the morning,but if the only way to access that feature is with some driver they won't give you and you have to hunt up yourself that may or may not work,how can they call that a feature?

I mean you look at this chart here(warning:PDF) and it says my 7600 AGP does H.264,WMV9,the list goes on and on,but when you look at their site all they have is a $20 DVD driver. WTF? Who in this day and age needs their video card just to decode a bloody DVD?

Re:Let me say this to you Linux guys

[ADRA]

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.

Re:Let me say this to you Linux guys

[Grey_14]

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.

Re:Let me say this to you Linux guys

[hairyfeet]

Uuum,you may need to correct me since it has been about 2 years since I messed with PowerDVD or WinDVD,but since the name is DVD I'm guessing that it is offloading DVD video,yes? Which again brings me back to my point. I could not care less about offloading standard def DVD video,since my P3 733MHz with 384Mb of RAM and an old Geforce MX4000 plays DVD discs full screen without skipping. What I want is to offload H.264,MP4,and WMV9 which it says my card can do. But after about 6 months of getting "shell out some cash for this and it MIGHT work,maybe" I gave up. Does PowerDVD actually offload the formats I named,or simply standard def DVD?

As for the other poster talking about a low power HTPC,I really REALLY wouldn't. Not unless the only thing you want to watch is standard def DVD on it. I would do this if I was you: Find a driver that will actually offload the formats you wish to watch FIRST. Then test the GPU by actually using something like process monitor to see how much load is actually being offloaded to the GPU. IF you are able to get the card to actually offload using the software THEN you can build a low power HTPC.

But as I said in my post I tried for 6 months and despite the claims all I ever saw offloaded was standard def DVD,which as I said is pointless. But I'm afraid that if you try you'll find out like me that you'll get a LOT of "shell out for this program and it MIGHT work,and oh yeah we don't support it." Believe me it is not fun and so far I haven't seen anyone but Nvidia make these claims. Has anyone found independent benchmarks for anything OTHER than DVD? Hopefully with a list of software used?

Re:Let me say this to you Linux guys

[GleeBot]

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 support), which is then used by specific applications (like WinDVD and PowerDVD). It's already cooked into the free drivers.

Re:Let me say this to you Linux guys

[hairyfeet]

Thanks for the info,and if anyone else wants some more details,they give a little more here. Has anyone here used this product lately? How is it for stability? Because I have PowerDVD 8 sitting on a disc in my software box which came with the last burner I bought,but I've been afraid to stick it on due to how flaky the one that came with last year's burner made my system. So any users? Did it screw up your media player classic like the last one did mine?

That still doesn't explain though why they don't actually package a driver in the box that lets you use the feature that is touted so heavily on the label,at least on my card. How is Joe and Jane consumer supposed to know that they can only use that feature by shelling out some cash for a certain version of PowerDVD or WinDVD? If even the cheapest burner manufacturers can pack in Nero OEM and WinDVD/PowerDVD I don't see why Nvidia can't pack in an OEM version that will allow you the use of the features you paid for right out of the box.

Re:Let me say this to you Linux guys

[ADRA]

A little late for the topic, but since you're going to make a purchasing decision at some point let me just chime in one more time:

If you're pushing hi-def into a PC, you're going to get warm no matter what. If the CPU or the GPU or whatever makes the heat it doesn't matter. Something has to crunch those instructions.

That being said, a GPU may be able to crunch floating points in a more efficient manner than a general purpose CPU, but then again, I can't really say for sure either way. I have never seen a unique benchmark measuring video acceleration/heat dissipation readings and I'm skeptical to believe there will be such a benchmark any time soon.

Ultra low level CPU's aren't terribly interesting if your GPU requires a fan and constantly cranks out heat in crunching decode operations.

I can't really recommend one solution over the other since the information is scarce, but beware of just assuming that GPU decoding will require less heat / electricity.

Re:Let me say this to you Linux guys

[m50d]

Has anyone here used this product lately? How is it for stability? Because I have PowerDVD 8 sitting on a disc in my software box which came with the last burner I bought,but I've been afraid to stick it on due to how flaky the one that came with last year's burner made my system. So any users? Did it screw up your media player classic like the last one did mine?

I'm using the PowerDVD 7.3 that came with my drive and it's beautiful; good playback, didn't conflict with anything else, excellent DVD menuing support (the main reason I used it, for playing Phantom of Inferno), and a way to get the VIDs for playing my blurays (no point actually watching them in a genuine player because it won't display at full resolution on my analogue monitor, but it's needed to help me rip them). It does the "incompatible with aero graphical effects" thing, but that's as you'd expect from a hardware-accelerated video player.

That said, if you want to buy something to play h264 faster you're probably better off with CoreAVC unless your processor's really weedy. It's not hardware-accelerated, but that's because it doesn't need to be.

Re:too late, I won't buy nvidia now

[MightyYar]

Well, chances are the clerk that you buy the video card from has an English degree :)

Re:is jesus real?

[mitzip]

Jesus was not endorsing taxes. All the money was owned by caesar. Jesus was saying if the owner asks for his property back, give it to him. The pharisees were trying to make Jesus publicly encourage people to break the law, to have him arrested. Which is completely different from how taxes in the US operate. In the US your wages are your property. The US Constitution says your property cannot be taxed. All property taxes, including "income taxes" operate in spite of our Constitution, as most of our laws today do.

Re:is jesus real?

[Anonymous Coward]

You mean that some scruffy, middle eastern looking dude with a history of extremist rhetoric, violence, and worst of all Marxist communist socialist redistributionist tendencies might not find a warm welcome?

I bet we'd sent him to Gitmo.

Re:too late, I won't buy nvidia now

[Plaid Phantom]

I buy from Newegg, you insensitive clod!

Re:Translation

[corychristison]

No.

Re:Translation

[SanityInAnarchy]

No. But they will suck less.

Depending on what you're doing, they already suck less than the competition.

TRUE 2X SLI performance....

[Khyber]

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.)

Re:too late, I won't buy nvidia now

[Tatsh]

Oh please. Until ATI specs are FULLY released and the open source drivers fully support 3D and are stable, it is pointless to think ATI/AMD are our new ally. Right now the open source drivers ati and radeon support 2D only (however they are 10x more stable than binary ATI drivers, any version).

Re:too late, I won't buy nvidia now

[BrokenHalo]

Are you going to respond to the content in the post, or are you grading English papers?

Nobody else seems to be interested, so I will.

I don't know what the GP was talking about with his flames about the reliability of nVidia's hardware. I've had many of their graphics cards over the years, and I have never, ever had one fail.

In fact, they are almost too damn good. I now have quite a few of them sitting in a crate because whenever I have upgraded motherboards, the slots keep changing, so I've had to change graphics cards when there was nothing wrong with the old one.

Nvidia were pretty much the first to give really good support for Linux, and I couldn't care less if they want to keep their source code secret. I've got better things to do than hack on that kind of code.

In a world where most hardware manufacturers have felt it only necessary to provide drivers for Windows, nVidia's attitude is a refreshing change.

Good but late

[mebrahim]

Good, but why so late?
AFAIK PureVideo is a very old feature of nVidia graphic chips.

Re:too late, I won't buy nvidia now

[Anonymous Coward]

Anywhere that written language is used should be "formal". Languages have rules because it facilitates communication. When you start misspelling every other word, using incorrect punctuation and typing things like "omg gtfo" you lose that ability to communicate effectively. It also makes you appear to be either uneducated or uncaring. If you lack the education to speak or write properly, then you probably also lack the knowledge to comment on the subject being discussed. If you just don't care enough to use correct grammar, then why should anyone care about what you have to say?

You don't have to be perfect in your speech or writing but you should at least try to be.

Re:too late, I won't buy nvidia now

[argiedot]

I found my Intel GMA 950 more pleasant to use on Linux for my current purposes (I play no games, but I like an accelerated desktop) than my nVidia 8400M GS. For some reason, while Firefox scrolled great on the old one, it's hell on the new one.

In addition, the 8400M and 8600M are vulnerable to heating issues, and I have already lost one motherboard to this. I don't know if ATi's Mobility 3850s are better, but these nVidia chips are bad, and if I'd known this and known if the GMA X3100 had better linux drivers I would have bought that instead.

I hate Linux graphics

[louzer]

Here is some good constructive criticism: http://linuxhaters.blogspot.com/2008/06/nitty-gritty-shit-on-open-source.html

Re:I hate Linux graphics

[JohnFluxx]

So basically, NVidia wrote their own memory manager rather than working with the community. Compared to Intel which is working with the to write a memory manager (TTM) which will benefit everyone.

And somehow NVidia is better than Intel? lol

Re:I hate Linux graphics

[makomk]

Actually, Intel gave up on that and wrote a memory manager (GEM) that only supported what was needed for their own drivers, ripping out TTM in the process. (This was done after TTM was largely complete and development had started on drivers using it, so it was rather disruptive.)

Current development efforts for ATI cards and the Nouveau project are going into creating some combination of GEM and TTM code that is actually useful for other hardware. I'm not sure how well this is going.

Why not use VaAPI?

[nxsty]

http://en.wikipedia.org/wiki/VaAPI

Why does nvidia always have to develop their own proprietary stuff rather than using what's already avilable?

Re:XVID or DivX

[Directrix1]

H.264 is a more advanced variant of MPEG-4.

Re:too late, I won't buy nvidia now

[TheGratefulNet]

'start sentences properly'?

really?

that's the best you have?

would you care to comment on the *content* of what I wrote instead of nitpicking on minutia?

with all the bad press the later chipsets are getting (and things like dell putting out a bios 'fix' that basically keeps the fan on ALL THE TIME) - I still maintain that nv chipsets in the 8's and 9's are timebombs waiting to go off. their failure rate is unacceptable and its seems to NOT be limited to just 1 or 2 production runs.

I have an 8-series card and when it stops working, do you think the vendor will accept it back? I doubt it.

nvidia: not for me, never again. sorry if this is 'trollish' to some but its a valid customer reaction to a FAIL on their part to design and actually implement long-term viable hardware.

nv is just not a good technology company beyond their core competancy. intel walks all over them in motherboard northbridge chipsets, ethernet chipsets and the only real thing nv is good at is video technology. their integrated motherboards are a disaster (performance and reliability). I built pc systems and have direct experience and as much as I *hate* giving intel the nod, I have to, right now. nvidia chipsets are annoying for linux builds and somewhat annoying for windows builds.

the video chipset hardware failure was just the last straw with me and nvidia. I gave them lots of chances and I have enough nv hardware here to show I've given them chances. I *wanted* viable alternatives to intel mobos but nv is NOT it, that much I now know from direct experience.

Re:too late, I won't buy nvidia now

[andreyvul]

The opensource r300 (9600 - X850) driver has full 3D support (i.e. compiz works perfectly), apart from a bug where GARTSize needs to be manually set in xorg.conf lest your X borks due to running out of texture memory.

Re:too late, I won't buy nvidia now

[makomk]

Yeah, on the last benchmarks I saw, the 2D acceleration on the modern NVidia hardware under Linux was significantly slower than on Intel graphics (by orders of magnitude in some cases). Supposedly, NVidia have improved it somewhat since then.

DRI2 + Gallium3D

[steverweber]

I thought the plan was to move to DRI2 and Gallium3D http://www.phoronix.com/scan.php?page=news_item&px=NjcyMA

Re:is jesus real?

[CarpetShark]

Considering it's an ethical and social issue, I doubt very much that he didn't care. He just knew he couldn't say it and get away with it, I think. It's one of the few disappointing things for me about Jesus's story.

Re:is jesus real?

[awrowe]

So it IS cos I is black!

You bastards!

Arghh - which video to buy?

[garyebickford]

This article is germane to my immediate decision problem - I've been authorized for a brand new workstation with dual, or even three monitors. There are limits - no $2100 3DLabs 3800x2400 cards are in the plan.

I prefer to work in the Compiz/OpenGL environment, and it has to run under Ubuntu.

So which way to go?

Do any of the video cards have fully functional open source drivers? (This is by no means a criticism of the OS driver gurus - they've done an amazing job of making this fancy hardware sing with the minimal support they got from the vendors for a long time. Props all round, folks.)

If not now, when are they going to? Sigh. On my Lenovo Z61m laptop with an ATI chip, the open source drivers support suspend/hibernate but not OpenGL. The ATI proprietary drivers support OpenGL but the laptop can't suspend or hibernate.

Is there a dual- or multi- monitor card with OpenGL, that has fully functional open source drivers? Enquiring minds want to know.