<p>They are all forms of hardware acceleration, which broadly, just means that specialized hardware is doing things faster than the basic CPU normally could.  The exact nature of what each type of acceleration does depends entirely on the software you are using and the hardware you are using.  </p>

<p>Some hardware is very purpose specific.  Something like Intel QuickSync is a specific hardware encoder and has limited functionality because it can only serve it's purpose driven role.  This is similar to any other dedicated encoder, such as the integrated encoder used for NVidia Shadowplay or the dedicated encoders on devices like the Matrox MXO2 or BlackMagic Intensity.  There are other rolls other than encoding that could be filled by a purpose driven card, but encoding is certainly one of the most common.</p>

<p>Other hardware, such as modern GPUs (CUDA or OpenCL based, I think ATI has a term too, but can't remember it) and video editing or mixing acceleration cards, such as Black Magic's ATEMs or Matrox's older RT line of real time editing cards, are designed to provide more general purpose functionality.  Depending on the hardware they may either offer a wider array of specialized functionality or simply a general purpose parallel processor that works better for video purposes.  In these cases, the functionality is made available to software, but it is up to software to utilize the processing capabilities of the hardware and the exact nature of the acceleration will depend on which algorithms and processing they choose to offload to the hardware.</p>

<p>Another option, as far as APIs are concerned, is something like DXVA, which strives to unify multiple technologies.  DirectX in general is a system for interfacing software and diverse graphics hardware.  It looks for any hardware that tells it that it can fill a role and then will utilize that hardware to do a job when software asks for the job to be done.  I'm not super familiar with DXVA, so I don't know if it puts any specific requirements on hardware (some directX stuff does), but on the hardware end, the implementation could potentially differ greatly and could use either CPU features or GPU features, depending on what's available to it.  It may or may not be directly implemented in terms of the more hardware specific feature sets (CUDA, QuickSync, etc), but it is designed to work across diverse hardware, so you know less about what is going on under the hood.</p>

<p>All of the technologies can be used to speed encoding, but the general purpose technology can also be applied to just about anything that you can process in parallel, so they can (potentially) impact render times as well (the time it takes to make the images that are going to be encoded).</p>

CC BY-SA 3.0
2015-08-19T14:38:28.677Z
So is it correct to say that: DXVA is simply a software interface that can enable applications to take advantage of CPU (e.g. *Intel*'s *QuickSync* technology) and/or GPU (e.g. a *NVidia*'s video card via the CUDA API) based hardware acceleration?  If such is the case, then I am assuming that video processing applications could skip DXVA and communicate more directly with the hardware (e.g. use the *QuickSync SDK* to interface with an *Intel* processor.
Pressacco
CC BY-SA 3.0
2015-08-19T14:43:01.823Z
@Pressacco not exactly, it isn't just making CUDA or QuickSync calls necessarily.  It may be integrated in the driver and may make lower use of the hardware as well.  A lot depends on driver support.  It's also possible a vendor may put functionality specifically for DXVA calls.  I'm not certain as I don't know if DXVA puts any specific requirements that can't be implemented directly in terms of any particular existing hardware API.  DirectX in general (and OpenCL like it) are at a more general level designed to be implemented once and work on diverse hardware.  CUDA and QuickSync aren't.
AJ Henderson
CC BY-SA 3.0
2015-08-19T14:47:31.553Z
Yes, the software likely could use the direct technologies and be slightly more efficient if it was to make ideal use of all possible hardware for it's exact purpose, but that's also a lot more labor intensive to maintain and handle different possible roles that can be filled by different hardware.  Implementing once with something like DXVA and letting it handle the wireup to hardware makes things much easier for the developer and could potentially result in better overall utilization if the connections to the various other technologies are out of date or less flushed out than DXVA is.
AJ Henderson
CC BY-SA 3.0
2015-08-19T14:54:43.810Z
I have been trying to picture in my mind how the different layers fit together... thank you for the clarification!
Pressacco
CC BY-SA 3.0
2015-08-19T14:25:23.473Z
2015-08-19T14:44:57.760Z
2015-08-19T14:44:57.760Z
AJ Henderson
<p>Many video playback applications (e.g. <em>VLC Player</em>, <em>MPC-HC</em>, etc.) are highly configurable. For example:</p>

<ul>
<li><em>VLC Player</em> allows you to enable: <em>QuickSync</em> and/or DXVA</li>
<li><em>Freemake</em> allows you to enable: CUDA and/or DXVA</li>
</ul>

<p>What I am trying to understand is... what is the relationship between hardware acceleration and these technologies?  </p>

<p>For example, can you enable DXVA to leverage GPU based hardware performance AND enable <em>QuickSync</em> to leverage CPU based hardware acceleration?</p>

<hr>

<p>It is my understanding that...</p>

<ul>
<li><strong>DirectX Video Accelerator (DXVA)</strong>

<ul>
<li>This type of hardware acceleration improves video encoding/decoding performance by routing 'work' to the GPU (integrated or discrete).</li>
</ul></li>
<li><strong>Intel QuickSync</strong>

<ul>
<li>This type of hardware acceleration improves video encoding/decoding performance by routing 'work' to the CPU - specifically a dedicated processor die that is responsible for performing video encoding/decoding operations.</li>
</ul></li>
<li><strong>Compute Unified Device Architecture (CUDA)</strong>

<ul>
<li>Is a closed API developed by NVIDIA that not only gives direct access to the the GPU's virtual instruction set, but also allows for data to be retrieved from the video card so that additional processing can be performed.</li>
</ul></li>
</ul>

CC BY-SA 3.0
2015-08-19T14:13:02.780Z
You are basically correct.  What exactly is the question?  i took a guess at it, but if that isn't what you are looking for, please clarify what you are looking for.
AJ Henderson
CC BY-SA 3.0
2015-08-19T14:27:03.010Z
I don't feel like my original post outlines the complete picture.  For example: [this](http://www.anandtech.com/show/4895/intel-engineer-ports-quicksync-video-decoding-to-ffdshow) article suggests that DXVA is an API that facilitates GPU & CPU based hardware acceleration. Other articles have mentioned that CUDA supports video decoding.
Pressacco
CC BY-SA 3.0
2015-08-19T14:34:10.393Z
good point about DirectX.  I updated my answer below to include a section on APIs as well.
AJ Henderson
<codec><hardware><playback><performance><setup>
What is the relationship between hardware acceleration and DXVA/QuickSync/Cuda?
Pressacco
# What is the relationship between hardware acceleration and DXVA/QuickSync/Cuda?

(Asked by: username_0 on 2015-08-19)

Many video playback applications (e.g. *VLC Player*, *MPC-HC*, etc.) are highly configurable. For example:

* *VLC Player* allows you to enable: *QuickSync* and/or DXVA
* *Freemake* allows you to enable: CUDA and/or DXVA

What I am trying to understand is... what is the relationship between hardware acceleration and these technologies?

For example, can you enable DXVA to leverage GPU based hardware performance AND enable *QuickSync* to leverage CPU based hardware acceleration?

---

It is my understanding that...

* **DirectX Video Accelerator (DXVA)**
  + This type of hardware acceleration improves video encoding/decoding performance by routing 'work' to the GPU (integrated or discrete).
* **Intel QuickSync**
  + This type of hardware acceleration improves video encoding/decoding performance by routing 'work' to the CPU - specifically a dedicated processor die that is responsible for performing video encoding/decoding operations.
* **Compute Unified Device Architecture (CUDA)**
  + Is a closed API developed by NVIDIA that not only gives direct access to the the GPU's virtual instruction set, but also allows for data to be retrieved from the video card so that additional processing can be performed.

**Tags:** codec, hardware, playback, performance, setup

> **Comments:**
> **username_1**: You are basically correct.  What exactly is the question?  i took a guess at it, but if that isn't what you are looking for, please clarify what you are looking for.  
> **username_0**: I don't feel like my original post outlines the complete picture.  For example: [this](http://www.anandtech.com/show/4895/intel-engineer-ports-quicksync-video-decoding-to-ffdshow) article suggests that DXVA is an API that facilitates GPU & CPU based hardware acceleration. Other articles have mentioned that CUDA supports video decoding.  
> **username_1**: good point about DirectX.  I updated my answer below to include a section on APIs as well.  

---

## 1 answers

### Answer by username_1 on 2015-08-19. Score: 1 | Accepted answer

They are all forms of hardware acceleration, which broadly, just means that specialized hardware is doing things faster than the basic CPU normally could. The exact nature of what each type of acceleration does depends entirely on the software you are using and the hardware you are using.

Some hardware is very purpose specific. Something like Intel QuickSync is a specific hardware encoder and has limited functionality because it can only serve it's purpose driven role. This is similar to any other dedicated encoder, such as the integrated encoder used for NVidia Shadowplay or the dedicated encoders on devices like the Matrox MXO2 or BlackMagic Intensity. There are other rolls other than encoding that could be filled by a purpose driven card, but encoding is certainly one of the most common.

Other hardware, such as modern GPUs (CUDA or OpenCL based, I think ATI has a term too, but can't remember it) and video editing or mixing acceleration cards, such as Black Magic's ATEMs or Matrox's older RT line of real time editing cards, are designed to provide more general purpose functionality. Depending on the hardware they may either offer a wider array of specialized functionality or simply a general purpose parallel processor that works better for video purposes. In these cases, the functionality is made available to software, but it is up to software to utilize the processing capabilities of the hardware and the exact nature of the acceleration will depend on which algorithms and processing they choose to offload to the hardware.

Another option, as far as APIs are concerned, is something like DXVA, which strives to unify multiple technologies. DirectX in general is a system for interfacing software and diverse graphics hardware. It looks for any hardware that tells it that it can fill a role and then will utilize that hardware to do a job when software asks for the job to be done. I'm not super familiar with DXVA, so I don't know if it puts any specific requirements on hardware (some directX stuff does), but on the hardware end, the implementation could potentially differ greatly and could use either CPU features or GPU features, depending on what's available to it. It may or may not be directly implemented in terms of the more hardware specific feature sets (CUDA, QuickSync, etc), but it is designed to work across diverse hardware, so you know less about what is going on under the hood.

All of the technologies can be used to speed encoding, but the general purpose technology can also be applied to just about anything that you can process in parallel, so they can (potentially) impact render times as well (the time it takes to make the images that are going to be encoded).

> **Comments:**
> **username_0**: So is it correct to say that: DXVA is simply a software interface that can enable applications to take advantage of CPU (e.g. *Intel*'s *QuickSync* technology) and/or GPU (e.g. a *NVidia*'s video card via the CUDA API) based hardware acceleration?  If such is the case, then I am assuming that video processing applications could skip DXVA and communicate more directly with the hardware (e.g. use the *QuickSync SDK* to interface with an *Intel* processor.  
> **username_1**: @username_0 not exactly, it isn't just making CUDA or QuickSync calls necessarily.  It may be integrated in the driver and may make lower use of the hardware as well.  A lot depends on driver support.  It's also possible a vendor may put functionality specifically for DXVA calls.  I'm not certain as I don't know if DXVA puts any specific requirements that can't be implemented directly in terms of any particular existing hardware API.  DirectX in general (and OpenCL like it) are at a more general level designed to be implemented once and work on diverse hardware.  CUDA and QuickSync aren't.  
> **username_1**: Yes, the software likely could use the direct technologies and be slightly more efficient if it was to make ideal use of all possible hardware for it's exact purpose, but that's also a lot more labor intensive to maintain and handle different possible roles that can be filled by different hardware.  Implementing once with something like DXVA and letting it handle the wireup to hardware makes things much easier for the developer and could potentially result in better overall utilization if the connections to the various other technologies are out of date or less flushed out than DXVA is.  
> **username_0**: I have been trying to picture in my mind how the different layers fit together... thank you for the clarification!  

---

