View Full Version : Intel QuickSync Decoder - HW accelerated FFDShow decoder with video processing
ajp_anton
19th June 2012, 07:07
I've heard 64-bit decoding can actually be slower because of the larger addresses, but I won't pretend like I know much about this, maybe it's just badly coded.
I'm a bit confused about nev's explanation. It implies x264 does not use "optimized SIMD code" (because doing so, 32 and 64-bit "will be about the same speed"), which to me sounds like a bad thing...
egur
19th June 2012, 07:16
I've heard 64-bit decoding can actually be slower because of the larger addresses, but I won't pretend like I know much about this, maybe it's just badly coded.
I'm a bit confused about nev's explanation. It implies x264 does not use "optimized SIMD code" (because doing so, 32 and 64-bit "will be about the same speed"), which to me sounds like a bad thing...
x264 uses a lot of "optimized SIMD code" -> SSE (maybe even AVX, not sure).
When one uses SSE/AVX instructions it matters very little if the code is 32 or 64. The SSE (xmm) registers are 128 bit. The AVX registers are 256 bit. 64 bit mode adds 8 of more these, allowing the writer and compiler more freedom to optimize their code. Note that it's not always beneficial to use all the registers.
So if a function is heavily optimized with SSE or AVX instructions it will not work (much) with the 32 or 64 bit general purpose registers (EAX/RAX, ECX/RCX, etc).
nevcairiel
19th June 2012, 09:08
x264 is very complex, and it does benefit from the additional registers much more then for example decoding would, which allows it to benefit much more from 64-bit - both from more general purpose registers as well as from more SSE registers. AFAIK, x264 has special implementation of some algorithms to take advantage of the additional registers and provide the performance boost.
egur
19th June 2012, 12:01
I also read the PhotoShop x64 is more than 2x faster that its 32bit version.
32 bit will go the way of the 16 bit apps. Microsoft will not keep producing 32bit OSes forever. They published that windows 8 will be the last 32 version. Once the OS and all the tools are 64 bit, it's natural that 32 bit compatibility mode will be deprecated as well.
nevcairiel
19th June 2012, 12:03
My guess is that Photoshop mostly benefits from the additional RAM it can use. :)
CruNcher
19th June 2012, 17:13
x264 is very complex, and it does benefit from the additional registers much more then for example decoding would, which allows it to benefit much more from 64-bit - both from more general purpose registers as well as from more SSE registers. AFAIK, x264 has special implementation of some algorithms to take advantage of the additional registers and provide the performance boost.
I guess the current improvement was somewhere @ the 15% and yeah 2x faster in which scenario in Photoshop for sure Crunching some over 4 GB raw data so as you said very Workflow dependent and most applications that are very well optimized surely wont get speedup of 2x x264 is the perfect case study for that ;)
Sure is if you combine Workflows and get 15% improvements step each in that chain of applications its nothing to look over :)
As Egur said 32bit will vanish we are already @ the edge see 4GB GFX Cards these days but 640K are enough as we all know ;)
egur
22nd June 2012, 23:34
Photoshop would run much faster than 2x if the 32 bits version was starved for memory. The 2x improvement is due to x64 architecture only. But that's very rare. I read this on Anandtech or Tom's Hardware a few years ago. I didn't actually run the 2 versions myself.
rtabrah
26th June 2012, 21:34
First time post, long time follower of this thread and forum. Since you are all passionate about QuickSync and Intel's Media SDK - we just found 2 Core i7 2600k processors and are giving them away this week. If you want a chance to win - you need to follow or retweet us on twitter @IntelMediaSDK by 6/28. U.S. residents only for now.
I'll be creating another thread in case you have any overall questions about the Intel Media SDK.
-Ryan Tabrah
Intel Media SDK Product Manager
andyvt
26th June 2012, 21:41
First time post, long time follower of this thread and forum. Since you are all passionate about QuickSync and Intel's Media SDK - we just found 2 Core i7 2600k processors and are giving them away this week. If you want a chance to win - you need to follow or retweet us on twitter @IntelMediaSDK by 6/28. U.S. residents only for now.
I'll be creating another thread in case you have any overall questions about the Intel Media SDK.
-Ryan Tabrah
Intel Media SDK Product Manager
Welcome.
JustinChase
27th June 2012, 17:54
First, thanks for all your hard work.
I just got a new i5 IvyBridge with the HD4000 GPU.
I installed everything fine, installed windows 7x64, then installed the VGA driver from the manufacturer, then installed the latest version from Intel's download center on top of that. (QuickSync Win7_64_15.26.12.64.2761)
Everything is basically fine, and windows displays fine. however, I'm sending to a DLP TV, which has overscan, so I can't see the taskbar, or start button, nor the minimize/maximize boxes in the upper right of maximized windows. TV offers no way to compensate, so it must be done at the PC.
So, I did some poking around and see that custom resolutions lets you use a slider to get reduced resolutions.
It took some 'trickery' to get it to finally let me use the custom resolution (1812 x 1020), but once I got it enabled, the desktop displayed fine.
When I opened Windows Media Center to a window, all was still fine. However, when I set it to maximize/full screen, I could still hear sound, but only got a black screen. I hit ctl-f4 to close the program, but the desktop did not return, just the black screen.
I turned off the AVR, and the desktop came back, but at a different resolution (1680 x 1050). My custom resolution wasn't available any more from the list of resolutions. When I turned the AVR on again, the resolution went back to my custom resolution.
I tried going back to the full 1920 x 1080 resolution, and everything works.
I uninstalled that driver, and installed the previous one (15.26.8.64.2696), and nothing changed. All behavior was the same.
I tried JRiver Media Center, and going into their fullscreen display also resulted in a black screen with the custom resolution.
I'm not sure this is even the right place to post this, but hopefully someone has some suggestions on how to resolve.
karl_lillevold
27th June 2012, 18:04
@JustinChase: I have learned to live my overscan on my DLP TV. I have expanded the taskbar to double height. Most of the time I manage fine... but it is annoying still. My biggest problem with the Intel HD Graphics on my DLP is that I can not get it to work with Full RGB, resulting in gray blacks. There is no way to resolve the problem except use a discrete graphics card. Intel support has no answer either. http://communities.intel.com/thread/29420 I was curious if you can get Full RGB to work with your TV?
andyvt
27th June 2012, 18:14
My biggest problem with the Intel HD Graphics on my DLP is that I can not get it to work with Full RGB, resulting in gray blacks. There is no way to resolve the problem except use a discrete graphics card. Intel support has no answer either. http://communities.intel.com/thread/29420 I was curious if you can get Full RGB to work with your TV?
Have you tried using a DVI connection?
egur
27th June 2012, 18:39
...
I'll be creating another thread in case you have any overall questions about the Intel Media SDK.
-Ryan Tabrah
Intel Media SDK Product Manager
Welcome!
Please post the link in this thread.
First, thanks for all your hard work.
I just got a new i5 IvyBridge with the HD4000 GPU.
I installed everything fine, installed windows 7x64, then installed the VGA driver from the manufacturer, then installed the latest version from Intel's download center on top of that. (QuickSync Win7_64_15.26.12.64.2761)
Everything is basically fine, and windows displays fine. however, I'm sending to a DLP TV, which has overscan, so I can't see the taskbar, or start button, nor the minimize/maximize boxes in the upper right of maximized windows. TV offers no way to compensate, so it must be done at the PC.
...
This is not related to this thread but I'll try to help.
I haven't seen a TV (or projector) that doesn't allow to view the full 1080p resolution. Maybe you should look again (usually under "setup" and not where image image properties are set).
WMC and maybe JRiver switch to full screen mode which may be different than the driver settings for desktop. The TV might not like the different resolution.
FYI resolution is made from width, height, refresh rate and timing (blanking properties).
You didn't write if the output is analog or digital.
The TV might think that an analog connection is not a PC.
In this case you're out of luck.
I'd stick with the newer driver. It fixes a few issues.
BTW, what's AVR?
andyvt
27th June 2012, 18:42
Welcome!
what's AVR?
Audio Video Receiver
JustinChase
27th June 2012, 19:10
@JustinChase: I have learned to live my overscan on my DLP TV...I was curious if you can get Full RGB to work with your TV?
I haven't gotten that far yet; still just trying to get video to play when set at a custom resolution. It seems like this should work, but doesn't. i think I'll have to learn to live with the overscan also. I guess a projector is next.
Welcome!
I haven't seen a TV (or projector) that doesn't allow to view the full 1080p resolution.
I can use 1920 x 1080 fine, it's just that my TV/monitor overscans that image and only shows me about 1812 x 1020 of the full image. This means the edges of the screen are all not visible, so it's hard to see the controls of windows, which are all on the edges of the screen, so get cut off from my view.
In my efforts to compensate for this, I created the custom resolution (1812 x 1020), so that after the edges get cut off by my TV, I see the complete desktop. However, when either program goes to full screen, it doesn't display video. This just seems buggy behavior. I realize it's probably not the QS decoder doing this, but figured some people with experience with Intel graphics might have some feedback if I'm just 'doing it wrong'.
It sounds like I'll have to live with the issues from the overscan, and just keep everything at 1920 x 1080. hopefully someday Intel can get this working correctly.
WMC and maybe JRiver switch to full screen mode which may be different than the driver settings for desktop. The TV might not like the different resolution.
FYI resolution is made from width, height, refresh rate and timing (blanking properties).
You didn't write if the output is analog or digital.
The TV might think that an analog connection is not a PC.
In this case you're out of luck.
I'd stick with the newer driver. It fixes a few issues.
BTW, what's AVR?
Maybe I'll play around and see if some combination of refresh rate and timing works with the resolution I need. The Intel software keeps selecting 59Hz instead of 60, so maybe I just need to leave it at that, but my TV claims to handle 23, 24, 29,30, 59,60Hz, so who knows.
I'll reinstall the latest driver again.
As babgvant said Audio Video Receiver.
Sorry, I forgot your native languauge isn't English, and that acronym might be unknown to you.
Thanks again.
karl_lillevold
27th June 2012, 19:17
Have you tried using a DVI connection?
Motherboard has HDMI only. Besides, I need this to bitstream HD audio formats to my AVR (Audio/Video Receiver...) anyway.
egur
27th June 2012, 19:17
Just had a long day, I know what an AVR is (and own one too).
By default, many AVRs will underscan the image for 1080p input.
My own projector (720p) is connected to an Onkio 608 AVR. The AVR defaulted to underscan.
andyvt
27th June 2012, 19:25
Motherboard has HDMI only. Besides, I need this to bitstream HD audio formats to my AVR (Audio/Video Receiver...) anyway.
Two cables usually works fine, so it might be worth a shot to see if you see the problem going direct into the TV.
karl_lillevold
27th June 2012, 19:31
Two cables usually works fine, so it might be worth a shot to see if you see the problem going direct into the TV.
Yes, I have tried this too. Doesn't help. Tried a different TV as well (Vizio LCD) - same problem.
andyvt
27th June 2012, 19:35
Yes, I have tried this too. Doesn't help. Tried a different TV as well (Vizio LCD) - same problem.
AFAIK, the levels are determined from the preferred values set in the EDID. So it's not strange that it doesn't use full (you can select it in the settings dialogs, just doesn't stay that way) over HDMI, but it's weird that your TV expects it to (or am I just assuming this part?).
karl_lillevold
27th June 2012, 20:05
AFAIK, the levels are determined from the preferred values set in the EDID. So it's not strange that it doesn't use full (you can select it in the settings dialogs, just doesn't stay that way) over HDMI, but it's weird that your TV expects it to (or am I just assuming this part?).
I don't know what's common. All I know is my Samsung DLP TV requires Full range RGB. I can see a big difference when switching between Limited and Full with all the ATI cards I have owned. Intel looks gray and flat - no matter the setting, and exactly like Limited RGB with the ATI cards.
Similarly, I have to set my PS3, Xbox 360, and Apple TV all to Full range to avoid gray blacks. All use HDMI.
andyvt
27th June 2012, 21:16
I don't know what's common. All I know is my Samsung DLP TV requires Full range RGB. I can see a big difference when switching between Limited and Full with all the ATI cards I have owned. Intel looks gray and flat - no matter the setting, and exactly like Limited RGB with the ATI cards.
Similarly, I have to set my PS3, Xbox 360, and Apple TV all to Full range to avoid gray blacks. All use HDMI.
I used to have a Samsung DLP which expected RGB full, but it was DVI and the driver detected the correct colorspace.
You can use a tool like moninfo (http://entechtaiwan.com/util/moninfo.shtm) to examine the EDID, maybe you could figure out a way to override it on the PC. If not, an HDMI Detective can do that (obviously the right solution is for Intel to make the driver more flexible here).
nevcairiel
27th June 2012, 21:18
Its a known bug in the Intel driver, in some HDMI configurations it just refuses to output full range, i have the same problem (or had, use a dedicated GPU now). Even temporarily changing the setting didn't do anything, nevermind the issue that the setting didn't stick.
andyvt
27th June 2012, 21:21
Its a known bug in the Intel driver, in some HDMI configurations it just refuses to output full range, i have the same problem (or had, use a dedicated GPU now)
Agreed, but since [AFAIK] the behavior is EDID based there are potential workarounds available.
Obviously the best solution is for Intel to 1) fix the problem 2) provide a workable way for end-users to override the default behavior if they don't like it.
JustinChase
28th June 2012, 00:06
Maybe I'll play around and see if some combination of refresh rate and timing works with the resolution I need.
I'll reinstall the latest driver again.
I kept playing around, and discovered a solution. I had been setting the corrected resolution (1812 x 1020) using the underscan slider, then selecting "center" as the scaling choice. this actually changes the resolution, and was killing the full screen players.
I changed the scaling choice from "Center" to "Customize aspect ratio", which let me keep the resolution at 1920 x 1080, then I moved the sliders to 55%, hit apply, and my desktop appears correct, but everything sees it as 1080. I've tried both players, with several videos and some music, and so far so good. I've tried starting with the AVR off, then turning it on, and turning it off while playing, etc. i've restarted, and so far, I get my desktop all visible, and everything else seems to be working good.
rtabrah
28th June 2012, 08:41
Welcome!
Please post the link in this thread.
Thanks Eric. Thread is here: http://forum.doom9.org/showthread.php?t=165249
egur
28th June 2012, 09:03
@JustinChase
Does your AVR perform scaling or just sends the video 'as is'?
Mine performs scaling so I can set a single output resolution for all sources.
What happens if you send 1680x1050, Does it still crop the image?
If things looks good, it might be the best quality option for your setup. 1080p media will look almost the same as there's a high quality algorithm for downscaling.
Also does the TV (bypass AVR) accept 1680x1050?
iSeries
28th June 2012, 15:34
@JustinChase: I have learned to live my overscan on my DLP TV. I have expanded the taskbar to double height. Most of the time I manage fine... but it is annoying still. My biggest problem with the Intel HD Graphics on my DLP is that I can not get it to work with Full RGB, resulting in gray blacks. There is no way to resolve the problem except use a discrete graphics card. Intel support has no answer either. http://communities.intel.com/thread/29420 I was curious if you can get Full RGB to work with your TV?
Full RGB works and sticks if you create custom resolutions.
CiNcH
10th July 2012, 14:53
There's very little programmable code that runs in the Intel GPU, most of the decoding/emcoding/VPP is done by ASIC (fixed function HW). That's why its so fast even when compared to a 250W GPU.
AnandTech did a performance test with Ivy Bridge (http://www.anandtech.com/show/5773/intels-ivy-bridge-an-htpc-perspective/6). My feeling is that the EU usage is quite high for a DXVA2 native decoder without VPP in shaders. 1080i60 and 1080p60 seem to consume about the amount of GPU time. So deinterlacing is performed by an ASIC? But what is causing the almost 50% usage?
nevcairiel
10th July 2012, 15:03
But what is causing the almost 50% usage?
The combination of decoding, converting to RGB, and displaying, i guess. It also doesn't explicitly say that all post-processing was off now that i read it again, or which EVR-CP settings were used (should've maybe used plain EVR for better comparison). EVR-CP does all its scaling (including 4:2:0 to 4:4:4 to RGB) in shaders, so even if you run 1080p it got something for the shaders to do, while plain EVR would've avoided that and let the GPUs hardware scaler do that.
Well, too bad they didnt do a plain EVR comparison.
egur
10th July 2012, 15:16
Yes, both MadVR and EVR-CP are EU hogs because they do scaling using shader language...
Too bad DXVA is very limited with respect to scaling...
The deinterlacing itself (and other HW/ASIC video processing) need very little EU work, mostly move data around.
CiNcH
10th July 2012, 20:40
Too bad DXVA is very limited with respect to scaling...
DXVA scaling is applied, when I pass a texture and a rectangle to the EVR mixer that is not the same size as the source, right? What type of scaling is applied?
EVR-CP in MPC-HC does not necessarily use the shaders to scale the image. It can also take advantage of the bilinear D3D scaler. Dunno where this is being calculated though. I thought that EVR-CP with the bilinear D3D scaler being set does not use any more GPU than the standard EVR...
egur
10th July 2012, 20:52
DXVA scaling is applied, when I pass a texture and a rectangle to the EVR mixer that is not the same size as the source, right? What type of scaling is applied?
EVR-CP in MPC-HC does not necessarily use the shaders to scale the image. It can also take advantage of the bilinear D3D scaler. Dunno where this is being calculated though. I thought that EVR-CP with the bilinear D3D scaler being set does not use any more GPU than the standard EVR...
EVR will use the best scaler available (driver decides what algorithm). In SandyBridge/IvyBridge it's a context adaptive 8 tap scaler (similar to Lanczos4 but less ringing artifacts and same sharpness).
D3D can scale images using bi-linear - one of the worst quality scaling algorithms.
Scaling quality is very clear when scale is factor is large and the original image is sharp. A blurred image will scale to blurred image in all algorithms :)
JohnPeterson
13th July 2012, 01:53
For example post 302 (http://forum.doom9.org/showthread.php?p=1546599#post1546599) gives instructions about Virtu settings. What is not mentioned is if the media player (mpc-hc.exe in my test) should "Work in D-mode" or "Work in I-mode" in Virtu MVP. I'm guessing I-mode to present the iGPU to the application when it asks for a GPU?
The Virtu MVP Installation Guide (http://download.asrock.com/manual/virtu/Z77%20Pro3/English.pdf) is ambiguous about this setting, "Select “Work in D-mode” or “Work in I-mode” according to your needs." The apparent ambiguity may be because the answer is simple, "Work in D-mode" presents the dGPU to the application and "Work in I-mode" present the iGPU to the application. (It's less ambiguous about which DVI slot to use, "We recommend using d-Mode [connect display to dGPU] for better 3D performance", and that is what I do.)
Both "Work in D-mode" and "Work in I-mode" display the Virtu MVP logo in the rendering window. The earlier option gives the ffdshow.ax Info "Decoder: libavcodec h264" and the later option "Decoder: Intel® QuickSync" which is expected if the setting does what I've written above that I guess it does.
The CPU/GPU usage for mpc-hc.exe (from ProcessHacker.exe) is 5%/6% in both cases. Why is the CPU usage not closer to 0 when decoding through QSV? When decoding through msmpeg2vdec.dll and dxva2.dll through iGPU/dGPU the CPU usage is around 1.00%/0.75% and GPU usage around 5%/3%. The sample is 1080p x264.
Thanks!
Virtu MVP 2.1.114.22585
AMD Catalyst 12.6
Intel HD Graphics driver 8.15.10.2696 2012-03-19
MPC-HC 1.6.1.4087
ffdshow 4466 2012-07-02
Process Hacker 2.27-4965 (GPU usage from Node 0 of 0-9)
Windows 6.1.7601 x64
Asus P8Z77-M Pro
Intel i7-3770K
AMD Radeon 6870
Keiyakusha
13th July 2012, 04:04
Maybe I'm wrong but to me its pretty clear and require no explanation. D mode = work on Discrete GPU, I mode = work on Intel. So you need "I" because quicksync is under it.
Not sure about CPU load but today decoding doesn't load cpu much anyway so using such things like Virtu only for that is an overkill imho. Also Virtu is a whole another framework, maybe it eats your CPU cycles. + drivers for both graphics are functioning + QS expected to eat more resources if compared to DXVA (classic, not copyback)
BTW dont know about ATI but with Nvidia it is not worth to use Virtu not only because it doesn't saves CPU cycles more than simpler methods, but it doesn't saves power too because it turns Discrete GPU in 2nd or 3rd power state (dont remember ) even if you don't use it. And it makes seeking slower.
Using DXVA only (classic or CB) turns Nvidia in 2nd power state but never 3rd + no load on CPU and nice seeking, no additional complication levels no anything. Works perfect - this is what I use.
Alternative would be connect display to Intel and use QS, and run your games and whatever under Virtu, but its buggy, you can google reviews.
JohnPeterson
13th July 2012, 04:19
Can you suggest a command line benchmark for decoding performance? For example VLC (or another program) commands that plays a video and present benchmark results. Playback at maximum framerate presenting the fps as benchmark result, or playback at fixed fps presenting the CPU/GPU usage as result.
(I prefer a command line benchmark tool to be able to copy and paste the command and output to make the test and results as unambiguous as possible.)
I would be interested to compare the decoding cases:
dGPU ffmpeg.dll libavcodec
iGPU ffmpeg.dll libavcodec
dGPU msmpeg2vdec.dll/dxva2.dll
iGPU msmpeg2vdec.dll/dxva2.dll
iGPU IntelQuickSyncDecoder.dll
The iGPU tests with Virtu MVP I-mode and without Virtu (display connected directly to iGPU). The dGPU tests both without Virtu MVP and in Virtu MVP D-mode. This will show the amount of Virtu overhead.
Keiyakusha
13th July 2012, 04:28
If you ask me - no sorry, i don't know commandline tools for this task.
Btw I think one of us is confused a bit. What this means?
dGPU ffmpeg.dll libavcodec
iGPU ffmpeg.dll libavcodec
these are software decoders they will run on CPU. You shouldn't see any difference whatever you select dGPU or iGPU
And if you just want to compare different hardware decoders, there is big thread about it on this forum. Not sure if virtu involved though
JohnPeterson
13th July 2012, 04:30
It tests if Virtu has overhead. And they could be three tests, dGPU without Virtu, dGPU with Virtu D-mode, iGPU with Virtu I-mode.
Keiyakusha
13th July 2012, 04:34
I still not quite understand. lets say you open file.mkv with your measure_cmd_tool.exe that will use ffmpeg. you will set some mode whatever I or D for this tool in virtu. But they will never request any GPU-related stuff so virtu won't do anything...
JohnPeterson
13th July 2012, 04:40
It's expected to do practically nothing. But it doesn't do literally nothing as Virtu MVP displays the In-Game Icon, showing that it intercepts the EVR.
Keiyakusha
13th July 2012, 04:48
But you see, if you run player under virtu, not measure tool -that's different and complicated matter. Player have renderer which works with GPU. Someone with better understanding of how virtu works internally maybe can point some way to test overheads and stuff but I expect quite an overhead. If you set player in I mode you make it run on another GPU but in the same time you want to see video on main GPU (the one which is connected to display), so some process should transfer data so in can be put on the screen. Also this is may be the cause of slow seeking.
You probably can just connect display to Intel, measure QS performance, then connect display to DiscreteGPU, measure QS performance with Virtu. And you can use GraphStudio to measure it (or maybe just run in player? depends on what you actually want) just make sure you select some and same renderer in both cases. That won't do what you want?
JohnPeterson
13th July 2012, 04:53
You probably can just connect display to Intel, measure QS performance, then connect display to DiscreteGPU, measure QS performance with Virtu.?That's also interesting. I find all tests that you have mentioned interesting.
JohnPeterson
13th July 2012, 05:04
Not sure about CPU load but today decoding doesn't load cpu much anyway so using such things like Virtu only for that is an overkill imho.I agree and I would like to ask again for a comment on the question "What about QSV encoding through ff_vfw.dll?" in post 1094 (http://forum.doom9.org/showthread.php?p=1570894#post1570894). Encoding h264 is five times as demanding as decoding h264 and that makes QSV interesting. Currently there is a lack of availability of QSV encoding libraries with the result that popular encoding software such as VLC and XSplit is lacking a QSV encoding option.
nevcairiel
13th July 2012, 06:58
I think Eric has already commented that he has no time/plans for encode support at this time.
egur
13th July 2012, 10:33
For example post 302 (http://forum.doom9.org/showthread.php?p=1546599#post1546599) gives instructions about Virtu settings. What is not mentioned is if the media player (mpc-hc.exe in my test) should "Work in D-mode" or "Work in I-mode" in Virtu MVP. I'm guessing I-mode to present the iGPU to the application when it asks for a GPU?
The Virtu MVP Installation Guide (http://download.asrock.com/manual/virtu/Z77%20Pro3/English.pdf) is ambiguous about this setting, "Select “Work in D-mode” or “Work in I-mode” according to your needs." The apparent ambiguity may be because the answer is simple, "Work in D-mode" presents the dGPU to the application and "Work in I-mode" present the iGPU to the application. (It's less ambiguous about which DVI slot to use, "We recommend using d-Mode [connect display to dGPU] for better 3D performance", and that is what I do.)
Both "Work in D-mode" and "Work in I-mode" display the Virtu MVP logo in the rendering window. The earlier option gives the ffdshow.ax Info "Decoder: libavcodec h264" and the later option "Decoder: Intel® QuickSync" which is expected if the setting does what I've written above that I guess it does.
The CPU/GPU usage for mpc-hc.exe (from ProcessHacker.exe) is 5%/6% in both cases. Why is the CPU usage not closer to 0 when decoding through QSV? When decoding through msmpeg2vdec.dll and dxva2.dll through iGPU/dGPU the CPU usage is around 1.00%/0.75% and GPU usage around 5%/3%. The sample is 1080p x264.
Thanks!
Virtu MVP 2.1.114.22585
AMD Catalyst 12.6
Intel HD Graphics driver 8.15.10.2696 2012-03-19
MPC-HC 1.6.1.4087
ffdshow 4466 2012-07-02
Process Hacker 2.27-4965 (GPU usage from Node 0 of 0-9)
Windows 6.1.7601 x64
Asus P8Z77-M Pro
Intel i7-3770K
AMD Radeon 6870
QuickSync will work if it sees an Intel GPU.
With Virtu you have 2 options:
D-mode - screen connected to dGPU (Nvidia/AMD). Must add player/application to Virtu's application list so QS will see the active GPU as Intel.
I-mode - screen connected to motherboard (iGPU). Must NOT add player to Virtu's application list as the iGPU is the active GPU.
Regarding performance. Lower bitrate clips will be faster in SW due to lower memory traffic. Should check CPU utilization of player and not the entire system. Other running apps (e.g. browsers) can lower performance a little (will not make viewing unwatchable).
Power aware users should also know that the dGPU can take a lot more power than the CPU or the iGPU, so looking at the CPU utilization alone is not a good way to measure power usage.
For the record, I have no plans to support encoding in the near future.
Keiyakusha
13th July 2012, 15:33
D-mode - screen connected to dGPU (Nvidia/AMD). Must add player/application to Virtu's application list so QS will see the active GPU as Intel.
I-mode - screen connected to motherboard (iGPU). Must NOT add player to Virtu's application list as the iGPU is the active GPU.
I think this is not what he asks. If you have display connected to Nvidia/AMD, you have to add player to Virtu and select I-mode (http://i.imgur.com/Uj0VI.png).
You can apply either mode regardless of how display is connected. If we select D-mode instead, QS won't be available because this mode just assigns selected application to be processed by selected GPU.
While we at it, am I right that "H" stands for HyperFormance? Any benefits/drawbacks of using it? (I can't make that column wider to see what this "H" actually is :D). What about Virtual Vsync?
JohnPeterson
13th July 2012, 18:54
I think this is not what he asks. If you have display connected to Nvidia/AMD, you have to add player to Virtu and select I-mode (http://i.imgur.com/Uj0VI.png).Thank you for pointing that out. To avoid confusion it might be better to say "connect display to iGPU/dGPU" instead of "using i-Mode/d-Mode" if there's a chance that it's confused with the Virtu MVP setting.
While we at it, am I right that "H" stands for HyperFormance?Yes.
(I can't make that column wider to see what this "H" actually is :D).Me neither, the column widths are locked in Virtu MVP -> Applications.
Any benefits/drawbacks of using it?No benefit for video playback, so it's best to disable it to avoid unintended effects.
What about Virtual Vsync?No benefit over regular vsync for video playback.
Regarding what HyperFormance and Virtual Vsync does in detail I've made a post (http://forums.anandtech.com/showthread.php?p=33675891#post33675891) about that that I believe is helpful.
egur
14th July 2012, 09:16
Sorry, I didn't test with Virtu MVP. My reports so far were relevant to Lucid Virtu (not MVP).
With MVP you should assign the players to I-mode.
I'll try to get a copy soon and test myself if things are working well.
Note that with Virtu it's either working with the iGPU or the dGPU. No hybrid solutions - can't have the decoder use QS and the renderer use the dGPU (e.g. for best MadVR experience).
Maybe Virtu should add a mode were both cards are enumerated in D3D9 to allow this flow. I'll try to contact them.
CruNcher
15th July 2012, 14:05
Sorry, I didn't test with Virtu MVP. My reports so far were relevant to Lucid Virtu (not MVP).
With MVP you should assign the players to I-mode.
I'll try to get a copy soon and test myself if things are working well.
Note that with Virtu it's either working with the iGPU or the dGPU. No hybrid solutions - can't have the decoder use QS and the renderer use the dGPU (e.g. for best MadVR experience).
Maybe Virtu should add a mode were both cards are enumerated in D3D9 to allow this flow. I'll try to contact them.
That would be awesome though in the case above i would wonder who would prefer MadVR above your Scaling (Performance/Quality/Power) ;)
egur
15th July 2012, 14:08
That would be awesome though in the case above i would wonder who would prefer MadVR above your Scaling (Performance/Quality/Power) ;)
The best would be MadVR with SNB/IVB scaler and not rely on EVR. I assume that EVR stayed the same in Win8.
vBulletin® v3.8.11, Copyright ©2000-2025, vBulletin Solutions Inc.