DSC Problems & Misinformation [DSC IS NOT A HOAX]

[Chief Blur Buster]

Blur Busters' Word On The DSC Lag Rabbit Hole

This is a complex rabbit hole.

Short answer: DSC should not add lag, but latency-buggy DSC settings/codecs/gpus/devices do.
That's the bad DSC lag you heard from some influencers/youtubers/reviewers. But there's better DSC.

Here's the long answer:

Keep in mind DSC performance varies from monitor to monitor and GPU to GPU. Ideally, the best implementations adds no extra lag, but it's wholly true that lag-buggy early implementations may add wayyyy more lag. And sometimes it's the specific display model's fault, and sometimes it's the specific GPU or specific GPU driver's fault. Many whac a moles to do.

And some early GPU implementations emit a DSC signal that accidentally adds too much DSC latency when it should not. Even for slice sizes in the VESA DSC protocol that doesn't even warrant processing latency, but that it's easier for an early-programmed DSC implementation to buffer more and just post-process. And it does happen. Sadly.

Yes, in the best low-latency implementations possible, DSC often needs to buffer 1 pixel row so it can process the streaming compression properly, but a 1080p 240Hz signal is 135 kilohertz scan rate (135000 scanlines/sec). So 1/135000th second of latency, which is not feelable by a human. Unfortunately some firmwares royally bØяK3d the DSC implementation lag-wise, and here we are. Yup, #ConclusionJumpers.

In fact, Retrotink 4K (Blur Busters Approved video processor box for retro market) can inject BFI into a video signal that is less laggy than many TV firmwares' own native BFI. Simply because of how many TV firmwares more fully buffers and processes the signal before displaying the refresh cycle. See? I do paid work to reduce lag of various display processing.

#ScalerFirmwareImplementationFails
#DontJudgeAllScalersByOthers
#GPUsettingsFail
#JumpingToConclusions

DSC can be realtime stream decompression, and proper DSC feels exactly like 422 chroma (but better quality).
Worst DSC = more lag like what you witnessed.
Best DSC = no more lag than 422 chroma.

DSC can support slice sizes that affects latency of "lazy DSC codecs" (those not programmed to optimal latency):
VESA DSC Specification, Slice Size Chapters
But you can have a slice size of just a scanline and stream process it with nigh no latency. GPUs should expose more settings, etc, to make this adjustable, in theory.

In theory, slices don't really add latency because it's simply retroactive compression help. However, some actual implementation of codecs add unwanted latency, which is supremely dissapointing. But it is not a #DSChoax thing.

While I can say VRR has more lag than VSYNC OFF for many specific use cases (especially "framerates far exceed Hz" and/or "need mouse cursor" situations), the theoretical minimum DSC latency is far lower than the theoretical minimum VRR latency by at least two orders of magnitude from grade-school mathematics (average half a scanout lag penalty versus average 1 scanline lag penalty). So equating DSC and VRR lag as being law of physics equal, is just trying to claim 2+2=5 when the story is sadly more complciated.

It's a cesspool, yes.
But reviewers & users are jumping to conclusions.
Sadly, DSC needs to be lag-tested on a per-product basis, without wholesale DSC-algorithm conclusion jumping.

Switch GPU? Retest.
Switch Displays? Retest.
Yadda, yadda.

Oh and yeah, I edited the topic title for y'all. You are welcome

There are great points in this thread, Some implementations of DSC can be crappy yes. This part is factually correct for some, but not all DSC implementations.. But it is lost in the fog of "LOL DSC IZ HOAX" equivalent of a very completely faked bait topic subject, so I've removed the bait with #Facts. m'kay?

And hey hey, open source programmers of NVInspector style tools, please, please (CAN I HAZ HALP?)... Let us reprogram slice sizes of the outgoing DSC stream. Some displays will improve in lag if they're using buggy slice processors that accidentally adds lag. Changing slice sizes GPU-side can actually bypass some lag-bugs display-side (but not for all displays, sadly).

Oh my, if only stream codecs did not add unnecessary lag, I wish! Sometimes it's sender-side lag, and sometimes it's receiver-side lag, oh my, I wish I could find the correct tree in the lag forest, sometimes! But DSC is not a hoax. DSC is great for the refresh rate ....if implemented properly. 4K 1000fps 1000Hz OLED with lagless esports framegen FTW.

And please copy-paste the permalink to this post to your favorite DSC latency newbies:

Code: Select all

https://forums.blurbusters.com/viewtopic.php?f=2&t=12730&p=99795#p99795

I insist. Please freely throw this link to anybody who talks about DSC latency.

You're welcome.

</>
Yes, my famous micdrop, for descendants of "Humans Cant See 30-vs-60" debators.<- Tiny Easter Egg

[r0ach]

The problem with this statement is that when me and this other guy instantly notice DSC is a problem for heavy cursor movement on two different monitors (300hz Innolux and an LG panel inside of a Dell) from the two most expensive monitor makers: Dell with their eons of monitor selling experience, and Asus with their….highway robbery prices, it means the problem is so widespread there’s no point going near one.

People just don’t have the time and patience, nor will Amazon even allow you to return 10 monitors in a row. I’m starting to get nervous over here after 2 monitor returns on different accounts. If it’s actually possible to create a usable DSC monitor (which I consider 100% theory until I’ve actually used one myself), I hope you can understand that DSC currently does not meet the r0ach standard of approval.

[yehaw]

The problem with this statement is that when me and this other guy instantly notice DSC is a problem for heavy cursor movement on two different monitors

Ah, the good ol' "feels heavy, trust me bro" and "this other guy" testing methodology to prove your point.

How do you know "feels heavy" isn't from another aspect of the monitor that can affect input lag and come to the conclusion it's DSC? You just guessed, right?

[Chief Blur Buster]

The problem with this statement is that when me and this other guy instantly notice DSC is a problem for heavy cursor movement on two different monitors (300hz Innolux and an LG panel inside of a Dell)

This is most definitely a problem.

DSC has some extra unnecessary lag on many units.
But we have to correctly call this out, so monitor manufacturers actually FIX the problemz.

We have to be careful to nuance this in a way because of the services I do for monitor manufacturers or teach classrooms (ya ya, shameless plugs) to defacto beta-test monitors and tune monitors (many who ask for private tests, no logo, etc). Some of their reps reads the forums, and they need to see the truths. Their corporate policies don't allow them to engage in the forums, but some (not all) most certainly read user reports in many forums including this one. Etc.

The DSC problem is vexing when it comes to lag-bugs in firmwares, but I have to call this out scientifically accurately.

I'm not sweeping this under the rug; It simply just has to be called out accurately so the parties know what the [BLEEP] is going on. I have to be "Mister Manufacturer Whisperer" sometimes when I gently publicly scold manufacturers in the open-door manufacturer policy. A fine line indeed!

And yes, they often blame a different vendor sometimes. There's always two ends to a DSC connection (Manufacturer blaming the GPU maker, GPU maker blaming the manufacturer, somebody else blaming the specs that confused that newbie intern engineer, or somebody else just did not lag-optimize properly). And on top of this, there's third party chips (HDMI/DP transceiver vendors) and engineers making assumptions that milliseconds doesn't matter (when they actually do: Milliseconds Matters).

Sometimes what is happening is surprisingly mudane; a non-DSC-aware port transceiver having to relay the HDMI/DP data to a different chip that does the DSC-decoding instead. (Basically DSC slice buffering occurs before DSC slice is decoded, when that was unnecessary latency). Especially when it should have been decoded realtime on the fly as part of the ASIC built into HDMI/DP transceiver, or that the FPGA (or ASIC) in the monitor wasn't designed in a way to do zero-latency streaming decode of those DSC slices. Teamwork between two unfamiliar chips of different vendors can be hard for an engineer under extreme time pressure, to pull off, and --oops-- some lag-bug slips in.

Sometimes the geek-topic discourse is targeted surgically, to get action done sometimes!

[r0ach]

The Innoview 240hz 1440p monitor (INVCM708-02B) runs at 10bit with DSC on by default. On the Asus XG27AQMR, turning DSC on just makes the monitor unbearable to use by bogging down your mouse movement. On this Innoview, DSC causes chop/stutter while panning in games (in addition to the exact same bogged down mouse movement as seen on the Asus).

Setting the monitor to 8bit turns DSC off and removes both of these problems. DSC causing stutter is an outlier, but it does NOT appear to be an outlier that it causes bogged down cursor movement. Therefore I would advise people to not purchase any monitor that relies on it to function or otherwise turn it off if you can.

*side note - the VA panel in this monitor appears to be the exact same as the Samsung G51c 1440p flat screen (G5 tier), just overclocked from 144/165 to 240hz. Very weird. As you can imagine, there's almost no benefit in doing so.

[Chief Blur Buster]

(merged: It's forum policy to merge same-topic + same-topicstarter content into same threads)

Yoohoo manufacturers, take heed. I'm annoyed by DSC bugs too. (Some, not all, manufacturers monitors these forums too)

[r0ach]

I'm telling you DSC is going to go down as the largest boondoggle in gaming monitors ever. I do not believe this is a firmware or implementation problem when it seems like every single monitor using DSC feels completely terrible to aim with having it turned on. Even the unwashed Reddit masses have noticed:

[Kyouki]

Is there software that allows me to read this out or figure this out?

[Brainlet]

Is there software that allows me to read this out or figure this out?

https://tomverbeure.github.io/video_timings_calculator
https://nvidia.custhelp.com/app/answers ... -%28dsr%29

DLDSR and DSR are incompatible with DSC, so based on this and the timing calculator above, you should be able to take an educated guess.

[r0ach]

Is there software that allows me to read this out or figure this out?

If you use higher than 8 bit 1440p 240hz on DP 1.4 then DSC is on. At 1080p I think it enables higher than 360hz. There’s also exceptions like if the monitor allows you to turn off DSC like the XG27AQMR then setting 300hz works but runs at YCBCR 422 instead of RGB full or 444.

When I used a 1070 GTX I noticed that on Nvidia mouse movement was a lot different between modes like HDMI full (0-255) and HDMI low (16-235), so if you use some non-standard color space like 422 you will probably notice your aim is way off compared to normal 8 bit RGB. Not sure about regular 8 bit RGB vs 10 bit RGB. Don’t have a monitor to test between the two at native hz with DSC off.

Also if anyone knows of a registry key to change between 8/10bit with AMD drivers installed in “driver only” mode, don’t be shy with that solution (or a way to replicate clamping colors to standard SRGB which you can do in the AMD driver menu but without installing the UI while installing via “driver only mode”).