It’s not about them but in this case but about my lack of confidence in the project at this crucial moment. Of course I can understand if people keep supporting, the concept is great.
Hope you guys will have lots of fun with it and maybe I join later.
Unfortunately, I’m with you on this. I’ve been agonising over whether to push the button or not, but I’m just not feeling confident enough to invest at this point in time (I can’t afford to buy each and every generation that comes out!).
I think these new HMDs will push the technology forward, and I am grateful to the backers for supporting PIMAX, just as I was grateful to the backers who originally supported the Oculus Rift, because they are supporting these VR pioneers to constantly improve their products.
However, for me the technology is close but isn’t quite there in terms of what I want from VR in terms of image clarity and FOV.
There have been plenty of excellent discussions (that PIMAX employees have been monitoring) during the course of the Kickstarter campaign, so hopefully some of the ideas proposed will be introduced into the next generation of HMDs, and perhaps they will tick all my boxes.
Congratulations to everyone who has taken the plunge and chosen to back these 5K and 8K headsets, I’ll look forward to monitoring your experiences, and hopefully at some point I’ll have an opportunity to demo the 8K in the near future.
I think it’s not that bad to skip a generation because the developments in VR are really taking of now. Next year we will see lots of new products (and announcements) and that is very exciting on itself.
But I am a person that does not have to be on the first row evertime some new device comes out and am happy with my rift and gaming Pc for simracing. Bought my Rift a few months ago as B-stock (new) for 320 Euros so that was luck.
And I keep following the developments too of course. VR has a bright future 
That is very smart idea, well done! I am more SW guy, and I read from Pimax SW engineer he explained why with 1DP input they can’t run 8K at native res(so they use scaler).
One of the reason is with 2 displays per chip, DSC can’t work.
My guess is that is why 8K X has 2xDP input, and DSC can work, so no need for “hacks” ?
But, that does increase cost +200$ over 8K and require GPU to support DSC(part of DP1.4 standard?) So they say you need 1(or 2?)xGTX 1080Ti or Volta GPU.
Not because rendering frames at that resolution is hard, but outputing 2x3840x2160@90 with DSC is a tall task even if is rendering simple VR scene.
2x DP1.4(with DSC) + 2x ANX7530 is in 8K X final solution? Can Pimax team confirm?
Hm. I guess you are right, with DP1.4 input it doesn’t support DSC. So why even market(ANX7530) as DP1.4 if can’t support HBR3 nor DSC lol .
Ok this is why 8K X is delayed I guess(comparing to 8K), they don’t have the solution yet probably…
For 8K X, it is for sure that current cards won’t be able to do 90 fps. For 8K, i do not know, noone really tested. But I doubt that titles such as Project Cars 2 or DCS will run at 90. With newer games, I usually don’t have 90 fps on single 4K display with 1080Ti with descent video settings.
i dont know what any of this means but i want them to hire you.
Hey LoneTech, you really know display hardware, super cool ! Really offtopic here but I hope you don’t mind, I wanted to ask you if you know about panel configuration commands ? With the Pimax 4k I’ve been trying to allow for 4k mode. I reverse engineered the firmware and managed to find all the commands that the FW sends to the panel, but I never managed to make sense out of them, as I explained here: http://community.openmr.ai/t/developers-hackers-thread/1475/12?u=sjefdeklerk (as you can see the only commands that made sense to me are the commands used to create the EDID data)
I managed to dump the ‘initialized data’ which contained the bulk of the LCD configuration data, which I saved: MEGA (so these are all the LCD config commands that were in the intialized data block, there were a few more in the FW code itself, like the EDID config commands I just mentioned)
Maybe you can take a look and see if it makes sense to you ? Each command is 6 bytes, so use 6 byte rows in your hex editor for a quick overview. Thanks !
(BTW there are 4 bytes missing from the file I just uploaded, I see from another dump that they’re 0x8c, 0x20, 0x0, 0x0)
But I’m sure you’ll notice this table starting at 0x102:
00 00 8c 00 00
00 01 8c ff 00 00
00 02 8c ff 00 00
00 03 8c ff 00 00
all the way up to
00 7c 8c 20 00 00
Where that 2nd byte is increasing with one every time, the 3rd byte always is 0x8c and that 4th byte seems to be the key here (some config data), but what does it represent ? I think these commands are used to config a 0x7c byte block in the LCD panel but how do I figure out what this represents ? Maybe it makes sense to you ?
EDIT LOL I just noticed that this table at 0x102 must the bulk of the EDID data 
Notice how it says “PIMAX P1” when you read that 4th column, at 0x2D0 
Also it says “MSCEM8R6K9DAK” , both strings are in the EDID data I just saw via an EDIDviewer.
So that’s solved So the main question is: what are those commands before 0x102 ?
No quick answers, I’m afraid. But PCA9587 sounds very much like a Philips I2C chip, perhaps an extender; a GPIO or bus switch chip, in the PCA95xx I²C, SMBus Repeaters, Switches, Expanders - TI | Mouser / General Purpose I/O (GPIO) | NXP Semiconductors / I²C Logic Multiplexers/Switches | NXP Semiconductors family. There’s also an I2C controllable audio amplifier with the same part number TDF8597: TDF8597TH | I2C-Bus Controlled Dual Channel 43 W/2 Ω | NXP Semiconductors
I might look a bit more at this later. One note, though; It’s quite likely the panel really can’t diverge from 60Hz, if it doesn’t have a self refresh feature. You might get stuck only displaying data on a fraction of the screen, for instance.
Yeah that’s what I feared and why I abandoned the whole project. I managed to find a datasheet for the LS055D1SX04 which is almost the same as our panel (LS055D1SX05) and I think I understood it might only do 60 hz … I never was 100% sure about this though.
Ah, here is the LS055D1SX04 datasheet, maybe you can take a quick look too: https://ds0.me/LS055D1SX04.pdf
It seems to say on page 13 that only 59-61 hz are supported ?
If you read the partial screenshot in the PimaxSWD post you linked, that chip does not support DSC on the DisplayPort side, period. It only supports it on the MIPI side in single or dual mode, while the 8K demands quad mode.
The listed pixel clock limits for dual or quad streams would suffice only for 65Hz or 86Hz, respectively. Given we’d run uncompressed at the input side, this matches up with the DisplayPort capacity of 17.28Gbps, producing exactly 720MHz pixel clock at 24bps… theoretical maximum, disregarding any sync/audio/whatever overhead. I guess the good news is, that means the 720MHz pixel clock is peak input rate, not necessarily an internal limitation. The bad news is, it literally cannot carry 3840x2160@90 at 24 bits per pixel.
At two MIPI ports, the maximum pixel clock listed produces about 22.2 bits per pixel raw capacity on the MIPI DSI side, suggesting the limit is for the DSC compressor, not the output port itself.
I called the fact that 720MHz pixel clock was on the DP side good news, because it means we may be able to produce faster outputs with less information in them. This could mean porch timing hacks are applicable as an alternative to command mode.
Okay folks i have created a special topic for team members & community members with technical skills in that area. Please only those ppl post in that topic.
http://community.openmr.ai/t/2017-q4-bandwidth-refresh-summit/4150?u=heliosurge
Any posts or users with demonstrated knowledge related to the above topic post a link in that topic.
Those community members linked with pokes let me know of others to add.
Precisely. And if you look at page 14, you’ll see the invisible data during HFP/HBP (horizontal front/back porch) which is the margin I’d like to tune. Within the DisplayPort bridge chip, our limit is on visible data, so we could let the bridge chip send more invisible data for us when there are parts of the panel that aren’t really visible.
Ok, well too bad but it at least explains why Pimax never allowed for 4k native @ 23 hz I had hoped they were simply not interested in this mode but the display can not support it. And from what you posted in this thread it seems it might be difficult to get 2x4k native too for the 8k X at 90hz. Hoping there’s indeed some kind of tweak to get it going but it does sound like a big deja vu.
i am not sure that 3 times more pixels means you need a gpu 3 times more powerfull. I don t know much about graphic engines but I assume that a part of the rendering is not linked to the output resolution.
Resolution is not everything, of course, but is a pretty big part. For example, plenty of graphic cards can run modern games on Ultra settings at 1920x1080 with 60+ fps, but only most powerful ones can do the same at 3840x2160.
we need to compare a gtx 1070 to a gtx 9xx thar performs as good at 1080p and then see the différence at 4k. Beside raw power there are optimisations in the architecture.