Badaboom article

[extra]

It was an interesting article, and it's fascinating to read about regular programs we all use being ported to use a GPU instead of a cpu, especially stuff that seems like it would lend itself well to a GPU, like video encoding.. But this article really rubbed me the wrong way. And I can't stand the way Nvidia has been behaving lately, but come on...

"NVIDIA has a year before Larrabee hits and you can be sure that Intel will leverage its relationships with the major codec developers (DivX anyone?) to ensure that there?s full Larrabee support right away."

I think it's a bit unfair to make it sound like it's Nvidia's fault that codec developers haven't written cuda ports of their encoders yet...And to say that you can be sure there's going to be full support for Larrabee right away! Because Intel is always right there, on the ball, with their drivers support for their video hardware being top-notch...right?

The article just seems a bit silly to me...Would be like faulting Nvidia for a third party's game being poorly coded and having performance problems but saying "just wait, you can bet the new intel hardware coming out will run this great!".... what? I'm an Intel fan, I live in Oregon, but come on, the conclusion was just out there and silly imho lol. I duno, anyone disagree, am I just reading too much into this?

 

[adlep]

I have the same impressions...

For the first GPU-accelerated video transcoding application written in CUDA I expected much more from Badaboom

That will simply NOT happen. You are talking about a small software company trying to develop a whole new type of a product. Obviously they WILL make mistakes.

From the article:

There's clearly potential for GPU-accelerated H.264 video encoding, but the first attempt was honestly a bust. Let's hope Elemental or someone else gets it right for round two...

No it wasn't.

The application crashes and it has some functional issues but:

1. It is still in the beta stage.
2. It does work.
3. It is one of the first applications of its kind... Give the developers some credit for being able to program in CUDA. Parallel Processing Programming is very difficult.
4. The application causes the PC to be more energy efficient...
5. It proves the point - GPU processing is much more efficient way of processing for some tasks. Just look at the benchmarks. The first one shows the GTX280 being 3.5x faster than the fastest CPU. And you are talking about the beta app....

Look - think about the application as a prototype and a technology demonstrator rather than a full blown product per say.
Clearly the version 2.0 of Badaboom will be very powerful provided that they will fix some of the issue pointed out by Anand...

 

[taltamir]

i wonder if a codec that processess both on the CPU and GPU at the same time is feasible.

 

[extra]

Originally posted by: taltamir
i wonder if a codec that processess both on the CPU and GPU at the same time is feasible.

I duno but I would think something like splitting it up so that the CPU processed the audio stream while the GPU did the video would work great.

 

[Keysplayr]

Originally posted by: extra

Originally posted by: taltamir
i wonder if a codec that processess both on the CPU and GPU at the same time is feasible.

I duno but I would think something like splitting it up so that the CPU processed the audio stream while the GPU did the video would work great.

Why bother with that when the GPU can do both at the same time faster than the CPU can do just the audio? You'd still end up waiting for the CPU to finish. At least I think that would be the case.

 

[QuixoticOne]

Of course you can share work between a CPU and GPU efficiently for most tasks. Only when you have to move large amounts of data back and forth between the multiple CPUs / GPUs is it a problem to let them work in parallel, and for video encoding this isn't so much the case.

The real problem with protocols, codecs, algorithms like compression / encryption / whatever is that the idiots who develop the standards do it in something like MS Word or PDF or some brain dead way. Then some poor schmoe goes through that mess of thousands of pages of paperwork in ambiguous english and tries to write a C program to implement the algorithms. That will probably be pretty inefficient, buggy, and non-portable. Then some other poor schmoe takes that and spends time making an even less portable faster less buggy version. etc.

What they need to do is WRITE the specification for the compression algorithms in a machine understandable language representation which expresses parallelism cleanly / clearly, and then have code generation tools that are efficient parallel generators take that electronic algorithm definition and translate it into particular code for CPUs / GPUs / PDAs / console game machines / whatever is desired. Then we wouldn't be waiting years for a port of some stupid thing like H.264 or FLASH 9 or PGP or OPERA / Firefox or whatever to our favorite Macintosh, Vista vs XP, PDA, smartphone, LINUX, NVIDIA GPU, ATI GPU, etc. It'd all just be a few clicks away to make something that at least worked 100% without bugs even if some manual optimizations could improve the results a bit here and there.

As it is we spend years reinventing the wheel trying to "port" code from CPU1 to CPU2 to CPU2 to GPU1 to GPU2 to PDA1 to PDA2 to OS1 to OS2 to OS3 ...... it could not be any more stupidly done. That is why your favorite algorithms / codecs / programs / games half the time never run well or at all on, say, Macintosh or LINUX or ATI vs NVIDIA or whatever.

 

[Cogman]

http://forum.doom9.org/showthread.php?t=136847

I really can't say much more then what has been said there. Basically, it is slower then x264, and gives worse quality with comparable settings. (assuming a semi decent cpu)

 

[ViRGE]

Originally posted by: keysplayr2003

Originally posted by: extra

Originally posted by: taltamir
i wonder if a codec that processess both on the CPU and GPU at the same time is feasible.

I duno but I would think something like splitting it up so that the CPU processed the audio stream while the GPU did the video would work great.

Why bother with that when the GPU can do both at the same time faster than the CPU can do just the audio? You'd still end up waiting for the CPU to finish. At least I think that would be the case.

Entropy coding (e.g. CABAC) is still done on the CPU as I understand it.

 

[thilanliyan]

I've heard transcoding is not that great and the best way to preserve quality is to re-encode it. Is this true?

 

[Cogman]

Originally posted by: thilan29
I've heard transcoding is not that great and the best way to preserve quality is to re-encode it. Is this true?

re-encode and transcode are pretty much the same thing. The only way they could be construde as being different is if by re-encode you mean transcoding the source.

Its like an MP3, if you make an MP3 or an MP3 of an MP3 eventually quality is going to be bad no matter what you do.

Now, if you download some movie off the internet and want to transcode it, then yeah, your quality will never be better then source so it will probably suck. Now if you want really good quality you take the movie from the DVD and transcode it (From MPEG2->your standard of choice) again, the quality is limited by that of the dvd, but most likely it will be better then anything on the internet.

Now if you want the best quality, you kill the security guards around the film vault, steal the original, setup some sort of digital interface with the movie reel, and then encode it. This would be the only situation where you are not transcoding.

 

[Keysplayr]

Originally posted by: ViRGE

Originally posted by: keysplayr2003

Originally posted by: extra

Originally posted by: taltamir
i wonder if a codec that processess both on the CPU and GPU at the same time is feasible.

I duno but I would think something like splitting it up so that the CPU processed the audio stream while the GPU did the video would work great.

Why bother with that when the GPU can do both at the same time faster than the CPU can do just the audio? You'd still end up waiting for the CPU to finish. At least I think that would be the case.

Entropy coding (e.g. CABAC) is still done on the CPU as I understand it.

Quote from (H):

"This new video processor in the 8600 GTS has some new features that the GeForce 8800 GTX and GTS do not which should make home theater enthusiasts happy. NVIDIA has added a bit stream and AES128 engine into the silicon so that they can do full specification HD DVD and Blu-ray acceleration. The bitstream engine accelerates entropy coding schemes such as Context Adaptive Variable Length Coding (CAVLC) and Context Adaptive Binary Arithmetic Coding (CABAC) as well as inverse transform from the GPU offloading work from the CPU. The AES128 engine accelerates the decode of AES128 encryption protocols to support video content security like Advance Access Content System (AACS) and Windows Vista PVP-UAB."

Uncertain if this is exactly what you were referring to.

 

[ViRGE]

Originally posted by: keysplayr2003

Originally posted by: ViRGE

Originally posted by: keysplayr2003

Originally posted by: extra

Originally posted by: taltamir
i wonder if a codec that processess both on the CPU and GPU at the same time is feasible.

I duno but I would think something like splitting it up so that the CPU processed the audio stream while the GPU did the video would work great.

Why bother with that when the GPU can do both at the same time faster than the CPU can do just the audio? You'd still end up waiting for the CPU to finish. At least I think that would be the case.

Entropy coding (e.g. CABAC) is still done on the CPU as I understand it.

Quote from (H):

"This new video processor in the 8600 GTS has some new features that the GeForce 8800 GTX and GTS do not which should make home theater enthusiasts happy. NVIDIA has added a bit stream and AES128 engine into the silicon so that they can do full specification HD DVD and Blu-ray acceleration. The bitstream engine accelerates entropy coding schemes such as Context Adaptive Variable Length Coding (CAVLC) and Context Adaptive Binary Arithmetic Coding (CABAC) as well as inverse transform from the GPU offloading work from the CPU. The AES128 engine accelerates the decode of AES128 encryption protocols to support video content security like Advance Access Content System (AACS) and Windows Vista PVP-UAB."

Uncertain if this is exactly what you were referring to.

No, it wasn't, but you were kind of close. I'm talking about entropy coding with respect to encoding. This is being handled by the CPU as I understand it.

 

[VirtualLarry]

Originally posted by: keysplayr2003

Quote from (H):

"This new video processor in the 8600 GTS has some new features that the GeForce 8800 GTX and GTS do not which should make home theater enthusiasts happy. NVIDIA has added a bit stream and AES128 engine into the silicon so that they can do full specification HD DVD and Blu-ray acceleration. The bitstream engine accelerates entropy coding schemes such as Context Adaptive Variable Length Coding (CAVLC) and Context Adaptive Binary Arithmetic Coding (CABAC) as well as inverse transform from the GPU offloading work from the CPU. The AES128 engine accelerates the decode of AES128 encryption protocols to support video content security like Advance Access Content System (AACS) and Windows Vista PVP-UAB."

Uncertain if this is exactly what you were referring to.

Is this stuff present in the G92-based products as well?

 

[AmdInside]

Sigh. I was really looking forward to this software but left disappointed. Back to Handbrake.