madVR - high quality video renderer (GPU assisted)

[madshi]

What's up with 1440x1080 HDTV files like this (https://hotfile.com/dl/185596632/ddef693/ayaka_MSSL12.ts.html)? With Jinc3+AR image upscaling algorithm (and Bicubic75+AR chroma upscaling), the rendering time is

- 1440x1080 --> 1920x1080: ~17.3ms
- 1440x1080 --> 1918x1079 (or any similar resolution such as 1900x1069 [1% zoom out]): ~10.4ms

I haven't seen such a drastic reduction of the rendering time by a slight change of resolution with any other file. A10-5800K+DDR3-2400+1080MHz iGPU.
The reason is that Jinc currently only works for *up*scaling but not for *down*scaling. Furthermore Jinc is a 2D operation, meaning you can't handle X and Y scaling separately. When upscaling 1440x1080 to 1920x1080 Jinc can be used. However, when doing 1440x1080 to 1918x1079 X requires upscaling while Y requires downscaling. Since Jinc does not support downscaling, it must be totally disabled in this situation. That's why the rendering times decrease because Jinc is not used, anymore...

By the way, due to the way LCDs work (they don't flicker like CRTs or film projectors do) and the way our eyes work (persistence of vision), shouldn't madVR smooth motion on 24p/60Hz brings LCDs closer to CRTs in terms of smoothness than native refresh rate (24p/24Hz or multiple) and no smooth motion? In other words, because the blended frames generated by madVR look close to the frames our brains "invent" between refreshes when looking at a CRT, I would expect smooth motion on a 60 Hz LCD to give superior results than native refresh rate on the same LCD. Does that makes sense?
I don't think our brain invents pictures. My personal opinion is that 24p/60Hz with smootion motion FRC turned on should ideally look nearly as good as 24p/24Hz, if all goes well, but it shouldn't look better. If it does look better on your display, then I think your display likely can't do 24Hz properly.

Maybe a good idea would be for us to put feature requests in the bug tracker, so that they can just sit there for some (possibly long) amount of time until you decide to consider them?
No. I don't want to be bothered with feature requests *at all* for now. There are already too many things on my to do list, and many of them are quite important. More important IMHO than 99.9% of the feature requests that are often posted here. So I'd rather ignore the "noise" of feature requests for a while...

Yes I am using overlay. Looks like the backbuffer queue is empty. It alternates between 0-8/8 and 7-8/8. The other queues never go to zero. On videos with no problem, backbuffer q is steady at 7-8/8.
Not sure why that happens. Is it possible that you have some browser running in the background with GPU acceleration enabled? That might explain the problem. You could try playing with the flush settings, but it might not help if there's some other software using the GPU behind madVR's back...

[truexfan81]

The reason is that Jinc currently only works for *up*scaling but not for *down*scaling. Furthermore Jinc is a 2D operation, meaning you can't handle X and Y scaling separately. When upscaling 1440x1080 to 1920x1080 Jinc can be used. However, when doing 1440x1080 to 1918x1079 X requires upscaling while Y requires downscaling. Since Jinc does not support downscaling, it must be totally disabled in this situation. That's why the rendering times decrease because Jinc is not used, anymore...

in that case what scaler is used? just curious

[Vyral]

BT.709 shares the same primaries as sRGB, which are needed for accurate color reproduction. If you don´t have the option/don´t want to calibrate your monitor and go with the sRGB mode that is implemented, you can enable "this display is already calibrated" under your monitor´s "calibration" tab setting in madVR and set "the display is calibrated to the following primaries / gamut:" to BT.709. That way, the primaries should match more closely, which should give you more accurate color reproduction. Also, choose "pure power curve" and "2.20" under the "the display is calibrated to the following transfer function / gamma:" option.

After that, you can also check with test patterns from e.x. AVS HD within madVR if your black levels are as they should be. If you need an adjustment you currently can either adjust gamma ("enable gamma processing" and set the target gamma" a bit (lower value = brighter, higher value = darker) or use the brightness slider under the "color & gamma" tab. You should stay away from the "saturation", "contrast" and "hue" slider if possible.

That´s as far as you´re able to go without actually doing any calibration yourself. Depending on the quality and native gamma of your panel and the careness of the implementation of the sRGB mode on your monitor, the results can vary though. It should however look a lot better than non-managed.

Note that you won´t see any difference when just playing with the calibration values themselves. They are however important so that madVR "knows" your settings for appropriate conversions to take place.

Thanks for the explanation. I also have a samsung monitor with sRGB. I'll try this settings later.

[toniash]

Well once in a while(like every 30/60 secs), my judder tests in mVR tend to move ever so slightly too fast.....hence ruining smoothness. That's usually when they reach the far right side of the screen, and often when Reclock's VSYNC indicator(spying on what mVR does :sly:) isn't on the top of the screen either.


:thanks:

I think you have to disable Vsync correction in ReClock so it doesn't fight against Madvr Vsync and if you disable it you don't see ReClock's Vsync indicator

[leeperry]

Here are two samples I´ve found that look perfect with smooth motion:
http://www.mediafire.com/?5xccccrs7109mjn
http://www.mediafire.com/?1zos93buokb981r
Indeed! No ghosting whatsoever on my CRT in 89.91Hz, I only wish that everything looked this good :(
I think you have to disable Vsync correction in ReClock so it doesn't fight against Madvr Vsync and if you disable it you don't see ReClock's Vsync indicator
Yep, I shall try with Reclock disabled I guess...but I don't have VSYNC correction enabled in Reclock, but Reclock is a dirty hack at heart.

[Reino]

I have just installed madVR for the first time, so I'm totally new to this, but I'm facing some problems:

MPC-BE_______________MPC-HC
http://www.ld-host.de/uploads/thumbnails/4050d9b6dad65e773250362dff40d861.png (http://www.ld-host.de/uploads/images/4050d9b6dad65e773250362dff40d861.png)__http://www.ld-host.de/uploads/thumbnails/29e2964105d5f8799e713e1507dfd5cb.png (http://www.ld-host.de/uploads/images/29e2964105d5f8799e713e1507dfd5cb.png)
In both cases LAV Splitter Source and MPC-VD (FFmpeg) are used together with madVR at default settings. In MPC-BE everything seems fine, but obviously in MPC-HC there's something seriously wrong 'somewhere'.
This brings me to my next question: How come MPC-VD (DXVA) won't connect to madVR? It always falls back to "Video Renderer".

[madshi]

in that case what scaler is used? just curious
IIRC Lanczos for upscaling and whatever scaler you specified in the settings for downscaling.

In both cases LAV Splitter Source and MPC-VD (FFmpeg) are used together with madVR at default settings. In MPC-BE everything seems fine, but obviously in MPC-HC there's something seriously wrong 'somewhere'.

Not sure what's going on there. My first guess would be that there's a bug in the MPC-HC decoder. These days most people don't use that decoder, anymore, anyway. Since you're already using LAV Splitter, why not also using LAV Video Decoder?

This brings me to my next question: How come MPC-VD (DXVA) won't connect to madVR? It always falls back to "Video Renderer".
Good question, I don't know. Could be that the decoder only connects to certain known renderers. Could be that the decoder requires a specific renderer behaviour which madVR might not fulfill. Could be a bug in the decoder or in madVR. It's hard to say without analyzing it in detail. Again I'd recommend to use LAV Video Decoder.

[Reino]

I can't use LAV VD for DXVA, because I'm on WinXP.

[madshi]

Ah! madVR only supports DXVA2, just like EVR, so that might be the cause of the issue? Is your decoder DXVA1 or DXVA2?

[Reino]

That explains it. Too bad, yet another piece of software I can't use :(.
Afaik DXVA2 isn't available on WinXP. MPC VD (DXVA) here is always DXVA1, yes.

[DragonQ]

Yeah, damn those developers ignoring a 12 year old OS! ;)

[Niyawa]

BT.709 shares the same primaries as sRGB, which are needed for accurate color reproduction. If you don´t have the option/don´t want to calibrate your monitor and go with the sRGB mode that is implemented, you can enable "this display is already calibrated" under your monitor´s "calibration" tab setting in madVR and set "the display is calibrated to the following primaries / gamut:" to BT.709. That way, the primaries should match more closely, which should give you more accurate color reproduction. Also, choose "pure power curve" and "2.20" under the "the display is calibrated to the following transfer function / gamma:" option.

After that, you can also check with test patterns from e.x. AVS HD within madVR if your black levels are as they should be. If you need an adjustment you currently can either adjust gamma ("enable gamma processing" and set the target gamma" a bit (lower value = brighter, higher value = darker) or use the brightness slider under the "color & gamma" tab. You should stay away from the "saturation", "contrast" and "hue" slider if possible.

That´s as far as you´re able to go without actually doing any calibration yourself. Depending on the quality and native gamma of your panel and the careness of the implementation of the sRGB mode on your monitor, the results can vary though. It should however look a lot better than non-managed.

Note that you won´t see any difference when just playing with the calibration values themselves. They are however important so that madVR "knows" your settings for appropriate conversions to take place.
Thanks! I'm going to do that and see how that works.

Edit: Okay. I did what you told me but I really didn't notice any difference in color (as expected). In fact, if I make a trade between enable and disable calibration nothing changes. The only thing that made the video a little more darker was gamma processing with "BT.709/601" but you said that "pure power curve" is the one to go, so I'm with that.

[Qotscha]

A little question. Have I understood correctly that "the display is calibrated to the following transfer function / gamma:" setting has no effect on anything if gamma processing is disabled?

[e-t172]

I don't think our brain invents pictures. My personal opinion is that 24p/60Hz with smootion motion FRC turned on should ideally look nearly as good as 24p/24Hz, if all goes well, but it shouldn't look better. If it does look better on your display, then I think your display likely can't do 24Hz properly.

I agree that it might just be that my display has poor 24p support. I recently ordered a new colorimeter (X-Rite i1 Display Pro), and from what I've read (http://www.argyllcms.com/doc/instruments.html#refreshmeasurement) it is capable of measuring refresh rate down to 0.05 Hz precision. This should remove this unknown from the equation.

I'm wondering why you seem so convinced that FRC 24p@60Hz will never look better than native 24p@24Hz. Keep in mind that 24p@24Hz on a LCD is nowhere near as smooth as a CRT at 24p@48Hz or 24p@72Hz, or a traditional film projector running at double or triple shutter speed. It is plausible that FRC is better at approximating the perceptual effect of the flicker/shutter of a CRT/projector, compared to just using native refresh rates. I'm not saying that's true - we don't have enough data to draw any conclusion yet - but I don't think it's as clear cut as you seem to think. I think we need more feedback on this, especially from people with 24p capable screens so they can compare native 24p with FRC 24p@60Hz. If you'd like to post feedback, please mention the precise model of your display so we can spot patterns (such as correlation with LCD pixel response time and overdrive).

[iSunrise]

A little question. Have I understood correctly that "the display is calibrated to the following transfer function / gamma:" setting has no effect on anything if gamma processing is disabled?
Yes, that´s correct. madVR currently only uses it to calculate the target gamma if you´re doing gamma processing.

I agree that it might just be that my display has poor 24p support. I recently ordered a new colorimeter (X-Rite i1 Display Pro), and from what I've read (http://www.argyllcms.com/doc/instruments.html#refreshmeasurement) it is capable of measuring refresh rate down to 0.05 Hz precision. This should remove this unknown from the equation.
Nice, it would be great if you could give me some feedback on it, since I also wanted to order the same probe, because supposedly it´s also a lot faster and a lot more gamma accurate than my current DTP94B. Also, since you also have an H-IPS results should be very comparable. Currently I´m not so sure if spending another 175 EUR is worth it. Thanks in advance!

[secvensor]

"Disable/Enable" ReClock botton please in menu!

[turbojet]

It's good to see frc works well with ips panels, especially since they are getting cheaper and more mainstream. I was messing around with overdrive and found out that turning it to minimum reduced the ghosting with frc, it was on default 3/5, turning it up increased ghosting with frc. Might be helpful to someone else.

With frc enabled, multiple videos play with out of order frames. If frc is disabled on one of the players the frames are in order but the backbuffers of both sit at 0 causing dropped frames. Is this a bug or a limitation?

[e-t172]

It's good to see frc works well with ips panels, especially since they are getting cheaper and more mainstream. I was messing around with overdrive and found out that turning it to minimum reduced the ghosting with frc, it was on default 3/5, turning it up increased ghosting with frc. Might be helpful to someone else.

It heavily suspect that RTC (Response Time Compensation) overshoot might be the direct cause of some reports of FRC ghosting. Indeed, without FRC you would only see the overshoot 24 times per second when the frame changes, and the duration of the overshoot is small compared to the length of a frame. However, with FRC it would overshoot 60 times per second, which would most likely register as flicker at the edge of moving objects.

As a matter of fact, RTC overshoot on my U3014 is quite bad according to reviews (http://www.tftcentral.co.uk/reviews/content/dell_u3014.htm#gaming), and I do in fact see flicker when dark objects move on a bright background using FRC 24p@60Hz, compared to 24p@24Hz. Nevertheless, despite this, FRC 24p@60Hz still looks globally better than 24p@24Hz on my monitor.

It would be very interesting to compare FRC 24p@60Hz on a responsive monitor with finely tuned RTC (e.g. gaming monitor) on one side, and 24p@24Hz on a typical LCD TV on the other side. I bet the result would be very interesting.

[turbojet]

Probably is the overshoot mostly responsible. On 2 crt tv's frc works fine, no ghosting, but there you have really fast response without overdrive trickery but leeperry writes his crt's have ghosting with frc.

madshi: Is there a chance for a kb shortcut for toggle overlay and toggle frc for only on\off? I see there's enable and disable frc but that's more tedious than it needs to be, I vaguely remember reading something about this earlier.

e-t172: concerning the display issues at native refresh rates are you sure the monitor is really what it's changing to? When I set 72hz custom resolution there's judder, madvr shows 72hz but reclock shows 60hz. madvr refuses to change to it.

[iSunrise]

madshi: Is there a chance for a kb shortcut for toggle overlay and toggle frc for only on\off? I see there's enable and disable frc but that's more tedious than it needs to be, I vaguely remember reading something about this earlier.
Yes, you read about it before. I requested the toggle for FRC already, but madshi said that some people requested seperate controls and some wanted a toggle, so he wasn´t sold on the idea.

IMHO, a toggle should be for fast access in on/off or true/false cases, too. Seperate controls make a lot more sense when you need to go up as well as down, without having to hammer your keyboard with a toggle, because with a toggle you would (in the worst case) need to go all the way around again if you only wanted to go back/down again. But ultimately it´s madshi´s decision and I respect that.

[e-t172]

e-t172: concerning the display issues at native refresh rates are you sure the monitor is really what it's changing to? When I set 72hz custom resolution there's judder, madvr shows 72hz but reclock shows 60hz. madvr refuses to change to it.

The display is definitely being fed 24Hz, it even shows 24Hz in the OSD. I'm not 100% sure it's not "cheating" (internal 3:2 pulldown) however, I'll confirm that as soon as I get my colorimeter which should be able to measure the actual refresh rate.

[truexfan81]

@madshi are you aware of mpc-hc having a memory leak when using madvr? for example today i started a video, paused it, looked at task manager mpc-hc was using 150MB of ram, when i got home from work it was using almost a gig. this does not happen when using evr-cp

[pie1394]

It heavily suspect that RTC (Response Time Compensation) overshoot might be the direct cause of some reports of FRC ghosting. Indeed, without FRC you would only see the overshoot 24 times per second when the frame changes, and the duration of the overshoot is small compared to the length of a frame. However, with FRC it would overshoot 60 times per second, which would most likely register as flicker at the edge of moving objects.

As a matter of fact, RTC overshoot on my U3014 is quite bad according to reviews (http://www.tftcentral.co.uk/reviews/content/dell_u3014.htm#gaming), and I do in fact see flicker when dark objects move on a bright background using FRC 24p@60Hz, compared to 24p@24Hz. Nevertheless, despite this, FRC 24p@60Hz still looks globally better than 24p@24Hz on my monitor.

It would be very interesting to compare FRC 24p@60Hz on a responsive monitor with finely tuned RTC (e.g. gaming monitor) on one side, and 24p@24Hz on a typical LCD TV on the other side. I bet the result would be very interesting.

Today most LCD panels are utilized with FRC natively + dithering, especially on 10-bit IPS / VA-type and 8-bit TN / e-IPS / c-PVA type panels. In addition the G-to-G time is still mini-second scale even the Over-drive is engaged. For some people with good eyes and dynamic vision, they can see the unstable color change on quick motion scenes --- if no very quick black image insertion is added during the crystal cell rotating phase.

My PC's monitor is U2412M, which uses 8ms LG e-IPS 8-bit (6-bit native + A-FRC). Since it does not have the scanning back-lit, the motion resolution is quite bad --- even madVR FRC is activated for 24fps @ 60Hz.

The high-end LCD TV models like the Sony 65HX92x / 65HX950 have some designs to improve the motion resolution. These models are installed with CMO/Innolux 64.5" 10-bit 240/200 Hz driving S-MVA panel (8-bit native + A-FRC). The motionflow options "Clear" , "Clear+", "Impulse" perform different high-speed partial black-bar insertion by direct back-lit LED array up to 960 fps speed for 24/60Hz modes and up to 800 fps for 50Hz modes.

The "Impulse" option on HX950 is just to emulate CRT's display behavior. As I have heard, scanning LED back-lit are turned off on 75% time per second with this mode. So it creates even dim and somewhat CRT-alike flicking effects. Yet it is reported the best option for high-speed FPS gaming due to minimum persistence vision like CRT/PDP.

The option "Clear+" is observed somewhat dimmer than "Clear" but indeed even better motion resolution feeling, just much similar to my Hitachi PDP.

[Asmodian]

Okay. I did what you told me but I really didn't notice any difference in color (as expected). In fact, if I make a trade between enable and disable calibration nothing changes. The only thing that made the video a little more darker was gamma processing with "BT.709/601" but you said that "pure power curve" is the one to go, so I'm with that.

Remember that when playing BT.709 content on a sRGB display you shouldn't notice any change with calibration enabled or disabled (BT.709 = sRGB, ignoring odd linear spots in the gamma curve) but for BT.601 content the colors will look better (correct) with calibration enabled.

[mindbomb]

so, if you are using smooth motion, ideally the render time has to be below the vsync interval?
because vsync interval is 1/refresh rate, and with frc, refresh rate=frame rate?

[futurex]

Apologies for asking what is probably a dumb question, but I have been unable to find an answer through searching:

Does madVR have any picture quality benefits (other than the amazing smoothmotion) over, say, EVR if the content is 1080p on a 1080p display? Or say 1920x800 video on a 1080p display?

Is any resizing done in the latter situation? What if it was 1918x1080?

[Niyawa]

Yes, you read about it before. I requested the toggle for FRC already, but madshi said that some people requested seperate controls and some wanted a toggle, so he wasn´t sold on the idea.
I also respect madshi's decision but I have no idea how using smooth motion with two separate controls would be any better. Someone can enlighten me here? At least from my perspective, seems way more intuitive and fast having one combination of buttons to set it on/off with ease.

Remember that when playing BT.709 content on a sRGB display you shouldn't notice any change with calibration enabled or disabled (BT.709 = sRGB, ignoring odd linear spots in the gamma curve) but for BT.601 content the colors will look better (correct) with calibration enabled.
Strange, I just tested with a video that has matrix BT.601 but no color changes either. Maybe I'm doing something wrong or I'm missing a detail? I have "BT.709/pure power curve/2.20" in calibration window, but I didn't mess with "enable gamma processing".

[Asmodian]

Does madVR have any picture quality benefits (other than the amazing smoothmotion) over, say, EVR if the content is 1080p on a 1080p display? Or say 1920x800 video on a 1080p display?

The color information of most video (a bluray for example) is 1/2 the resolution of the black and white information.

So the Y channel is 1920x1080 and the U and V channels are 960x540. This means the U and V needs to be resized to match the Y so the chroma resize options are used even when watching 1080p on a native 1080p display. This new set of values then needs to be converted to the R, G, and B values used by the computer monitor. MadVR does this at the max quality too, making no sacrifices for performance. It actually does have options to sacrifice quality for performance but these are not set by default.

Resize is used in all your examples and so is the conversion to RGB, both of which are higher quality in MadVR vs EVR.

Strange, I just tested with a video that has matrix BT.601 but no color changes either. Maybe I'm doing something wrong or I'm missing a detail? I have "BT.709/pure power curve/2.20" in calibration window, but I didn't mess with "enable gamma processing".

Don't use anime when checking this, I find it amazingly hard to notice the change with anime but it is pretty obvious with color bars or a "real life" source. You don't need to mess with gamma processing.

[Niyawa]

Don't use anime when checking this, I find it amazingly hard to notice the change with anime but it is pretty obvious with color bars or a "real life" source. You don't need to mess with gamma processing.
I see, I'll test this later and give you my results, does anyone have any sample with a matrix of BT.601 there? I'll look for one but I'm not sure if I'll find it today.

[Vyral]

I have "BT.709/pure power curve/2.20" in calibration window, but I didn't mess with "enable gamma processing".
If I have "BT.709/pure power curve/2.20" in Calibration window, it's better to disable "enable gamma processing" in Color & gamma window :confused:
I also enable "disable gpu gamma ramp" option in Calibration window since I calibrate my monitor with sRGB.

Actually, I also search for the best settings possible to watch animes and movies.

[DragonQ]

You can't simply compare it to "EVR" since EVR can have different upscaling settings. Bicubic in MPC-HC looks pretty good, bilinear in MediaPortal looks like arse.

[Devrim]

I hope madshi will implement a way to dedicate a gfx card to use with madvr, for now I have switched to EVR due to the fact my second screen is connected to Intel HD and it is useless due to huge amount the frame drops. (My first screen is connected to my 680gtx and works flawless :<)

[nevcairiel]

I hope madshi will implement a way to dedicate a gfx card to use with madvr

You have to use the card that the screen is connected to, thats just how Direct3D works.
Anything else would have a very high overhead and most likely not be worth the effort.

[jkauff]

You have to use the card that the screen is connected to, thats just how Direct3D works.
Anything else would have a very high overhead and most likely not be worth the effort.
The iGPU and dGPU can be used together if your BIOS supports it. Eric Gur posted an out-of-the-box method, but I've found I have to use Virtu MVP to make it work. LAV Video is using the HD4000 with Eric's code, but madVR is using my GTX 660.

I don't need deinterlacing very often, but if nevcariel could enable the HD 4000 hw deinterlacing, I'd have a perfect system.

[DragonQ]

I hope madshi will implement a way to dedicate a gfx card to use with madvr, for now I have switched to EVR due to the fact my second screen is connected to Intel HD and it is useless due to huge amount the frame drops. (My first screen is connected to my 680gtx and works flawless :<)
What decoder are you using? It's possible (although not likely) that if you use software decoding or CUDA, then your Intel IGP will have a bit more processing power free for MadVR.

[kasper93]

I get black image when saving through mpc-hc... It could be driver issues, but could anyone check? I have AMD HD5870.

[cyberbeing]

I get black image when saving through mpc-hc... It could be driver issues, but could anyone check? I have AMD HD5870.

Known issue (http://bugs.madshi.net/view.php?id=19) when you have Smooth Motion enabled in madVR.

[kasper93]

Thanks. Now I recall that I read this, but forget ;p

[Devrim]

What decoder are you using? It's possible (although not likely) that if you use software decoding or CUDA, then your Intel IGP will have a bit more processing power free for MadVR.

Nah, I use CUDA but the Intel chip is just too slow.

[jkauff]

Nah, I use CUDA but the Intel chip is just too slow.
Didn't I read somewhere in this thread that madshi uses an HD4000 without problems? That is the one you're using, right? Do you have all the iGPU tweaks enabled in your BIOS?

[Devrim]

Didn't I read somewhere in this thread that madshi uses an HD4000 without problems? That is the one you're using, right? Do you have all the iGPU tweaks enabled in your BIOS?



The GA-Z77X-UD3H seems to have a HD3000. I'll check later today if I have the iGPU tweaks enabled

[jkauff]

The GA-Z77X-UD3H seems to have a HD3000. I'll check later today if I have the iGPU tweaks enabled
That would explain the difference. I doubt the HD3000 is powerful enough to handle the settings you want to use. The 3rd gen HD4000 has been reported as 2.5x more powerful than the 2nd gen chip.

[obieobieobie]

The GA-Z77X-UD3H seems to have a HD3000. I'll check later today if I have the iGPU tweaks enabled

GA-Z77X-UD3H supports new Ivy Bridge CPU with HD4000 GPU. GPU is on the CPU, not on mobo.

[Devrim]

GA-Z77X-UD3H supports new Ivy Bridge CPU with HD4000 GPU. GPU is on the CPU, not on mobo.

You seem to be right

http://kthnxbai.info/PicAyzo/de82a1.png

The question now is, how do I tweak it...

[DragonQ]

My HD4000 is not sufficient for the best settings in MadVR (Jinc3 + AR) for all content. There are a few versions of it though with slightly different clock speeds and mine is the slowest, IIRC.

[Niyawa]

My HD4000 is not sufficient for the best settings in MadVR (Jinc3 + AR) for all content. There are a few versions of it though with slightly different clock speeds and mine is the slowest, IIRC.
There are some people who claim a HD 3000 can do up to Jinc 3 + AR (one of the users of my guide said so at least), so I guess even though the 4000 should be more powerful, there are still fragments between their speed. I'm pretty sure if you try to optimize your settings you might get somewhere. In my case, by default madVR gives me about 10-12ms of rendering. After some research and changes in the backbuffer, flush settings and queue as well disabling "use a separate device" for smooth motion, my rendering time is about 0.10-0.16 depending on whether I'm playing in 8-bit or 10-bit.

Unfortunately I still can't play 1080p 60fps, because the movie frame interval is 16 ms, but my rendering goes to 18-20ms. Close at least.

[DragonQ]

An HD 3000 may well be able to do Jinc 3 + AR but not for everything. Some people consider a GPU capable of using an algorithm if it works for up to 30p content but I would only consider it capable if it could do up to 30i and 60p.

[nevcairiel]

In my case, by default madVR gives me about 10-12ms of rendering. After some research and changes in the backbuffer, flush settings and queue as well disabling "use a separate device" for smooth motion, my rendering time is about 0.10-0.16 depending on whether I'm playing in 8-bit or 10-bit.

Ah but you fooled yourself.
The rendering time can only be accurately measured when certain flush settings are active (i forgot which), so if you turn those off, the number goes down, but its not the truth.

[dansrfe]

How can we determine the most appropriate flush settings for exclusive and windowed mode for our hardware? My system has an i7 3770k and GTX 670 2GB, if anything can be concluded from that.

[Niyawa]

An HD 3000 may well be able to do Jinc 3 + AR but not for everything. Some people consider a GPU capable of using an algorithm if it works for up to 30p content but I would only consider it capable if it could do up to 30i and 60p.
I see, I don't watch broadcasts or anything of sort that would need 60p so I'm not particularly worried of not being able to play them.

Ah but you fooled yourself.
The rendering time can only be accurately measured when certain flush settings are active (i forgot which), so if you turn those off, the number goes down, but its not the truth.
I was aware of that other rendering stats, but I never had the will to change my current settings to see them again. It only shows when you enable "flush & wait loop/sleep" in "after last render step". So, my real rendering would be around 10 ms (which I consider to be the safe range for most things I watch).

I'm really not sure which one is safer to use, but I noticed flush for everything is what usually works best.

How can we determine the most appropriate flush settings for exclusive and windowed mode for our hardware? My system has an i7 3770k and GTX 670 2GB, if anything can be concluded from that.
You have to test it yourself. I believe that for powerful machines though, high queues and backbuffers with "don't flush" will use your GPU to it's full potential. Since I have an old Intel Graphics, I leave all of those at lowest they can be.