A lot of people seem to forget that classic TVs with their interlacing at low frequencies didn’t look good just (or even mostly) because of persistence of vision, but because of slow phosphors and unfocused lines. The screen was blurred in both a resolution and movement sense, so the discrepancies from field to field wouldn’t dominate too much. In VR, we’ve so far actively worked against the delay blur (high persistence) and the focal blur has been insufficient to cover the gaps (screen door effect), let alone blending with nearby pixels, though some devices try with diffusion screens. An odd observation is that I wouldn’t be surprised if you could interlace some LCD panels by driving them an entirely out of spec pattern - basically double the horizontal retrace pulses. Where CRTs achieve the half-line offset by literally drawing a half scanline (this is why the bottom scanline is halved), LCDs take the horisontal sync pulse to mean the next scanline should start receiving data. Higher resolution ones, like the Sharp display I mentioned in the first post, do have interlacing in an odd-even pixel pattern. Given that our display panels now are digital devices and effectively hold a frame buffer, I would think it might make more sense to move to a compressed delta scheme. Let all the pixels behave in a hold-and-modify style, with new changes fed over an aggressively compressed signal that can skip over static parts, no matter how detailed. A modern example of an interlaced display is high resolution image shifting projectors.
Side note: the temporal discrepancy between eyes Doc Ok described for the Oculus DK2 is precisely what “Brain Warp” tries to exploit, by doing reprojection on the later eye to match its presentation time. The new Pimax HMDs don’t do the rolling exposure, however, and the 5K/8K might actually have to drop to a lower frame rate to order the video signal for the eyes in such a manner (ANX7530 is designed for a horizontal split, in which both eyes receive data practically in lockstep). For the 8K X it does not matter as they don’t even share a cable, and they could be phase offset if desired. Top-and-bottom or frame packed modes are notably less efficient over the wire than side by side, as they multiply the blanking periods. (I could be mistaken in that the panels could be short scanline form in the first place; that would also lose efficiency and could explain some of the refresh rate problems!)
@LoneTech Reading your posts here I understood that you assume 80% of horizontal space is what Pimax understands as 80% utilization, right?
Next, I realized that I never considered audio, encoded in DP stream. I guess this increases the bandwidth requirement for ANX7530. Do we know, what audio encoding/streaming is used by VR and how it impacts the overall bandwidth?
Concerning your suggestion about restricting the “rendering view” on 4K panel by using command mode to redefine the image placement in the panel, I assume it would require using DP aux channel to pass those commands to the HMD. Is it possible with current Windows implementation? I was trying to find out any info on Nvidia cards and user access to the DP aux channel, but did not find any?
Yes, I assumed there was horizontal space going unused. That may or may not currently be the case but it’s a sacrifice I would be willing to make to push the frame rate a little bit. As noted, I ended up sacrificing 8% of the resolution for 12% faster refresh rate, and that’s while assuming I couldn’t tune the vertical timing.
As for audio, it is likely negligible. Just the vertical blanking period here, even with my reduced pixel count mode, represents some 640Mbps. Compare an unusually (perhaps even ridiculously) high quality signal of stereo 24 bits per sample 192kHz; that’s about 9Mbps. Audio tends to be insignificant, as capacity goes.
As for the command mode shifting, it doesn’t need to be controlled by the host computer, and even if it were it would likely be easier to signal over USB (where the IPD position itself would be reported, as well as tracking data) than using the DisplayPort.
It is known that ANX7530 has limit of 720MHz pixel clock.
Implications for Pimax 8K:
5120x1440@90 pclk is 714.23MHz, very close to limit, stability in risk
5120x1440@80 pclk is 631.91 MHz, should be stable, 80Hz confirmed stable by Pimax.
Implications for Pimax 8K X:
3840x2160@90 pclk is 811.44Mhz, much above ANX7530 limits, will require new chip, that explains delay and price diff between 8K/8K X .
3840x2160@80 pclk: 717.76MHz even closer to 720 than 2x1440p@90, probably not stable, hence the need for new chip.
Conclusion, if Pimax rush with delivering 8K to backers, they may get 2x2560x1440@80Hz, for 90Hz it was noted that there is backup input res of 2x1920x1080 source .
If Pimax can solve 2160p@90 native per eye with new chip on 8K X, I think this option should be offered to 8K backers who prefer to wait for 90Hz, or probably that chip will not have enough slots for 2 screens, since 8K X use 2xDP, and 8K 1xDP… Confusion with 3 products is real .
I am excited about that solution for native 4k@90/eye, since that can translate to Pimax 4K v2, that could use one of 8K X screens, and be great alternative to Win MR headsets, if priced correctly.
@Matthew.Xu Any news on the questions asked in here, in particular @LoneTech suggestions regarding the pixel clock?
I wonder how did Pimax originally plan to overcome the pixel clock limitation of ANX7530 in the design, when it had to be clear right from the chip spec that 720 MHz pixel clock is not enough for a naive implementation of 90Hz refresh.
Did you plan to reduce display active area (as suggested by @LoneTech), or did you plan to operate ANX7530 out of the spec? And if the latter, did you test such an operating mode before committing to the DisplayPort design?
@SpecsReader I am not sure what is your point here. I have asked @Matthew.Xu about the limitations of ANX7530 and you are coming up with an explanations about panels.
Please, do not answer for Pimax, and do not state your speculations as the answers.
Some good information but also a bit of speculation here and there.
I beliefe or hope that the team is developing the best possible solution and I would be very happy if maybe till christmas they could state on what they are planing or doing to get to a satisfactory image quality in this mater - would be nice to know where this is going first hand rather than hoping for the best.
He is right you are speculating as we do not know the panel model or info. The bridge chip does seem to be the factor. The Bridge chip does state 90hz as a max value & as Jim pointed out often electronic componets often do not perform at max advertised spec. Gigabyte advertises Theoretical performance & states if componets work at best spec.
Well Pimax marketed 4K HMD as 90Hz async, so what stops them from using same method on 8K…
My assumption, and would like to proven wrong, Brainwarp is “invented” to solve async MTP problems from 4K. Without Brainwarp, you will just get more sick at 90Hz/eye than on 75Hz/HMD. Give us facts, not examples how someone markets 90Hz as boost, when industry is having 90Hz stable standard for 6DOF VR…
The 4k model is not the same panel as the 8k panels. The 4k uses a sharp panel at 60hz.
As i and others have used the v2 prototype we can assure you its not the same panel & the sub pixel layout is somerhing like rgbw where as the 4k is rgb
I have read the comments and thank you for your attention to our products. Today we are talking with the software team about the refresh rate issues. Now, Pimax 8K refresh rate is stable at 80Hz and the software team is trying various schemes to debug 85Hz and 90Hz. I will update the refresh rate for any new progress. Thank you
Ok, sorry about async vs sync, I understand that we don’t need async on 8K since we have 2 screens and CLPL is working on panel, no shutters needed.
But 90Hz/ eye is in Brainwarp mode, right? Input is 60Hz/HMD.
Also have question about DSC on MIPI on V1-V2 vs no DSC on V3, is that maybe reason for drop of refresh rate? Panel Driver IC is spec’d at 90Hz with DSC(on MIPI) or no?
[quote=“matthew.xu, post:26, topic:4150, full:true”]
Today we are talking with the software team about the refresh rate issues. Now, Pimax 8K refresh rate is stable at 80Hz and the software team is trying various schemes to debug 85Hz and 90Hz. [/quote]
Thank you, Matthew, for the update.
if you look at some of the steamvr pimax reviews where they show the output it states 80hz as the output as you can see here
EDIT: This is for the 8kX … but ive also seen one for the 8k where it states that it runs at 75hz. Will look for it!
Good news guys, I found the actual input res. Pimax 8K V1 and V2 use DSC 2:1 with 16b/pixel color 4:2:0 on input. And were stable 90Hz.
If we use same mode on V3, we run into 720MHz limit that ANX7530 has.
Since Driver IC DSC mode is 3:1(2 mipi/panel/IC), we need to send to each panel 3840x1080@90 data, this means actual input res per HMD is 3840x2160. Actual 4K, as Pimax was saying in FAQ on KS, they removed that I think.
Now here is why you can’t have 90Hz stable with such mode of operation: 3840x2160 @ 90.000 Hz Reduced Blank (CVT) field rate 90.000 Hz; hsync: 202.860 kHz; pclk: 795.21 "high risk they say, I say impossible" 3840x2160 @ 80.000 Hz Reduced Blank (CVT) field rate 80.000 Hz; hsync: 179.440 kHz; pclk: 703.40 "Stable" 3840x2160 @ 82.000 Hz Reduced Blank (CVT) field rate 82.000 Hz; hsync: 184.090 kHz; pclk: 721.63 "Risky, 720 is limit"
So it is pixel clock after all. But because of no DSC support on input… GPU has to do DSC compression(or at least color compression) for HMD to operate at 90Hz. That is my understanding. Could be wrong, probably not. BTW DSC on MIPI is by using anx7530 DSC engine 3:1, 2160hx3840v fed into it(not by using DSC but simple sub/up sampling) Huge loss of image quality comparing to DSC method to reduce BW on DP/HDMI(GPU-HMD cable).
Here are some specs, not to think I imagine stuff
ANX7530 is DP interface/splitter with two display support. It is not a scaler. So it receives 2x 25601440 and outputs the same resolution. You may either consider it as two separate 25601440 frames or one frame 5120*1440 which is split. Either way you need to redo your math.
.
