Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Hardware & Software > Software players

Reply
 
Thread Tools Search this Thread Display Modes
Old 9th June 2015, 15:05   #30881  |  Link
GCRaistlin
Registered User
 
GCRaistlin's Avatar
 
Join Date: Jun 2006
Posts: 350
There's another annoying issue that is present in all madVR builds I've used so far. The problem is that it should be very hard to reproduce.
I use Mozilla Firefox, and there are always a lot of tabs open there (185 for now). When playing a video with madVR on the 2nd monitor Firefox sometimes crashes, sometimes behaves weird (only the window title is displayed, the rest is "transparent" - the contents of a background window is visible). I don't know if this is caused either by some of the opened tabs, or by playing on the 2nd monitor, or even by madVR (EVR CP looks really ugly on the projector + 140" screen, and the issue is too unstable and relative rarely appearing to perform a good test). But it does exist.
__________________
Windows 8.1 x64

Magically yours
Raistlin
GCRaistlin is offline   Reply With Quote
Old 9th June 2015, 15:15   #30882  |  Link
Anime Viewer
Troubleshooter
 
Anime Viewer's Avatar
 
Join Date: Feb 2014
Posts: 339
Finesharp testing results report #3

For reference when I refer to FineSharp (i) below I am referring to FineSharp in Image Enhancements, and when I refer to FineSharp (u) I am referring to FineSharp in Upscaling Refinement. Its easier that typing each phrase over and over again.

Quote:
Originally Posted by madshi View Post
Can you explain why you like it better/worse in either of these sections? In which way does it look better in image enhancement? In in which way does it look worse in upscaling refinement? Have you tested FineSharp alone (without SuperRes etc) in upscaling refinement? Do you still dislike linear light there? Or maybe it's only when used together with SuperRes?
The main benefit I see from using the Image Enhancement version as opposed to the Upscaling Refinement version is that the Image Enhancement version doesn't increase render times. That makes it more problem free (more universally usable) when it comes to using it across different gpus. Using the Upscaling Enhancement version the render times increase, and it can drag down a weak gpu.

The tests I have done when I made the second report (above) and this one were done without SuperRes, so only the first test I did involved using SuperRes in combination with FineSharp. As I reported in the first test report I felt that if one is combining FineSharp with SuperRes they seem to work better if they are both used from the Upscaling Refinement area.

When enabling Linear Light in FineSharp (i) I notice a significant change in shading and around black areas on the screen. Its a look I prefer having enabled as opposed to disabled in the (i) version. Linear Light in the (u) version has much less (an almost unperceptive) effect. Enabling Linear Light in the (u) version makes it look like a very small (insignificant) increase in sharpness/jaggedness. Very much insignificant in my view, and I'd have no objection to it enabled by default when used by the (u) version. I don't notice the change in blacks and shading with the (u) version like I do with the (i) version.

Quote:
Originally Posted by madshi View Post
Not really. Try this image:

http://madshi.net/castleOrg.png

Double it with NNEDI3, then apply FineSharp as upscaling refinement. Then compare repair with 0.0 to 1.0. Look at the diagonal roof lines. They contain a bit of aliasing when using repair 0.0, which is mostly gone with 1.0. Using 0.25 is somewhere in between. It's a subtle difference in this image. I've seen far worse aliasing caused by FineSharp in other images. Sadly I can't find them on a quick look right now.
I'm having a hard time seeing a difference. As I'm toggling things off and on I thought I may have been seeing a small change in the roof edges, but then when I toggle again I don't think I see any change, so I'm not sure if I'm seeing any effect from the repair feature. With that being said if its believed a 1.0 value improves things then I say go ahead and set it to that. I don't see anything getting worse or negatively effected by having it set to 1.0, so I see no reason not to have it default to that value.

Quote:
Originally Posted by madshi View Post
So you'd suggest 2.0 for "high" and 0.5 for "low"? Can you play with "thinning" a bit to see if you like those values to be changed in any way for high or low?
If Image Doubling is combined with FineSharp I think higher settings can be used with less negative effects (artifacts). Increasing the thinning setting gives the impression the image is composed of more tiny dots/circles and looks to increase sharpness slightly. In FineSharp (i) it higher settings (beyond default) give (for lack of a better term) a bit of an artificial look. I like the look of the sharpening increasing the setting gives when used in FineSharp (u). When I have more time I'll try to spend more time adjusting the thinning settings and see if there are certain values that appeal to me in each type of FineSharp situation.

Quote:
Originally Posted by madshi View Post
You mean using FineSharp in image enhancements, and then afterwards doubling? What kind of effect does doubling have on FineSharp in your experience?
Doubling smooths out the jaggedness (alaising) I see that is created when using FineSharp especially at the FineSharp's higher strength settings. Interestingly enough I feel like I see it having different effects depending on which FineSharp it is used with. When using Doubling with the FineSharp in image enhancements it greatly reduces the amount of artifacts I see.
When using Doubling with the FineSharp in upscaling refinement it smooths out jaggedness of alaising lines. (When comparing FineSharp (i) to FineSharp (u) at the same strengths FineSharp (u) is more of a blurry image with far less artifacts. To a degree Doubling may be reducing artifacts with FineSharp (u) as well, and reducing sharping edges with FineSharp (i), but given that the pre-doubled image was already pretty smooth with FineSharp (i), and the pre-doubled image with FineSharp (u) was pretty artifact free before doubling the effects are less noticeable). Combining both FineSharps (aka enabling both) doesn't appear to look too bad as long as both are reduced in strength by half (causing the total strength to FineSharp to remain the same when all is said and done), but then you bring in the possibility of FineSharp (u) increasing render speeds and dragging down weaker gpu.


------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Quote:
Originally Posted by GCRaistlin View Post
There's another annoying issue that is present in all madVR builds I've used so far. The problem is that it should be very hard to reproduce.
I use Mozilla Firefox, and there are always a lot of tabs open there (185 for now). When playing a video with madVR on the 2nd monitor Firefox sometimes crashes, sometimes behaves weird (only the window title is displayed, the rest is "transparent" - the contents of a background window is visible). I don't know if this is caused either by some of the opened tabs, or by playing on the 2nd monitor, or even by madVR (EVR CP looks really ugly on the projector + 140" screen, and the issue is too unstable and relative rarely appearing to perform a good test). But it does exist.
It sounds to me like you are running out of memory. If you either leave task manager open, or open it once you encounter the problem how much memory does it say your browser is using? How much memory do you have in your system? I've seen similar effects to what you describe when people run out of memory. The fault is with the browser and it leaking memory as opposed to madVR. If you type "about:memory" in your address bar you can use the buttons under free memory to reclaim some of it. Tabs that are running Adobe, Java, and video plugins (even if you don't have any of them actively playing) can be huge memory leaks. You can try FireFox developer edition, and see if that works better - in my testing it leaks far less memory. Finally as it relates to madVR you can reduce the queue settings, so that it uses less memory (and frees up more for your browser), but doing that may have a negative effect on your video playback. Its something you'd have to experiment with yourself, and determine if it makes things better or worse.
__________________
System specs: Sager NP9150 SE with i7-3630QM 2.40GHz, 16 GB RAM, 64-bit Windows 10 Pro, NVidia GTX 680M/Intel 4000 HD optimus dual GPU system. Video viewed on LG notebook screen and LG 3D passive TV.

Last edited by Anime Viewer; 9th June 2015 at 15:27. Reason: added reply to GCRaistlin
Anime Viewer is offline   Reply With Quote
Old 9th June 2015, 16:37   #30883  |  Link
GCRaistlin
Registered User
 
GCRaistlin's Avatar
 
Join Date: Jun 2006
Posts: 350
madshi, should I create a ticket on the bug tracker for my request about the ability to change the refresh rate from the icon menu?
__________________
Windows 8.1 x64

Magically yours
Raistlin
GCRaistlin is offline   Reply With Quote
Old 9th June 2015, 16:41   #30884  |  Link
GCRaistlin
Registered User
 
GCRaistlin's Avatar
 
Join Date: Jun 2006
Posts: 350
Quote:
Originally Posted by Anime Viewer View Post
How much memory do you have in your system?
3 GB. I'll check how much memory Firefox use next time I'll experience the issue.
__________________
Windows 8.1 x64

Magically yours
Raistlin
GCRaistlin is offline   Reply With Quote
Old 9th June 2015, 18:08   #30885  |  Link
SecurityBunny
Registered User
 
Join Date: Jul 2013
Posts: 76
Quote:
Originally Posted by madshi View Post
Does this one fix the issue? It's based on the latest v0.88.11:

http://madshi.net/madVR64queueFix1.rar

If it does fix the issue, please also double check with 23/24p display modes (if your display supports them), with both this build and v0.88.8. Your logs so far were mostly 59p, IIRC.
That does seem to fix the issue. Queues fill fine with D3D11 10-bit output. The only issue I'm able to tell is with D3D11, present queue is 15-15/15 while on D3D9 it bounces between 15-16/16 | 16-16/16. So you seem to lose one prepresented frame with D3D11.

Unfortunately I don't believe my monitor supports 23/24p display modes since it switches back to 59.95 hz after going fullscreen for a few seconds. But for those few seconds testing 24hz (display reporting 24.00 in madvr), queues fill all the way with prepresented at 14-15/15. Testing 23hz (presuming you don't mean 23.976hz) queues did not fill but the display was outputting 22.99hz.

Testing 0.88.8 at 24hz, queues fill perfectly fine. But similar to above, D3D11 seems to lose a prepresented frame in present queue when compared to D3D9.

All testing done with Ordered Dithering with both options enabled.

Edit: Probably doesn't mean much but with the test build, D3D11 10-bit, present queue displays 14-15/15 in windowed mode, whereas fullscreen it is completely stable at 15-15/15.

Last edited by SecurityBunny; 9th June 2015 at 18:14.
SecurityBunny is offline   Reply With Quote
Old 9th June 2015, 18:21   #30886  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by GCRaistlin View Post
There's another annoying issue that is present in all madVR builds I've used so far. The problem is that it should be very hard to reproduce.
I use Mozilla Firefox, and there are always a lot of tabs open there (185 for now). When playing a video with madVR on the 2nd monitor Firefox sometimes crashes, sometimes behaves weird (only the window title is displayed, the rest is "transparent" - the contents of a background window is visible). I don't know if this is caused either by some of the opened tabs, or by playing on the 2nd monitor, or even by madVR (EVR CP looks really ugly on the projector + 140" screen, and the issue is too unstable and relative rarely appearing to perform a good test). But it does exist.
Doesn't sound like madVR would be at fault.

Quote:
Originally Posted by Anime Viewer View Post
I'm having a hard time seeing a difference. As I'm toggling things off and on I thought I may have been seeing a small change in the roof edges, but then when I toggle again I don't think I see any change, so I'm not sure if I'm seeing any effect from the repair feature. With that being said if its believed a 1.0 value improves things then I say go ahead and set it to that. I don't see anything getting worse or negatively effected by having it set to 1.0, so I see no reason not to have it default to that value.
Ok. Anybody else objecting to setting "repair" to 1.0?

Quote:
Originally Posted by Anime Viewer View Post
When I have more time I'll try to spend more time adjusting the thinning settings and see if there are certain values that appeal to me in each type of FineSharp situation.
Would appreciate that, thanks.

Quote:
Originally Posted by Anime Viewer View Post
When using Doubling with the FineSharp in upscaling refinement it smooths out jaggedness of alaising lines.
That's what "repair" also is supposed to help with, I think.

Quote:
Originally Posted by GCRaistlin View Post
madshi, should I create a ticket on the bug tracker for my request about the ability to change the refresh rate from the icon menu?
The bug tracker is only for bugs, not for feature wishes. About your feature wish see my reply here:

http://forum.doom9.org/showthread.ph...43#post1721943

Quote:
Originally Posted by SecurityBunny View Post
That does seem to fix the issue. Queues fill fine with D3D11 10-bit output. The only issue I'm able to tell is with D3D11, present queue is 15-15/15 while on D3D9 it bounces between 15-16/16 | 16-16/16. So you seem to lose one prepresented frame with D3D11.

Unfortunately I don't believe my monitor supports 23/24p display modes since it switches back to 59.95 hz after going fullscreen for a few seconds. But for those few seconds testing 24hz (display reporting 24.00 in madvr), queues fill all the way with prepresented at 14-15/15. Testing 23hz (presuming you don't mean 23.976hz) queues did not fill but the display was outputting 22.99hz.

Testing 0.88.8 at 24hz, queues fill perfectly fine. But similar to above, D3D11 seems to lose a prepresented frame in present queue when compared to D3D9.
If your monitor doesn't support 23/24p, then you shouldn't see any image at all. You do seem to see an image. Not sure why it's switching back to 59p, though.

What is important to me is if v0.88.8 is in any way better than the test build or not. If v0.88.8 is not better (not at any refresh rate), then we can consider the problem in v0.88.9+ fixed, and we can stop investigating. You're saying v0.88.8 filled the queue at 24hz, and the test build, too. But the test build doesn't seem to fill the queues at 23hz. So does v0.88.8 do that?
madshi is offline   Reply With Quote
Old 9th June 2015, 18:22   #30887  |  Link
Hyllian
Registered User
 
Hyllian's Avatar
 
Join Date: Jun 2014
Posts: 42
Hi, sorry for hijacking the thread a bit. For some time I have developed some shaders for other systems (emulators) and would like to know how one of them compares to the shaders used to upscale videos. My shaders are used primary for games, but I think some of them could be used for videos too.

What do you think about the quality of this 4x upscaled image?

http://i.imgur.com/d0usxSP.png

Last edited by Hyllian; 9th June 2015 at 18:36.
Hyllian is offline   Reply With Quote
Old 9th June 2015, 18:41   #30888  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
@Hyllian,

that looks quite nice, actually. Compared to NNEDI3, I would say in some areas it's a bit better (e.g. the wheels of the white van) and in others a bit worse. However, I do see some ringing in your image. Did you sharpen it with a bad sharpener? Or does your scaler introduce ringing itself? FWIW, here's what NNEDI3 does, without and with sharpening:

NNEDI3 -|- NNEDI3 - sharpened

What kind of algorithm does your shader use? How fast is it?
madshi is offline   Reply With Quote
Old 9th June 2015, 18:42   #30889  |  Link
TheLion
Registered User
 
Join Date: Dec 2010
Posts: 62
Quote:
Originally Posted by madshi View Post
Thanks. So for "image enhancements" you would suggest a strength of 2.0 for the "high" preset, using the default "thinning"? Have you played with the "thinning" a bit to find out whether you like it at its default value or slightly different maybe?

What would you suggest for medium and low presets?

And how much better do you like mode 3? I'm asking because it costs more performance. So the question is whether it's worth the added performance cost?
For FineSharp as Image Enhancement i would suggest:

Preset:Strength= low:0.5 medium:1.0 high:2.0
Always with linear light ON

Thinning seems fine at default for all three modes, but it's very hard to come up with a preference for me I am afraid - so I would certainly not object when this parameter is changed from default. I guess it would seem logical that the "optimum" thinning setting changes as well with different strength presets.

Mode 3 is certainly not "night and day" but in my opinion the difference is relevant enough to make it the default, with mode 1 or 2 perhaps a new "trade quality for performance" checkbox. I know you hate additional options, but madVR is all about best quality first, afterall
TheLion is offline   Reply With Quote
Old 9th June 2015, 19:02   #30890  |  Link
Hyllian
Registered User
 
Hyllian's Avatar
 
Join Date: Jun 2014
Posts: 42
Quote:
Originally Posted by madshi View Post
@Hyllian,

that looks quite nice, actually. Compared to NNEDI3, I would say in some areas it's a bit better (e.g. the wheels of the white van) and in others a bit worse. However, I do see some ringing in your image. Did you sharpen it with a bad sharpener? Or does your scaler introduce ringing itself? FWIW, here's what NNEDI3 does, without and with sharpening:

NNEDI3 -|- NNEDI3 - sharpened

What kind of algorithm does your shader use? How fast is it?
To tell you the truth, my algorithm is only for 2x, as NNEDI3 or NEDI. I have used my other jinc2 shader to go from 2x to 4x. And in fact it has some ringing, though most of them come from the jinc2 pass (the last pass). I didn't use any kind of sharpener and maybe it could improve the image a bit more.

My algorithm is called super-xbr, as it was derived from the standard xbr algorithm I already had developed for cartoon games some years ago and is largely used in emulators. The super-xbr is more focused in high color gradient images than cartoons, so I think it could be good for videos. For now, it's only in cg shader language and available for emulators like Retroarch. The sources are in this repository: https://github.com/libretro/common-s.../xbr/super-xbr

Unfortunately, I don't know other shaders languages to port it, but maybe you could port it and test in madVR or other players/systems. It's a bit less aggressive then the NEDI shader.


If I disable the anti-ringing I get this: http://i.imgur.com/bDA74E2.png

Last edited by Hyllian; 9th June 2015 at 19:51.
Hyllian is offline   Reply With Quote
Old 9th June 2015, 19:23   #30891  |  Link
SecurityBunny
Registered User
 
Join Date: Jul 2013
Posts: 76
Quote:
Originally Posted by madshi View Post
If your monitor doesn't support 23/24p, then you shouldn't see any image at all. You do seem to see an image. Not sure why it's switching back to 59p, though.

What is important to me is if v0.88.8 is in any way better than the test build or not. If v0.88.8 is not better (not at any refresh rate), then we can consider the problem in v0.88.9+ fixed, and we can stop investigating. You're saying v0.88.8 filled the queue at 24hz, and the test build, too. But the test build doesn't seem to fill the queues at 23hz. So does v0.88.8 do that?
At 23hz (22.99hz), with 0.88.8, queues seem to fill. Not as stable / completely filled as 59/24hz (15/15 queue size), but filled. Numbers like 12-15/15 for present queue, whereas the test build it is 2-8/15 for present queue.

So it seems odd integer refresh rates aren't fixed but 3:2 pulldown & 1:1 is fine?

Last edited by SecurityBunny; 9th June 2015 at 19:27.
SecurityBunny is offline   Reply With Quote
Old 9th June 2015, 19:35   #30892  |  Link
huhn
Registered User
 
Join Date: Oct 2012
Posts: 7,903
Quote:
Originally Posted by SecurityBunny View Post
At 23hz (22.99hz), with 0.88.8, queues seem to fill. Not as stable / completely filled as 59/24hz (15/15 queue size), but filled. Numbers like 12-15/15 for present queue, whereas the test build it is 2-8/15 for present queue.

So it seems odd integer refresh rates aren't fixed but 3:2 pulldown & 1:1 is fine?
what? 23 hz is supposed to be 24000/1001 = ~23.976
huhn is offline   Reply With Quote
Old 9th June 2015, 19:42   #30893  |  Link
starla
Registered User
 
Join Date: Jan 2004
Posts: 56
In case someone happens to have performance issues with madVR rendering (excluding cases where DXVA scaling seems to work) one thing that could cause it is a buggy motherboard bios.

Same HW, but different MB bios versions resulted quite different texture upload speeds:

Quote:
A8R8G8B8 Texture speed test:
default: upload 17 fps, download 138 fps
dynamic: upload 9 fps, download 8 fps, trick download 121 fps
vs.

Quote:
A8R8G8B8 Texture speed test:
default: upload 132 fps, download 167 fps
dynamic: upload 239 fps, download 9 fps, trick download 131 fps
starla is offline   Reply With Quote
Old 9th June 2015, 19:45   #30894  |  Link
SecurityBunny
Registered User
 
Join Date: Jul 2013
Posts: 76
Quote:
Originally Posted by huhn View Post
what? 23 hz is supposed to be 24000/1001 = ~23.976
Check my previous message. :P I tested both 24hz and 23hz since madshi asked for both. Setting my display to 23hz puts it in 22.99 whereas 24hz puts it at 24.00.

Though there still seems to be some type of problem if 0.88.8 can play 22.99hz with relatively full queues and the test build can't at this specific hz. Even if it isn't the norm.
SecurityBunny is offline   Reply With Quote
Old 9th June 2015, 20:29   #30895  |  Link
nlnl
Registered User
 
Join Date: Aug 2008
Posts: 176
Quote:
Originally Posted by nlnl View Post
madshi
tested new image ehancement option using this image https://cloud.mail.ru/public/abgy/uwuasurxh
the results:
Fine sharp on

fs off


can not see horisontal lines when fs off and the same with superres filter off for chroma upsampling.
madshi
I mean that horisontal lines in window (marked using arrow)
FS OFF, image inhancement

no horisontal lines
and
FS ON, image inhancement,

we see lines.
This is the test image for correct chroma upsampling (Spears & Munsil) and we should see horisontal lines with and without Fine Sharpening?

Last edited by nlnl; 9th June 2015 at 20:46.
nlnl is offline   Reply With Quote
Old 9th June 2015, 21:06   #30896  |  Link
MysteryX
Soul Architect
 
MysteryX's Avatar
 
Join Date: Apr 2014
Posts: 2,559
Madshi, I'll add one more thing about SuperRes anti-ringing. It adds distortion to the image so you have to be careful. If it's too low, it doesn't quite remove anti-ringing, but then if it is too high, the image looks "flat"

Last edited by MysteryX; 24th June 2015 at 06:02.
MysteryX is offline   Reply With Quote
Old 9th June 2015, 21:41   #30897  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,344
Quote:
Originally Posted by nlnl View Post
madshi
I mean that horisontal lines in window (marked using arrow)
FS OFF, image inhancement

no horisontal lines
and
FS ON, image inhancement,

we see lines.
This is the test image for correct chroma upsampling (Spears & Munsil) and we should see horisontal lines with and without Fine Sharpening?
I see lines in both cases on your screenshot, on a PC monitor with guaranteed 4:4:4 reproduction. Maybe it interacts badly with your chroma sampling test?
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is offline   Reply With Quote
Old 9th June 2015, 22:33   #30898  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by TheLion View Post
For FineSharp as Image Enhancement i would suggest:

Preset:Strength= low:0.5 medium:1.0 high:2.0
Always with linear light ON

Thinning seems fine at default for all three modes, but it's very hard to come up with a preference for me I am afraid - so I would certainly not object when this parameter is changed from default. I guess it would seem logical that the "optimum" thinning setting changes as well with different strength presets.

Mode 3 is certainly not "night and day" but in my opinion the difference is relevant enough to make it the default, with mode 1 or 2 perhaps a new "trade quality for performance" checkbox. I know you hate additional options, but madVR is all about best quality first, afterall
Ok, thanks.

Quote:
Originally Posted by Hyllian View Post
To tell you the truth, my algorithm is only for 2x, as NNEDI3 or NEDI. I have used my other jinc2 shader to go from 2x to 4x. And in fact it has some ringing, though most of them come from the jinc2 pass (the last pass). I didn't use any kind of sharpener and maybe it could improve the image a bit more.
Why don't you use your super-xbr twice, like 2*2x = 4x? That's what I'm doing with NNEDI3/NEDI, too.

Quote:
Originally Posted by Hyllian View Post
My algorithm is called super-xbr, as it was derived from the standard xbr algorithm I already had developed for cartoon games some years ago and is largely used in emulators. The super-xbr is more focused in high color gradient images than cartoons, so I think it could be good for videos. For now, it's only in cg shader language and available for emulators like Retroarch. The sources are in this repository: https://github.com/libretro/common-s.../xbr/super-xbr

Unfortunately, I don't know other shaders languages to port it, but maybe you could port it and test in madVR or other players/systems. It's a bit less aggressive then the NEDI shader.

If I disable the anti-ringing I get this: http://i.imgur.com/bDA74E2.png
Ouch, looks very ugly without anti-ringing!

Which license does your super-xbr algo (and the shaders) come with? I might be interested trying it for madVR, but it depends on the license. Thanks!

Quote:
Originally Posted by SecurityBunny View Post
At 23hz (22.99hz), with 0.88.8, queues seem to fill. Not as stable / completely filled as 59/24hz (15/15 queue size), but filled. Numbers like 12-15/15 for present queue, whereas the test build it is 2-8/15 for present queue.

So it seems odd integer refresh rates aren't fixed but 3:2 pulldown & 1:1 is fine?
I know what the problem is: In v0.88.9 I extended the refresh rate fix for Direct3D11. The refresh rate fix monitors which refresh rate D3D11 tries to set, and modifies that, if needed. If I leave the refresh rate untouched, your queues fill. If I modify the refresh rate, you get the problems with the non-filling queues. In v0.88.9+ I *always* modified the refresh rate. v0.88.8 only filled the refresh rate in some very special situations. The test build walks middle ground by changing the refresh rate when D3D11 tries to set a refresh rate which is too far away from what we really want to get. In your case with 23Hz madVR sees 23p and expects 23.976Hz, but D3D11 asks for 23.000Hz. That's too far apart, so madVR changes that to 23.976Hz. And that makes the queue no filling. Nothing I can do about it, I guess.

I'm not sure exactly *why* the queues aren't filling. I mean I know it's caused by me modifying the refresh rate. But I'm not sure why modifying the refresh rate causes the queues to not fill - and only in 10bit mode. Strange. And it seems to only affect some users, not all. In any case, I've done what I could do. I think I'll call it a day now and leave things as they are in the test build.

Quote:
Originally Posted by starla View Post
In case someone happens to have performance issues with madVR rendering (excluding cases where DXVA scaling seems to work) one thing that could cause it is a buggy motherboard bios.
Yep, especially when the upload queue doesn't fill, a BIOS update has just proven one possible fix.

Quote:
Originally Posted by MysteryX View Post
Madshi, I'll add one more thing about SuperRes anti-ringing. It adds distortion to the image so you have to be careful. If it's too low, it doesn't quite remove anti-ringing, but then if it is too high, the image looks "flat"
Yes, I've seen issues with anti-ringing set to 1.0, and I think the same issues also occur with lower values, just not as strongly.

Quote:
Originally Posted by nlnl View Post
I mean that horisontal lines in window (marked using arrow)
FS OFF, image inhancement
no horisontal lines
and
FS ON, image inhancement,
we see lines.
This is the test image for correct chroma upsampling (Spears & Munsil) and we should see horisontal lines with and without Fine Sharpening?
Quote:
Originally Posted by nevcairiel View Post
I see lines in both cases on your screenshot, on a PC monitor with guaranteed 4:4:4 reproduction. Maybe it interacts badly with your chroma sampling test?
^ What nevcairiel said.
madshi is offline   Reply With Quote
Old 10th June 2015, 00:00   #30899  |  Link
SecurityBunny
Registered User
 
Join Date: Jul 2013
Posts: 76
Quote:
Originally Posted by madshi View Post
I know what the problem is: In v0.88.9 I extended the refresh rate fix for Direct3D11. The refresh rate fix monitors which refresh rate D3D11 tries to set, and modifies that, if needed. If I leave the refresh rate untouched, your queues fill. If I modify the refresh rate, you get the problems with the non-filling queues. In v0.88.9+ I *always* modified the refresh rate. v0.88.8 only filled the refresh rate in some very special situations. The test build walks middle ground by changing the refresh rate when D3D11 tries to set a refresh rate which is too far away from what we really want to get. In your case with 23Hz madVR sees 23p and expects 23.976Hz, but D3D11 asks for 23.000Hz. That's too far apart, so madVR changes that to 23.976Hz. And that makes the queue no filling. Nothing I can do about it, I guess.

I'm not sure exactly *why* the queues aren't filling. I mean I know it's caused by me modifying the refresh rate. But I'm not sure why modifying the refresh rate causes the queues to not fill - and only in 10bit mode. Strange. And it seems to only affect some users, not all. In any case, I've done what I could do. I think I'll call it a day now and leave things as they are in the test build.
Sounds good. The test build seems to function just fine with both 24hz and 60hz in D3D11 10-bit mode. As long as the queues fill, I would consider the issue fixed. At least would fix my problem.

Any idea why 1 prepresented frame is being dropped when using D3D11 though? With frames in advance set to 16, 15-15/15 present queue with D3D11, 15-16/16 present queue with D3D9.
SecurityBunny is offline   Reply With Quote
Old 10th June 2015, 01:17   #30900  |  Link
JackCY
Registered User
 
Join Date: Jun 2015
Posts: 15
Quote:
Originally Posted by madshi View Post
Technically not possible right now, because custom shaders are not flexible/powerful enough to run Shiandow's deband. At some point in the future, that should be possible, though.
So, where does it run right now? What HW (CPU/GPU), what part of HW (if not GPU shaders).
I might ask Shiandow about the alg. then.

Quote:
Of course my plan is to get rid of the edit boxes altogether and just offer low/medium/high. I could allow the edit boxes to be edited, but it's not that simple, then I also must parse the text and complain if the format isn't correct etc. So some extra work involved there...
Yeah I know checking user input is rather a PITA, I guess C++, gotta write too much and able to reuse only a little.
JackCY is offline   Reply With Quote
Reply

Tags
direct compute, dithering, error diffusion, madvr, ngu, nnedi3, quality, renderer, scaling, uhd upscaling, upsampling

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 19:11.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.