Slashdot Mirror
Transcoding in 1/5 the Time with Help from the GPU
mikemuch writes "ExtremeTech's Jason Cross got a lead about a technology ATI is developing called Avivo Transcode that will use ATI graphics cards to cut down the time it takes to transcode video by a factor of five. It's part of the general-purpose computation on GPU movement. The Aviva Transcode software can only work with ATI's latest 1000-series GPUs, and the company is working on profiles that will allow, for example, transcoding DVDs for Sony's PSP."
Added power to the user, just as those wacky halloween shenanigans occur to cripple hardware such as this to only pipe a tune when it's paid
My educated guess is, No, there won't be Linux support..
ATI was the leader in MPEG2 acceleration, enabling iDCT+MC offload to their video processor almost 10 years ago. How'd that go in terms of Linux support, you ask? Well, we're still waiting for that to be enabled in Linux.
Nvidia and S3/VIA/Unichrome have drivers that support XvMC, but ATI is notably absent from the game they created. So, I won't hold my breath on Linux support for this very cool feature.
I want transgendering!
You don't have to fly to Sweeden anymore for that.
I wonder if http://www.gpgpu.org/ could offload some of the Slashdot effect to their GPU?
Maybe others have had this idea. Maybe it's too expensive or just not practical. Imagine using PCI cards with a handful of FPGAs on board to provide reconfigurable heavy number crunching abilities to specific applications. Processes designed to use them will use one or more FPGAs if they are available, else they'll fall back to using the main CPU in "software mode."
Hasn't nVidia been talking about using the GPU for video acceleration since the GeForce 5 came out? I don't understand why this isn't already available...
"A truly wise man realizes he knows nothing."
With tech stuff these days, but this is awesome. A very clever use of technology just sitting in your computer and a huge timesaver. Anyone that does any transcoding will have immediate justification for laying out bucks for a premium video card.
"Eve of Destruction", it's not just for old hippies anymore...
We need more info for the bug report. Did you go for a #1 or a #2?
This should be written in Shader Language (or whatever it's called these days) which is portable between cards. There's no reason NOT to release this on any platform. Since it only runs on the latest ATI cards it probably uses some feature that nVidia will have in it's next batch of cards as well. If ATI doesn't release it for Linux and the Mac hopefully it won't be that difficult to duplicate their efforts. After all, shader programs are uploaded to the video driver as plain text.... ;)
the X1800XT ties almost exactly with the 7800GTX @ stock of 430 core in most gaming benchmarks.
with nVIDIA's 512mb implementation of the G70 core touted to be at 550mhz core, it should theoretically thrash the living daylights out of the X1800XT.
http://theinquirer.net/?article=27400
the decision is between aVIVO's encode and transcode abilities for h.264, or superior performance by nVIDIAs offering?
Why? Do you want to date yourself?
But will the outputs have to be certified by Hollywood or the media industry? You know, because the only reason for processing audio or video is to steal profits from Sony, BMG, Warner, ... and renegade hacker tactics like A/D conversion should be legislated back to the hell they came from
GPU Stream programming can be done with Brook http://graphics.stanford.edu/projects/brookgpu/. Brook supports the nVidia series, so that is what you purchase.
Pick up a 5200FX card (for SVIDEO/DVI output) and then use the GPU to do audio and video transcode. I have been thinking about audio (MP3) transcode as a first "trial" application.
"Heftier" GPUs may be used to assist in video transcode -- but it strikes me that the choice of stream programming system is most important (to allow code to move to other GPUs, driver permitting). I think that nVidia also supports developers using the GPU (there are comments and test results generated by nVidia available on the 'web). So far, not much from ATI, so I think nVidia gets the nod...
Ratboy.
Just another "Cubible(sic) Joe" 2 17 3061
I wouldn't date myself if I were the last person on Earth.
You're nothing; like me.
I have seen a combo FPGA/PPC chip for embedded applications. The issue I see with this is how long would it be useful? FPGAs are slower then ASICs. Something like the Cell or a GPU will probably be faster than an FPGA. There are a few companies looking at "reconfigurable" computers. So far I have heard about any products from them yet.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
Video cards with GPU's used to be a "cheap" way to increase the graphic processing power of your computer by adding a chip who's sole purpose was to process graphics (and geometry, with the advent of 3d-acellerators).
Now that GPU's are becomming more and more programmable, and more and more general~purpose, what, really, is the difference between a GPU and a standard CPU? What is the benefit to having a 3d~acellerator over having a dual~CPU system with one CPU dedicated to graphic processing?
It's had video acceleration since the GF3. I don't know what you're talking about. Maybe you're talking about hardware encoding(VIVO since GF3 AFAIK)? Or video encoding on GPU(Never heard this, would like to see a link)?
I'm sure there must be some, otherwise they wouldn't have them... How are GPU's specifically optimised for graphics work? Do they have built in de/compression algorithms? Wouldn't it just be easier to have multiple CPUs?
nVidia has been doing this for a while now. In fact, there are finally getting to be interesting implementations like GNU software radio on GPUs:
An Implementation of a FIR Filter on a GPU
"I assumed blithely that there were no elves out there in the darkness"
The article isnt specific on this just says that cards from this series should work. The reason I ask this is I would hate to see a repeat of the Nvidia Purevideo technology. I never could get that to work and I don't think I am the only one. If its only the X1800 they should say that. I wished they would have compared performace as well between an X1300 if available to the X1800 using this technology.
There's also the fact that up until the R5x0 GPU's, only Nvidia and 3D Labs supported 32-bit floats, making it easier to implement features like this.
Thanks for the link, this looks fun. I'll have to see about playing around with it, and maybe some simple benchmarking.
I'd rather see GPU's ofloading thier work to the system CPU. There's no *good* way to do this. So, why not run this isn reverse? If it's possible to speed up general processing, why can they speed up graphics processing? Especially since my CPU hardly does anything when I'm playing a game; it has to wait on the graphics card.
So, what about it ATI? Or will thi be an NVIDIA innovation?
--Mac "Nine point eight meters per second squared: The Best Damn Windows Accelerator, Ever."
CPU and GPU are designed for very different types of processing.
CPUs are general-purpose processors. They are superscalar, have medium-length pipelines, excellent dynamic instruction path selection support (i.e. branch prediction), have limited number of general-purpose registers, have large expressive instruction sets, can do very fast integer calculations, have access to system RAM, etc.
GPUs are specialized for parallel tasks, in particular rendering tasks. They have many parallel pipelines, lousy dynamic instruction path selection support (and very deep pipelines--200 cycles or more), large numbers of orthogonal registers, limited instruction sets with support for a variety of very fast floating point calculations, limited support for integer calculations, limited access to system RAM.
GPU pipelines are becoming more general, and ultimately you will be able to do almost any computational task on either type of processor, but GPUs will still be much better for certain types of task (highly parallelizable tasks) than CPUs.
This might work, but the question to ask is whether it would really be faster. FPGAs are usually a lot slower than ASICs, as another replier pointed out. One FPGA emulation that I saw didn't even run half as fast (in terms of compute time for a task) as the actual ASIC. And if the FPGA becomes the critical path in your processing, it had better be fast (or at least faster than your CPU).
So I think that this would only work if a general purpose CPU (or GPU, for that matter) has a serious architectural weakness for your particular computing application. And I think that would be rare, given that it is the job of CPU manufacturers to keep track of what kind of computation people are interested in, and architect the chips accordingly.
If there isn't a serious architectural weakness, it would probably be more cost-effective to make a system that bolts on another general purpose CPU (or GPU) into the PCI slot. But that could be fun.
It looks like they're using their own codec to produce MPEG-2 and MPEG-4 material. How would you get an existing, x86-only aware application to utilize the GPU, which is not x86 instruction compatible? It's a good bet that codecs will be rewritten to utilize the GPU once code becomes available from ATI, nVidia, etc.
I'd actually be willing to spend more than $50 on a video card if more multimedia apps took advantage of the GPU's capabilities.
In the scientific computing world there have been several episodes where someone comes up with a attached processor an order of magnitude faster than a general purpose CPU and try to get the market to use it. Each generation improved the programming interface eventually using some subset of C (now Cg) combined with a preprogrammed routine library.
All these companies died mainly because the commodity computer makers could pump out new generations about three times faster and eventually catch up. And the general purpose software was always easier to maintain than the special purpose software. Perhaps graphics card software will buck this trend because its a much larger market than specialty scientific computing. The NVIDAS and ATIs can ship new hardware generations as fast as the Intels and AMDs.
fyi this is already done by Roxio in Easy Media Creator 8. they offload a lot of the rendering or transcoding to GPUs that support it. for those that are older they have a software fallback. probably not an increase by such a large factor but still a significant boost on newer PCI-E cards.
Right now it seems like this sort of thing is being done on specialized projects. It would be really awesome if someone would write an acceleration add-on to a library like GNU GSL or FFTW. That would allow a large number of scientists and engineers to easily accelerate their code without having to get involved in the intricacies of doing it. Maybe you wouldn't get the fastest code this way, but there would be great benefits, and people would actually use it.
Had this happen to me once or twice but not on this article
some of Apple's apis (core video/core image/core audio) use the gpu when it detects a supported card, otherwise it just uses the cpu, seemlessly and without fuss. So this isn't new.
http://www.apple.com/macosx/features/coreimage/
GPU's are designed to do parallel bulk vector processing (which is why they can transcode faster than a CPU) but this also limits what kind of applications or tasks you can reasonably offload to the GPU.
This means that the 'general purpose GPU' code, isn't really going to be general purpose, it going to be heavily vector orientated. On the other side the CPU is more general purpose, good at running many tasks and handling interrupts &co, for this reason the CPU won't replace the GPU and the GPU won't replace the CPU, no matter how many mflops you can squeeze out of either.
It would be nice to have protein folding done of the GPU, since it's a task the a GPU should be good at.
thank God the internet isn't a human right.
When I got my 6600gt the box that it came said it could do hardware mpeg2 encoding, obviously this is not the case. I remember reading somewhere that nvidia orginally wanted the 6XXX series to be able to do loads of on board video stuff but they couldn't get it working on time. Its a real shame.
As I remember from my hardware class...there's an Intel 8051 or similar in most PC keyboards...wouldn't it be cool to somehow be able to use that CPU for something useful (aside from polling the keyboard)
That while few people will notice the difference between 150fps and 200fps, those numbers are more or less there to help you determine the lifespan of the card itself. While, for current games, both cards will perform extremely well, a 50fps difference means that on future games, the Nvidia card will be able to last longer and run with more graphics options enabled without bottoming out on fps.
While a select few individuals still always buy the latest and the greatest, the majority of buyers look at video cards as long term investments mainly because of the rediculously inflated prices in the GPU market. All that said, I think you have to look at the card's feature set and make a decision based on that. While, gaming wise, the Nvidia GPU may be superior, the dramatically increased transcoding times definitely make the ATI card a potentially attractive purchase to people who work a lot with video. Given the amazing rise in popularity of the Video Ipod and the existing PSP market, the number of people with interests in transcoding video is definitely on the rise, and ATI was smart in tapping that market now.
You are who you are, let no one tell you different. But, never close your mind to a new point of view.
Bleh, speaking of shader languages. It'd be nice if they spent a little less time on obscure video processing features and a little more time on implementing Shader Model 3.0 properly. Their lack of texture lookups in the vertex shader is weak.
There's no reason there couldn't be Linux Support. At the IEEE Viz05 Conference there was a nice talk from the guys operating www.gpgpu.org about cross-platform support, and there's a couple of new languages coming out that act as wrappers for Cg/HLSL/OpenGL on both ATI & NVidia, & Windows & Linux... Check out Sh (http://libsh.sourceforge.net/ and Brook (http://brook.sourceforge.net./ Once their algorithm is discovered (Yipee for Reverse engineering), it won't be long.
wow, for once there's a slashdot article i have insight on! (whether it's modded that way remains to be seen.... ;) )
i would actually be shocked if there weren't linux support. the ability to do what they want only need to be in the drivers. i've been doing a gpgpu feasability study as an internship and did an mpi video compressor (based on ffmpeg) in school. using a gpu for compression/transcoding is a project i was thinking of starting once i finally had some free time since it seems built for it. something like 24 instances running at once at a ridiculous amount of flops (puts a lot of cpus to shame, actually). if you have a simd project with 4D or under vectors, this is the way to go.
like i said, it really depends on the drivers. as long as they support some of the latest opengl extensions, you're good to go. languages like Cg and BrookGPU, as well as other shader languages, are cross-platform. they can also be used with directx, but fuck that. i prefer Cg, but ymmv. actually, the project might not be that hard, just needs enought people porting the algorithms to something like Cg.
that said, don't expect this to be great unless your video card is pci-express. the agp bus is heavily asymmetric towards data going out to the gpu. as more people start getting the fatter, more symmetric pipes of pci-e, look for more gpgpu projects to take off.
The IRS is the one organization that you don't want to fuck with. Remember, these are the guys who took down Al Capone.
5X faster than what? Because an Athlon X2 4800+ can transcode pretty damn fast.
I would rather some reality-based claims, such as "real-time encoding of 3 VGA streams into XVid". Give me a real reason to include an X1800 into my entertainment box.
Man, if Ivan Sutherland were dead he'd be rolling over in his grave.
This is cool, but if the feeds that process generates is as nonstandard as the MPEG2 their Multimedia Center puts out, it is worthless.
I can't use the files I recorded on anything but ATI's software and Pinnacle Videostudio (go figure, it understands the codec).
You're not old until regret takes the place of your dreams.
The Hitachi SH4 that powers the PlayStation2 can perform 128-bit double calculations in hardware [or so I'm told].
By contrast, Sun's SPARC has a "quad" precision [128-bit] double, but it's a software implementation.
I believe the chipset that powers IBM's Z390 mainframe can also do 128-bit doubles in hardware.
If GPUs are more optimized for graphics, why can't renderfarms use more GPU's rather than more CPU's?
Pixar is using Intel boxes. Since Pixar writes it's own code, wouldn't it be better to write code into Renderman to shift the workload to multiple GPU's in each box in the renderfarm?
Just a thought...
"This is, after all, one of the fastest CPUs money can buy, paired with very fast RAM.
"1 GB of very low latency RAM "
After the other review posted today about fast memory doing almost nothing for transcoding:
"moving to tighter memory timings or a more aggressive command rate generally didn't improve performance by more than a few percentage points, if at all, in our tests."
"Mozilla does show a difference between the settings, both on its own and when paired with Windows Media Encoder. Still, the differences in performance between 2-2-2-5 and 2.5-4-4-8 timings, and between the 1T and 2T command rates, are only a couple of percentage points."
my karma will be here long after I'm gone
It is my understanding the the GPU of a graphics card runs at 300Mhz to 500Mhz. Why hasn't this processing power been harnessed for non-graphical applications?
Unfortunately, there are a few problems with this scenario in practice that prevent it from becoming widespread. I worked on optimizations with VHDL destined for FPGA's in a prior life.
- Tools: FPGA tools are getting better, but still suck compared to modern IDEs and software development. This might be me being jaded (VHDL can get nasty), some things like System C and others are in the infancy stage, but long ways to go here.
- Synthesis time: It can take DAYS on a very fast machine to run the synthesis that produces your design for the FPGA. Some designs work out to be impossible to synthesise; you might not find this out until hours or worse into the process. Then your whole design might have to change! Ha ha ha.
- Tool expense: The good tools cost a lot of money. The ones that can do good designs on the fly cost on the order of a new Ferrari or worse. Engineers that are framiliar with optimizing and implementing these tools and designs cost a lot too, but sadly, don't get to drive too many Ferraris. (me anyway!)
- CPUs and GPUs are heavily optimized and VERY VERY VERY fast for most tasks. In many cases it is cheaper to go buy a farm than implement on a FPGA, unless you are trying to do something very specialized. FPGAs are more often used for specialty communications brokering, timing, and interfacing tasks where bus speeds on a micro are too low.
Great idea in principle. Wouldn't hold my breath, however.
..don't panic
GPU stands for General Purpose Unit right? Or was is Generic Processing Unit? I can't remember.
SPAM
Is this even going to be legal in a couple years?
Stop! Dremel time!
Aple does this now. "Core Image" is built into the OS and all "correctly written" applications that need to do graphic use Core Image. Core Image wil use the GPU if one is available. This is a very good idea but the hardest part of getting this to work on a non-Apple platform will be standarizing the API so that we can use any GPU. OK X11 did this fr displays on UNIX ad we have OpenGL for 3D graphic so we can hope something will happen an API for GPU based image transfomation. The biggest use for this wil not be just simple transcoding but editing and dispay programs for still and moving images Think "gimp" and "cinelerra".
If it has TV in, then the tv stream will come into the computer as an mpeg2 stream.
Most newer cards include this feature by default.
However, the article is talking about using the GPU to transcode from one computer format to another (I commonly want to convert xvid avi files into DVD vobs, a process that can take upto 2-3 hours currently).
I hope this technology pans out, because it would save me the one last big ballache I have with this stupid computer, and especially so since I have a £300 graphics card sitting idle 80% of its time (it plays hl2 and farcry wonderfully tho).
liqbase
Another great idea that will no doubt be poorly implemented and suffer from a closed spec, stifling developer input.
;)).
At the risk of becoming -1 redundant, many other posters have already pointed out that stuff like this should be done in a generic shader language so that it can be run across a gamut of GFX cards - I'm no programmer, but in my mind this would be like current CPU apps asking "do you support MMX? SSE? SSE2?" etc etc etc. Interesting projects like LibSh offer to provide a platform-independent method of integrating GPU shader routines into standard C++ programs.
I'm afraid I can't get too worked up about ATI's implementation though. What with their "what's Linux?" reputation and the heavily competitive/proprietary world of GPU subsystems, I find it unlikely that they'd open up an API to allow non-ATI apps to hook into the GFX card, meaning that I wouldn't be able to use my GPU to speed up my XviD transcodes in VDubMod. I wish they'd prove me wrong, but I doubt it somehow. All glitz and no geek (unless of course it does turn out to be written in a platform independent shader language that allows anyone to hook into it, then I'll eat my words
Moderation Total: -1 Troll, +3 Goat
If you seriously think this is an issue, you either work for nVidia, or you've been drinking their Kool-Aide. Texture lookups for vertex shaders is considerably more obscure than hardware encode/decode acceleration.
I've got an older AGP-based system (Athlon XP Barton), and this sounds like the perfect thing to speed up transcoding and playing of H.264 video. Too bad the irony will be that most systems with PCIe (and support for all these new cards) can play H.264 at a decent speed w/o this card (and transcode quite a bit faster then mine), while most systems that really need it would have to be upgraded in the first place. I know AGP has reached it's limit for 3D performance due to it's bandwidth limitations, but the implementation of GPU-assisted transcoding/decoding of H.264 sounds like something that would still be doable over AGP.
In undeveloped countries, the consumer controls the market. In capitalist America, the market controls you.
Careful about that "32-bit float" term you're throwing around. NVidia's 32-bit floating point computations are sketchy at best-- you don't quite get real 32-bit precision during additions and subtractions (rounding is screwed up), while multiplications have even lower precision (and, since division is implemented as an reciprocal-then-multiply operation, division is even worse yet).
Not a big deal for games, where you're talking about a pixel that might only be shown for a split second. But for general-purpose stuff (like transcoding or some of the other general-purpose apps discussed in the thread), this just doesn't cut it. I'd like to see if ATI's 32-bit floats actually operate like real 32-bit floats, but I haven't been able to find anything substantial yet.
That said, ATI has announced that they will be providing a general-purpose API for the R5x0 series GPUs, so I imagine that they'll be releasing information soon enough. We'll see, I guess.
Back when the GeForce 6800 was launched, during the launch presentation, one of the features that was supposed to become available was using the GPU to assist encoding video. As far as I know, this has yet to materialize.
Does anyone have any transcoding software recommendations? Nero for some reason keeps losing audio sync after a few minutes of video.
__
Do ya feel happy-go-lucky, punk?
> This might work, but the question to ask is whether it would really be faster.
:-), and that synthesis can be slow.
Yup, gotta look at the costs too.
> FPGAs are usually a lot slower than ASICs, as another replier pointed out. {snip}
> And if the FPGA becomes the critical path in your processing, it had better be fast (or at least faster than your CPU).
But the FPGA is less likely to be the bottle neck anyway, the IO bus probably going to be a bigger factor. But the issue isn't whether an ASIC is faster than an FPGA, its whether the whole round trip of memory->bus->FPGA->bus->memory, will get your data crunched faster than doing it in the processor. Many algorithms can be implemented very efficeintly in hardware, for example DES encryption (an old example, I know) has a lot of bit fiddling that is really slow in a standard processor. They've sold crypto accelerator boards in the past, for this very reason.
The really neat thing about FPGAs is that they can be reprogrammed in board. If one day you are doing a lot of crypto and the next are doing MPEG encoding, you just load an new hardware design onto the FPGA.
The big hurdles have been mostly mentioned in other posts, stuff like most software guys don't know verilog/vhdl and its hardware orientedness
But its a cool idea with some potential, I would love to have a board like that in my pc. I should disclaim that I'm currently taking my School's FPGA design class though...
They'll think I've lost control again and leave it all to evolution. -- Supreme Being, Time Bandits
ATI isn't obligated to cater to your tiny niche OS. If you don't like it, don't buy it. I'm sure Nvidia is hard at work on a similar technology, anyway. -Eric
SJW: Someone who has run out of real oppression, and has to fake it.
Just wait until the kiddies get this one in their cell phone.
--dave
See Foley and Van Dam, Fundamentals of Interactive Computer Graphics Addison-Wesley, 1982
davecb@spamcop.net
BTW, it would be nice if someone could mirror this somewhere. I really didn't have anywhere to host this that could withstand a slashdotting.
What if the processing done in the keyboard could be used for entropy, or to provide input for applications and physics engines? I distrinctly remember the IBM Cell processor having a physics engine or two in there, but it wasn't attached to anything sophisticated as the available 102 or 104 instruction-set they my processor posesses. And I bet they RIAA and MPAA would go after the next person for so as much as using their keyboard to pirate music. Hmmm. I better go patent that before Sinclair starts making keyboards again.
And I ran. I ran so far away.
You've been hit by a smooth criminal.
Hitchin' up the buggy; Churning lots of butter; Raise the barn on Monday; Soon I'll raise another.
without prejudice
Compiling would go faster if you could find a way to get the GPU to do part of the work! Somehow use the GPU to cross-compile for the CPU! Then updateing my Gentoo box woudn't take 5hrs but 1hr!
One does not simply learn teh funnay.
This is totally off topic but I read your sig and was surprised to see another fan of Celldweller. I have been a fan of theirs since they were listed on mp3.com. Hopefully more people check them out.
I thought from my first read of the article that they're using the standard codecs, but on second read-through, it appears that you're right. This leaves open the possibility that they have a really pared-down MPEG4 codec which produces really crappy results, quickly. That is not very impressive. What they need is to take an open-source codec like Xvid and "port" it to their hardware. Or better, they need to release the interface so that people can code for it. Yes, this is a lot less cool than I realized at first.
http://www.bittorrent.com/ ;)
Whenever there's a possibility of a Slashdotting...
"A truly wise man realizes he knows nothing."
I'm a graphics coder, I'm not pulling this off random bullshit I heard on gamespot or anandtech or something. Of course now texture looksups in the VS are obscure, since ATI didn't bother to implement them.
Although I wish I had done way more research before I purchased my ATI HDTV card, which I will be getting rid of soon because it pisses me off, I have no trouble encoding the mpeg2 from it to Xvid using the frontend Gordian Knot and the tools it uses like vstrip, dgindex, vdubmod, etc for fully HD streams at 59.94 and crazy resolution(Mpeg 4 compliance can eat me.) Maybe u might want to give GK a whirl or its easier to use brother, AutoGK.
A #1 and the bathroom is right out side my room... so 1min max.
This is great news IMO. Shaders will be able to allow adding new and previously computationally infeasible of features into video codecs.
How about a near-optimal motion vector search at subpel accuracy? No problem for a GPU. How about a GPU driven parametric inloop filtering which saves many many CPU cycles?
Especially codecs like H.264 which have many options for motion vector resolution could benefit greatly from this technology. The GPU will help in bringing the bitrates down by providing a better motion vector accuracy in the encoding process.
Also relatively new techniques could be implemented, like overlapping (blended) macroblocks to reduce blocking - using the GPU's alpha channel.
This is exciting stuff from a codec developer's perspective.
--- Eat my sig.
Somehow I don't think that's really what the parent poster meant. ATI could very possibly provide passable support if they wanted to, but they don't. ATI is notorious for their total lack of interest in Linux. I agree with you, that any sane company aiming at establishing a foot hold in an emerging platform market would jump at the opportunity to make their own products work great on said platform. However ATI is not such a company. Sad as it might seem, ATI still doesn't see enough value for providing adequate product support on Linux. They're suffering from the hen and chicken syndrome, hoping that the effort spent on RedHat and SuSE (since that's what Linux basically is to them) by their competitor(s) might some day make it grow to a viable market segment for them.
In a society that believes in nothing, fear becomes the only agenda ~ Bill Durodié
Yeah, I doubt that's what he meant too. ;)
Fortunately this is a little different than drivers... ATI is about the only one who can make drivers for their cards. But this is an extension to the fragment programming capabilities of the card. Those features will become part of the standard, so anyone can use them (at least they always have in the past). If ATI doesn't do it then nVidia will.
ATI has lots of pretty tech demos where they write some cool fragment programs and then show how they work. But now that the ARB fragment programming language and Shader Language have been standardized those same fragment programs will run on nVidia hardware (maybe not the bleeding edge ones, but the next set back from that). Fragment programs aren't very big, so it shouldn't be difficult for the open source community to duplicate this transcoding program, and make it better.