madVR - high quality video renderer (GPU assisted)

[Anime Viewer]

Anyone else experiencing frame drops reported by mpc-hc when turning on smooth motion in fullscreen?

The video looks smooth to me but mpc-hc reports about 140 frames dropped on 2000 frames drawn.

Also the framerate seems to be 44ish on a 23,976fps video

Are you using NNEDI3 for anything? Image doubling? Chroma upscaling? What dithering/error diffusion option are you using?

Many people have seen frame drops reported when using NNEDI3 doubling, Error Diffusion, and Smooth Motion combined. Try changing to Ordered Dithering or Random Dithering if you've been using Error Diffusion and see if the reports of dropped frames goes away.

[huhn]

Anyone else experiencing frame drops reported by mpc-hc when turning on smooth motion in fullscreen?

The video looks smooth to me but mpc-hc reports about 140 frames dropped on 2000 frames drawn.

Also the framerate seems to be 44ish on a 23,976fps video

i get this problem only with 720p60 6:4 cadence and in windowed too. i already created a report in the bug tracker.

but plaese check Anime Viewer suggestion i don't have a performance issue for sure!

[truexfan81]

How do you all manage to push your gpus to the limit running it at near 100% with smooth playback? If my gtx650 gets higher than 78% madvr starts dropping frames like crazy.

[Asmodian]

The GTX650 has a lower memory bandwidth (80 GB/s) and less other hardware features, maybe you are limited by something other than raw GPU power.

From bit-tech.net's (http://www.bit-tech.net/hardware/graphics/2012/10/04/evga-geforce-gtx-650-1gb-review/1) review:
"Like the rest of the 6-series, the GTX 650 is still based on the 28nm Kepler architecture, but in a similar vein to the GTX 660, it features a new GPU, the GK107. This GPU is significantly cut down in comparison to even the GTX 660's GK106, as it features just a single graphics processor cluster (GPC), compared the GK106's three. This GPC is identical to those found on all other Kepler based cards, and as such is subdivided into two streaming-multiprocessors (SMXs). As each SMX contains 192 stream processors and 16 texture units, this gives the GTX 650 a total of 384 stream processors and 32 texture units, compared to the GTX 660's 960 and 80 respectively.

The single GPC/dual SMX layout of the GK106 means that it features a pair of polymorph engines (one per SMX), and therefore a pair of tessellators, as well as just a single raster engine (one per GPC). Given the reduced size of the GPU, it should come as no surprise that the transistor count of 1.3 billion is significantly smaller than the 2.54 billion of the GTX 660's GK106 GPU. Consequently, the power draw of the GK107 is equally tiny with a TDP of just 64 watts."

[michkrol]

How do you all manage to push your gpus to the limit running it at near 100% with smooth playback? If my gtx650 gets higher than 78% madvr starts dropping frames like crazy.

It just works. I'm on Geforce GTX 750Ti, Windows 8.1 x64, drivers version 335.23.
With right settings (NNEDI doubling, etc.) with certain content I get GPU usage ~95%, render times ~40.6ms and playback is smooth with 23.976fps progressive content (41.71ms movie frame interval), max render time stays around 42ms, so the fluctuations are rather small.

You should check if some queues are empty when this happens or maybe your max render time skyrockets. If not it might be a driver or system problem. Render times can be too high with low GPU usage due to OpenCL interop and many other things. Another problem might be your GPU being throttled, especially with NNEDI enabled, check with GPU-Z or similar app whether your GPU is not lowering core frequency during playback.

[truexfan81]

It just works. I'm on Geforce GTX 750Ti, Windows 8.1 x64, drivers version 335.23.
With right settings (NNEDI doubling, etc.) with certain content I get GPU usage ~95%, render times ~40.6ms and playback is smooth with 23.976fps progressive content (41.71ms movie frame interval), max render time stays around 42ms, so the fluctuations are rather small.

You should check if some queues are empty when this happens or maybe your max render time skyrockets. If not it might be a driver or system problem. Render times can be too high with low GPU usage due to OpenCL interop and many other things. Another problem might be your GPU being throttled, especially with NNEDI enabled, check with GPU-Z or similar app whether your GPU is not lowering core frequency during playback.

i have the gpu set to go to performance mode when mpc-hc is running, i have the gpu monitor sidebar gadget running, it shows the gpu at fullspeed, is also how i monitor the gpu usage

when at more than 78% the render and backbuffer queues are empty

[cyberbeing]

when at more than 78% the render and backbuffer queues are empty

Have you tried enabling the "use separate device" settings? Those can help when you are pushing your GPU really hard.

Have you tried disabling flushing entirely, or otherwise tweaking your flush settings? Flushing adds delays which can potentially cause bottlenecks.

Do you bottleneck like this in all modes? Windowed (Old path | New path), FSE (Old path | New path), Overlay?

[truexfan81]

Have you tried enabling the "use separate device" settings? Those can help when you are pushing your GPU really hard.

Have you tried disabling flushing entirely, or otherwise tweaking your flush settings? Flushing adds delays which can potentially cause bottlenecks.

Do you bottleneck like this in all modes? Windowed (Old path | New path), FSE (Old path | New path), Overlay?

yes, yes, and yes, have to use Overlay to be able to run the thing at higher than 60%

[cyberbeing]

I assume you have no issues hitting 95%+ usage in 3D games, and your PCI-E slot running the GPU with the proper link speed x8 or x16, 2.0 or 3.0? Everything set to Application Controlled under Global 3D Settings in the NVCPL?

If so, it must be a certain feature which is stalling your GPU pipeline. Smooth Motion? 3DLUT? NNEDI3? Error-Diffusion Dithering? Debanding? Jinc? 32bit pixel shader buffer? Linear light scaling?

Back when I had my GT440 DDR5 and 7800GTX 512, I could certainly create bottlenecks at GPU loads like 80% in Windowed mode, with certain combinations enabled features and video framerates, but those GPUs were rather borderline performance wise anyway.

[truexfan81]

I assume you have no issues hitting 95%+ usage in 3D games, and your PCI-E slot running the GPU with the proper link speed x8 or x16, 2.0 or 3.0? Everything set to Application Controlled under Global 3D Settings in the NVCPL?

If so, it must be a certain feature which is stalling your GPU pipeline. Smooth Motion? 3DLUT? NNEDI3? Error-Diffusion Dithering? Debanding? Jinc? 32bit pixel shader buffer? Linear light scaling?

Back when I had my GT440 DDR5 and 7800GTX 512, I could certainly create bottlenecks at GPU loads like 80% in Windowed mode, with certain combinations enabled features and video framerates, but those GPUs were rather borderline performance wise anyway.


that is likely the bottleneck, pc is so old it only has pcie x16 1.1

[huhn]

that is likely the bottleneck, pc is so old it only has pcie x16 1.1

if you don't use nnedi or copyback deinterlacing pcie should matter at all copying 1080p60 8 bit to the gpu is a joke even for pcie 16x 1.1

[truexfan81]

if you don't use nnedi or copyback deinterlacing pcie should matter at all copying 1080p60 8 bit to the gpu is a joke even for pcie 16x 1.1

i do sometimes use nnedi, only 16 neurons tho

[Niyawa]

I did a quick search but I'd still like someone to clarify for me, what exactly "old path" and "new path" means?

[Mangix]

old path is buggy, makes most sense for xp, and breaks with some features like SmoothMotion.

new path is the default and is better. It is activated by checking "present several frames in advance".

[Niyawa]

Thanks, for some reason however, enabling new path makes playback impossible to me, and even using old path doesn't make things that much better. I'm not sure what madshi implemented in this version compared to previous 0.87.9 aside from it that could cause such a huge performance impact. I'll keep trying some settings to see what I can do about but I'll likely be downgrading if nothing works.

[huhn]

old path is buggy, makes most sense for xp, and breaks with some features like SmoothMotion.

new path is the default and is better. It is activated by checking "present several frames in advance".
I did a quick search but I'd still like someone to clarify for me, what exactly "old path" and "new path" means?

the old path is the original window mode. nothing should be broken with it.
the new path is a combination of fullscreen exclusive mode and window mode. it does the same what full screen excluive does without entering d3d fullscreen.

nothing should be broken for both and if something is broken feel free to make a new issue in the bug tracker. the old path should work with every thing like all older versions of madvr.

[cyberbeing]

that is likely the bottleneck, pc is so old it only has pcie x16 1.1
PCI-E x16 1.x (PCI-E x8 2.0 equivalent) shouldn't be too bad, unless your GPU isn't actually running at x16 link speed in 1.x PCI-E mode.

It's also noteworthy that GPU load will often fall significantly when madVR beings dropping a heavy number of frames. Like say madVR requires a GPU 2x more powerful than your current GPU to playback a sample without dropped frames with a particular feature, you may only see 60-80% GPU load while getting hundreds of dropped frames per second. On lower to lower-midrange GPUs which do not have overbuilt pipelines, you could also run into a situation like Feature A cost = 60%, Feature B cost = 10%, Feature C cost = 5% when used individually, but when using Feature A together with Feature B & C the required cost becomes >100%.

Thanks, for some reason however, enabling new path makes playback impossible to me, and even using old path doesn't make things that much better.
Not particularly surprising, since 'new path' Windowed is the slowest display mode in madVR, while 'old path' Windowed in the second fasted behind Overlay. Windows 8.1 handles the 'new path' Windowed mode significantly better, but I still found it slower than 'new path' FSE which seems to handle presenting in advance much better, especially at higher refresh rates and GPU loads.

[Mangix]

the old path is the original window mode. nothing should be broken with it.
the new path is a combination of fullscreen exclusive mode and window mode. it does the same what full screen excluive does without entering d3d fullscreen.

Both paths exist for both windowed and exclusive.

That being said, my comments regarding some features breaking was with the old exclusive path, not the windowed one.

Not particularly surprising, since 'new path' Windowed is the slowest display mode in madVR, while 'old path' Windowed in the second fasted behind Overlay.

My experience is different. By enabling NNEDI3 and setting it to 32 neurons to cause madVR to drop frames, the new path in windowed mode was the fastest. That is, fewer frames dropped. Overlay would render the first few frames and then slow to a crawl if I remember correctly.

[cyberbeing]

My experience is different. By enabling NNEDI3 and setting it to 32 neurons to cause madVR to drop frames, the new path in windowed mode was the fastest. That is, fewer frames dropped. Overlay would render the first few frames and then slow to a crawl if I remember correctly.
YMMV, then I guess. Windowed 'new path' is definitely the slowest mode on my GTX770. At very high GPU loads I experience massive presentation glitches, which do not occur with FSE.

[Niyawa]

YMMV, then I guess. Windowed 'new path' is definitely the slowest mode on my GTX770. At very high GPU loads I experience massive presentation glitches, which do not occur with FSE.
In my case it's just impossible to watch anything higher than 720p. Unless I disable smooth motion which honestly is one of the few things that keeps me tied to madVR feature-wise. Using new path is very slow and doubles my rendering time while old path is for some reason not as fast as it used to be.

What I did notice is that compared to how it used to be my "present queue" is always 0, using the same settings as before I guess that confirms it is a performance issue.

Well, it was about time I got a new PC and left this old laptop I guess.

[mzso]

have you been here:
http://www.dvbsupport.net/

I don't use DVB, but it may have some useful info for you

and I think this may be a little Off Topic...

QB

I doubt there is a more appropriate one.

By the way. What's all the software that can use madVR? Is Potplayer, KMPlayer, MPC variants, JRiver all of it?

[huhn]

I doubt there is a more appropriate one.

By the way. What's all the software that can use madVR? Is Potplayer, KMPlayer, MPC variants, JRiver all of it?

there is more, media browser can use it too. and thats not all

[StinDaWg]

Should I be using IVTC on hard telecined 1080i29 videos? It works fine with soft telecined, but with hard I get occasional stuttering, a few frames here and there per episode. I suppose this is madVR algorithm not handling it correctly. The weird thing is it does not happen every time on the same frames. If I see a small stutter I can quickly rewind it and it might not stutter again at the same spot. It's not dropping frames though according to the OSD. If I play it back with regular deinterlacing the stuttering goes away.

I suppose this is probably a question for madshi, hope to see you back soon!

[tyto]

If I decode with LAV does it already do random dithering? If so, should I disable madVR's diterhing or just starting decode with madVR?

(Since in Lav Video Decoder options I can see "Dithering mode")

[e-t172]

LAV only dithers if you're using it to convert to RGB. Unless you changed the default conversion options madVR does the conversion, and the dithering options in LAV have no effect in this case.

[turbojet]

Should I be using IVTC on hard telecined 1080i29 videos? It works fine with soft telecined, but with hard I get occasional stuttering, a few frames here and there per episode. I suppose this is madVR algorithm not handling it correctly. The weird thing is it does not happen every time on the same frames. If I see a small stutter I can quickly rewind it and it might not stutter again at the same spot. It's not dropping frames though according to the OSD. If I play it back with regular deinterlacing the stuttering goes away.

I suppose this is probably a question for madshi, hope to see you back soon!

I use it on hard telecined 1080i content regularly. With old window mode I experienced the occasional hiccup but not with the new window mode, overlay or fse. There are some shows that are time compressed and nothing works well because they remove necessary fields to shorten the time. There are some exceptions where the cadence isn't found correctly and have been mentioned in bug tracker. 25 fps at i29 doesn't currently work with madvr ivtc.

[Conquerist]

I have two feature requests.

Feature request #1: Keyboard shortcut for turning subtitles on and off when using XySubfilter, similar to "On/Off Subtitle" in MPC-HC.

Note: It's also possible to use the next/previous subtitle keyboard shortcuts from MPC-HC to toggle the subtitles, but that's not as convenient because 1) it's potentially necessary to step through many other subtitles to get to "none" and 2) the audio pauses and the video goes black while switching tracks.

Feature request #2: When switching subtitle tracks, show the track's title in the OSD.

Note: When switching audio tracks, both the MPC-HC OSD and the MadVR OSD display track language and track title. But on subtitle tracks, only the MPC-HC OSD displays both track language and title, the MadVR OSD only displays the track language.

Thanks for reading!

[cyberbeing]

I have two feature requests.

Feature request #1: Keyboard shortcut for turning subtitles on and off when using XySubfilter, similar to "On/Off Subtitle" in MPC-HC.
MPC-BE already supports this. For MPC-HC we're awaiting on this (https://trac.mpc-hc.org/ticket/4122), which despite its title, also includes VSFilter/XySubFilter support for the "On/Off Subtitle" hotkey and a few others.

[Stereodude]

Has anyone else noticed stuttering, dropped frames, and presentation glitches when playing back p60 material when using 3DLUT in some scenes? The average rendering time stays well under 1/60th of a second (the max spikes well above though). The upload, render, and present queue's drop to zero or seem starved. The decoding queue stays full.

With 3DLUT disabled the clip will play perfectly smooth with no glitches. I have tried this several times with consistently repeatable results. I'm using 0.87.10 on a 1920x1080 monitor. I have seen this with both 720p60 and 1080p60 content.

Is the 3DLUT done by the CPU or the GPU? Why would this only happen on certain scenes? Does the CPU/GPU load of the 3DLUT depend on the color palette of each frame?

[cyberbeing]

Why would this only happen on certain scenes? Does the CPU/GPU load of the 3DLUT depend on the color palette of each frame?

3DLUT is handled by the GPU.

NVIDIA GPUs experience load spikes during scenes which requires a large gamut corrections when using an 8bit 3DLUT. If you use a 6bit 3DLUT you should never experience slowdowns, though only yCMS output supports this. The 8bit 3DLUT woes on NVIDIA has been an ongoing issue since the initial madVR release in 2009, and I have a few posts about it in this thread. madshi was never able to determine why this occurs. AMD and Intel GPUs do not have this issue, it's an NVIDIA-specific quirk.

Though as NVIDIA's GPUs become more and more powerful, this becomes less of an issue over time. You'll only run into significant trouble if you buy underpowered entry-level cards, like the GT440 DDR5 I owned in the past. Once you reach mid-range and above, the anomaly quickly becomes insignificant.

[tyto]

How queues works?
OR better, how smooth motion works?

I dont understand how much presenting frames in advance is actually useful.

And how should I set queues: my pc can run fine with cpu queue and GPU at the cap, with 16 frame presented, but why should it bother, instead of using a smaller queue?

I guess for smooth motion you must have some frames in advance, but whats the point of having a huge queue size? Does it just increase gpu-cpu load?

[DarkSpace]

I have two feature requests.
madshi doesn't accept feature requests before madVR reaches 1.0.

EDIT: I misread some part of feature request #2, and wrote an unfitting answer.

[Stereodude]

3DLUT is handled by the GPU.

NVIDIA GPUs experience load spikes during scenes which requires a large gamut corrections when using an 8bit 3DLUT. If you use a 6bit 3DLUT you should never experience slowdowns, though only yCMS output supports this. The 8bit 3DLUT woes on NVIDIA has been an ongoing issue since the initial madVR release in 2009, and I have a few posts about it in this thread. madshi was never able to determine why this occurs. AMD and Intel GPUs do not have this issue, it's an NVIDIA-specific quirk.

Though as NVIDIA's GPUs become more and more powerful, this becomes less of an issue over time. You'll only run into significant trouble if you buy underpowered entry-level cards, like the GT440 DDR5 I owned in the past. Once you reach mid-range and above, the anomaly quickly becomes insignificant.
Thanks for the reply. I'm using the Intel HD 4600 graphics in a i7-4770k though, not an Nvidia card. Today the issue is gone though. I was doing some x264 encoding from AVIsynth yesterday in the background that was using about 35% CPU usage when I was testing. With that load no longer present on the system the video plays back very smoothly, even in the same problem scene. I guess the graphics weren't able to get enough memory bandwidth with x264 and AVIsynth doing their thing. :confused:

[cyberbeing]

I guess the graphics weren't able to get enough memory bandwidth with x264 and AVIsynth doing their thing. :confused:

That sounds likely, considering the performance of Intel iGPUs can easily become bottlenecked by lack of memory bandwidth. madVR requires ~15GB/s to even be usable, while Intel systems usually sit at ~20GB/s. Though its also possible x264's CPU load alone could have caused issues. The type of load x264 places on your CPU is rather unique in the respect that it can often be a better judge of system stability than most stress tests.

[yok833]

What is the good setting for 720P movies to fullhd Tv between :
Chroma Up :16 N
Image Doub luma : 16 N
Image Doub Chroma : 16 N

or

Chroma Up :32 N
Image Doub luma : 32 N
Image Doub Chroma : 0 N

Both with ordered dithering

My GTX 770 cannot go further with NNEDI3...

[Anime Viewer]

What is the good setting for 720P movies to fullhd Tv between :
Chroma Up :16 N
Image Doub luma : 16 N
Image Doub Chroma : 16 N

or

Chroma Up :32 N
Image Doub luma : 32 N
Image Doub Chroma : 0 N

Both with ordered dithering

My GTX 770 cannot go further with NNEDI3...

The general consensus is that Chroma Doubling doesn't have much visual effect while having a large drain on resources. Most people on the board would probably recommend the 2nd of the two.

That being said another general feeling for many people on the board is that NNEDI3 is most noticeable at resolutions lower than 720p, and that it is often difficult to see much (if any) difference between Jinc and NNEDI3 at the HD resolutions. Also a factor is what screen resolution you have it upscaling to. If you're going from 720 to 1080 its less significant than going from 720 to 1440.

You may also want to experiment with using Jinc for the Chroma upscaling which will free up resources you may be able to use for another feature (possibly increase your doubling to 64 -although again might be a waste-, or simply to tax your system less) at possibly no noticeable difference is visual quality to your eyes.

[StinDaWg]

I can't remember if this was posted before or not but there is a regression with NNEDI3 and the latest AMD drivers. I went back to 13.12 and I'm getting 3-5ms lower rendering time for 720p24 content at the same settings as 14.4. I'll stay at 13.12 until I hear otherwise.

[hozes]

i have 7850...for bluray watching, i habe no performans hit between random dithering, ordered dithering and error diffision...all are about 5ms...

my settings are renethx level 5 settings, chroma upscaling bicubic 75ar, for others which have no role in playing 1080p movies-image upscaling, image downscaling-image doubling- , jinc3 ar, ct ar ll, and no doubling...

debanding is set to low/high...

is it normal for 7850...my cpu is i2500k@4500mhz, in lav decoder "none" is selected...

[Conquerist]

MPC-BE already supports this. For MPC-HC we're awaiting on this (https://trac.mpc-hc.org/ticket/4122), which despite its title, also includes VSFilter/XySubFilter support for the "On/Off Subtitle" hotkey and a few others.Thanks for the info!

madshi doesn't accept feature requests before madVR reaches 1.0.Good to know...

[DarkSpace]

Good to know...
As I stated below that statement, I actually misunderstood your feature request #2. (I somehow read it as "for audio, MPC-HC and madVR display both name and language in OSD, but for subtitles, MPC-HC and madVR display only language", which I would have blamed on MPC-HC. I blame sleep for that.) I'm not sure if it actually qualifies as a bug, but I'd try to get others' opinions on that.

[Niyawa]

I found what was making my madVR go haywire. It seems that... the option in "devices" > your monitor > called "native display bit depth" was the culprit. Since I use a TN monitor I'd always assume 6-bit was the best for it, but the moment I put 8-bit again everything returned to how it was. I can't even see the increase that cyber told me I'd get for using the new path.

It's funny though, that option didn't make any difference in old path, but the new one made it useless for me. I wonder why is that...

[QBhd]

I can't remember if this was posted before or not but there is a regression with NNEDI3 and the latest AMD drivers. I went back to 13.12 and I'm getting 3-5ms lower rendering time for 720p24 content at the same settings as 14.4. I'll stay at 13.12 until I hear otherwise.

I can confirm this... after rolling back I was able to squeeze out even more neurons and actually notice the increase in PQ. So, I too will be sticking with 13.12 until something better comes along (better Catalyst or better madVR)

QB

[Audionut]

i have 7850...for bluray watching, i habe no performans hit between random dithering, ordered dithering and error diffision...all are about 5ms...

Same here on a 7850.

[michkrol]

i have 7850...for bluray watching, i habe no performans hit between random dithering, ordered dithering and error diffision...all are about 5ms...

Same here on a 7850.

The only reason for that would be madVR not using error diffusion at all and silently falling-back to ordered dithering.
Error diffusion uses DirectCompute, available only on DX11. Are you perhaps using Windows XP? Other than that it might be a driver issue. I don't own AMD's GPU, so can't help you here.
Try checking with GPU-Z if your cards support DirectCompute.
By the way, you can have working NNEDI and broken ED, since NNEDI uses OpenCL.

[mindbomb]

atm, does madvr only support 8 bit output? does selecting 6 bit in display properties do anything?

[hozes]

The only reason for that would be madVR not using error diffusion at all and silently falling-back to ordered dithering.
Error diffusion uses DirectCompute, available only on DX11. Are you perhaps using Windows XP? Other than that it might be a driver issue. I don't own AMD's GPU, so can't help you here.
Try checking with GPU-Z if your cards support DirectCompute.
By the way, you can have working NNEDI and broken ED, since NNEDI uses OpenCL.

i have win7 64bit...
in gpu-z directcompute was there with opencl...but renders time didnot differ between order dither, random dither and error diffisuion..

[Ceremony]

question: why is there no 64bit version of madvr? with it, we could have even larger buffers and overall performance could increase thanks to the larger registers.

I understand that you dont want to maintain both 32bit and 64bit, but with the death of windows xp, is there any reason to release a 32bit version? (talking to all users here)

Most non-ancient hardware should also be capable of 64bit without any issues. Also Vista's and Win7's 32bit keys are also valid for an identical 64bit edition, so even if you bought 32bit (by accident), you can still switch to 64bit on the next install (which I recommend).
There is no reason to still use a 32bit Windows OS (unless you really want to stick with XP).

[tp4tissue]

Hello Hello..

Once an image is upscaled from 1920 to 2560, How does that work with respect to viewing distance..

the equation for viewing distance has a factor for material resolution..

So, I am wondering how this works once Madvr upscaling is involved. ?

Link to equation here http://en.wikipedia.org/wiki/Optimum_HDTV_viewing_distance#Human_visual_system_limitation

[vivan]

with it, we could have even larger buffers and overall performance could increase thanks to the larger registers.But do we need larger RAM buffers and higher CPU perfomance?
madVR is GPU-heavy, CPU doesn't really matter there.

I understand that you dont want to maintain both 32bit and 64bit, but with the death of windows xp, is there any reason to release a 32bit version? (talking to all users here)Reclock?

So, I am wondering how this works once Madvr upscaling is involved. ?Works for pixels, doesn't work for details (video resolution).
E.g. if you will downscale video with a native resolution of your screen to 320x240 and then upscale it back - you'll be able to distinguish it from source video. However you won't be able to distinguish individual pixels of the display.

[huhn]

atm, does madvr only support 8 bit output? does selecting 6 bit in display properties do anything?
if you select 6 bit madvr will dither it to 6 bit. the picture it self is still 8 bit but the first 2 bit are not used anymore. this should increase dither quality for 6 bit tn panels because madvr dither should result in better picture quality and the screen shouldn't touch the 8 bit input with the first 2 bits zero.