DXVA Encode

[shades]

Well it's obvious that the new ATi and Nvidia chips can accelerate a decode for certain video compression, so is it possible to do an encode on these GPUs too?

I know the stanford protein folding program used the GPU to do it's folding work, is there any interest or development looking in to accelerated encoding options for the .h264 etc video compression types being experimented on?

[nm]

search -> badaboom:
H.264 baseline GPU accelerated encoder (http://forum.doom9.org/showthread.php?t=136847)
GPU transcoding (http://forum.doom9.org/showthread.php?t=141007)
80% faster encoding? [hardware] (http://forum.doom9.org/showthread.php?t=140385)
DXVA encoding era has started (http://forum.doom9.org/showthread.php?t=140744)
CUDA encoders for H.264, hows the quality? (http://forum.doom9.org/showthread.php?t=139158)
...

[Sagekilla]

Can we make a sticky thread about all this GPU accelerated encoding nonsense? It'd save a lot of time and questions -- plus provide one central thread for all the information.

[CruNcher]

yep i suggest the baseline thread and merge everything else into it because baseline is what badaboom will be released as there will also be no PRO version anymore only Badaboom, speed for the last beta4 increased a little

[shades]

yep i suggest the baseline thread and merge everything else into it because baseline is what badaboom will be released as there will also be no PRO version anymore only Badaboom, speed for the last beta4 increased a little

Isn't Badaboom only for Nvidia? what about ATi ?

[Ranguvar]

Bottom line, GPUs rock at floating-point computations, but not so much with everything else. There's little-to-no floating-point in encoding. Therefore, unless either of those two conditions changes, just get a good CPU :)

[shades]

Bottom line, GPUs rock at floating-point computations, but not so much with everything else. There's little-to-no floating-point in encoding. Therefore, unless either of those two conditions changes, just get a good CPU :)

If this was true, then why offload decoding to GPU for acceleration?

[Shinigami-Sama]

If this was true, then why offload decoding to GPU for acceleration?

because untill recently software decoders sucked like a [insert euphemism here]
so dxva was needed
now that decoders have sped up and hardware has gotten much cheaper its not really needed
but when it works right(which can be a pain) its much smoother than software

[lucassp]

If this was true, then why offload decoding to GPU for acceleration?

because the GPUs have a independent small piece of silicon (VP1/2/3 and UVD/HD) that only does decoding. for the encoding you need to write a app which uses the shader hardware.

[G_M_C]

If this was true, then why offload decoding to GPU for acceleration?

I've got the feeling it is mostly because it is a fashionable thing to say ....

(in marketing terms, that is ;) )

[Pensive]

I've noticed that dxva encoded movies dont look anywhere near as crisp as CPU encoded ones. Obviously this has a lot to do with the particular implementation of the shader hardware, but there may also be inherent video "colourations" from using the graphics chip to do this job.....this is a guess really, but old school canopus DV Rex RT hardware mpeg encoders tended to apply a "smoothing" algorithm beforehand which reduced data processing requiremetns and gave a perceived "better quality encode". It wasnt better though. It looked "smoother" on CRT telly's at the time, but detail was lost at the end of the day.

Shaders are just like little processers though..right? Is there a way to utilise them without the image being "processed" by the graphics chip with its rendering pipeline unavoidables?

[nm]

I've noticed that dxva encoded movies dont look anywhere near as crisp as CPU encoded ones. Obviously this has a lot to do with the particular implementation of the shader hardware, but there may also be inherent video "colourations" from using the graphics chip to do this job.....this is a guess really,
Nope, graphics hardware doesn't cause any artifacts, it's just a computing device. Quality issues are due to the (software) encoder implementations using the GPU. Currently they are simply poor compared to good CPU-based encoders.

[deets]

not directly related, but if you offload the resizing and deinterlacing onto the graphics card via neuron2's nvidia CUDA specific progs, you will see a nice speed up as the cpu no longer needs to worry about those things.

edit: plus the deinterlacing quality is the best if seen if done via the hardware

[Pensive]

So the shader's are limited in their functionality; And this results in more inaccurate processes taking place, than that which would be used by a CPU using x264 encoding.

The end result I have seen is that all the detail from a 1080P movie is lost, so much so that I can't tell all that much difference between it and a 720P cpu-coded version.

Great for realtime video editing for example (as long as the final render to disc takes place CPU-bound.), but I would say that those shaders will always be poor quality compared to the flexibility and mathematical accuracy of a CPU. With quad cores running at 4 and 5 Ghz, ok you're not at realtime but what really is the benefit.....? You encode a video just once, you watch it many times....surely its worth the extra hour or two for the huge increase in sharpness?

[ajp_anton]

With quad cores running at 4 and 5 Ghz, ok you're not at realtimeNo, you're probably at multiple times realtime if you encode at the same quality as the GPU-based encoders.

[nm]

So the shader's are limited in their functionality; And this results in more inaccurate processes taking place, than that which would be used by a CPU using x264 encoding.
Shaders or stream processors are limited when compared to a CPU core but they don't cause inaccurate results. As I said, quality is entirely up to the encoder implementation (software algorithms run on both the CPU and the GPU). One could certainly write an encoder that uses the GPU and gives as high quality as x264. It's just that nobody has done that yet.

[Zelos]

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

neuron did it.

[Dark Shikari]

Nice thread necromancy.

[nm]

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

neuron did it.
That's a decoder, using dedicated hardware.

[Pensive]

Shaders or stream processors are limited when compared to a CPU core but they don't cause inaccurate results. As I said, quality is entirely up to the encoder implementation (software algorithms run on both the CPU and the GPU).

Not to be contrary (In fact I'm finding your responses most enlightening), but I've been coding since around 1990, and if I've learnt one thing - its that a LongDIV instruction on one cpu can have a wildly differing level of accuracy on another CPU.

Now these shaders - they have an instruction set. Probably a smaller instruction set than a CPU; I'm going to assume so (rather naughtily) - without having googled it as its late.

Therefore, an "implementation" of, for example, inverse discrete cosine transforms (such as those required for DVD playback) can be coded into an ATI K6-2-500mhz using 3dNOW! and also into a P3-733 MMX and get differing quality.
The reason is that the speed which can be achieved from these cores stems from the "estimated" but very fast high speed instructions from the mmx chipset (or 3dNOW! set).

One could certainly write an encoder that uses the GPU and gives as high quality as x264. It's just that nobody has done that yet.

If you could write the algorithm to work at identical quality as the CPU implementation;

Would you actually get a speed increase?

(answer is of course dependant on GPU + SLI setup etc., assume one Radeon 4800).

[nm]

Not to be contrary (In fact I'm finding your responses most enlightening), but I've been coding since around 1990, and if I've learnt one thing - its that a LongDIV instruction on one cpu can have a wildly differing level of accuracy on another CPU.
You have a point there, but I don't think this is a major problem for a video codec. As you said, division is a problematic instruction (slow and inaccurate), but it can also be avoided in most cases. CPU-based encoders don't use division in tight loops either. If there are other accuracy issues, they can also be worked around with some loss of performance.

Anyway, I'm certain that accuracy issues (if there are any) are not the reason for the poor output quality of GPU encoders.

If you could write the algorithm to work at identical quality as the CPU implementation;

Would you actually get a speed increase?
Well, that's difficult to estimate without actually implementing things. GPU is good for doing some things (like motion estimation (http://wiki.videolan.org/SoC_x264#GPU_Motion_Estimation)) and not so good for others (such as arithmetic coding). Moving data between the GPU and the CPU costs a lot of time, so things need to be coordinated carefully.

[popper]

" Pensive:If you could write the algorithm to work at identical quality as the CPU implementation;"

"NM:Well, that's difficult to estimate without actually implementing things. GPU is good for "

it seems its not so hard to try, IF you have a suitable ATI or Intel card and OpenCL driver set ,you could always go and try some GPU scripting with PyOpenCL:
OpenCL Python wrappers

http://www.khronos.org/message_boards/viewtopic.php?f=28&t=2008&sid=5e390eb564003a6c65ffa949919c8dfc

http://mathema.tician.de/software/pyopencl

http://tiker.net/pipermail/pyopencl_tiker.net/2009-September/thread.html

or his other PyCUDA wrappers.... http://mathema.tician.de/software/pycuda

http://wiki.tiker.net/CudaVsOpenCL

and OC if you dont know Python ,they already have generic OpenCL C# and C++ wrappers
http://www.khronos.org/message_boards/viewforum.php?f=28&sid=480f4ce6790cb9a4cfc63d6941a97791

[Dark Shikari]

Well, that's difficult to estimate without actually implementing things. GPU is good for doing some things (like motion estimation (http://wiki.videolan.org/SoC_x264#GPU_Motion_Estimation)) This is dubious. We actually have nothing that suggests that the GPU is very good at all, and the tests we've done since (very unoptimized, so take with a giant grain of salt) don't suggest very high speeds.

[Pensive]

Popper has a point; and the only way to know is to try - but that scripting solution would not be the complete answer.

I would love to try it but I only have an ATI 2900XT and very little spare time free at the moment.

BUT, While you are using your GPU you have a (mostly) idle CPU. What we need is someone to write an identical algorithm implementation on both GPU and CPU, and an encoding management system which has the GPU shaders perform as if they are further CPU "cores" during this encoding process, without it suffering too much from the data transfer delays between the two.

That way (with a decent coder), you shouldn't end up wth a slower or lower quality result than CPU-borne encoding, and it should be the same quality while being considerably faster - at least 1.5 times and I would hope 2 times or more.

Until the quality is equivalent I really dont see the benefit of using GPU at present; its like encoding MP3s at 320kbps with low quality ticked; where is the quality going?

Thanks for your input nm :thanks:

[Reimar]

Not to be contrary (In fact I'm finding your responses most enlightening), but I've been coding since around 1990, and if I've learnt one thing - its that a LongDIV instruction on one cpu can have a wildly differing level of accuracy on another CPU.

I guess you are talking about floating point. Floating point is the only thing that is rather inaccurate across architectures and was never supposed to give exact results (everyone writing financial applications should know this very well). Since H.264 needs to be bit-exact, floating-point is not really useful for it in anyway.

Now these shaders - they have an instruction set. Probably a smaller instruction set than a CPU; I'm going to assume so (rather naughtily) - without having googled it as its late.

Which CPU? Almost anything has a smaller instruction set than x86, but there are a lot of (mostly embedded) CPUs with a smaller instruction sets than current GPUs (particularly the CPUs without floating point unit), the biggest difference is that GPUs have no function calls and no arbitrary jumps.


Therefore, an "implementation" of, for example, inverse discrete cosine transforms (such as those required for DVD playback) can be coded into an ATI K6-2-500mhz using 3dNOW! and also into a P3-733 MMX and get differing quality.
The reason is that the speed which can be achieved from these cores stems from the "estimated" but very fast high speed instructions from the mmx chipset (or 3dNOW! set).


3DNOW is a somewhat special case, it was specifically designed to have low accuracy. MMX/SSE though should have the same precision as "normal" FPU if after each instruction you read the result from the FPU and write it back again. And even if not, the difference should be in the area of what you get by simply using different compiler(-options).
Apart from that, floating point behaviour is specified by IEEE 754 and the GPU instructions (at least for NVidia) that do not follow it are few and explicitly documented as such (and I think they give suggestions how to fix the results at the cost of a few extra instructions, so it at least is not a show-stopper).


If you could write the algorithm to work at identical quality as the CPU implementation;

Would you actually get a speed increase?

(answer is of course dependant on GPU + SLI setup etc., assume one Radeon 4800).

As an attempt to get back on-topic: The speed increase would probably be similar to what you'd expect from a 256-core i7 running at maybe 250 MHz.
Sure, there are some additional details, but it basically depends on how well you can parallelize things.
So far all GPU encoders (and most other things that have been ported to GPUs only recently) have taken the easy approach to parallelizing: Throw away dependencies until it's easy to do - which particularly for compression necessarily hurts quality.

[Dark Shikari]

As an attempt to get back on-topic: The speed increase would probably be similar to what you'd expect from a 256-core i7 running at maybe 250 MHz.Nowhere near. If you want to consider a GPU as having SIMD, it would be more like a 16-core i7. If you want to consider a GPU as not having SIMD, it would be more like a 256-core 486.

[buzzqw]

very dumb suggestion: what about a --preset dvxa ? (based on medium preset...) just for user that want for sure a dvxa preset ...

BHH

[Pensive]

Which CPU?


Im talking about the average PC processor, since we are in a DXVA encoding thread that limits us to windows XP and above, on dual or quad core intel/amd architecture. To bring embedded/risc cpu architecture into the equation complicates things and takes us off topic. Lets assume my CPU - Intel Core2Duo E6750 @ 2.66mhz.


Sure, there are some additional details, but it basically depends on how well you can parallelize things.
So far all GPU encoders (and most other things that have been ported to GPUs only recently) have taken the easy approach to parallelizing: Throw away dependencies until it's easy to do - which particularly for compression necessarily hurts quality.

That explains everything. Its like encoding in 1 pass low quality mode w/ constant bitrate - It's not even constant quality.

That means until someone writes dependancies in it'll look terrible.

On the other hand if someone DID write them in you could use both the CPU cores and the GPU to do a proper 2pass (or more passes) encode. Cool beans!

[LoRd_MuldeR]

very dumb suggestion: what about a --preset dvxa ? (based on medium preset...) just for user that want for sure a dvxa preset ...

So far x264's presets are for "quality -vs- speed" and hence "DXVA" doesn't fit in. The same way it doesn't fit into the tune system, because these tune x264 for a specific type of source.

If at all, then "DXVA" would fit into a future "--target" or "--device" option. This was already discussed to some extent, but not added until now...

[Audionut]

but not added until now...

Last I checked, it still wasn't implemented.