Forum Discussion
Time warp shaders
Hi,
because it is Sunday, i was curious to look at if i could gpu capture ( renderdoc, vsgd, nsight or whatever ) the oculus server. Sadly, nothing worked, but i was mostly looking for the distortion shader, so i digged in the executable, and the DXBC are not encrypted :)
I found 32 shaders, most of them seems to relate to the debug display and are VS/PS, the core system is four compute shaders, depends if you provide a depth buffer or not and if you hit a multipass blending..
without depth, but blend to the framebuffer :http://jsbin.com/dabiqopuda
with depth : http://jsbin.com/yipexeceha
without depth, replace the framebuffer :http://jsbin.com/sanogitaxa
and an other compute : http://jsbin.com/vufeqayiza
They are long shaders, so i have not yet extract any meaning full logic in them, the compute receive only 4 swap chain texture at a time, if you have more than 4 in flight texture in your layers, it runs the compute several times and you accumulate cost.
A thread group is made of 64 threads (8x8x1), very typical, but only output 4 values, we do have a 4x4 thread block to write a single pixel, this is i guess to compute derivatives for mip mapping on quad layers, but it may be for something else too.
There is also a bunch of manual srgb to linear transformation, after the compute read a texture ( 3 reads because texcoord for each channels are different follow by the srgb to linear based on an unknown condition). This is a little strange as they recommend to us to create fee them with SRGB texture and the hardware is able to do it at the sample call site !
The last compute seems to account for the panel pixel persistance, they use the current and last frame buffer to change the pixel value in order to fight ghosting, it is know on monitor as overdrive mode.
because it is Sunday, i was curious to look at if i could gpu capture ( renderdoc, vsgd, nsight or whatever ) the oculus server. Sadly, nothing worked, but i was mostly looking for the distortion shader, so i digged in the executable, and the DXBC are not encrypted :)
I found 32 shaders, most of them seems to relate to the debug display and are VS/PS, the core system is four compute shaders, depends if you provide a depth buffer or not and if you hit a multipass blending..
without depth, but blend to the framebuffer :http://jsbin.com/dabiqopuda
with depth : http://jsbin.com/yipexeceha
without depth, replace the framebuffer :http://jsbin.com/sanogitaxa
and an other compute : http://jsbin.com/vufeqayiza
They are long shaders, so i have not yet extract any meaning full logic in them, the compute receive only 4 swap chain texture at a time, if you have more than 4 in flight texture in your layers, it runs the compute several times and you accumulate cost.
A thread group is made of 64 threads (8x8x1), very typical, but only output 4 values, we do have a 4x4 thread block to write a single pixel, this is i guess to compute derivatives for mip mapping on quad layers, but it may be for something else too.
There is also a bunch of manual srgb to linear transformation, after the compute read a texture ( 3 reads because texcoord for each channels are different follow by the srgb to linear based on an unknown condition). This is a little strange as they recommend to us to create fee them with SRGB texture and the hardware is able to do it at the sample call site !
if_nz r3.w
494: mov_sat r14.x, r14.x
495: lt r3.w, r14.x, l(0.040450) // typical srgb boundary
496: mul r6.w, r14.x, l(0.077399) // srg constant 12.92
497: add r8.w, r14.x, l(0.055000)
498: mul r8.w, r8.w, l(0.947867)
499: log r8.w, r8.w
500: mul r8.w, r8.w, l(2.400000)
501: exp r8.w, r8.w
502: movc r14.x, r3.w, r6.w, r8.w
503: mov_sat r19.x, r19.x
504: lt r3.w, r19.x, l(0.040450)
505: mul r6.w, r19.x, l(0.077399)
506: add r8.w, r19.x, l(0.055000)
507: mul r8.w, r8.w, l(0.947867)
508: log r8.w, r8.w
509: mul r8.w, r8.w, l(2.400000)
510: exp r8.w, r8.w
511: movc r19.y, r3.w, r6.w, r8.w
512: mov_sat r20.x, r20.x
513: lt r3.w, r20.x, l(0.040450)
514: mul r6.w, r20.x, l(0.077399)
515: add r8.w, r20.x, l(0.055000)
516: mul r8.w, r8.w, l(0.947867)
517: log r8.w, r8.w
518: mul r8.w, r8.w, l(2.400000)
519: exp r8.w, r8.w
520: movc r20.y, r3.w, r6.w, r8.w
521: else
522: mov r19.y, r19.x
523: mov r20.y, r20.x
524: endif
The last compute seems to account for the panel pixel persistance, they use the current and last frame buffer to change the pixel value in order to fight ghosting, it is know on monitor as overdrive mode.
No RepliesBe the first to reply