GPU buffering - Revision history

Shadowdawn at 12:07, 14 December 2015

2015-12-14T12:07:50Z

← Older revision		Revision as of 12:07, 14 December 2015
Line 1:		Line 1:
			{{stub}}
	[[GPU buffering]] plays an important role in the [[motion-to-photon]] pipeline of current [[Virtual Reality Platform\|VR systems]]. Buffering optimization can greatly reduce [[latency]] and help minimize common problems such as [[simulator sickness]] or disorientation.		[[GPU buffering]] plays an important role in the [[motion-to-photon]] pipeline of current [[Virtual Reality Platform\|VR systems]]. Buffering optimization can greatly reduce [[latency]] and help minimize common problems such as [[simulator sickness]] or disorientation.

Line 4:		Line 5:
	According to [[John Carmack]], [[Virtual reality]] (VR) is one of the most demanding human-in-the-loop applications from a latency standpoint. The latency between the physical movement of a user’s head and updated photons from a [[HMD\|head mounted display]] reaching their eyes is one of the most critical factors in providing a high-quality experience.		According to [[John Carmack]], [[Virtual reality]] (VR) is one of the most demanding human-in-the-loop applications from a latency standpoint. The latency between the physical movement of a user’s head and updated photons from a [[HMD\|head mounted display]] reaching their eyes is one of the most critical factors in providing a high-quality experience.

	Human sensory systems can detect very small relative delays in parts of the visual or, especially, [[VR audio\|audio fields]], but when absolute delays are below approximately 20 milliseconds they are generally imperceptible. Interactive 3D systems today typically have latencies that are several times that figure, but alternate configurations of the same hardware components can allow that target to be reached.		Human sensory systems can detect very small relative delays in parts of the visual or, especially, [[VR audio\|audio fields]], but when absolute delays are below approximately 20 milliseconds they are generally imperceptible. Interactive 3D systems today typically have latencies that are several times that figure, but alternate configurations of the same hardware components can allow that target to be reached.<ref> http://altdevblog.com/2013/02/22/latency-mitigation-strategies/</ref>

	==How to Improve Latency by Preventing GPU Buffering==		==How to Improve Latency by Preventing GPU Buffering==
Line 12:		Line 13:

	[[File:render pipline basic1.png\|600px]]		[[File:render pipline basic1.png\|600px]]
			'''Source: “Latency Mitigation Strategies” by John Carmack'''

	*I = user input, S = simulation, R = rendering command, G = rendering of graphics, V = scanout, \| = Vsync		*I = user input, S = simulation, R = rendering command, G = rendering of graphics, V = scanout, \| = Vsync
Line 18:		Line 20:

	[[File:render_pipeline_no_gpu_buffering1.png\|600px]]		[[File:render_pipeline_no_gpu_buffering1.png\|600px]]
			'''Source: http://www.chioka.in/category/virtual-reality/'''

	==References==		==References==
	<references />		<references />

Shadowdawn at 12:05, 14 December 2015

2015-12-14T12:05:18Z

← Older revision		Revision as of 12:05, 14 December 2015
Line 11:		Line 11:
	The following picture illustrates the classic processing model used in [[VR applications]]:		The following picture illustrates the classic processing model used in [[VR applications]]:

	[[File:render pipline basic1.png\|~~700px~~]]		[[File:render pipline basic1.png\|600px]]

	*I = user input, S = simulation, R = rendering command, G = rendering of graphics, V = scanout, \| = Vsync		*I = user input, S = simulation, R = rendering command, G = rendering of graphics, V = scanout, \| = Vsync
Line 17:		Line 17:
	As you can see, rendering takes place only after every rendering command has been issued. This introduces unnecessary latency and simultaneously suggests a simple solution. If GPU buffering is prevented, rendering can start as soon as the first command is issued, thus reducing 16ms of latency.		As you can see, rendering takes place only after every rendering command has been issued. This introduces unnecessary latency and simultaneously suggests a simple solution. If GPU buffering is prevented, rendering can start as soon as the first command is issued, thus reducing 16ms of latency.

	[[File:render_pipeline_no_gpu_buffering1.png\|~~700px~~]]		[[File:render_pipeline_no_gpu_buffering1.png\|600px]]

	==References==		==References==
	<references />		<references />

Shadowdawn at 12:04, 14 December 2015

2015-12-14T12:04:52Z

← Older revision		Revision as of 12:04, 14 December 2015
Line 11:		Line 11:
	The following picture illustrates the classic processing model used in [[VR applications]]:		The following picture illustrates the classic processing model used in [[VR applications]]:

	[[File:render pipline basic1.png\|~~500px~~]]		[[File:render pipline basic1.png\|700px]]

	*I = user input, S = simulation, R = rendering command, G = rendering of graphics, V = scanout, \| = Vsync		*I = user input, S = simulation, R = rendering command, G = rendering of graphics, V = scanout, \| = Vsync
Line 17:		Line 17:
	As you can see, rendering takes place only after every rendering command has been issued. This introduces unnecessary latency and simultaneously suggests a simple solution. If GPU buffering is prevented, rendering can start as soon as the first command is issued, thus reducing 16ms of latency.		As you can see, rendering takes place only after every rendering command has been issued. This introduces unnecessary latency and simultaneously suggests a simple solution. If GPU buffering is prevented, rendering can start as soon as the first command is issued, thus reducing 16ms of latency.

	[[File:render_pipeline_no_gpu_buffering1.png\|~~500px~~]]		[[File:render_pipeline_no_gpu_buffering1.png\|700px]]

	==References==		==References==
	<references />		<references />

Shadowdawn at 12:04, 14 December 2015

2015-12-14T12:04:40Z

← Older revision		Revision as of 12:04, 14 December 2015
Line 11:		Line 11:
	The following picture illustrates the classic processing model used in [[VR applications]]:		The following picture illustrates the classic processing model used in [[VR applications]]:

	[[File:render pipline basic1.png]]		[[File:render pipline basic1.png\|500px]]

	*I = user input, S = simulation, R = rendering command, G = rendering of graphics, V = scanout, \| = Vsync		*I = user input, S = simulation, R = rendering command, G = rendering of graphics, V = scanout, \| = Vsync
Line 17:		Line 17:
	As you can see, rendering takes place only after every rendering command has been issued. This introduces unnecessary latency and simultaneously suggests a simple solution. If GPU buffering is prevented, rendering can start as soon as the first command is issued, thus reducing 16ms of latency.		As you can see, rendering takes place only after every rendering command has been issued. This introduces unnecessary latency and simultaneously suggests a simple solution. If GPU buffering is prevented, rendering can start as soon as the first command is issued, thus reducing 16ms of latency.

	[[File:render_pipeline_no_gpu_buffering1.png]]		[[File:render_pipeline_no_gpu_buffering1.png\|500px]]

	==References==		==References==
	<references />		<references />

Shadowdawn at 12:04, 14 December 2015

2015-12-14T12:04:23Z

← Older revision		Revision as of 12:04, 14 December 2015
Line 11:		Line 11:
	The following picture illustrates the classic processing model used in [[VR applications]]:		The following picture illustrates the classic processing model used in [[VR applications]]:

			[[File:render pipline basic1.png]]

	*I = user input, S = simulation, R = rendering command, G = rendering of graphics, V = scanout, \| = Vsync		*I = user input, S = simulation, R = rendering command, G = rendering of graphics, V = scanout, \| = Vsync

	As you can see, rendering takes place only after every rendering command has been issued. This introduces unnecessary latency and simultaneously suggests a simple solution. If GPU buffering is prevented, rendering can start as soon as the first command is issued, thus reducing 16ms of latency.		As you can see, rendering takes place only after every rendering command has been issued. This introduces unnecessary latency and simultaneously suggests a simple solution. If GPU buffering is prevented, rendering can start as soon as the first command is issued, thus reducing 16ms of latency.

			[[File:render_pipeline_no_gpu_buffering1.png]]

	==References==		==References==
	<references />		<references />

Shadowdawn: /* How to Improve Latency by Preventing GPU Buffering */

2015-12-14T11:58:43Z

How to Improve Latency by Preventing GPU Buffering

← Older revision		Revision as of 11:58, 14 December 2015
Line 9:		Line 9:
	In order to create a VR system with low latency, we have to consider every component and its individual involvement. Current LCD displays have fairly poor [[pixel switching time]] and [[refresh rate]]. This means that even if the latency on the host level is minimal, there still will be a noticeable delay between every image update. However, these issues will be easily solved as more advanced displays become prevalent.		In order to create a VR system with low latency, we have to consider every component and its individual involvement. Current LCD displays have fairly poor [[pixel switching time]] and [[refresh rate]]. This means that even if the latency on the host level is minimal, there still will be a noticeable delay between every image update. However, these issues will be easily solved as more advanced displays become prevalent.

	The following picture illustrates the classic processing model used in VR applications:		The following picture illustrates the classic processing model used in [[VR applications]]:

Shadowdawn at 11:57, 14 December 2015

2015-12-14T11:57:56Z

← Older revision		Revision as of 11:57, 14 December 2015
Line 16:		Line 16:

	As you can see, rendering takes place only after every rendering command has been issued. This introduces unnecessary latency and simultaneously suggests a simple solution. If GPU buffering is prevented, rendering can start as soon as the first command is issued, thus reducing 16ms of latency.		As you can see, rendering takes place only after every rendering command has been issued. This introduces unnecessary latency and simultaneously suggests a simple solution. If GPU buffering is prevented, rendering can start as soon as the first command is issued, thus reducing 16ms of latency.

			==References==
			<references />

Shadowdawn: Created page with "GPU buffering plays an important role in the motion-to-photon pipeline of current VR systems. Buffering optimization can greatly reduce ..."

2015-12-14T11:57:38Z

Created page with "GPU buffering plays an important role in the motion-to-photon pipeline of current VR systems. Buffering optimization can greatly reduce ..."

New page

[[GPU buffering]] plays an important role in the [[motion-to-photon]] pipeline of current [[Virtual Reality Platform|VR systems]]. Buffering optimization can greatly reduce [[latency]] and help minimize common problems such as [[simulator sickness]] or disorientation.

==Latency in Virtual Reality==
According to [[John Carmack]], [[Virtual reality]] (VR) is one of the most demanding human-in-the-loop applications from a latency standpoint. The latency between the physical movement of a user’s head and updated photons from a [[HMD|head mounted display]] reaching their eyes is one of the most critical factors in providing a high-quality experience.

Human sensory systems can detect very small relative delays in parts of the visual or, especially, [[VR audio|audio fields]], but when absolute delays are below approximately 20 milliseconds they are generally imperceptible. Interactive 3D systems today typically have latencies that are several times that figure, but alternate configurations of the same hardware components can allow that target to be reached.

==How to Improve Latency by Preventing GPU Buffering==
In order to create a VR system with low latency, we have to consider every component and its individual involvement. Current LCD displays have fairly poor [[pixel switching time]] and [[refresh rate]]. This means that even if the latency on the host level is minimal, there still will be a noticeable delay between every image update. However, these issues will be easily solved as more advanced displays become prevalent.

The following picture illustrates the classic processing model used in VR applications:

*I = user input, S = simulation, R = rendering command, G = rendering of graphics, V = scanout, | = Vsync

As you can see, rendering takes place only after every rendering command has been issued. This introduces unnecessary latency and simultaneously suggests a simple solution. If GPU buffering is prevented, rendering can start as soon as the first command is issued, thus reducing 16ms of latency.