StrobeMaster wrote: ↑18 Nov 2024, 06:02
No, I meant that VRR might cause other issues which I am not willing to deal with.
Makes sense. It does, give you the advantage of a much more deterministic time between Present()+Flush() and photons, that is usually constant on all monitor models, as long as you help the driver get the frame begin to get delivered immediately. I've seen jitter shrink to 10us leagues on some machines. I'd realistically do 100us + realtime app + realtime thread, but make sure to immediately yield CPU to drivers (Present+Flush) to help the drivers speed up the start of new refresh cycle.
It does create other problems and issues, though --
But it's at least autodetectable by a photodiode connected to the display, feedbacking to the system. You can kind of detect VRR is working by intentionally randomizing intervals between Present()'s well within the VRR range and then seeing the lag doesn't vary. An autodetect calibration pass confirms VRR is working + confirms error margins quite easily. Sometimes easier than trying to beam-race the VSYNC, in some cases, just a whole new workflow to learn which is the initial hassle.
StrobeMaster wrote: ↑18 Nov 2024, 06:02
I don't see how. In which way should the tweaking go? At least for 120Hz, the frequencies match rather well (a difference of only one frame in about 11 minutes). If the PLL is not even able to work in this case, then what? Making the mismatch bigger, like feeding 121Hz instead of 120Hz? Or is it more about the timing details (front porch, back porch, and such)? Moreover, "always-reliable" would mean, at least to me, that the lag is really always the same, not one day this and the other day that.
Just as you see the 240Hz frameskipping bugs, you can see how a firmware-based PLL disengages/engages with only minor timings changes. It's a low-effort (5min of playing with ToastyX) to see if it produces consistency for your specific model running specific firmware.
Low odds, but low-experimentation-effort (Try only two or three timings variants). Sometimes things latch, much like timings tweaks on early 240Hz.
Chief Blur Buster wrote: ↑16 Nov 2024, 19:27
Even more surprising then that ASUS screwed up, no? I don't see why new refresh rates should make such a bug more likely - the processing logic should be independent of refresh rate. Or did they think that nobody cares at such high refresh rates, so let's keep it simple? I am a bit afraid that this will never get fixed, because it is easily overlooked (like in reviews) and/or is not considered a bug. Well, let's see.
Oh boy, where do I start...
(here goes, drum roll)
[IMPORTANT DISCLAIMER: Industry wide general issue. This is well known stuff rather than NDA stuff here. This has nothing to do with ASUS in particular -- this is generic industrywide problem. Note that the ASUS people who I do work with from time to time; The people I deal with still try to pull off miracles within the budget of one gaming monitor model, to compete with others. It's very cutthroat competition industrywide]
You have to understand these are 3-figure priced displays rather than 5-figure priced displays, where almost all vendors (even big ones too) subcontracts to chinese scaler/TCON vendors such as MSTAR, TPV, AOC, Suzhou Lehui, to do the low level programming.
This ain't the IBM T-221 beautiful Wizard of Oz days, where you did everything in house, where IBM lovingly worked on the two FPGAs driving from opposite ends of the displays, as ultra-bleeding edge scalers/TCON doing 4K in year 2001 for about $10K a pop.
Also, according to publicly available statistics, a monitor models sells by the tens or hundreds of thousands, rather than television selling by the millions. At these margins, it's pretty hard to budget a (discount generic) QA crew on things that gets easily unnoticed by electronics engineers or FPGA/ASIC developers who aren't gamers. The Milliseconds Matters crew isn't always there.
Sometimes the collab is very buggy for an initial release, like the first-gen 144Hz displays, or the first-gen 240Hz displays. We're currently on first-gen 480Hz OLEDs.
If you want the Porsche sports car, a display manufacturer subcontracts to NVIDIA as the scaler/TCON vendor -- you're getting a GSYNC scaler (G-SYNC chip). Not the case here, though. Even when NVIDIA is the scaler/TCON vendor (as is for G-SYNC native), they sometimes have bugs. But right now, I believe all OLEDs are done on a G-SYNC Compatible basis (AFAIK), as OLED fast pixel response and performance often makes it hard to add the premium.
In many cases, you've got ACME™ RoadRunner vendor trying to polish CoyoteTron™-supplied panels with a chinese NoName™ scaler/TCON vendor with CubicleFarm™ staff. You've got situations where an employee at NoName™ used VESA-CVT-RB2 and their subcontract at CubicleFarm™ used VESA-CVT-RB3, and the panel was only designed to PLL at either RB2 or at RB3....because they only did fulltime autosync during VRR=ON but not during VRR=OFF, in their perpetual-full-refresh-cycle autobuffering situation. And staff at CubicleFarm™ don't speak English as first language, so you have to keep explaining technicals like ELI5. Full refresh cycle framebuffering just in case of HDR processing and all, you can't beamrace the scanlines in modes that requires find-and-measure-all-brightest-pixels, which requires full refresh cycle framebuffering rather than beamraced sync.
And the price quote given by CubicleFarm™ to re-setup a model after teardown at the end of a project, to fix a bunch of bugs? It's possible for CoyoteTron™ and ACME™ to balk at a 10x price quote for trying to fix a 3-year-old monitor that no longer has a dedicated laboratory of already-setup-specimens for it.
D'oh. Roll, roll the dice, baby! Maybe only 10% chance, but sometimes low-effort experimentation causes one model to shut up cupcake and sync. Weird model-specific bugs of all kinds. The cutthroat race-to-bottom also did its number on the bugcounts too, in an era of increasing display complexity.
And yes, I've had some difficulties getting monitor manufacturers get their panels Blur Busters Certified, and the firmware bugs often make it hard to award logos to them -- I've got a few abandoned pre-prandemic Blur Busters Certified DVT/EVT prototypes in the back. Also a few old VA turds that couldn't be successfully polished, too (Several are still nice for office work though).
And sadly, sometimes bugs end up unfixable even when budget is spent. Sadly, that sometimes happens, e.g. Mudane blockers like a write-only FPGA (permanently jumpered readonly), or a unreprogrammable ASIC because of a rush on a bleeding edge new tech, and the firmware flash process being unable to go deep enough to fix it. This type of bug is alas, not recall-league, but can be errata'd into a new submodel release with a newer circuit revision.
/unpacked
P.S. Submitted latency bug report to ASUS staff. They've ticketed it. I have no idea if it's an intrisinic hardware limitation
