The thing is And does have something that can be developed to a form ffr or even potentially. dfr. That being the FSR.
I wouldn’t put much stock in the current AMD benchmarks. (I mean, unless you’re buying a GPU today. Then absolutely do that,) Their drivers lag behind, but eventually get there. The 6000 series is pretty kickass for anyone not playing Cyberpunk with RT on; the 7000 should be the same in a few months time.
Good questions on FR though. It would be a shame if they fail to support that, and would probably kill AMD use for the 12K.
Hey, what about 3080ti?
Is not related as tested or to be tested…
I think all Nvidia cards are good.
1 Like
I hope so! Cause my 3080ti is not indeed listed. And the other ti, 3090, marked as 6m fiber cable needed.
1 Like
I tried the crysal on a 3080ti and it worked perfect. Was much better framerates than I expected actually.
2 Likes
I think we can make some assumptions that, without any notable architecture/functionality changes in cards post 2080, all such nVidia cards should be just fine.
AMD was, until recently, less clear. And… Nothing is ‘official’ until PIMAX runs their checks and has enough confidence to make a statement on their website for their product about it.
1 Like
But wait. Wasn’t one of the selling points of the Crystal its QLED + Mini LED and a tech that would help provide focus where the eyes are looking and reduce the resolution in the peripheral? This by itself without reliance on GPU tech.
No, you misunderstand, that’s on the GPU and the game engine.
The Game Engine has to have a degree of support for foveated rendering, but that’s not as out there as you’d think. Nvidia’s VRS can do jury rigged foveated rendering and through things like the VRPerfkit, you can do fixed foveated rendering even on flatscreen to VR mods, like the RE games, and get some tangible performance gains.
Nvidia has VRS for this, but AMD physically lacks something to do foveated rendering right now. Fixed Foveated Rendering exists right now in PiTool and the VRPerfkit, but ONLY Nvidia RTX cards can do it, because anything else lacks the hardware abilities to use it with the current framework for Foveated Rendering. DFR is basically just that, but moving the circle, least where the tech is at this moment.
Considering all the current Foveated Rendering methods that aren’t some super closed ecosystem with everything purpose built for it(Like the Q2) use VRS for their FR, I would assume Pimax is doing it the same way right now and thus AMD is incompatible. And I don’t see that changing if the game doesn’t build itself from the ground up to support gaze based rendering. Unless somebody at Pimax wants to correct me that it works on AMD.
Pimax have said that their DFR is driver level and doesn’t require support from the game, except in apparently a few fringe cases.
This is probably the claim for these new headsets that I am the most skeptical of, so not saying this as a solid fact that it is happening just mentioning the expectation Pimax is setting.
I just thought that the PIMAX Crystal itself could use the eye tracking to make in focus and increase the resolution of what the user is looking at and lower the resolution surrounding the focal point, so as to help increase performance. i.e. not necessary to drive a 4K display 100%
Perhaps this is what you’re talking about, but I swear somewhere that Pimax Said that their headset technology would provide that advantage and I didn’t see any reliance upon the GPU or game maker for this tech to work.
I think what this means is similar to how it already works for the 8KX now. Support is not required from the game because Pimax’s software uses DLL injection to forcibly add/enable foveated rendering support in the game engine.
In addition, besides foveated rendering, there is also foveated transport which must be occurring at the driver level, I think. And I’ve wondered how exactly this works because the game will need to perform foveated rendering in the game engine (like Omniwhatever mentions), but the information about the structure of foveated rendering will need to come along with each frame somehow, particularly since is moving around dynamically with DFR. Not clear how all that will work exactly. I don’t see a reason it can’t work technically, but there are a number of moving parts there that haven’t been defined anywhere that I’ve seen.
Anyway, I don’t think Pimax is lying about this or anything. But I think language isn’t being used very precisely. Especially, when they say driver level, they could mean they’re using a driver to perform the DLL injection.
2 Likes
Sargon already beat me too it, but it’s not universal support. Kev stated a bit back it worked in around 50% of games tested.
I’m pretty sure the feature is driver level, which means that it would get around certain blocks that currently prevent it(Like say, some versions of EAC notably, if I got my info right), but that does not mean it’ll work out of the box with everything unless it supports it.
1 Like
It does that via Foveated Rendering, as has already been outlined, which works the way both me and Sargon described.
We already have the capacity to do this via things like Varjo’s eye tracking or even the current Pimax HMDs with the eye tracker addon. They work the exact same way and have the same limitations. You can’t just change deep levels of a game engine with a flip of a switch like that. It’s just like how things such as Dynamic Resolution scaling exist, but you can’t just easily drop it into any game with the push of a button, the game has to support it or possess certain frameworks in place to enable it.
This is all assuming it works the same way it currently does, which I see no reason not to as it’s the case for literally every PCVR Foveated Rendering solution and headset right now.
Foveated transport happens after the game has already rendered the frames, regardless whether those frames have been rendered foveated or naive, and should be the work of a post-effect shader in Pimax’s software, courtesy of Tobii, working on the eye-texture bitmaps – I don’t see how that would need any GPU driver trickery…
Since it is Tobii and Pimax who dictate the foveation map - no matter whether fixed or per-frame, rather than the game, they know it (EDIT: …so do not need the game to tell them - they tell it, except for the odd game that actually does foveated rendering all on its own, (…as opposed to being none the wiser about whatever might modify its shaders behind its back), should such a one ever appear… :7).
As for FSR: It is not a VRS alternative (…although I am pretty sure I have read somewhere that AMD does have one), but a DLSS alternative, and both FSR and DLSS are likely to be somewhat tripped up by a foveated frame, since they do naive work regarding the bitmap density, that does not account for rendered pixels being repeated over blocks of output bitmap pixels – a special version of the two, which do take this into account, might be in order…
1 Like
Actually, you can combine FSR and FFR at least, the VRPerfkit does it and it’s a mod. The performance gains do stack and can lead to some pretty good boosts in supported titles.
However, that said it’s FSR 1.0, which requires much less deep access to the game engine functions than DLSS or FSR 2.0+ does. Which could potentially explain why they work together.
I don’t know of any VR game which natively supports FSR 2.0, but there’s a handful which support DLSS, I even own a few. Perhaps something worth testing to see if there are any performance gains, or even if it works.
1 Like
Oh, you can absolutely perform upscaling on a foveated frame, as it is - not suggesting otherwise; What I mean is that the upscaler could probably produce a better result, if it knew that you have repeat pixels, and had ways to deal with this, so that it could e.g. do some timely skips in such places, so that that 45 degree diagonal line does not look to it like a staircase. :7
EDIT: Even better if the “foveator” would produce single pixels with attached scale and position metadata, instead of producing pixel blocks… :7
1 Like
If it’s only using foveated transport to traverse a DisplayPort bottleneck, then I think that’s all it would need, yes.
However, gaining performance benefits (~40%) to frame rate requires that foveation be performed at the game engine level. There’s foveation happening at two different parts of the video pipeline here. If it’s only done for foveated transport after frame generation, then the game engine will have wasted its time rendering a lot of detail that just gets thrown away by foveated transport.
In order to get the full performance benefit, it must perform foveated rendering at the game engine and then perform foveated transport after the frame is generated. And the structure of that foveation will need to match exactly between the two for each individual frame somehow. My guess would be that information about this structuring is probably metadata that gets attached to each frame.
Exactly - they are are two distinct, independent things, which must not be confused or jumbled together.
One can use only either, or both together – in the latter case, one could of course give each a different foveation map, but why would one? (…other than possibly to account for eye motion in the time between frame rendering start and display, possibly with accompanying reprojection/frame synthesis.)
Anyway: Unless the game has its own foveation stuff, it is the eyetracker that knows where you are looking, and should be its software that tells the game how to foveate its rendering, so with it being the alpha and the omega here, and with it being integrated with Piserver, I imagine there is no foveation info that Piserver needs from the game.
Metadata, here, I imagine, would be something Tobii sends with the frames to the HMD, so that it knows how to recomposite the received bitmaps. :7
The PSVR2 headset have DFR and the PS5 have a RDNA2 card, so the architecture support DFR.
I hope that AMD update their PC driver to activate that also. (And in the 7000 cards if possible)
1 Like