View Full Version : Media Player .NET (MPDN) - D3D HQ GPU Video Renderer [v2.49.0/v1.31.0 27 Dec 2018]
aufkrawall
23rd April 2015, 14:16
With a GTX 980, I'm having a little higher GPU load with MPDN 64 neurons, compared to madVR (with the exact settings you have given).
With madVR, it's ~32% GPU usage when scaling 720p25 -> WQHD, with MPDN it's ~39%. The difference seems to get stronger when I additionally let both renderers downsample to maximized windowed resolution.
In both players, render and presentation queues are set to 4 frames (new windowed path).
I'm not giving much about render times since the GPU doesn't always run with the same clock.
But, it's working without any glitches on a quick try. Will do quality comparisons as soon as I got more time.
Very nice progress again! :devil:
Edit: Could someone please explain again what the technical reason is why NNEDI3 via DirectCompute is much slower than via OpenCL?
Scyna
23rd April 2015, 22:51
1) Amd 290
2)A 16/Scalar: 84%/534 Avg Render 10.50ms, 32/Scalar: 88%/564 Avg render 11.85ms, 64/Scalar: 83%/610 Avg Render 15.34ms, 128/Scalar: 100%/725 Avg Render 21.30ms, 256/Scalar: 100%/922 Avg Render 33.63ms DWM glitches present 84
2)B 16/vector: 67%/606 Avg Render 11.11ms, 32/vector: 72%/586 Avg Render 12.71ms, 64/vector: 85%/630 Avg Render 16.35ms, 128/vector: 90%/743 Avg Render 23.57ms, 256/vector: 100%/953 Avg Render 37.27ms DWM glitches present 221
2)C 16/branches: 84%/544 Avg Render 11.28ms, 32/branches: 80%/605 Avg Render 12.78ms, 64/branches: 81%/642 Avg Render 16.35ms, 128/branches: 96%/753 Avg Render 23.48ms, 256/branches: 100%/953 Avg Render 37.34ms DWM glitches present 229
3) 1280/720 24p
4) 1920x1059
5) Max Performance
2)A 16/Scalar: 67%/565Mhz Avg Render 11ms, 32/Scalar: 96%/574 Avg Render 12ms, 64/Scalar: 80%/630 Avg Render 15.65ms, 128/Scalar: 100%/720 Avg Render 21.42ms, 256/Scalar: 100%/923 avg render 33.72ms DWM glitches Present 68
2)B 16/vector: 80%/553mhz Avg Render 11.48ms, 32/vector: 62%/561 Avg Render 13.08ms, 64/vector: 81%/655 Avg Render 16.45ms, 128/vector: 100%/764 Avg Render 23.73ms, 256/vector: 100%/955 Avg Render 37.56ms DWM glitches present 127
2)C 16/branches: 72%/523 Avg Render 10.83ms, 32/branches: 95%/584 Avg Render 13.19ms, 64/branches: 98%/648 Avg Render 16.44ms, 128/branches: 100%/760 Avg Render 23.58ms, 256/branches: 100%/953 Avg Render 37.70ms DWM glitches present 203
5) Image Quality
Zachs
24th April 2015, 02:20
With a GTX 980, I'm having a little higher GPU load with MPDN 64 neurons, compared to madVR (with the exact settings you have given).
With madVR, it's ~32% GPU usage when scaling 720p25 -> WQHD, with MPDN it's ~39%. The difference seems to get stronger when I additionally let both renderers downsample to maximized windowed resolution.
In both players, render and presentation queues are set to 4 frames (new windowed path).
I'm not giving much about render times since the GPU doesn't always run with the same clock.
But, it's working without any glitches on a quick try. Will do quality comparisons as soon as I got more time.
Very nice progress again! :devil:
Edit: Could someone please explain again what the technical reason is why NNEDI3 via DirectCompute is much slower than via OpenCL?
It's very hard to compare GPU load if the clock speed isn't the same between the two. Lower clock speed will incur greater load, but that doesn't mean it's doing more work - in fact it could be doing less. What I'm interested to know is which "path" is the fastest for your 980GTX.
1) Amd 290
2)A 16/Scalar: 84%/534 Avg Render 10.50ms, 32/Scalar: 88%/564 Avg render 11.85ms, 64/Scalar: 83%/610 Avg Render 15.34ms, 128/Scalar: 100%/725 Avg Render 21.30ms, 256/Scalar: 100%/922 Avg Render 33.63ms DWM glitches present 84
2)B 16/vector: 67%/606 Avg Render 11.11ms, 32/vector: 72%/586 Avg Render 12.71ms, 64/vector: 85%/630 Avg Render 16.35ms, 128/vector: 90%/743 Avg Render 23.57ms, 256/vector: 100%/953 Avg Render 37.27ms DWM glitches present 221
2)C 16/branches: 84%/544 Avg Render 11.28ms, 32/branches: 80%/605 Avg Render 12.78ms, 64/branches: 81%/642 Avg Render 16.35ms, 128/branches: 96%/753 Avg Render 23.48ms, 256/branches: 100%/953 Avg Render 37.34ms DWM glitches present 229
3) 1280/720 24p
4) 1920x1059
5) Max Performance
2)A 16/Scalar: 67%/565Mhz Avg Render 11ms, 32/Scalar: 96%/574 Avg Render 12ms, 64/Scalar: 80%/630 Avg Render 15.65ms, 128/Scalar: 100%/720 Avg Render 21.42ms, 256/Scalar: 100%/923 avg render 33.72ms DWM glitches Present 68
2)B 16/vector: 80%/553mhz Avg Render 11.48ms, 32/vector: 62%/561 Avg Render 13.08ms, 64/vector: 81%/655 Avg Render 16.45ms, 128/vector: 100%/764 Avg Render 23.73ms, 256/vector: 100%/955 Avg Render 37.56ms DWM glitches present 127
2)C 16/branches: 72%/523 Avg Render 10.83ms, 32/branches: 95%/584 Avg Render 13.19ms, 64/branches: 98%/648 Avg Render 16.44ms, 128/branches: 100%/760 Avg Render 23.58ms, 256/branches: 100%/953 Avg Render 37.70ms DWM glitches present 203
5) Image Quality
Thank you for such a detailed feedback!
All these reports will be very handy to come up with automatic "path" selection.
Anime Viewer
24th April 2015, 04:22
I've uploaded MPDN build 3066 to the test builds folder. It fixes a problem in 3065 where scaling luma wasn't skipped even when render script told it to, so it was unnecessarily scaling luma with MPDN's internal scaler even when it's already being scaled by nnedi3. So it should be make things a little faster.
I've also updated the nnedi3 script on GitHub - it now has an extra option called "Path" which presents you with 3 options: Prefer Scaler, Prefer Vector or Avoid Branches. Each GPU+driver works differently (as I've gathered from the tests you have done so far) so try out each path for each neuron setting, you'll find one that's fastest.
Same as before, I'd like feedback to be in the following format.
1) GPU name
2) 16/32/64/128/256 Neurons - Selected Path (Scalar/Vector/NoBranch) - GPU load / clock speed when it's running + render time (optional)
3) Source clip resolution / frame rate
4) Target resolution (must be bigger than source clip res)
5) Render quality settings (preferably "Image Quality" which is the MPDN default)
1) Nvidia 680m GTX (Optimus system)
2)
16/Scalar: 24%/718.5Mhz(gpu)900mhz(mem) (render 12-13ms),
16/Vector: 22-17% gpu load (clocks remain the same as in other test) 11-12ms,
16/Branch: 22% gpu (render 11-12ms),
32/Scalar: 33% gpu (render 16ms),
32/Vector: 31% gpu (render 15ms),
32/Branch 30% gpu (render 15ms),
64/Scaler: 52% gpu (render 24ms),
64/Vector: 48% gpu (render 24ms),
64/Branch: 48% gpu (render 22ms),
128/Scalar: 94% gpu (render 64ms) in other words dropped frames and failure to be a worthwhile setting,
128/Vector: 92% gpu (render 62ms) in other words dropped frames and failure to be a worthwhile setting,
128/Branch: 84% gpu (render 36-37ms) - Actually worked!?!
3) 848x480 23p
4) 1920x1080
5) Image Quality
At first I thought they all performed pretty similar, and that it wouldn't make much difference, but then I got the the 128 neuron test and there was a very significant difference. "Avoid Branches" seems to be the better choice for 680m GTX Optimus systems.
Zachs
24th April 2015, 04:29
At first I thought they all performed pretty similar, and that it wouldn't make much difference, but then I got the the 128 neuron test and there was a very significant difference. "Avoid Branches" seems to be
If the driver does a good job at utilizing the GPU resource with any given shader code, you should get the same regardless of which option you choose. NV hardware seems to like the "Avoid Branches" path, and yes the difference could be massive like what you saw. Blame the driver!
Anime Viewer
24th April 2015, 04:46
If the driver does a good job at utilizing the GPU resource with any given shader code, you should get the same regardless of which option you choose. NV hardware seems to like the "Avoid Branches" path, and yes the difference could be massive like what you saw. Blame the driver!
While the Intel 4000 HD can't handle any forum of NNEDI3 (render times are too high) it seems the Intel (or at least Optimus Intel's) seem to like the Vector setting best (70ms vs 190-Scalar and 206-Branches).
I feel like it would be slightly amusing if AMD turns out to work best with the third option (Scalar). Then each of the three vendor cards would work better with a different shader code.
ryrynz
24th April 2015, 04:47
At first I thought they all performed pretty similar, and that it wouldn't make much difference, but then I got the the 128 neuron test and there was a very significant difference. "Avoid Branches" seems to be the better choice for 680m GTX Optimus systems.
Can confirm on a 850m Avoid Branches is fastest at 64+ neurons. 32 neurons was a touch faster on Prefer Scaler and at 16 it's too close to determine a winner.
Zachs
24th April 2015, 04:54
While the Intel 4000 HD can't handle any forum of NNEDI3 (render times are too high) it seems the Intel (or at least Optimus Intel's) seem to like the Vector setting best (70ms vs 190-Scalar and 206-Branches).
I feel like it would be slightly amusing if AMD turns out to work best with the third option (Scalar). Then each of the three vendor cards would work better with a different shader code.
My Intel HD 4600 runs best with scalar - even does 320x180 256 neurons with only 73% GPU load!
From Scyna's feedback, AMD seems to prefer scalar/vector depending on the neuron setting.
Anime Viewer
24th April 2015, 05:10
My Intel HD 4600 runs best with scalar - even does 320x180 256 neurons with only 73% GPU load!
That's interesting. I would have guessed that all 4000 series Intel gpu would work better with the same option. I just found that there is a Intel gpu driver update available for my card (version 15.33.35.64.4176), so I'm going to download, install, and test to see if that changes anything (I expect NNEDI3 to still be unusable with the 4000 after the update, but I'll be curious to see if the scalar then works better or if ms render readings drop at all).
Edit: with the new drivers the scalar ms reading dropped slightly (from 190ms to 187ms), but vector still seemed to preform better with the Intel 4000. Maybe its an Optimus thing more than a 4000 thing, but regardless it doesn't matter since NNEDI3 is unusable with the 4000 anyway.
Zachs
24th April 2015, 05:14
That's interesting. I would have guessed that all 4000 series Intel gpu would work better with the same option. I just found that there is a Intel gpu driver update available for my card (version 15.33.35.64.4176), so I'm going to download, install, and test to see if that changes anything (I expect NNEDI3 to still be unusable with the 4000 after the update, but I'll be curious to see if the scalar then works better or if ms render readings drop at all).
Can't remember the exact improvements but the new driver improved it quite a bit for me.
Anyway, I've just found two other code paths that could make a difference, I'll add that and let you guys have a play.
ryrynz
24th April 2015, 05:50
My Intel HD 4600 runs best with scalar - even does 320x180 256 neurons with only 73% GPU load!
From Scyna's feedback, AMD seems to prefer scalar/vector depending on the neuron setting.
Same with nvidia. Intel HD graphics does better with Prefer Vector and considerably so.. Strange is that 64 neurons with Prefer Vector is twice as fast as 32 neurons set the same.. Any ideas why? In fact 64 neurons is faster than 16!
Zachs
24th April 2015, 05:56
Same with nvidia. The 820m does better with Prefer Vector and considerably so.. Strange is that 64 neurons with Prefer Vector is twice as fast as 32 neurons set the same.. Any ideas why?
Nope. Only Nvidia can answer that question I'm afraid!
My only very rough guess is that they do very specific optimizations for games and some conditions must've triggered it. On other cases, they couldn't be bothered.
ryrynz
24th April 2015, 06:08
Nope. Only Nvidia can answer that question I'm afraid!
My only very rough guess is that they do very specific optimizations for games and some conditions must've triggered it. On other cases, they couldn't be bothered.
Thought something was fishy there.. It was the hd graphics not the 820 that was running. Surprising what works for one doesn't work so well for others and changing depending on neuron count... I think this should perhaps be able to be set individually per neuron count. Trying to do it automatically might not work too well.
Zachs
24th April 2015, 06:14
Thought something was fishy there.. It was the hd graphics not the 820 that was running. Surprising what works for one doesn't work so well for others and changing depending on neuron count... I think this should perhaps be able to be set individually per neuron count. Trying to do it automatically might not work too well.
Yeah it certainly looks that way now. I might just leave it the way it is so you can select the neuron and the code path individually.
Zachs
24th April 2015, 06:19
OK guys, grab the latest nnedi3 script from github - it adds two more code paths. I've also optimized it further.
ryrynz
24th April 2015, 06:42
Have the first three been optimized further?
Zachs
24th April 2015, 06:47
It's a general (minor) optimization that affects all paths.
Zachs
24th April 2015, 07:10
but is works fine with EVR/madVR using direct audio with a 90 % buffer.
but i wouldn't be shock if the driver of this card are kind of "broken".
asus and creative doesn't really care about there driver.
the ac3 filter is load but not used i tried both 32 and 64 bit MPDN.
Can you try lowering MPDN's priority to high to see if it helps? I suspect the problem may be because you've only got 2 CPU cores. If it doesn't help, try lowering it down further and let me know which one works?
Scyna
24th April 2015, 07:37
1) Amd 290
2)A 16/Scalar small code: 88%/530 Avg Render 10.78ms, 32: 78%/575 Avg Render 12.14ms, 64: 87%/638 Avg Render 15.29ms, 128: 100%/717 Avg Render 21.17ms, 256: 100%/905 Avg Render 32.87ms DWM glitches present 13
2)B 16/vector small code: 78%/556 Avg Render 10.93ms, 32: 50%/610 Avg Render 12.96ms, 64: 93%/634 Avg Render 16.54ms, 128: 100%/749 Avg Render 23.18ms, 256: 100%/951 Avg Render 36.82ms DWM glitches present 259
3) 1280/720 24p
4) 1920x1059
5) Max Performance
2)A 16/Scalar small code: 59%/579 Avg Render 10.85ms, 32: 86%/589 Avg Render 12.62ms, 64: 80%/667 Avg Render 15.15ms, 128: 100%/734 Avg Render 21.41ms, 256: 100%/918 Avg Render 33.06ms DWM glitches present 6
2)B 16/vector small code: 61%/564 Avg Render 11.30ms, 32: 82%/596 Avg Render 13.02ms, 64: 81%/649 Avg Render 16.22ms, 128: 100%/743 Avg Render 23.48ms, 256: 100%/951 Avg Render 37.07ms DWm glitches present 251
5) Image Quality
Zachs
24th April 2015, 08:24
Looks like the small code versions did help AMD at 16 neurons!
huhn
24th April 2015, 11:12
Can you try lowering MPDN's priority to high to see if it helps? I suspect the problem may be because you've only got 2 CPU cores. If it doesn't help, try lowering it down further and let me know which one works?
i tried normal priority. to be honest i don't think a CPU like this really cares as long as the file is h264 and 1080p and lower.
here a screen from the performance issue:
http://abload.de/img/mpdntestbpbv7.png
i set GPU queue and CPU queue to the max but that doesn't help at all. they are not dropping now but the issue is the same.
i do an audio test next.
this can take time. all i do is searching for a small audio issue in playback they can be very obvious.
i had the problem in the past too. about 10 years ago on a AMD 64 system and a creative xtrem music audio card same issue low buffer 15-44%. a work around was the audio switcher in mpc-hc or using the ffdshow audio mixer and a ll audio props where gone.
Anime Viewer
24th April 2015, 12:03
OK guys, grab the latest nnedi3 script from github - it adds two more code paths. I've also optimized it further.
1) Nvidia 680m GTX (Optimus system)
2)
16/Branch: 22% gpu (render 11ms),
32/Branch 29% gpu (render 15ms),
64/Branch: 47% gpu (render 22ms),
128/Branch: 82% gpu (render 37ms) - still works - looks like gpu load dropped slightly (2%) compared to previous github version at this setting.
3) 848x480 23p
4) 1920x1080
5) Image Quality
Branch still works best for the Nvidia. All the optimizations (scalar, vector, and branch) all seemed to improve slightly (less gpu load) than the previous github version. Here are the new Scalar small code and Vector small code results:
2)
16/scalar small: 25% gpu (render 12ms),
32/scalar small 32% gpu (render 16ms),
64/scalar small: 76% gpu (render 34ms),
16/vector small: 22% gpu (render 11ms),
32/vector small 30% gpu (render 15ms),
64/vector small: 82% gpu (render 37ms),
64/scaler: 49% gpu 24ms
64/vector: 48% gpu 22ms
small appears to work worse (more gpu load and higher render times) in my case.
Zachs
24th April 2015, 12:37
MPDN v2.25.4 is now properly released.
NNEDI3 branch is no more - it's been merged into the main branch, so just download it via the links on the OP.
Shiandow has also integrated SuperRes with NNEDI3!
Have fun everyone!!!
trandoanhung1991
24th April 2015, 12:44
I'm getting crashes when seeking on the latest build. Application has stopped working.
Here's the log:
Faulting application name: MediaPlayerDotNet.exe, version: 2.25.4.3067, time stamp: 0x553a27ec
Faulting module name: CallbackFilter.ax, version: 0.0.0.0, time stamp: 0x546e875c
Exception code: 0xc0000409
Fault offset: 0x00008770
Faulting process id: 0x3038
Faulting application start time: 0x01d07e83883c7cdf
Faulting application path: C:\Program Files (x86)\Media Player.NET\MediaPlayerDotNet.exe
Faulting module path: C:\Program Files (x86)\Media Player.NET\Native\x86\CallbackFilter.ax
Report Id: ca156526-ea76-11e4-82cd-54271efce7d3
Faulting package full name:
Faulting package-relative application ID:
Here's the details on the file causing trouble:
http://puu.sh/hp4MN/447375194e.png
Also I couldn't found a way to change the neuron count when using NNEDI3 with SuperRes. Any ideas?
aufkrawall
24th April 2015, 13:00
It's very hard to compare GPU load if the clock speed isn't the same between the two. Lower clock speed will incur greater load, but that doesn't mean it's doing more work - in fact it could be doing less. What I'm interested to know is which "path" is the fastest for your 980GTX.
Sorry, I should have mentioned that the clocks were identical.
I unfortunately somehow also missed your information about the paths.
Well, prefer vector is faster than prefer scalar with the 980. ~10% higher GPU load with higher clocks (max boost, 1440Mhz).
With prefer vector, clock stays at 1126Mhz.
prefer vector vs. madVR: 35 vs. 31% GPU usage with both 1126Mhz. Just little room for performance improvement. :)
Shiandow
24th April 2015, 13:06
I'm getting crashes when seeking on the latest build. Application has stopped working.
Here's the log:
[...]
Also I couldn't found a way to change the neuron count when using NNEDI3 with SuperRes. Any ideas?
Neurons can't be changed yet, I'll add that when I have time. For what it's worth I expect using more neurons will have an even smaller difference when using SuperRes on top of NNEDI3.
By the way, could you try running that file without XySubFilter?
trandoanhung1991
24th April 2015, 13:11
Neurons can't be changed yet, I'll add that when I have time. For what it's worth I expect using more neurons will have an even smaller difference when using SuperRes on top of NNEDI3.
By the way, could you try running that file without XySubFilter?
That seems to have solved the issue. Any drawbacks to using DirectVobSub over XySubFilter?
Zachs
24th April 2015, 13:13
Did you recently update LAV filters? That seems to cause troubles with MPDN.
Shiandow
24th April 2015, 13:14
That seems to have solved the issue. Any drawbacks to using DirectVobSub over XySubFilter?
It renders the subtitles before scaling so they will generally have a lower resolution.
trandoanhung1991
24th April 2015, 13:44
I'd like to report a performance regression with the latest build.
Using the same extensions as found on here (https://github.com/zachsaw/MPDN_Extensions/tree/92a1648f9b4431ec8efa3ad8aa12f8fa936122c7), there is a performance regression of about 4-5ms between 2.25.4.3067 and 2.25.3.3059. Specifically, on 2.25.3 I was getting around 13-14ms render times and with identical settings, 2.25.4 gets me between 18-19ms render times. :(
ryrynz
24th April 2015, 13:47
I'd like to report a performance regression with the latest build.
Have you tested all optimizations? This with 16 or 32 neurons? Also you'd want to compare GPU utilization, render times don't always tell the full story.
Zachs
24th April 2015, 13:47
What render scripts are you running?
trandoanhung1991
24th April 2015, 13:49
What render scripts are you running?
Same as before: SuperChromaRes 3 pass > Deband > SuperRes NEDI 3 pass.
Shiandow
24th April 2015, 13:50
I'd like to report a performance regression with the latest build.
Using the same extensions as found on here (https://github.com/zachsaw/MPDN_Extensions/tree/92a1648f9b4431ec8efa3ad8aa12f8fa936122c7), there is a performance regression of about 4-5ms between 2.25.4.3067 and 2.25.3.3059. Specifically, on 2.25.3 I was getting around 13-14ms render times and with identical settings, 2.25.4 gets me between 18-19ms render times. :(
Which settings? Also, try the new renderscripts (see first post for a link) they might work better.
Edit: Especially SuperRes + NEDI is faster.
Zachs
24th April 2015, 14:06
Strange. Nothing I've changed should've affected render time that much! Are you sure all settings are the same?
Oh by the way are you using software decoder? If not, can you try it to see if it helps? MPDN used to wait until the decoder queue is full before playing. I've changed this to let it play much sooner. Once it gets filled though you should see render duration get back down though.
trandoanhung1991
24th April 2015, 14:06
What I did:
Use the extensions found here (https://github.com/zachsaw/MPDN_Extensions/tree/92a1648f9b4431ec8efa3ad8aa12f8fa936122c7)
Use this build http://mpdn.zachsaw.com/Old%20Releases/2.25.3/MediaPlayerDotNet_x86_2_25_3_3059.zip
Compare it with the latest build.
My settings are in the attachment.
Depending on files, there is a difference between 2-4ms in render time using the exact same settings between the 2 builds.
Zachs
24th April 2015, 14:30
I'll take a look to see if I can replicate that.
Anima123
24th April 2015, 16:51
SuperResFast, is it recommended to use with NNEDI3? Or how it should be used?
Shiandow
24th April 2015, 18:13
I'd like to report a performance regression with the latest build.
Using the same extensions as found on here (https://github.com/zachsaw/MPDN_Extensions/tree/92a1648f9b4431ec8efa3ad8aa12f8fa936122c7), there is a performance regression of about 4-5ms between 2.25.4.3067 and 2.25.3.3059. Specifically, on 2.25.3 I was getting around 13-14ms render times and with identical settings, 2.25.4 gets me between 18-19ms render times. :(
I'm actually noticing a similar regression from 2.25.4.3066 to 2.25.4.3067, in the mean time using 2.25.4.3066 might help, there should be a link a few pages back.
SuperResFast, is it recommended to use with NNEDI3? Or how it should be used?
Well it's very slightly faster, but it disables anti-ringing so if the performance difference isn't too significant I wouldn't use it.
Anima123
24th April 2015, 18:32
The regression you guys experienced might due to the tuned down priority of MPDN.
Scyna
24th April 2015, 19:12
just to let you know subtitles doesn't work on this build or the last beta build. after testing i always had to revert back to 2.25.3. Shiandow are you also going to add which optimization to choose from?
Shiandow
24th April 2015, 20:06
I'll eventually add a way to customize the settings for NNEDI3, but that'll require some more time.
Zachs
24th April 2015, 23:34
Can you try to change the process priority back to high with task manager to see if the regression issue goes away?
Zachs
24th April 2015, 23:37
Scyna, do you get the same crash with subtitles enabled as trandoanhung1991?
Scyna
25th April 2015, 00:04
I don't get any crash subtitles just don't show up.
Shiandow
25th April 2015, 00:24
Can you try to change the process priority back to high with task manager to see if the regression issue goes away?
Doesn't have any effect. I'd be surprised if it had actually, since the actual GPU usage also jumps by 20~30%. I honestly have no idea what could be causing it. Best I could come up with was that it was somehow stuck in "Max Image Quality" mode, but that doesn't seem to be the case since setting it to "Max Image Quality" is even worse.
Zachs
25th April 2015, 00:42
Shouldn't be too hard to figure this one out since it only affects build 3067.
Shiandow
25th April 2015, 00:47
FWIW the XySubFilter issue doesn't occur in build 3059, but does occur in build 3066. I can't narrow it down any more than that unfortunately.
Zachs
25th April 2015, 00:49
I'm on my mobile at the moment. Could you quickly try replacing all the files under native folder with those from build 3059?
Shiandow
25th April 2015, 01:03
That seems to have fixed it.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.