View Full Version : H.264 DXVA Benchmarks: QuickSync vs UVD 2.2 vs VP4 vs VP5
Pages :
1
[
2]
3
4
5
6
7
8
9
wanezhiling
9th January 2012, 14:52
http://cafe.daum.net/pot-tool/AZMV/8571
wanezhiling 12.01.07. 20:53
It seems that Nvidia and AMD benefit from WMV9 VLD.
Intel is still WMV9 IDCT, why? And VC1 is IDCT too... God...
팟플.개발자 19:27
Intel's VC1 VLD mode(ClearVideo) is diffrent.
So it cannot support.
different... Does anyone know the difference?:confused:
NikosD
9th January 2012, 15:38
Intel has two different Decoder devices for VC-1 installed regarding Intel HD graphics (sandy):
ModeVC1_VLD_ClearVideo
ModeVC1_VLD_2_ClearVideo
I don't know the difference.
I know that egur (Eric Gur) posted that VC-1 hardware inside Sandy can use HW acceleration for Advanced profile of VC-1 only.
The other profiles (Simple and Main) are handled by software decoding.
WMV3 is compliant with Simple and Main VC-1 profiles, so it can't get any HW acceleration (just like Simple and Main VC-1 profiles)
This is the same reason that I couldn't benchmark WMV9 as Egur asked me to do so in a previous post.
There is no WMV9 HW acceleration.
And I'm a little curious why Egur asked me to benchmark WMV9, BTW :rolleyes:
I don't know if this is a hardware/drivers/Media SDK or other kind limitation.
CruNcher
9th January 2012, 15:55
Arcsofts Decoder supports also WMV3 streams it shows the Decoder being the VC-1 Bitstream (ClearVideo), though i didn't found a bitstream yet that shows a big difference decoding wise vs either Libavs Software Decoder or WMV Video Decoder. Though what really surprised me VC-1 (WVC1) decodes more efficient with Intels MSDK Decoder then a DXVA Decoder it seems it shows much lower utilization even with the Memory copy going on but im still looking into that.
So for WMV3 MP@HL it looks even DXVAed it's pretty much the same power consumption as Libavs Decoder (so on the first sight pretty useless)
http://img824.imageshack.us/img824/9205/arcsoftdxvawmv3mphl.png
Though the WVC1 decoding result was surprising
NikosD
9th January 2012, 16:09
We are talking about Full bitstream acceleration (VLD), not HW acceleration in general.
Intel's drivers support DXVA decoder devices of ModeVC1_IDCT and ModeWMV9_IDCT.
We are not talking about them, they are hardware assisted (partial) acceleration.
PotPlayer added WMV9 VLD support for suitable hardware/drivers.
CruNcher
9th January 2012, 16:33
I see the on paar results of Libav and Arcsofts results Decoding WMV3 Main show also that they pretty similar most probably indeed Software Decoding so comparable to Libav
Also the difference between Arcsofts WVC1 decoding and MSDK (LAV Video,ffdshow-quicksync) result could indicate that Arcsoft only uses the old VC1 mode that is not such performant else i wouldn't understand why MSDK has better Performance with the Memory Copy then Arcsofts DXVA Decoder
wanezhiling
9th January 2012, 19:28
I5 2300(HD2000), DXVA VC1(WVC1) failed by MPC HC..
We know MPC HC's DXVA is based on VLD, so this proved that Korean was right, Intel's VC1_VLD(ClearVideo)must be unusual.
Hope developer will explain this I ask to him tomorrow..
-------------------------------------------
Because Intel's VC1 VLD is not standard struct DXVA.
But intel's IDCT mode is standard DXVA.
I request document VC1 VLD mode to intel, but intel cannot do anything...
:devil:Korean developer said nothing...
Maybe Egur can answer this..
NikosD
10th January 2012, 10:09
A lot of people report problems with Intel Video Hardware/drivers working together with pure, vanilla DXVA.
That's why Egur is trying to build a new approach of using Intel's video hardware to accelerate decoding through Intel's Media SDK - the QS decoder project.
It's like a requirement to use Media SDK in order to HW accelerate video decoding of MPEG-2, VC-1, H.264 through DXVA for Intel.
On the other hand, Nvidia and AMD can work without problems nowdays with direct, pure DXVA.
From my limited tests I had a lot of problems with MS DS H.264 decoder and QuickSync hardware (corrupted images and crashing during benchmarking in DXVA checker), but no problem at all with MS MFT H.264 decoder and QuickSync.
Unfortunately Intel's MFT decoders for MPEG-2, VC-1, H.64 are broken, they don't even enumerate in DXVA checker.
A lot of effort is needed by the teams of Intel Graphics Driver development and Intel Media SDK development to reach the maturity of video drivers by AMD and Nvidia.
mariner
10th January 2012, 17:12
...
Another 2:
http://115.com/file/be83t4l4#
HD.Club-4K-Chimei-inn-50mbps
http://115.com/file/e7zwgsgg#
Crowd_Run_2160p_50fps_275Mbps
...
Greetings wanezhiling and NikosD.
Thanks for posting these interesting clips. Was able to get hold of a Sapphire 6670 DDR5 and did some quick tests:
1. Could not get DXVA to work in Potplayer playing these 2160p clips, using both internal and external filters. What settings are required?
2. Was able to get AS video decoder to run in DXVA using mpc and dxva_checker, but with corrupted output and low frame rate.
3. Benchmark for the other clips are in line with 6750's results. A few fps higher, but lower than VP5.
4. The Duck clip (9) failed to enumerate.
5. Finally, how does one identify if UVD3 is in use?
Many thanks and best regards.
NikosD
10th January 2012, 17:34
1. Could not get DXVA to work in Potplayer playing these 2160p clips, using both internal and external filters. What settings are required?
If you force enable of DXVA use in PotPlayer latest version for every resolution and still can't play 2160p files, then there is nothing you can do about.
But you have to force it by checking "Always use" in "Resolution limit".
Maybe you could try CoreAVC DXVA as external filter to PotPlayer.
2. Was able to get AS video decoder to run in DXVA using mpc and dxva_checker, but with corrupted output and low frame rate.
ATI is still limiting UVD3 I suppose for 4K playback.
3. Benchmark for the other clips are in line with 6750's results. A few fps higher, but lower than VP5.
So UVD3 is faster than normal UVD2.2 and UVD2.2+
Can you post your results here ?
I could update them to first post too in order to have an all around comparison.
5. Finally, how does one identify if UVD3 is in use?
The easiest way for me is by observing the gpu/memory frequency.
From idle low clocks, goes to UVD mode clocks during video playback/benchmarking and then back to idle clocks.
BTW, can you see if the clocks of GPU change during benchmarking ?
I mean from lower to higher as the clip moves on.
Another way could be by using AMD GPU clock Tool which has UVD status report and it's for older cards and , but I think it works for yours too.
wanezhiling
10th January 2012, 18:00
HD7970 is still UVD3.0, just adds a VCE, sigh..
I'm waiting for Kepler,hope it's VP5+:D
"The Way it's meant to be played" :p
I never expect AMD.
NikosD
10th January 2012, 18:08
UVD2.x/3.x has a lot more power than it is exposed by current BIOS/drivers.
Don't understimate AMD's hardware, only get angry with their tactics and policies.
mariner
10th January 2012, 18:19
Thanks for the reply, NikosD.
If you force enable of DXVA use in PotPlayer latest version for every resolution and still can't play 2160p files, then there is nothing you can do about.
But you have to force it by checking "Always use" in "Resolution limit".
Maybe you could try CoreAVC DXVA as external filter to PotPlayer.
I meant Potplayer reverted to YUY2 when forced to use DXVA, for both internal and external decoders, Arcsoft's included.
Using version 31393.
ATI is still limiting UVD3 I suppose for 4K playback.
How did this chap do it?
http://www.agile-news.com/news-323468-Photo:-no-fear-of-4K-x-2K!-Fire-whirlwind-2-HD6570-2G-Daniel-Edition-hardware-solution-2160p!.html
So UVD3 is faster than normal UVD2.2 and UVD2.2+
Can you post your results here ?
I could update them to first post too in order to have an all around comparison.
The 6670 (don't know if it's UVD3 or not) is faster by about 5fps. Will try to download all the clips.
Facing a couple of issues here:
1. AMD MFT crashed with the h264 mp4 clips,
2. Duck clip would not enumerate.
Catalyst 11.12
The easiest way for me is by observing the gpu/memory frequency.
From idle low clocks, goes to UVD mode clocks during video playback/benchmarking and then back to idle clocks.
BTW, can you see if the clocks of GPU change during benchmarking ?
I mean from lower to higher as the clip moves on.
Another way could be by using AMD GPU clock Tool which has UVD status report and it's for older cards and , but I think it works for yours too.
Will take a look. Do you mean this one?
http://www.techpowerup.com/downloads/1128/AMD_GPU_Clock_Tool_v0.9.8.html
Thanks.
wanezhiling
10th January 2012, 18:29
HD6000 is UVD3.0 expect 6770/6750.. So HD6670 is 3.0.
NikosD, I got a HD7970's DXVA Checker (http://we.pcinlife.com/data/attachment/forum/201201/11/0119101z55hxsx2sfihhf2.jpg):D, compared with HD6850 (http://we.pcinlife.com/data/attachment/forum/201201/11/011910fvb3zb1ljbfyql3f.jpg), no difference at all..
NikosD
10th January 2012, 18:41
I meant Potplayer reverted to YUY2 when forced to use DXVA, for both internal and external decoders, Arcsoft's included.
Using version 31393.
Then it seems to fall back to software mode.
CoreAVC, Cyberlink DXVA maybe
How did this chap do it?
http://www.agile-news.com/news-323468-Photo:-no-fear-of-4K-x-2K!-Fire-whirlwind-2-HD6570-2G-Daniel-Edition-hardware-solution-2160p!.html
I would really like to know.
I'm guessing with special driver/BIOS and/or special Video player.
Facing a couple of issues here:
1. AMD MFT crashed with the h264 mp4 clips
You have to disable AVIVO transcoding from Catalyst Control Center.
Do you mean this one?
http://www.techpowerup.com/downloads/1128/AMD_GPU_Clock_Tool_v0.9.8.html
Yes.
Better use a desktop gadget like GPU Observer for GPU/VPU info.
I use it.
6670 has UVD3 inside.
NikosD
10th January 2012, 18:50
HD6000 is UVD3.0 expect 6770/6750.. So HD6670 is 3.0.
NikosD, I got a HD7970's DXVA Checker (http://we.pcinlife.com/data/attachment/forum/201201/11/0119101z55hxsx2sfihhf2.jpg):D, compared with HD6850 (http://we.pcinlife.com/data/attachment/forum/201201/11/011910fvb3zb1ljbfyql3f.jpg), no difference at all..
It has one more line at the end, I don't know what it is stands for.
Don't expect much from the DXVA Checker screenshot, because the main info from that is the codecs and resolutions accelerated.
There are no more codecs to be accelerated.
MPEG-2, MPEG-4 ASP, MPEG-4 AVC, MVC, VC-1, WMV3 are already in hardware.
I can't think of any other codec right now in real need of HW acceleration.
The thing that matters right now is speed for 4K playback with H.264.
wanezhiling
10th January 2012, 19:04
The thing that matters right now is speed for 4K playback with H.264.
VP5 has showed that, I believe Kepler will be faster in terms of speed.
As mariner saied "6670 is faster by about 5fps than (6)750", so assuming that 6670 could dxva 4K, how do you think it's capable of this (http://xhmikosr.1f0.de/index.php?folder=c2FtcGxlcy8yMTYwcC9EdWNrc1Rha2VPZmY=)(2160p,370M bitrate,50fps)?:rolleyes:
NikosD
10th January 2012, 19:12
VP5 has showed that, I believe Kepler will be faster in terms of speed.
I think Kepler, whenever comes, will have exactly same speed because it will have exactly same VPU - VP5
As mariner saied "6670 is faster by about 5fps than (6)750", so assuming that 6670 could dxva 4K, how do you think it's capable of this (http://xhmikosr.1f0.de/index.php?folder=c2FtcGxlcy8yMTYwcC9EdWNrc1Rha2VPZmY=)(2160p,370M bitrate,50fps)?:rolleyes:
That's what I'm saying all the time.
DON'T BELIEVE ATI!
The hardware is more capable than ATI wants you to think!
wanezhiling
10th January 2012, 19:33
I think Kepler, whenever comes, will have exactly same speed because it will have exactly same VPU - VP5
Compared with GT240, GTX560TI does have same speed, so maybe you're right, but maybe a little surprise, just let it happen.
The hardware is more capable than ATI wants you to think!
:p
btw,if possible, I'll try to contact with hd7970's owner to test the power of "UVD3.0+VCE".
mariner
12th January 2012, 07:36
144mbps 4k/60p benchmark
Now that the JVC GY-HMQ10 has been released, would like to see 4k/60p benchmark posted as well.
It seems UVD3 would most likely fail. Lets see if VP5 or QS (or is it actually vlc?) would make the cut.
Thanks.
http://pro.jvc.com/prof/attributes/features.jsp?model_id=MDL102132
CruNcher
12th January 2012, 16:00
hehe QS in Sandy Bridge @ least is hardly capable of QFHD @ 50Mbps 30 fps so this 60 fps will stutter even more, though their is no possibility to use that resolution for DXVA yet which could ultimately confirm the Decoder isn't capable of it, but for now it looks like it's to weak and Ivy Bridge will support it.
NikosD
12th January 2012, 18:36
QS not capable of 4K ?
Says who ?
Have you done any tests by yourself and proved that is not capable ?
QS is clearly faster than VP5.
So if VP5 is capable of 4K, how is it possible a faster HW like QS not being able to accelerate 4K ?
nevcairiel
12th January 2012, 18:39
Speed is not the only concern, especially with fixed-function hardware, it may just not have been designed for 4K frame sizes.
At least the Driver thinks its not capable, because it doesn't expose a 4K DXVA2 mode.
NikosD
12th January 2012, 19:14
So they have to "open" driver to support up to 4K.
And of course MSDK too, because it seems that everything has to pass through MSDK in order to work DXVA properly.
NikosD
12th January 2012, 20:57
I did some tests today with QuickSync HW:
1) 4K playback
4K is not possible in HW due to driver's and MSDK restrictions.
The software fallback works OK with PotPlayer using both pure DXVA internal codec and QuickSync "internal" codec.
Also the fallback works OK with CoreAVC DXVA, LAV video and QS decoder, but MSDK uses slowest software decoding than ALL the others (Pot internal, LAV, CoreAVC)
So, if you play out of Intel's HW DXVA video files, AVOID the QS decoder software MSDK routines, they are not optimized as FFMpeg, CoreAVC, LAV.
MS DS/MFT doesn't provide software fallback and crashes DXVA checker.
2) CoreAVC although it says it uses MSDK, it doesn't. It's pure DXVA and very fast implementation.
3) QS decoder is faster than LAV video QS and MS DS/ CoreAVC are both a lot faster than both MSDK solutions in 60fps clips.
But MS MFT is the fastest of all, only usable in WMP12 though.
4) For normal playback PotPlayer's internal DXVA codecs work like a charm for both MPEG-2/ H.264 progressive or interlaced.
Minimum power consumtion - at least 50% down from MSDK solutions (LAV QS, QS decoder) and easy playback of all up to 1080p video files.
You only need QS decoder for VC-1, because PotPlayer is not able to utilise VC1_VLD mode, only VC1_IDCT.
UPDATE:
I sent an email to ahahlive@hanmail.net, suggesting a method to utilise VC1_VLD with DXVA and QuickSync.
Let's hope it's feasible and see it in next PotPlayer.
nevcairiel
12th January 2012, 21:08
Obviously "pure" DXVA codecs are faster and more efficient o.O
NikosD
15th January 2012, 21:57
The last few days I was thinking and reading about OVD API - which means OpenVideo Decode API.
It's a Video Acceleration API similar to NVCUVID from Nvidia, but of course it's not using CUDA - which is exclusive for Nvidia's hardware.
OVD uses DXVA through OpenCL which like OpenGL is not exclusive to any HW or Platform and it was created by ATI/ AMD for ATI GPU.
But there is OpenCL support for GPU HW by both Nvidia and ATI, and after IvyBridge launch, Intel is going to support OpenCL for GPU HW too.
So although ATI started the project, it could probably integrated to Nvidia and Intel in the near future.
Anyway, for ATI i think that OVD API could resolve two major issues:
1) Fast Frame Copy version - useful for anyone who would like to use a different renderer than EVR, like madVR.
Using Frame Copy version through OVD API, which means through OpenCL, is the only way to have zero penalty during the frame copy process (From GPU to CPU).
Unfortunately there is no other fast way for that kind of process, regarding ATI's HW.
2) OVD API could lead to major performance increase, even greater than direct, pure DXVA.
The reason for this, is the clock of the GPU which means the clock of UVD.
Because using OpenCL pushes the clocks to maximum 3D clocks, which means a twofold increase for many cards out there.
Direct, pure DXVA put GPU in UVD mode where the clock is only 400MHz.
But the GPU is capable of more than 800MHz in 3D mode for many ATI cards.
The only drawback of that approach (OVD) is the increase in power consumption and maybe the unknown - at least to me - difficulty of OVD API.
CruNcher
16th January 2012, 01:48
I did some tests today with QuickSync HW:
1) 4K playback
4K is not possible in HW due to driver's and MSDK restrictions.
The software fallback works OK with PotPlayer using both pure DXVA internal codec and QuickSync "internal" codec.
Also the fallback works OK with CoreAVC DXVA, LAV video and QS decoder, but MSDK uses slowest software decoding than ALL the others (Pot internal, LAV, CoreAVC)
So, if you play out of Intel's HW DXVA video files, AVOID the QS decoder software MSDK routines, they are not optimized as FFMpeg, CoreAVC, LAV.
MS DS/MFT doesn't provide software fallback and crashes DXVA checker.
2) CoreAVC although it says it uses MSDK, it doesn't. It's pure DXVA and very fast implementation.
3) QS decoder is faster than LAV video QS and MS DS/ CoreAVC are both a lot faster than both MSDK solutions in 60fps clips.
But MS MFT is the fastest of all, only usable in WMP12 though.
4) For normal playback PotPlayer's internal DXVA codecs work like a charm for both MPEG-2/ H.264 progressive or interlaced.
Minimum power consumtion - at least 50% down from MSDK solutions (LAV QS, QS decoder) and easy playback of all up to 1080p video files.
You only need QS decoder for VC-1, because PotPlayer is not able to utilise VC1_VLD mode, only VC1_IDCT.
UPDATE:
I sent an email to ahahlive@hanmail.net, suggesting a method to utilise VC1_VLD with DXVA and QuickSync.
Let's hope it's feasible and see it in next PotPlayer.
http://forum.doom9.org/showpost.php?p=1551696&postcount=2121
Works also with Cyberlink though as i said the information how to utilize it is most probably under NDA and only so far with this nice fake Adapter which looks very similar to VC1Tweak from Madshi just that it supports WM ASF Reader you can utilize it for .wmv (though some bitstreams still fail (only a hand few), not sure why yet they are progressive and dont seem so much complex or different @ all, could be mux dependent) :)
PS: Got it working in MPC-HC also now via AV Splitter (it has a special interoperability table setting dynamic vc-1 tweak though not only for vc-1) though parkyoy.wmv seems the only one working many others fail (black screen audio plays) much more compared to Potplayers Adapter ;)
Here you can find some measurement done with MPC-HC trunk (EVR Custom) comparable to Potplayer (EVR Custom) MPC-HC experimental gave marginally better results (lower render overhead) :)
http://forum.doom9.org/showpost.php?p=1551882&postcount=553
pirlouy
16th January 2012, 13:15
Why would OVD be quicker than DXVA if is is based on DXVA ? :/
From your second point, it seems, it will just change AMD profile in order to go to a mode which uses more potential from the card. But that could be fixed for DXVA too if they fixed Drivers/firmware/hardware.
If it is based on DXVA, it can't be better. The only way to be better than DXVA is if you use your own way of communication with GPU (i.e. DXVA independent). I guess it's what CUDA allows...
nevcairiel
16th January 2012, 13:48
You can easily force your GPU into 3D mode, but that would not make decoding faster, just consumes more power.
CUDA does the same, it forces full performance mode (for actual CUDA functions), however it doesn't make decoding faster - the decoders run on their own clock domain, separate from the main GPU or the CUDA cores. Thats the same for NVIDIA and ATI - may be different for Intel. The only thing that benefits from faster clocks is deinterlacing, but the driver should automatically bring the card to full performance mode if the load is high enough.
The frame copying is never "zero penality", copying the frame always takes time (and CPU cycles). I cannot judge if OVD would make that faster then it is with DXVA2, noone really can without trying. One can at least hope!
Note that on the NGC-based graphics card (7xxx series), the DXVA2 frame copy is also quite a lot faster then on previous models.
OVD has one main disadvantage - its not based on D3D, which means you cannot use it for a "native" DXVA mode, and you cannot access the cards post-processing/deinterlacing functions.
Also, the API is indeed difficult to use. I don't know if anyone is actually using it.
Anyway, since i cannot prove this to you without writing or finding a decoder that uses OVD, i'll just leave it at this. :)
PS:
CUDA also isn't any faster then DXVA, its just a hell of a lot easier to use and has a much better error resilience.
NikosD
16th January 2012, 15:53
Why would OVD be quicker than DXVA if is is based on DXVA ? :/
From your second point, it seems, it will just change AMD profile in order to go to a mode which uses more potential from the card. But that could be fixed for DXVA too if they fixed Drivers/firmware/hardware.
True, but they DON'T FIX it.
So until then, forcing 3D clocks right now using OpenCL is not going to make OVD faster than DXVA, only the card itself - in particular the UVD ASIC will be faster (from 400MHz to 3D clocks).
But a faster UVD means faster decoding.
You can easily force your GPU into 3D mode, but that would not make decoding faster, just consumes more power.
CUDA does the same, it forces full performance mode (for actual CUDA functions), however it doesn't make decoding faster - the decoders run on their own clock domain, separate from the main GPU or the CUDA cores. Thats the same for NVIDIA and ATI - may be different for Intel.
Well, from my experiments with 5750 card as i have written before, when I push GPU clocks to 3D mode with original BIOS nothing happens in the decoding mode, just consumes more power, as you wrote.
BUT after flashing my 5750 with a BIOS of 6750, without changing clocks in BIOS, allowed the same card go in ACTUAL 3D mode clocks FOR UVD ENGINE.
So in my (6)750 I have decoding performance of a UVD2.2 clocked in 710 MHz and memory clocked in 1160MHz (GDDR5) instead of a 400/900 UVD2.2 which is the default frequency mode.
I don't know the reason, but I suspect that Firmware/Driver restrictions are keeping down the internal clocks of UVDx engine and after the BIOS flashing the restrictions stopped working.
Because my card is not recognized as a 5750 nor 6750.
It's both at the same time depending on the software.
That's why I call it (6)750 or Frankenstein card.
PS:
CUDA also isn't any faster then DXVA, its just a hell of a lot easier to use and has a much better error resilience.
Early benchmark results based on VP5 HW at my first post, not done by me, seem to indicate that CUDA sometimes is faster than DXVA - at least from the results/ codecs tested.
Of course "faster than DXVA" can't really be done when CUDA and OVD are based on DXVA.
But maybe poor/ slow implementations of direct DXVA decoders can be slower for specific clips than optimized CUVID decoders and in the future optimized OVD decoders.
So, from your words it seems that even if you own an AMD card, you wouldn't even try to write a decoder based on OVD?
nevcairiel
16th January 2012, 16:18
So, from your words it seems that even if you own an AMD card, you wouldn't even try to write a decoder based on OVD?
I would not, the API is not worth it.
I actually own a AMD card now, i just don't have it in my main dev PC. :)
NikosD
17th January 2012, 10:36
The OVD profiles of my card as reported by DXVA Checker are not even capable yet of H.264 L5.1 profile.
Profile
OVD_H264_Baseline_41: Yes
OVD_H264_Main_41: Yes
OVD_H264_High_41: Yes
OVD_H264_Baseline_51: No
OVD_H264_Main_51: No
OVD_H264_High_51: No
OVD_H264_Stereo_High: No
OVD_VC1_Simple: Yes
OVD_VC1_Main: Yes
OVD_VC1_Advanced: Yes
OVD_MPEG2_VLD: Yes
Last line - which exposes MPEG2_VLD for HD5000 series - forced ATI to declare that it's a bug of AMD APP :)
NikosD
24th January 2012, 17:29
NikosD, I got a HD7970's DXVA Checker (http://we.pcinlife.com/data/attachment/forum/201201/11/0119101z55hxsx2sfihhf2.jpg):D, compared with HD6850 (http://we.pcinlife.com/data/attachment/forum/201201/11/011910fvb3zb1ljbfyql3f.jpg), no difference at all..
Can you upload somewhere a DXVA Checker screenshot of your UVD 2.0 ?
I suppose you have Win 7 and recent Catalyst drivers, right ?:p
wanezhiling
24th January 2012, 17:57
http://i.imgur.com/VeTDw.png
http://i.imgur.com/IgXlZ.png
PS: http://www.gokuai.com/f/1Iy283I8786B8FG2;)
renq
28th January 2012, 20:16
Some Beta test results to follow;)
Rig:
I5-2500K
2x4GB 1600MHz
HD6950 w/ shaders unlocked @ 800/1250 (def 6950 clocks:o)
Windows 8 Dev Preview
Default Win8 AMD driver- 8.88.5.3 dated 20.09.2011
DXVAChecker properties:
Renderer: Enhanced Video Renderer (DirectShow)
Decoder: Microsoft DTV-DVD Video Decoder
Decoder Device: ModeH264_VLD_NoFGT
Processor Device: -
Results:
1.
Time: 00:14.293
Average FPS: 56,041
Min/Max FPS: 49 / 64
2.
Time: 01:03.296
Average FPS: 48,139
Min/Max FPS: 39 / 63
3.
Time: 01:24.346
Average FPS: 57,442
Min/Max FPS: 45 / 63
4.
Time: 03:25.727
Average FPS: 58,082
Min/Max FPS: 40 / 66
5.
Time: 00:42.109
Average FPS: 56,686
Min/Max FPS: 40 / 60
6.
Time: 00:52.456
Average FPS: 57,686
Min/Max FPS: 52 / 60
7.
Time: 00:11.802
Average FPS: 28,724
Min/Max FPS: 27 / 32
8.
Time: 00:18.077
Average FPS: 29,319
Min/Max FPS: 26 / 38
9.
Time: 00:13.095
Average FPS: 30,622
Min/Max FPS: 21 / 36
10.
Time: 00:04.600
Average FPS: 23,913
Min/Max FPS: 16 / 27
wanezhiling
28th January 2012, 21:02
3.
Average FPS: 57,442
4.
Average FPS: 58,082
5.
Average FPS: 56,686
6.
Average FPS: 57,686
http://forum.doom9.org/showpost.php?p=1548287&postcount=4 ;):D
NikosD's (6)750, what a Frankenstein card...
So nev, I think you needn't spend more time on DXVA2(copy-back) for 60fps movies, because it's AMD's issue.:p
NikosD
29th January 2012, 16:23
The results of Renq above, indicate that UVD3 "seems" to have same the performance as 5750 and not (6)750.
ATI makes UVD3 to look like UVD2.2 in terms of raw performance.
At the same time UVD3 according to ATI is capable of 4K HW acceleration :sly: and according to this (http://www.agile-news.com/news-323468-Photo:-no-fear-of-4K-x-2K!-Fire-whirlwind-2-HD6570-2G-Daniel-Edition-hardware-solution-2160p!.html)
Of course the above results are coming from a Beta OS like Windows 8.
But I think that Win 7 SP1 would give similar results.
I have no explanation for the contradicting results, statements and facts
renq
29th January 2012, 19:06
Of course the above results are coming from a Beta OS like Windows 8.
But I think that Win 7 SP1 would give similar results.
I have no explanation for the contradicting results, statements and facts
Well, let us see;)
Same rig.
Windows 7 X64 SP1
DXVAChecker 2.6.2 64bit (previous Windows 8 DP results were with 32bit IIRC, 95% certain of it)
LAVFilter 0.45
AMD Catalyst 12.1 WHQL (8.93-111205a-132104C-ATI)
Default Vid Quality settings in CCC:
* Edge Enh- 10
* De-noise 64
* Mosquito NR 50
* De-block 50
* Dyn contrast enabled, ESVP (Enforce smooth video playback) enabled
PS! LAV results are ALL Software mode results (i5-2500K @ 4,2GHz)
AVG Results:
1.
LAV video - 486,152
DS- 73,500
MFT- 68,980
2.
LAV video - 177,882
DS - 63,797
3.
LAV- FAIL
DSD - 76,834
4.
LAV - 334,202
DS - 76,559
5.
LAV - 257,164
DS - 75,807
MFT - 75,276
6.
LAV - 267,098
DS- 77,147
7.
LAV - 69,567
DS- 45,479
MFT - 37,715
8.
LAV - 64,448
DS- 40,021
9.
LAV - 76,746
DS - 43,753
10.
LAV - 62,916
DS - 36,268
More thorough results:
1.
Renderer: Enhanced Video Renderer (DirectShow)
Decoder: LAV Video Decoder
Decoder Device: -
Processor Device: -
Time: 00:01.697
Average FPS: 486,152
Min/Max FPS: 481 / 481
Renderer: Enhanced Video Renderer (DirectShow)
Decoder: Microsoft DTV-DVD Video Decoder
Decoder Device: ModeH264_VLD_NoFGT
Processor Device: -
Time: 00:10.898
Average FPS: 73,500
Min/Max FPS: 46 / 103
NOTE- No Video in Preview
Renderer: Enhanced Video Renderer (Media Foundation)
Decoder: Microsoft H264 Video Decoder MFT
Decoder Device: ModeH264_VLD_NoFGT
Processor Device: -
Time: 00:11.960
Average FPS: 68,980
Min/Max FPS: 49 / 88
2.
Renderer: Enhanced Video Renderer (DirectShow)
Decoder: LAV Video Decoder
Decoder Device: -
Processor Device: -
Time: 00:17.208
Average FPS: 177,882
Min/Max FPS: 134 / 243
CPU Usage (%): Avg: 00 Min: 00 Max: 00
GPU Usage (%): Avg: 03 Min: 00 Max: 20
NOTE- random(ish) peaks of gpu usage
Renderer: Enhanced Video Renderer (DirectShow)
Decoder: Microsoft DTV-DVD Video Decoder
Decoder Device: ModeH264_VLD_NoFGT
Processor Device: -
Time: 00:47.761
Average FPS: 63,797
Min/Max FPS: 46 / 93
NOTE- No VIdeo in preview window
3.
LAV- Doesn't do anything
Renderer: Enhanced Video Renderer (DirectShow)
Decoder: Microsoft DTV-DVD Video Decoder
Decoder Device: ModeH264_VLD_NoFGT
Processor Device: -
Time: 01:03.058
Average FPS: 76,834
Min/Max FPS: 71 / 80
NOTE- Green blocks corruption for first few secs of preview
4.
Renderer: Enhanced Video Renderer (DirectShow)
Decoder: LAV Video Decoder
Decoder Device: -
Processor Device: -
Time: 00:36.050
Average FPS: 334,202
Min/Max FPS: 316 / 376
CPU Usage (%): Avg: 00 Min: 00 Max: 00
GPU Usage (%): Avg: 11 Min: 00 Max: 35
NOTE- The GPU usage goes up to 35% occasionally
Renderer: Enhanced Video Renderer (DirectShow)
Decoder: Microsoft DTV-DVD Video Decoder
Decoder Device: ModeH264_VLD_NoFGT
Processor Device: -
Time: 02:36.075
Average FPS: 76,559
Min/Max FPS: 72 / 91
NOTE- No Video in Preview window
5.
Renderer: Enhanced Video Renderer (DirectShow)
Decoder: LAV Video Decoder
Decoder Device: -
Processor Device: -
Time: 00:09.667
Average FPS: 257,164
Min/Max FPS: 219 / 296
CPU Usage (%): Avg: 00 Min: 00 Max: 00
GPU Usage (%): Avg: 06 Min: 00 Max: 30
NOTE- The GPU usage goes up to 30% once per run (usually in the middle of the video/run/test)
Renderer: Enhanced Video Renderer (DirectShow)
Decoder: Microsoft DTV-DVD Video Decoder
Decoder Device: ModeH264_VLD_NoFGT
Processor Device: -
Time: 00:31.488
Average FPS: 75,807
Min/Max FPS: 73 / 85
NOTE- No Video in Preview window
Renderer: Enhanced Video Renderer (Media Foundation)
Decoder: Microsoft H264 Video Decoder MFT
Decoder Device: ModeH264_VLD_NoFGT
Processor Device: -
Time: 00:33.025
Average FPS: 75,276
Min/Max FPS: 70 / 78
6.
Renderer: Enhanced Video Renderer (DirectShow)
Decoder: LAV Video Decoder
Decoder Device: -
Processor Device: -
Time: 00:11.449
Average FPS: 267,098
Min/Max FPS: 244 / 294
CPU Usage (%): Avg: 00 Min: 00 Max: 00
GPU Usage (%): Avg: 12 Min: 00 Max: 30
NOTE- Up to 30% GPU usage 2-3 times per run!
Renderer: Enhanced Video Renderer (DirectShow)
Decoder: Microsoft DTV-DVD Video Decoder
Decoder Device: ModeH264_VLD_NoFGT
Processor Device: -
Time: 00:39.224
Average FPS: 77,147
Min/Max FPS: 74 / 99
NOTE- No Video in Preview window
7.
Renderer: Enhanced Video Renderer (DirectShow)
Decoder: LAV Video Decoder
Decoder Device: -
Processor Device: -
Time: 00:05.333
Average FPS: 69,567
Min/Max FPS: 68 / 71
Renderer: Enhanced Video Renderer (DirectShow)
Decoder: Microsoft DTV-DVD Video Decoder
Decoder Device: ModeH264_VLD_NoFGT
Processor Device: -
Time: 00:07.454
Average FPS: 45,479
Min/Max FPS: 17 / 79
NOTE- No Video in Preview window
Renderer: Enhanced Video Renderer (Media Foundation)
Decoder: Microsoft H264 Video Decoder MFT
Decoder Device: ModeH264_VLD_NoFGT
Processor Device: -
Time: 00:09.837
Average FPS: 37,715
Min/Max FPS: 36 / 41
8.
Renderer: Enhanced Video Renderer (DirectShow)
Decoder: LAV Video Decoder
Decoder Device: -
Processor Device: -
Time: 00:08.534
Average FPS: 64,448
Min/Max FPS: 58 / 72
Renderer: Enhanced Video Renderer (DirectShow)
Decoder: Microsoft DTV-DVD Video Decoder
Decoder Device: ModeH264_VLD_NoFGT
Processor Device: -
Time: 00:13.243
Average FPS: 40,021
Min/Max FPS: 20 / 94
NOTE- No Video in Preview window
9.
Renderer: Enhanced Video Renderer (DirectShow)
Decoder: LAV Video Decoder
Decoder Device: -
Processor Device: -
Time: 00:06.502
Average FPS: 76,746
Min/Max FPS: 65 / 93
CPU Usage (%): Avg: 00 Min: 00 Max: 00
GPU Usage (%): Avg: 03 Min: 00 Max: 10
Renderer: Enhanced Video Renderer (DirectShow)
Decoder: Microsoft DTV-DVD Video Decoder
Decoder Device: ModeH264_VLD_NoFGT
Processor Device: -
Time: 00:09.165
Average FPS: 43,753
Min/Max FPS: 23 / 83
NOTE- No Video in Preview window
10.
Renderer: Enhanced Video Renderer (DirectShow)
Decoder: LAV Video Decoder
Decoder Device: -
Processor Device: -
Time: 00:03.306
Average FPS: 62,916
Min/Max FPS: 59 / 64
CPU Usage (%): Avg: 00 Min: 00 Max: 00
GPU Usage (%): Avg: 04 Min: 00 Max: 09
Renderer: Enhanced Video Renderer (DirectShow)
Decoder: Microsoft DTV-DVD Video Decoder
Decoder Device: ModeH264_VLD_NoFGT
Processor Device: -
Time: 00:03.033
Average FPS: 36,268
Min/Max FPS: 33 / 41
NOTE- No Video in Preview window
nevcairiel
29th January 2012, 19:17
These DXVA numbers are impossible for an ATI card.
Are you sure it didn't use your Intel GPU or software or something? :) (It'll always use the primary GPU)
renq
29th January 2012, 19:43
These DXVA numbers are impossible for an ATI card.
Are you sure it didn't use your Intel GPU or software or something? :) (It'll always use the primary GPU)
Ur, right, it's SW mode, dunno why DXVAChecker shows 0% CPU util.
:o
NikosD
29th January 2012, 20:30
You have to check your ATI's clocks.
From idle mode clocks they have to go to UVD mode clocks (usually 400/900) or more.
Use GPU Observer gadget.
It works for Nvidia and AMD cards.
wanezhiling
29th January 2012, 20:58
http://forum.doom9.org/showpost.php?p=1554385&postcount=85
I never doubt it, it's true AMD.;)
http://forum.doom9.org/showpost.php?p=1554567&postcount=88
Obviously, made by I5 2500K(cpu mode)
0% CPU util, just a bug~~
renq
30th January 2012, 07:03
You have to check your ATI's clocks.
From idle mode clocks they have to go to UVD mode clocks (usually 400/900) or more.
Use GPU Observer gadget.
It works for Nvidia and AMD cards.
500/1250 according to GPU-Z:)
NikosD
30th January 2012, 13:09
Use DXVA Checker 32bit, not x64
NikosD
30th January 2012, 21:24
PS:
http://www.gokuai.com/f/B05Yj637KS6yyu75
4096 x 3072, maybe you could collect it.
VP5 DXVA 4096 x 3072 (http://we.pcinlife.com/data/attachment/forum/201201/06/230440e20a0a3zeo0zaecz.jpg)
These clips (first post - second post) are the same ?
Because I downloaded the first one and it says that is a Sorenson Spark clip at 117.586 fps.
Sorenson Spark is very close to H.263, not H.264.
So how can VP5 accelerate a clip in DXVA like the screenshot you posted at the second reference ?
Maybe PotPlayer uses MPEG1 or MPEG2 HW acceleration of VP5, because H.263 and Sorenson Spark is close to MPEG1/MPEG2, not H.264.
Can you confirm that the clip of second post - with VP5 screenshot - uses Sorenson Pack codec ?
nevcairiel
30th January 2012, 21:27
Sorenson Spark and H.263 are close to MPEG-4, not MPEG1/2
NikosD
30th January 2012, 21:35
True.
Sorenson Video (first versions) was close to MPEG1/MPEG2.
But H.263 and Sorenson Spark is close to MPEG-4.
And this makes things more complicated, because DXVA MPEG-4 is not even supported by PotPlayer for Nvidia HW :confused: (except H.264 of course)
EDIT:
-------------
PotPlayer says Input: AVC1, although in File info (from MediaInfo tool) says Sorenson Spark.
Somehow the Sorenson Spark format is HW accelerated via H.264.
CruNcher
30th January 2012, 23:54
and Sorenson SVQ is near to H.264 ;) you see the pattern, its a very common one see RealVideo and other codec implementer whenever they send some white paper to MPEG they work on something similar and sometimes a own codec comes up, and sometimes they don't agree and create something complete different see Microsoft (though they are back stabers its not really that unique,except psy ideas), Leadtools, Iterate and others ;)
Its a evolutionary process and only very few times something unique comes up somewhere else apart from the Mpeg Chain (of monster patents) (Dirac and Snow being one of the last unique ones in our current time, that made some news their where some other Wavelett based ones XWD,loco but Dirac and Snow are the most known Dirac even made it to a SMPTE standard, Iterate being the craziest different one (fractal) that still no one yet reverse engineered) ;)
wanezhiling
31st January 2012, 02:00
You could ask developer and he will reply what nev has said.:)
PS: VP5 could DXVA 4096 x 4096 smoothly if clips are light.
No, VP5 can't decode 4K x 2K by CoreAVC DXVA. CoreAVC CUDA is ok. you can see that screenshots. In fact besides CoreAVC CUDA, VP5 can docode 4K x 2K by PotPlayer self DXVA(note: old version,at least before 2011.11), TMT5, MainConcept(Broadcast) AVC/H.264 deocoder.
Failure lists: PowerDVD11 DXVA, ffdshow DXVA, MPC-HC DXVA, CoreAVC DXVA, MS DTV-DVD, LAV CUVID
Add a new member: LAV DXVA2(copy-back), it showed active when playing duckstakeoff 2160p though very very slow.:(
nevcairiel
31st January 2012, 08:15
LAV DXVA2(copy-back), it showed active when playing duckstakeoff 2160p though very very slow.:(
The problem here is that the only VP5 card is the 520, which is just a very slow card. It would probably do OK with pure DXVA, but the copy-back is probably too much for it. ;)
If NVIDIA releases their new generation of GPUs, i'll get one and see what can be done. ;)
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.