madVR - high quality video renderer (GPU assisted)

[aufkrawall]

Nope, simple D3D9 HLSL pixel shaders.
That's great! So now AMD users now have good alternative to NNEDI3, combined with SuperRes.


I don't know, maybe the DirectCompute compiler didn't optimize the code as well as the OpenCL compiler did? Or maybe I was too stupid to write well optimized DirectCompute code? I tried to directly convert the OpenCL kernel to DirectCompute, and while it produced correct image output, it was very slow. Could very well have been my fault, for all I know.
Well, someone else couldn't make it fast with DirectCompute neither (you don't want me to explain this more in detail :D ).

[XMonarchY]

I just compared the same clip in WMP vs. madVR and I have to say that without FineSharp or LumaSharpen madVR (best quality settings) does make the image so soft that some people may dislike it and prefer playback via WMP simply due to sharpness, especially if you sit close to your display. LumaSharpen changes that.

Have any tests shown whether LumaSharpen adds more ringing than FineSharp?

[iSunrise]

I will not reply to this post of yours, unless you reply to my earlier posts first. I've written detailed replies to most of your previous FineSharp LL related posts, and so far you've decided to not comment on any of that at all. I can only hope that you've simply missed my posts?
Yes, I missed it indeed. As I said, you are way too fast with changes, extremely hard to keep up.

To your questions:

1) All my examples are done in image enhancements, under the processing tab (so before upscaling). This is because all the algorithms will be applied before upscaling, which shows me the differences a lot more clearly.

2) Regarding the thinning under upscaling refinement, I agree, lower strengths are also advantageous here, I would say thinning should be between 0.020 and 0.035, not higher. I definitely had some strange artefacts appear with a setting of 0.100 on my first samples I posted, therefore I would not recommend them.

3) Thanks for fixing the bug so fast, really appreciated.

4) Regarding your question, which image looks subjectively better, it's pretty clear for me and I invested quite a lot of time to be sure. I think if you take a look at my enhanced screenshots, you will agree.

5) The brightness you see is exactly what a sharpener does if you use way too high strengths, that's why I was absolutely against too high values. Like I wrote before, a good sharpener enhances fine details and by looking at your shots, no LL does exactly represent what I would expect, instead of masking and darkening the result. A sharpener should in an optimal case never do anything else than to sharpen. Your shots all look more accurate from a sharpener point if view with no LL, as do the squirrel shots. The other two examples you provided (the dark ones) are all masking the weird blackness mask that the LL enabled finesharp introduces. This is not the case with the no LL finesharp. The no LL finesharp is a lot more accurate even at higher strengths, so if we might settle on values like 0.5, 1.0 and 2.0, then I think everyone should be equally happy. I prefer mild sharpening, while others will like a higher setting,

If you need further tests, I can do them, but I think when you look at the enhanced squirrel, you will see the heavy artefacting that I am speaking of.

[cyberscott]

http://madshi.net/madVR.zip

[code]madVR v0.88.12

* added workaround for one more cause of queues not filling in D3D11 FSE mode


madasihi,

My "present queue" fill beyond 4 now. I set the present queue to 12 and I'm getting 11/12 in DSD11 FSE 10 bit mode. First time since v088.8 :D :thanks:

[har3inger]

Super-xbr and some light superres (1 pass, .75 str, .3 sharp, .1, soft, .3 AA, 1.0 AR) works really quite well for 720p. The superres seems to help clean up some artifacts when stripes (like on skyscrapers) are upscaled by super-xbr.

Can't wait to test the version with madshi's AR filter.

[Anima123]

I doubt that SuperRes's sharpness enhance would be needed if Super-xbr used. Here's what I am using for 576p: 2pass, 0.65 str, 0.0 sharp, 0.2 soft, 0.25 AA, 0.75 AR.

Edit: With both sharpness and softness set to 0, it seems more passes won't hurt too much of the quality. I just tested with pass 8, and the quality didn't is quite good to my eyes.

[JarrettH]

So here comes an improved image comparison for super-xbr:

clown - downscaled with lanczos (?) - heavy ringing artifacts:
unscaled original (http://madVR.com/doom9/clown/clown.png) - - | - - super-xbr original AR (http://madVR.com/doom9/clown/clownSuperXBRstrictAR.png) - - | - - super-xbr no AR (http://madVR.com/doom9/clown/clownSuperXBRnoAR.png) - - | - - super-xbr madVR AR (http://madVR.com/doom9/clown/clownSuperXBR.png)

clown - downscaled with bilinear (?) - no ringing artifacts:
unscaled original (http://madVR.com/doom9/clown/clownBox.png) - - | - - super-xbr original AR (http://madVR.com/doom9/clown/clownBoxSuperXBRstrictAR.png) - - | - - super-xbr no AR (http://madVR.com/doom9/clown/clownBoxSuperXBRnoAR.png) - - | - - super-xbr madVR AR (http://madVR.com/doom9/clown/clownBoxSuperXBRselectiveAR.png)

"original AR": This is a very strict AR algorithm written by Hyllian. It removes almost all ringing that isn't in the source. Sounds good, but sometimes ringing is helpful!
"no AR": This is super-xbr without any AR. This adds noticeable ringing, of course.
"madVR AR": This is a selective AR algorithm which tries to surpress unwanted ringing, while keeping helpful ringing.

If you look at the 2nd set of images, you should see that both AR algorithms remove most of the ringing and that super-xbr itself doesn't really ring much at all if the source is clean. It *does* sharpen=increase ringing that is already in the source, though.

You can also directly compare Hyllian's fast and agressive AR algorithm to the (slower and more complicated) one madVR uses. Hyllian's algorithm is better for comic style video games, but I believe mine's better for photos and movies.

Thoughts?

The colour is juiced up in lanczos super-xbr madVR AR

http://madvr.com/doom9/clown/clownSuperXBR.png

[MS-DOS]

Hmm, found a bug on the image doubling page in the latest version: it shows chroma doubling as enabled for NNEDI3 even though it's actually disabled.

[Anime Viewer]

Interestingly, for upscaling refinement with a good image doubling algorithm (e.g. NNEDI3), I find that I like rather low strength, but higher thinning. E.g. I've tried strength 0.0 and thinning 0.35 and like it. But it's hard to say which is "better". It might really be a matter of taste. Unfortunately that's not going to help. I very very much want to reduce the number of options as much as possible.


I like the 0.0 strength and 0.035 (I'm guessing you meant 0.035 and not the 0.35 you typed as you can only go up to 0.27ish, and that setting produces a lot of jaggedness). I hadn't even contemplated 0.0 as a strength setting in my previous testing because I thought 0.0 would effectively be disabling FineSharp. Is that not the case? What about a 0.1 strength, does that produce anything unwanted in your tests? (In mine I don't see a difference in 0.0 and 0.1 strength, but that may be related to the source files I'm testing with...)

I think those settings work just as well when paired with super-xbr for image doubling.

NEDI was my previous image doubling choice (NNEDI3 was far to much of a resource waste and generated too high render stats for what it gives comapared to NEDI in my mind), but now I find I like the sharpness of the super-xbr better. On the 720p video I tested NEDI runs at ~11.5ms while super-xbr runs at ~15.7ms, and for 480p 6.4ms (NEDI) and 8.5ms (super-xbr).

[aufkrawall]

Seems like super-xbr looks nice for chroma scaling.
Jinc3AR:
http://abload.de/thumb/jinc3ar8gqs7.png (http://abload.de/image.php?img=jinc3ar8gqs7.png)

super-xbr:
http://abload.de/thumb/new52o6d.png (http://abload.de/image.php?img=new52o6d.png)

NNEDI3 256:
http://abload.de/thumb/nnedi3256ppqv4.png (http://abload.de/image.php?img=nnedi3256ppqv4.png)

Luma scaling was NNEDI 256 doubling for all three examples (and will be for the following if not stated otherwise).

Regarding sharpening (image enhancement):
FS seems to thicken and darken contoures, I don't like this artificial look for cartoons. Lumasharpen is brighter, but this can be reduced by lowering clamp value (e.g. to 0.02).
FS (1;0):
http://abload.de/thumb/fs2ypqa.png (http://abload.de/image.php?img=fs2ypqa.png)

LS (1;0.035;1):
http://abload.de/thumb/ls7cqhm.png (http://abload.de/image.php?img=ls7cqhm.png)

No sharpening:
http://abload.de/thumb/no3tpre.png (http://abload.de/image.php?img=no3tpre.png)

LS (0.8;0.02;1):
http://abload.de/thumb/lsnewghqaj.png (http://abload.de/image.php?img=lsnewghqaj.png)

Will talk about luma scaling in the next post.

[aufkrawall]

One other thing first:
Here you can also see how SuperRes for chroma vanishes some contoures.
super-xbr + SuperRes:
http://abload.de/thumb/newsuperresjxpnj.png (http://abload.de/image.php?img=newsuperresjxpnj.png)

NNEDI3 256:
http://abload.de/thumb/nnedi3256ppqv4.png (http://abload.de/image.php?img=nnedi3256ppqv4.png)

You can see some dark lines almost vanish compared to NNEDI3 256. I don't think this is desired, since NNEDI 256 is considered to be dam good with clear dark lines in simple structures.

Now luma:
NNEDI3 is still far superior for this strong cartoon resizing. However, super-xbr seems definitely better than NNEDI to me.

NNEDI:
http://abload.de/thumb/nnedi89qql.png (http://abload.de/image.php?img=nnedi89qql.png)

NNEDI3 256:
http://abload.de/thumb/nnedi3256syo4l.png (http://abload.de/image.php?img=nnedi3256syo4l.png)

super-xbr:
http://abload.de/thumb/super-xbrtaokn.png (http://abload.de/image.php?img=super-xbrtaokn.png)

super-xbr + SuperRes:
http://abload.de/thumb/super-xbrsuperresmgo59.png (http://abload.de/image.php?img=super-xbrsuperresmgo59.png)

SuperRes settings:
http://abload.de/thumb/superresn9q96.png (http://abload.de/image.php?img=superresn9q96.png)

The difference is very visible. But source's resolution is just 640x368, kinda extreme.
With 720p -> WQHD, the difference is almost neglectable.

NNEDI3 64:
http://abload.de/thumb/nnedi364m7ruy.png (http://abload.de/image.php?img=nnedi364m7ruy.png)

super-xbr + SuperRes:
http://abload.de/thumb/super-xbrsuperreshwppc.png (http://abload.de/image.php?img=super-xbrsuperreshwppc.png)

[JarrettH]

Bicubic75 AR chroma
Jinc3 AR luma
https://farm1.staticflickr.com/554/18629268240_e5d9662b77_o.png

super-xbr doubling
super-xbr chroma
Jinc3 AR luma
https://farm1.staticflickr.com/341/18630818659_90e2fce661_o.png

Didn't we figure out a long time ago that the chroma upscaling method isn't very important past Bicubic75? Cartoon examples really exaggerate things

[aufkrawall]

Forgot to say: FS' thinning is hardcore terrible for cartoons, it introduces extreme aliasing with contoures.

[FireFreak111]

88.12 has some serious improvements. Fullscreen exclusive times in D3D11 exclusive 8 bit has easily been reduced significantly (takes ~80% less time than before on Win 10, HDMI plasma), not sure why, but I can switch between FSE and fullscreen windowed super fast.

Build 10130 of Win 10 has stopped me from being able to use image doubling. Immediate crash with any algo. Hopefully next build it's not a problem. I can use Super-XBR for chroma now however, which works nicely. I didnt activate SuperRes for Chroma. I noticed there's no SuperRes default for Super-XBR doubling. Is there no need? Also, will there be defaults for Chroma?

I'm curious on whether NEDI or Super-XBR is better for chroma. I'll do some testing, but I wonder what others think, especially for animation.

[har3inger]

Aufkrawall, you've pointed out something I've also noticed with superchromares. Usually in lower quality sources (?), when you have white text on solid red or solid green backgrounds, such as on a street sign or news banner, there's a darkish outline around the white parts. Superchromares likes to attempt to erase these dark halos, but sometimes ends up turning the dark halos into oversaturated colored halos, and even introduce some possible chroma bleed.

This img from google images illustrates the halos I'm talking about.
https://cbschicago.files.wordpress.com/2013/03/k-bigpic.jpg
Notice how there's darkening around the letters of the word "DePAUL". These disappear and sometimes become bright red (or whatever the background color is) halos if you apply superchromares. I think this might be some sort of chroma bleed where the red is going into the letters. It can make the image look strange and IMO pretty ugly. I'd post a sample screenshot, but I lost the file where I first noticed this issue.

This street sign also illustrates the dark halos I'm talking about. Here, it's very obvious that the removal of those dark edges is desirable, and applying superchromares in these sorts of cases does work as intended.
http://i.walmartimages.com/i/p/02/34/56/78/95/0234567895517_500X500.jpg

In some other cases, thin red lines on black background will have very different saturation between superchromares and jinc3 ar, but it's harder to say what's supposed to be correct in those cases. Overall, Superchromares can look amazing in some isolated cases (solid red on white/black), but it does have these weird behaviors associated with it. Setting the anti-ringing to 1.00 seems to alleviate the color bleeding, but not the loss of the dark halos.

[James Freeman]

88.12 is completely unusable with my system (i7, gtx660), in D3D9 or D3D11; render & present are empty all the time in windowed fullscreen.
Back to 88.11 for now.
Strange. Can you please try to isolate what is causing the problem? So far nobody else has reported the problem. So it doesn't seem to be a general problem with v0.88.12. E.g. try to reset madVR settings to default. Is it only the render & present queues which are empty? Or also other queues?
It appears that my rendering time raised to 41ms thus the queues not filling up.
* I downclock my GPU to save power.
In version 88.11 the rendering was twice as fast, at about 20-25ms.
Nothing special, just Lanczos 3, Smooth Motion, Ordered Dithering.

[iSunrise]

Forgot to say: FS' thinning is hardcore terrible for cartoons, it introduces extreme aliasing with contoures.
Try FS in 0.88.11 and de-select LL. The heavy contouring is a side-effect of the LL finesharp, which is also very apparent in the tests I've done. This does not happen with no LL enabled. I already showed screenshots to madshi, hopefully he will listen.

[MistahBonzai]

Aufkrawall, you've pointed out something I've also noticed with superchromares. Usually in lower quality sources (?), when you have white text on solid red or solid green backgrounds, such as on a street sign or news banner, there's a darkish outline around the white parts. Superchromares likes to attempt to erase these dark halos, but sometimes ends up turning the dark halos into oversaturated colored halos, and even introduce some possible chroma bleed.

I've observed many of the video 'oddities' mentioned above while testing these new settings with video test patterns developed for use in calibration procedures. You can use chroma and luma resolution calibration patterns to get a better sense of how the settings affect 'pristine' video.

I thought there were suitable test video sequences in the MP4-2C HDTV Calibration Disc From the AVSForum however I just discovered that the 720p Chroma 4:2:0 and 4:4:4 resolution patterns I have been using aren't included - I must have picked them up elsewhere. Inanycase it shouldn't be that difficult to obtain suitable 720p resolution test sequences for upscaling if so inclined... You might be surprised by how some of the settings we are testing affect the video resolution under test conditions. That way you get a better idea of what to look for when testing on your video samples.

Edit: There are image samples in various resolutions of the Belle Nuit Montage at their web site: http://www.belle-nuit.com/test-chart

[James Freeman]

"original AR" by Hyllian, looks best to me in this image.
It retains the image properties without enhancing anything and remains faithful to the original, as it should (IMO).

Back to 88.11 for testing.
Finesharp:
LL over-enhances the edges and clips the shades = VERY BAD.
Thinning 0.020 as agreed, I see little difference.
Mode 3 as agreed.
IMO, Strength should stay a variable for different content (for now).

[ryrynz]

Double post.

[ryrynz]

Bicubic75 AR chroma
Jinc3 AR luma
https://farm1.staticflickr.com/554/18629268240_e5d9662b77_o.png

super-xbr doubling
super-xbr chroma
Jinc3 AR luma
https://farm1.staticflickr.com/341/18630818659_90e2fce661_o.png

Didn't we figure out a long time ago that the chroma upscaling method isn't very important past Bicubic75? Cartoon examples really exaggerate things


It doesn't "exaggerate things" it highlights things.

That frame you have screenshot there isn't a good test, there's almost nothing that any chroma resizer is going to make a shred of difference on.

There are many of us that use madVR for upscaling of lower resolution cartoon/animated content where chroma upscaling quality is of more obvious importance but it can still be hard to tell much of a difference in many scenes.

Bicubic 75 AR has been determined to be very good for it's performance penalty, but sometimes people want "better" results.

[iSunrise]

...Didn't we figure out a long time ago that the chroma upscaling method isn't very important past Bicubic75? Cartoon examples really exaggerate things
That's why madVR offers profiles and settings that can be tailored to your content and your setup. Not every content will behave and show the same, that's what makes madVR special, it can be specifically configured so that you can get most out of your sources.

On HQ/HD 4:2:0 mastered movies with a high bitrate the differences will be a lot less visible than on cartoon, game recordings or line charts or patterns. But they are just as valid examples and very useful to detect specific behaviours of algorithms madVR uses.

[madshi]

I just compared the same clip in WMP vs. madVR and I have to say that without FineSharp or LumaSharpen madVR (best quality settings) does make the image so soft that some people may dislike it and prefer playback via WMP simply due to sharpness, especially if you sit close to your display.
madVR does not make the image soft at all. I don't know what WMP does, if it's sharper than madVR then WMP probably uses some sort of sharpening.

Can't wait to test the version with madshi's AR filter.
It's already implemented in v0.88.12.

Hmm, found a bug on the image doubling page in the latest version: it shows chroma doubling as enabled for NNEDI3 even though it's actually disabled.
Will check.

I like the 0.0 strength and 0.035 (I'm guessing you meant 0.035 and not the 0.35 you typed as you can only go up to 0.27ish, and that setting produces a lot of jaggedness). I hadn't even contemplated 0.0 as a strength setting in my previous testing because I thought 0.0 would effectively be disabling FineSharp. Is that not the case? What about a 0.1 strength, does that produce anything unwanted in your tests? (In mine I don't see a difference in 0.0 and 0.1 strength, but that may be related to the source files I'm testing with...)

I think those settings work just as well when paired with super-xbr for image doubling.

NEDI was my previous image doubling choice (NNEDI3 was far to much of a resource waste and generated too high render stats for what it gives comapared to NEDI in my mind), but now I find I like the sharpness of the super-xbr better. On the 720p video I tested NEDI runs at ~11.5ms while super-xbr runs at ~15.7ms, and for 480p 6.4ms (NEDI) and 8.5ms (super-xbr).
I haven't fully studied yet how FineSharp works inside. But it seems to me that strength and thinning are mostly independent of each other, and control two different sharpening methods, or something like that.

88.12 has some serious improvements. Fullscreen exclusive times in D3D11 exclusive 8 bit has easily been reduced significantly (takes ~80% less time than before on Win 10, HDMI plasma), not sure why, but I can switch between FSE and fullscreen windowed super fast.

Build 10130 of Win 10 has stopped me from being able to use image doubling. Immediate crash with any algo. Hopefully next build it's not a problem. I can use Super-XBR for chroma now however, which works nicely. I didnt activate SuperRes for Chroma. I noticed there's no SuperRes default for Super-XBR doubling. Is there no need? Also, will there be defaults for Chroma?
Shiandow is working to further improve SuperRes atm, so I didn't bother creating new defaults for super-xbr yet.

It appears that my rendering time raised to 41ms thus the queues not filling up.
* I downclock my GPU to save power.
In version 88.11 the rendering was twice as fast, at about 20-25ms.
Nothing special, just Lanczos 3, Smooth Motion, Ordered Dithering.
That doesn't make a lot of sense. I haven't changed anything which would explain a performance difference. Are you sure the downclock works the same with v0.88.11 and v0.88.12? I'm rather thinking that maybe with one of those versions the clock of your GPU might be different or something. Nobody else has reported anything like this yet, either. So I think the problem is likely on your side somewhere. Sorry, I wish I could be more specific. But I don't have enough information to say anything more helpful...

"original AR" by Hyllian, looks best to me in this image.
It retains the image properties without enhancing anything and remains faithful to the original, as it should (IMO).
In which image? The clown image? I could pinpoint 10-20 image parts where Hyllian's AR results in artifacts compared to madVR's AR. On the other hand, madVR's AR in 10-20 image parts has left unwanted ringing in the image which Hyllian's AR has removed. But overall I strongly prefer madVR's AR, for the clown image at least. As I said, for cartoonish video games the situation is very different...

Seems like super-xbr looks nice for chroma scaling.

Regarding sharpening (image enhancement):
FS seems to thicken and darken contoures, I don't like this artificial look for cartoons. Lumasharpen is brighter, but this can be reduced by lowering clamp value (e.g. to 0.02).
I don't like Lumasharpen in your screenshots at all. Can you try the FineSharp strength vs. thinning parameters to check which of them (or both) are responsible for the "thicken & darken"? Also, maybe you could double check with v0.88.11 whether disabling linear light makes a difference for you?

Now luma:
NNEDI3 is still far superior for this strong cartoon resizing. However, super-xbr seems definitely better than NNEDI to me.
Agreed. Due to the way NNEDI3 works, it removes some of the ringing that is already in the source, while super-xbr instead sharpens/increases the ringing. I think this is one key factor why NNEDI3 looks better with your test video. Another reason is that NNEDI3 produces lines which are "tighter" (less bloated up) compared to super-xbr. The ringing problem might be fixable (at some point in the future) by running a de-ringing algorithm before upscaling it.

I'm not a fan of NEDI at all, at least not when using it "alone". In combination with SuperRes NEDI might work well, though, because SuperRes removes most of the ugly NEDI artifacts. I believe NEDI should not be used alone, but only in combination with SuperRes.

Forgot to say: FS' thinning is hardcore terrible for cartoons, it introduces extreme aliasing with contoures.
Could I have a sample (or two or three) which nicely show this problem? I've found that FineSharp's "repair" may have to be set to values higher than 1.0, if you increase the "thinning" higher than 0.19, in order to avoid aliasing problems. Maybe I will also have to improve the repair algorithm. Would be good to have some samples to play with for that purpose.

Yes, I missed it indeed. As I said, you are way too fast with changes, extremely hard to keep up.
Currently we have about 2 million options in the upscaling refinement page. I want most of them gone. So is it really too fast to remove an option when after a week's worth of testing *everybody* had the same opinion about that option?

As I wrote in the v0.88.12 release notes, at the moment when you voiced your concerns about FineSharp's linear light option, I had already removed the option from my sources. I only had the choice of either releasing v0.88.12 as it was, or delaying it a full week. Should I have delayed it - keeping super-xbr from all madVR users for a full week? I'm perfectly fine with further discussing the linear light option. I'm willing to revert my decision, if that's what seems the correct choice to me.

The reason I'm trying to make some reasonably fast decisions now is that I want to reduce the complexity of the testing/feedback cycle. The less options there are, the more precise the feedback will be. If you have to test 3 options for an algorithm instead of 2 options, it costs you much more time, and the feedback will be less precise. So that's why I thought it was a good idea to remove an option quickly where every user had the same preference, anyway.

1) All my examples are done in image enhancements, under the processing tab (so before upscaling). This is because all the algorithms will be applied before upscaling, which shows me the differences a lot more clearly.
Fair enough. That also explains your preference for lower sharpness settings, though. When applying sharpening before upscaling you always need lower sharpening strength compared to sharpening after upscaling.

2) Regarding the thinning under upscaling refinement, I agree, lower strengths are also advantageous here, I would say thinning should be between 0.020 and 0.035, not higher. I definitely had some strange artefacts appear with a setting of 0.100 on my first samples I posted, therefore I would not recommend them.
I wouldn't recommend 0.100, either. And maybe I wouldn't go very high in the image enhancement settings. But I think in upscaling refinement higher thinning values may be useful.

4) Regarding your question, which image looks subjectively better, it's pretty clear for me and I invested quite a lot of time to be sure.
It seems several other users are having a different subjective impression, though. Things like this are hard to judge. I can't value one user's subjective impression higher than those of several others.

5) The brightness you see is exactly what a sharpener does if you use way too high strengths
Oh no, you're making it *way* too easy for yourself here.

Do you know how sharpeners technically work? They usually take some sort of "average" of the neighborhood of each pixel, and then kind of substract the average from the image. The key thing here is that the averaging practically blends multiple colors together. And scientifically it is "wrong" to do this in gamma light. It will produce incorrect results. The brightening you're seeing when applying FineSharp with "LL off" with those 3 test images I uploaded shows exactly this problem. Turning LL on fixes this problem and resultingly should make the whole processing scientifically "better".

You saying that we can ignore this problem because it's caused by too high sharpening strength is kind of funny, considering that you zoomed into the squirrel screenshot, created with the same high sharpening strength, and then on top even applied some GIMP processing to make the differences even more visible! If this is not a double standard then what is? Of course lowering the sharpening strength will also lower the brightening that LL off produces with those 3 test images. But in the same way lowering the sharpening strength will also lower the artifacts that you're complaining about. But that doesn't mean that either artifacts isn't there, or should be ignored.

If you need further tests, I can do them, but I think when you look at the enhanced squirrel, you will see the heavy artefacting that I am speaking of.
I can see that there's added ringing in the squirrel image, with LL turned on. I agree that's not a good thing. But you cannot simply ignore that LL off makes some images brighter. On the very same squirrel image some image features appear to get brighter/bigger when turning LL off! You cannot harp on just one type of artifact and ignore the others!

From what I can see, LL on/off both produce different kinds of artifacts. The key question is which kind of artifacts are worse. I know your opinion about it. I'm not sure myself.

I'm wondering whether maybe I should try a FineSharp LL build using the BT.709 gamma curve instead of a 2.2 power curve. Maybe that could give us the best of both worlds? Will have to wait for next weekend, though.

[kalston]

Does the fact overlay mode report 24fps in fraps while regular FSE report 144 (or whatever my screen refresh rate is) matter in any way? I'm curious because I've started using Smooth motion (as I've heard it's great with high refresh rates) and I've noticed that it doubles the reported framerate when using overlay mode (so 24fps becomes 48, 60 becomes becomes 120 etc.) while obviously with regular FSE it just shows a number equal to my refresh rate no matter what.

(overlay feels just as smooth and reliable as FSE for me so I kinda doubt it matters but I'd rather make sure I'm not doing anything wrong :) )

[huhn]

That's great! So now AMD users now have good alternative to NNEDI3, combined with SuperRes.

AMD was/is still better at nnedi3 than NVIDIA for the same price even with the interop copyback.

but no real issue for both AMD and NVIDIA they both aim at gaming performance not openCL.

[huhn]

Does the fact overlay mode report 24fps in fraps while regular FSE report 144 (or whatever my screen refresh rate is) matter in any way? I'm curious because I've started using Smooth motion (as I've heard it's great with high refresh rates) and I've noticed that it doubles the reported framerate when using overlay mode (so 24fps becomes 48, 60 becomes becomes 120 etc.) while obviously with regular FSE it just shows a number equal to my refresh rate no matter what.

(overlay feels just as smooth and reliable as FSE for me so I kinda doubt it matters but I'd rather make sure I'm not doing anything wrong :) )

this has to do how frames are present. you can ignore your fraps results. FSE new path has just more repeated frames drawn while overlay leaves them out and presenting "nothing" which comes don't to the same result.

[kalston]

Good to know, I really love overlay mode as it combines windowed mode advantages with FSE's performance. My monitor won't accept 10bit input so it appears there is really no point bothering with FSE on my machine.

[RyuzakiL]

First of all i think this is the best version madvr had so far in terms of handling queues especially when using DX11 FSE 10bit mode. (And Display mode switching + FSE was insanely fast this time. Around 3 seconds waiting time compared to previous version where you had to wait for 10-15 seconds at best.)

I'm running on Win 8.1 64bit 2X HD7850 on crossfire + FX8320 @ 4.3ghz

Using Samsung 40inch Led Tv as my monitor. AMD CCC video settings turned all to off except deinterlacing and ITC Processing and Pixel Format: RBG 4:4:4

i followed the madvr setup guide found here https://imouto.my/madvr/
but made some modifications>> i changed NNEDI3 and
use Super-XBR instead since it seems lighter on AMD cards than NNEDI3 + InteropHack enabled.

I'm also using SuperRes Filter on Chroma Upscaling though I know that SuperRes Filter's default settings was for NNEDI3 but it seems picture quality wasn't affected much.

I cannot discern any big difference between Super-XBR vs. NNEDI3 so performance wise i selected Super-XBR since my HD7850 liked it better hehe.

Workaround for AMD Crossfire Users >>

Since the stupid AMD Catalyst always mistake Madvr as a game, ergo Crossfire is always turned on whenever it detects Madvr.

Now i found a simple work around to prevent AMD Catalyst to not use Crossfire when it detects Madvr. Here's the procedure.

Just open your AMD CCC and head on to "My Digital Flat-Panels Tab" and put a Check to "Enable GPU up-scaling" ofcourse put the dot on "scale image to full panel size" and voila! no more crossfire on Madvr yehey!

advantages:

1. No more power wasting due to Crossfire (we already know that madvr will not benefit on using crossfire)

2. In some way performance will be better since crossfire is not enabled (maybe because no more mirroring of data between gpu's)

disadvantages:

1. Madvr Display Mode Switching will not gonna work any longer, I don't know why but it seems using the said work around will bypass Madvr's Display Mode Switching.

2. It may in some way interfere with madvr's handling of things, especially when using DX11 FSE 10bit queues aren't full when using this work around. So you are stuck on using DX11 Windowed Fullscreen 8bit.

So in the end it's up to you.

If you want DX11 FSE 10bit running smoothly with crossfire wasting energy then do not use this work around.

But if you want to save electricity and make the 2nd card enter powersave then use this workaround.

FYI i cannot discern any difference at all using DX11 FSE 10bit vs. DX11 WF (Windowed Fullscreen) 8bit. That's why i'm using this setup.


Any corrections, objections and violent reactions are welcome.

P.S you need to use Madvr Smooth Motion since you are stuck on 60hz when using this workaround.

[iSunrise]

Currently we have about 2 million options in the upscaling refinement page. I want most of them gone. So is it really too fast to remove an option when after a week's worth of testing *everybody* had the same opinion about that option?
I completely understand your developer point-of-view, I would probably do the same, just so that I could concentrate on the more important points on my checklist. I think you just did too much at the same time, when you introduced too many options in one of the last updates, that's why people really get confused and try out 2 million different settings and they never really provide meaningful feedback for only one option. I have never once had the feeling you did this on purpose though, but I think you can understand that people like me, who also have limited time to do these tests at least need 3-4 weeks to get familiar with the new settings and to concentrate on one specific test case. Otherwise, you will end up with a chaotic mix of feedback, which doesn't really help anyone.

Fair enough. That also explains your preference for lower sharpness settings, though. When applying sharpening before upscaling you always need lower sharpening strength compared to sharpening after upscaling.
Yes, and it's important that others not just turn up the knobs, but also see the negatives and the positives, that's one of the very reasons why there need to be example shots. And most of the feedback I have read about finesharp was not screenshot based at all, everyone just basically says "I like XX better than YY", but very rarely they took their time to actually show it to everyone else. When we did the dithering tests, there was great communication, screenshots and lots of example shots where you could very clearly detect the positives and negatives and you also reacted very fast to improve them. With finesharp, this was not the case, since no one other than TheLion, me and you even provided screenshots. That's 3 people out of maybe 20 that basically just said "I like A better than B", but they could not tell us, why. If you enable picture processing on a modern LCD, you have to be very careful, but the majority will simply tell you that it's great for picture quality. And we know that such quick judgements are rarely about accuracy, but because of very quick first impressions.

If you show the average Joe two pictures on two of the very same monitors at the same time and you maximize every picture processing setting on one monitor, the majority will fall for it and pick the one with the heavy processing, but not the more accurate one. I, however, specifically look for an accurate representation, that's why I also bought an Eizo CG, because I want to see every detail in the source and I don't think that picking an algorithm that looks totally processed (like finesharp LL does) makes any sense at all when you can have finesharp without LL. The negatives will quickly add up and you end with heavy ringing that destroys every picture.

One of the main reasons why a lot of DVDs were so bad, was not because of their low native resolution, but because of their excessive ringing that was applied in post. They are almost completely unwatchable when you upscale them to HD or 4K. Finesharp with the current LL will amplify that even more and that doesn't make any sense when you can just use finesharp with no LL without these negatives.

I wouldn't recommend 0.100, either. And maybe I wouldn't go very high in the image enhancement settings. But I think in upscaling refinement higher thinning values may be useful.
At least in image enhancement, I would not go any higher, but that's up for discussion. If someone provides some positives with going a lot higher and proves that it doesn't harm, then there should not be anything against it.

It seems several other users are having a different subjective impression, though. Things like this are hard to judge. I can't value one user's subjective impression higher than those of several others.
As long as you still value screenshots more and that still rings an alarm when you look at them, I see no harm in that. But the majority is not a good measurement of accurateness, like I already explained above.

From what I can see, LL on/off both produce different kinds of artifacts. The key question is which kind of artifacts are worse. I know your opinion about it. I'm not sure myself.

I'm wondering whether maybe I should try a FineSharp LL build using the BT.709 gamma curve instead of a 2.2 power curve. Maybe that could give us the best of both worlds? Will have to wait for next weekend, though.
If you can get rid of the heavy ringing, I would not be against LL. However, with results like this, this heavy amount of ringing is what made you create your AR algorithm for the upscalers in the first place. With finesharp, you basically destroy your own work, by adding heavy ringing again. I just cannot see how that's a good thing. Especially not when you're watching cartoons or anime or other things, where this will totally look processed and completely unnatural. I have not found a sample that doesn't exhibit the heavy ringing. If you zoom into your source (PotPlayer can do that natively, so madVR does all the rendering here) it's hard to miss it. It's everywhere.

And like I already explained, I can also see that the diagonal lines will get brightened up a bit, but that's because of the compression artefacts that get amplified by using higher strength values. The squirrel is however completely unnaffected by this, without all of the heavy ringing. And for me, real images are always more important than diagonal lines. In real images, the tiny amount of brightening is not noticable at all. At least not in the shots I saw, including the ones that you kindly provided.

I am pretty sure that 6233638 and cyberbeing would also love to have a say in this, but sadly, both seem to be too time restricted or just not here atm. So please at least leave the LL option in place, so others still are able to test with before/after results.

[Meulen92]

Workaround for AMD Crossfire Users >>

Since the stupid AMD Catalyst always mistake Madvr as a game, ergo Crossfire is always turned on whenever it detects Madvr.

Now i found a simple work around to prevent AMD Catalyst to not use Crossfire when it detects Madvr. Here's the procedure.

Just open your AMD CCC and head on to "My Digital Flat-Panels Tab" and put a Check to "Enable GPU up-scaling" ofcourse put the dot on "scale image to full panel size" and voila! no more crossfire on Madvr yehey!

advantages:

1. No more power wasting due to Crossfire (we already know that madvr will not benefit on using crossfire)

2. In some way performance will be better since crossfire is not enabled (maybe because no more mirroring of data between gpu's)

disadvantages:

1. Madvr Display Mode Switching will not gonna work any longer, I don't know why but it seems using the said work around will bypass Madvr's Display Mode Switching.

2. It may in some way interfere with madvr's handling of things, especially when using DX11 FSE 10bit queues aren't full when using this work around. So you are stuck on using DX11 Windowed Fullscreen 8bit.

So in the end it's up to you.

If you want DX11 FSE 10bit running smoothly with crossfire wasting energy then do not use this work around.

But if you want to save electricity and make the 2nd card enter powersave then use this workaround.

FYI i cannot discern any difference at all using DX11 FSE 10bit vs. DX11 WF (Windowed Fullscreen) 8bit. That's why i'm using this setup.


Any corrections, objections and violent reactions are welcome.

P.S you need to use Madvr Smooth Motion since you are stuck on 60hz when using this workaround.AFAIK you could just create a custom game profile in CCC for Madvr, then scroll all the way down and select Disabled as Crossfire mode. Enjoy regular MadVR use without crossfire and without restricting your options.

[aufkrawall]

It's definitely LL that makes contoures look too thick and dark with FS.
not LL:
http://abload.de/thumb/nollzjpua.png (http://abload.de/image.php?img=nollzjpua.png)

LL:
http://abload.de/thumb/llhmqr0.png (http://abload.de/image.php?img=llhmqr0.png)

Sample (1 frame):
http://www52.zippyshare.com/v/lTUNZizZ/file.html

So I vote to make not LL the new default option. In fact, I don't see any reason for having a LL option if it distorts images as shown.

LL is devilish. Always, it seems. :devil:

As for thinning: With low values I don't see any effect (at least no positive). Combined with SuperRes, it can even look worse because it already seems to introduce tiny bits of aliasing which then get stronger. With higher values, this aliasing also becomes visible without SuperRes. So I don't see any point in this parameter, thus I vote to set it to 0 by default and probably even remove this option.

[RyuzakiL]

AFAIK you could just create a custom game profile in CCC for Madvr, then scroll all the way down and select Disabled as Crossfire mode. Enjoy regular MadVR use without crossfire and without restricting your options.


thanks! Now that is much simpler. i hope this kind of configuration or procedure should be posted on the 1st page. So new users wouldn't have to ask again or search their eye balls out.

Just my two cents.

[nevcairiel]

So I vote to make not LL the new default option. In fact, I don't see any reason for having a LL option if it distorts images as shown.

LL is devilish. Always, it seems. :devil:

That is just false. Both LL on and LL off will cause problems in certain content.
How do you think we arrived on the decision for LL on at the first place (and incidentally noone objecting)? Because someone thought LL on looked better? Exactly!

thanks! Now that is much simpler. i hope this kind of configuration or procedure should be posted on the 1st page. So new users wouldn't have to ask again or search their eye balls out.

If you run a CrossFire or SLI setup, you better know how to setup a profile to disable it, since its not going to work with everything.
Because if you don't, your in for a world of hurt.

[aufkrawall]

AMD was/is still better at nnedi3 than NVIDIA for the same price even with the interop copyback.

but no real issue for both AMD and NVIDIA they both aim at gaming performance not openCL.
I was not able to use NNEDI3 at all with Hawaii GPU, while it was never an issue on GK110 (PCIe 2.0). With a GTX 980, NNEDI3 64 even can be used for 1080p24 (or even p30) -> WQHD, although it is only specified with 5TFLOPs while Hawaii XT is with 5.6TFLOPs. I have never read that Hawaii can do 1080p24 -> WQHD with 64 neurons.

That is just false. Both LL on and LL off will cause problems in certain content.
How do you think we arrived on the decision for LL on at the first place (and incidentally noone objecting)? Because someone thought LL on looked better? Exactly!

"Better" is not objective. LL scaling seems to always manipulate brightness in a way that leads to an inaccurate result compared to the source. At least from what I've seen.
Well, I don't know if it's actually comparable, but I'll post an example regarding C-R DS in the next few days (could be a bit time consuming to reproduce) which shows this clearly too.

Even if LL can look "better" in some cases, it can be hardly worth it when it totally fails in some other cases (while gamma corrected hardly ever seems to completely fail).

[ryrynz]

Madshi, are there any knobs to turn for Super-xbr with regards to sharpness outside of SuperRes?

[nevcairiel]

"Better" is not objective. LL scaling seems to always manipulate brightness in a way that leads to an inaccurate result compared to the source. At least from what I've seen.
Well, I don't know if it's actually comparable, but I'll post an example regarding C-R DS in the next few days (could be a bit time consuming to reproduce) which shows this clearly too.

Even if LL can look "better" in some cases, it can be hardly worth it when it totally fails in some other cases (while gamma corrected hardly ever seems to completely fail).

I could link you an example right now where not using LL downscaling distorts the brightness quite badly, too. It always depends a bit on the source. Both variants are not perfect. In my experience, on Live-Action content LL downscaling will usually look more natural. On animation it may be another matter entirely.
Maybe the same categories apply to FS as well. LL may look better on live-action, but have problems with animation or other content with artificial hard borders (like zoomed macro images).

[tobindac]

For those of us valuing sharpness above all else, all other algorithms seem useless compared to super xbr based on the example pictures. Though to be honest I don't seem to be able to show such differences here on common sources. Do you use it on image upscaling or something, because here I only see a chroma upscaling option for it, for which I always had a hard time seeing differences between algorithms on 1080p sources.

[aufkrawall]

I could link you an example right now where not using LL downscaling distorts the brightness quite badly, too. It always depends a bit on the source. Both variants are not perfect. On Live-Action content LL downscaling will usually look more natural. On animation it may be another matter antirely.
Ok. However, I for myself have already stumbled over three (with FS now four) more or less "real world" examples in which LL was clearly worse.
Well, then I suppose it might be best if madshi leaves us the option to choose, like with scaling.

[ThurstonX]

For those of us valuing sharpness above all else, all other algorithms seem useless compared to super xbr based on the example pictures. Though to be honest I don't seem to be able to show such differences here on common sources. Do you use it on image upscaling or something, because here I only see a chroma upscaling option for it, for which I always had a hard time seeing differences between algorithms on 1080p sources.

I had that problem last night when I finally got a few minutes to test. S-XBR is in the Image Doubling section, in the drop-down menus for Luma and Chroma (I like to Capitalize certain Words, cuz I ain't no e.e. cummings ;-) It's true that S-XBR is in the Chroma upscaling section, but not the Image upscaling section. I think that's where the confusion comes in. madshi's post (forum.doom9.org/showthread.php?p=1726378#post1726378) set me straight.

@madshi:
FWIW, I just opened the Settings to confirm the above, and sure enough "Double Chroma Resolution" is checked. That must be the new default setting, as I've never checked that option in the past. I think that maybe "Double Luma Resolution" is also getting checked as a new default (both set to "NNEDI3, 16 neurons"), as I'm pretty sure I didn't check double luma on this laptop (it can't handle it).

[huhn]

I was not able to use NNEDI3 at all with Hawaii GPU, while it was never an issue on GK110 (PCIe 2.0). With a GTX 980, NNEDI3 64 even can be used for 1080p24 (or even p30) -> WQHD, although it is only specified with 5TFLOPs while Hawaii XT is with 5.6TFLOPs. I have never read that Hawaii can do 1080p24 -> WQHD with 64 neurons.

now compare the prices of these cards and you will see what i mean.

and my r9 270 outperforms my gtx 760 when it comes down to madVR. of cause my AMD is in a very much needed PCIe 3.0 system and i know some AMD systems can't do nnedi3 at all but that's rare most people with the same cards have no issue.
my r9 270 can do 256 neuron 480p23 to 1080p23 easily my 760 GTX can't do more than 128 neurons in that case.
maybe the copyback issue gets out of hand at higher resolutions than 1080p.

[Eyldebrandt]

I know madshi wants some report about FS first, but it will be more practical to me to make an overview of the lasts features.

Finesharp
I used it years ago when Didée released it on avisynth after an user of doom9 ask him what was the best sharpener for HD source.
So here we have a important point.
Finesharp is definitively not an option to considering if we talk about sources < 720p.
FS is a factory for aliasing, distorsions, and artifacts. He has to be used only with very HQ content. Linear Light or not, he's too strong for low quality sources, the result is always horrible.
At least in my opinion, and my opinion is the only thing i can provide here.

Thinning control seems to be the equivalent setting to "xstr" in the Didée's avisynth script.
In others words, xstr/thinning is the setting than you absolutely want to turn down the most, unless you're an aliasing fan.

Finesharp is a very destructive sharpener, and to be efficient, i think he will be only used with Blu-ray or 1080p content.

And even on these types of sources, i think the strength should not exceed 1.2, in upscaling refinement, and no more than 0.7/0.8 in image enhancement.

Repair was set at 1.0, and to be honest, i don't know what to think about that. By the fact, i have not succeed to rule if repair fonction is equivalent to the "cstr" factor in the avisynth script. I think is some of, but not completely, cos i suspect the madvr version is quite different in some ways than the original script.
For fact, if repair have some strong common point with cstr, so 1.0 seems to be too high for me.

LumaSharpen

I discovered this sharpener with a previous build of madVR.
I think it's an adaptation of a SweetFx option, and i welcome it with a sort of mistrust, because i hate SweetFX :d
Anyway, i tried to let him a chance, and after some tests, i have to say he can have some utility, on very HQ content, again.
With really moderate settings, and considering is just an eye candy toy, he adds some kind of pop effect wich is not unpleasant.

As he active on the luma, he brighter just some objects and pixels in a frame, and in some ways, i like it.

Maybe a lead for futures evolutions, add an usharp mask (like Unsharp HQ) to work with luma sharpen will open a new way for those who wants to build a very pop picture. If madshi let Luma Sharpen in madVR, and i'll like he will, this will be an option to hardly considerate.

An other opinion is if you're upscaling the content, you should definitively not turn on a sharpener in image enhancement, whatever it is.

SuperRes
I'm a great fan of the method. I bought it just on the principe.
But, as shiandow is currently working at improve it, i don't think it's the right time to forge a definitive opinion about.

Super-xbr

As i play almost only 1080p content on 3440x1440 monitor and 4K VP, and as i have the rigs to motorize anything, i was a faithful user of NNEDI3 in chroma upscaling and Double resolution.
But super-xbr have insinuate the doubt in me.
On some aspects, super-xbr outclasses NNEDI. Which are aliasing control, clarity and natural look. But he's beaten by NNEDI3 on cleanliness, ringing control and precision.
This is worth for almost all types of content.

Then, super-xbr is incredibly less greedy for a result which is different but fairly comparable in terms of quality to NNEDI3, event at 128 or 256 neurons.

And more than that, it seems to me than super-xbr produce fantastic result in chroma upsampling.

To be more accurate, here are my differents settings, if that can help for anything.

720p content on 1080p TV.
- Custom Res at 2560x1440 in Nvidia panel Control (no DSR)
- Chroma upscaling : super-xbr (without SuperRes)
- Luma/chroma doubling : super-xbr
- Upscaling refinement : Super Res (NNEDI3 defaults, 4 passes)

1080p content on 1080p TV
- Custom Res at 2560x1440 in Nvidia panel Control (no DSR)
- Chroma upscaling : super-xbr (without SuperRes)
- Luma/chroma doubling : super-xbr
- Upscaling refinement : Super Res (NNEDI3 defaults, 4 passes), FS (strength 0.4, thinning 0.007), LS (strength : 0.25, clamp : 0.045, radius 0.3)
- image downscaling : C-R AR LL

1080p content on 3440x1440 monitor
- Chroma upscaling : super-xbr (without SuperRes)
- Luma/chroma doubling : super-xbr
- Upscaling refinement : Super Res (NNEDI3 defaults, 4 passes), FS (strength 0.7, thinning 0.012), LS (strength : 0.35, clamp : 0.45, radius 0.4).
- image downscaling : C-R AR LL

1080p content on 4K VP
- Chroma upscaling : super-xbr (without SuperRes)
- Luma/chroma doubling : NNEDI 64
- Upscaling refinement : Super Res (NNEDI3 defaults, 4 passes), FS (strength 0.9, thinning 0.015), LS (strength : 0.45, clamp : 0.45, radius 0.6).

Edit: and for all settings, I refine the image after every ~2X upscaling step and i apply SuperRes first.

[aufkrawall]

now compare the prices of these cards and you will see what i mean.

and my r9 270 outperforms my gtx 760 when it comes down to madVR. of cause my AMD is in a very much needed PCIe 3.0 system and i know some AMD systems can't do nnedi3 at all but that's rare most people with the same cards have no issue.
my r9 270 can do 256 neuron 480p23 to 1080p23 easily my 760 GTX can't do more than 128 neurons in that case.
maybe the copyback issue gets out of hand at higher resolutions than 1080p.
No question, Radeons perform well in madVR apart from NNEDI3. But we were talking about NNEDI3, weren't we. ;)
And yes, small Kepler GPUs can be awfully slow with Compute and often also lack shader power in general compared to GCN Radeons.
But Kepler is end of life, it is almost completely replaced by Maxwell GPUs, from low end (which is less low end than some years ago) to high end. And Maxwell often is much faster regarding Compute than Kepler (in some cases even faster than GCN, which is a highly Compute optimized architecture with many crossbars etc.).
The pricing is high, but an OCed 970 gives a lot of bang for bucks in madVR, and can be close to completely silent.

[huhn]

No question, Radeons perform well in madVR apart from NNEDI3. But we were talking about NNEDI3, weren't we. ;)
but my way cheaper r9 270 outperforms my 760 in term of nnedi3 and that by a lot.
And yes, small Kepler GPUs can be awfully slow with Compute and often also lack shader power in general compared to GCN Radeons.
But Kepler is end of life, it is almost completely replaced by Maxwell GPUs, from low end (which is less low end than some years ago) to high end. And Maxwell often is much faster regarding Compute than Kepler (in some cases even faster than GCN, which is a highly Compute optimized architecture with many crossbars etc.).
The pricing is high, but an OCed 970 gives a lot of bang for bucks in madVR, and can be close to completely silent.

i doubt the gtx 960 which is about 5% faster than my gtx 760 can beat my r9 270 in term of nnedi3 and general processing power when used for madVR.
but i will find this out my self soon enough i need a GTX 960 soon anyway.

[aufkrawall]

but my way cheaper r9 270 outperforms my 760 in term of nnedi3 and that by a lot.

This doesn't surprise me, as long as PCIe isn't limiting.
GTX 760 is a GK104 with 2 blocks of disabled ALUs/TMUs, and even a GTX 680 was rather infamous for its Compute abilities.


i doubt the gtx 960 which is about 5% faster than my gtx 760 can beat my r9 270 in term of nnedi3 and general processing power when used for madVR.

With Compute, the 960 is much faster than the 760:
http://www.computerbase.de/2015-01/nvidia-geforce-gtx-960-im-test/5/#abschnitt_gpucomputing
(dunno what's wrong there with ComputeMark, probably a bug since 960 should be much faster than the 750 Ti).


but i will find this out my self soon enough i need a GTX 960 soon anyway.
For madVR, I think a 970 would be much better.
HEVC 10 bit probably won't be important soon.
Well, of course with super-xbr, NNEDI3 is often a waste of resources now, so a 960 might be nice as well.

[nevcairiel]

For madVR, I think a 970 would be much better.
HEVC 10 bit probably won't be important soon.
Well, of course with super-xbr, NNEDI3 is often a waste of resources now, so a 960 might be nice as well.

I have been hoping for a GTX 960 Ti, which would fill the quite large performance gap between 960 and 970, and (hopefully) also have full HEVC support ... but so far nothing in sight. :(

[baii]

the scaling factor profile rule bug is into tracker. In the mean time, any one can suggest a workaround?
All I need is 2 profile, a and b,
when the image/video is upscaled ->active profile,
not upscaled -> active b.

This is essentially for the image enhancement tab~

[huhn]

This doesn't surprise me, as long as PCIe isn't limiting.
GTX 760 is a GK104 with 2 blocks of disabled ALUs/TMUs, and even a GTX 680 was rather infamous for its Compute abilities.


GPU computing test are hard to judge. nearly all nvidia GPU are terrible with double precision which is not used in madVR


With Compute, the 960 is much faster than the 760:
http://www.computerbase.de/2015-01/nvidia-geforce-gtx-960-im-test/5/#abschnitt_gpucomputing
(dunno what's wrong there with ComputeMark, probably a bug since 960 should be much faster than the 750 Ti).

it has to be at least double as fast as my gtx 760 in term of GPU openCL computing to beat my r9 270.

760 gtx 128 neurens ~31ms
r9 270 256 neurons ~33ms

not sure if i should use the computerbase benchmarks for nnedi3 performance.

For madVR, I think a 970 would be much better.
HEVC 10 bit probably won't be important soon.
Well, of course with super-xbr, NNEDI3 is often a waste of resources now, so a 960 might be nice as well.

not going to put a 300+ euro GPU in my HTPC sorry.
and my r9 270 is passive cooled should be easily possible with a 960 GTX too.

I have been hoping for a GTX 960 Ti, which would fill the quite large performance gap between 960 and 970, and (hopefully) also have full HEVC support ... but so far nothing in sight. :(

i would like a 950 ti that's faster than the 750ti with HDMI 2.0 and HEVC decoder.

i guess a lot of cards where planned with the same limitation as the 970 which results in a pretty bad reputation for that feature so they are not released anymore.

[aufkrawall]

There is already a lot deactivated with GTX 970 GM204 and deactivating ROPs and segmenting VRAM doesn't make always sense. I think it might never have been planned to fill the gap between 960 and 970.
960 is already selling well for a high price and you can still pay even more for a 4GB version.

[nevcairiel]

There is already a lot deactivated with GTX 970 GM204 and deactivating ROPs and segmenting VRAM doesn't make always sense. I think it might never have been planned to fill the gap between 960 and 970.
960 is already selling well for a high price and you can still pay even more for a 4GB version.

There were rumors about a 960 Ti at some point, but they never substantiated. Oh well.

If nothing else shows up, I'll probably build a new HTPC with Skylake and a 4GB 960 later this year.

[James Freeman]

It appears that my rendering time raised to 41ms thus the queues not filling up.
* I downclock my GPU to save power.
In version 88.11 the rendering was twice as fast, at about 20-25ms.
Nothing special, just Lanczos 3, Smooth Motion, Ordered Dithering.
That doesn't make a lot of sense. I haven't changed anything which would explain a performance difference. Are you sure the downclock works the same with v0.88.11 and v0.88.12? I'm rather thinking that maybe with one of those versions the clock of your GPU might be different or something. Nobody else has reported anything like this yet, either. So I think the problem is likely on your side somewhere. Sorry, I wish I could be more specific. But I don't have enough information to say anything more helpful...

I am terribly sorry. :o

I was running a Shader in MPC-HC which I forgot I enabled, it did not change the image, just take GPU power which raised my rendering times from 20ms to 40ms.
This downclocking (P8 state) of the GPU is intentional, at full throttle of my GTX660 I get around 4ms.
Same with CPU, I keep the "Minimum and Maximum processor state" at 0% so that I always get 1600Mhz with my i7.

Current test show my system takes around 20W when playing a movie, never needed more than that, plus, it helps to keep the heat and bills down...

ahem... back to topic please. :D