CPU VR latency

[Xebec]

Hi folks --

Are there any good analyses of CPUs affecting VR latency and framerate in Elite Dangerous with Horizons?

Something showing the generations of CPUs, preferably including a 5775C broadwell with the 128MB L4 cache for comparison?

I can't seem to find any.. (if my search skills suck, please call me out on that by showing me links ).

Thanks!
CMDR Xebec

 

[[HJ]-RedRaven]

Many are reporting good results over i5 2600 CPU's.

Your i7 5775C is probably one of the lesser-known processors, but at 3.3-3.7GHz its no slouch.

Are you using your 5775C broadwell in a laptop, or desktop? (I presume desktop)
Is it slow/feel slow with other games?
What video card are you using it with?

 

[vizvayu]

Hi folks --

Are there any good analyses of CPUs affecting VR latency and framerate in Elite Dangerous with Horizons?

Something showing the generations of CPUs, preferably including a 5775C broadwell with the 128MB L4 cache for comparison?

I can't seem to find any.. (if my search skills suck, please call me out on that by showing me links ).

Thanks!
CMDR Xebec

I'd be interested in this as well. However I think most latency problems regarding CPU in Elite VR come from IO Wait... like network related or lack of cache.
Just a personal opinion not saying that for a fact.

 

[[HJ]-RedRaven]

I'd be interested in this as well. However I think most latency problems regarding CPU in Elite VR come from IO Wait... like network related or lack of cache.
Just a personal opinion not saying that for a fact.

Yes, I think this may be the core issue with some USB 3.0 controllers... they might allow USB 3.0, but they're slow at passing data between the Oculus sensor, headset and software etc.

 

[vizvayu]

Yes, I think this may be the core issue with some USB 3.0 controllers... they might allow USB 3.0, but they're slow at passing data between the Oculus sensor, headset and software etc.

I was thinking on something much more simple like lack of pre-loading and caching needed data from disk or from the network. Many times it looks like ED loads stuff as needed in the instant it needs it (like the micro-stutter felt always when jumping from system to system).
Besides, I'm using Vive, not Oculus

 

[[HJ]-RedRaven]

Many times it looks like ED loads stuff as needed in the instant it needs it (like the micro-stutter felt always when jumping from system to system).
Besides, I'm using Vive, not Oculus

Its difficult to predict which assets need loading in advance, especially in a game where human input is in a sense, chaotic.

I'm not sure how ED caches assets - many engines will rank assets based on how often they're accessed, size etc, and fill all the VRAM with high-ranked assets so pre-loading is minimised - you only get a load when something 'unusual' needs to be loaded that wasn't already in VRAM.

But there's several quite large textures that can't be cached - the stars. Generating the starfield as seen from your destination is one of the main 'simulation-like' features of ED. There's no way to predict your next jump until you enter it, and then the starfield shader needs to be loaded (it will be loaded into the 3D shader cores each time you jump) and the whole task must be completed in the time it takes to warm up the drive, 5 sec countdown plus the jump itself. It also has to load the star (from disk), nav positions and see if anyone is around locally at the arrival point (network).

So there's a lot going on for the CPU and for the 3D card (and all the while it is rendering a 'worm-hole' so you have something to look at!) If it simply showed a black screen you wouldn't notice any micro-stutter.

 

[vizvayu]

Its difficult to predict which assets need loading in advance, especially in a game where human input is in a sense, chaotic.

I'm not sure how ED caches assets - many engines will rank assets based on how often they're accessed, size etc, and fill all the VRAM with high-ranked assets so pre-loading is minimised - you only get a load when something 'unusual' needs to be loaded that wasn't already in VRAM.

But there's several quite large textures that can't be cached - the stars. Generating the starfield as seen from your destination is one of the main 'simulation-like' features of ED. There's no way to predict your next jump until you enter it, and then the starfield shader needs to be loaded (it will be loaded into the 3D shader cores each time you jump) and the whole task must be completed in the time it takes to warm up the drive, 5 sec countdown plus the jump itself. It also has to load the star (from disk), nav positions and see if anyone is around locally at the arrival point (network).

So there's a lot going on for the CPU and for the 3D card (and all the while it is rendering a 'worm-hole' so you have something to look at!) If it simply showed a black screen you wouldn't notice any micro-stutter.

As I see it, the witch space is a loading screen. They have plenty of time to preload everything on the next system, and on a different thread to avoid locking up the graphics engine. But what I was referring was actually the loading screen itself. It's like it stutters every time it starts when it loads those weird clouds. They should just keep that in memory... it's not that much and it's used all the time anyway. They should avoid at all costs locking up the graphical engine while waiting for IO.
As for the mission board... I have absolutely no idea what could take that long, and why do they have to do it every single time I open the board, or after I accept a mission. Something is definitely missing there (cache maybe?).