googlestadia / porque4k Goto Github PK

Single displayed image, with either vertical or horizontal split merging two images (internal + native, as an example).
The split should be changeable via UI interactions (click-drag)

Right now, we just allocate 1 MiB per frame (soon to be 4 MiB) of CPU-visible GPU memory in order to push constants via dynamic uniform buffer. This number is totally fabricated. We should validate the actual usage, and pick an amount based on that like sane engineers.

Karis14: http://advances.realtimerendering.com/s2014/epic/TemporalAA.pptx
Pedersen16: https://github.com/playdeadgames/temporal/blob/master/GDC2016_Temporal_Reprojection_AA_INSIDE.pdf

With VK_AMD_mixed_attachment_samples, we would be able to get full depth resolution for our checkerboard rendering. We can then use that full-res depth to better inform our checkerboard resolve.

There are outstanding questions about how it interacts with VK_EXT_sample_locations. Using these two extensions together would be required, since the default 4X MSAA sample locations are not suitable for use with checkerboarding.

Would make it easier for contributors to figure out where they can plug in

https://www.guerrilla-games.com/read/decima-engine-advances-in-lighting-and-aa

• Simple image delta (absolute values)
• Luminance delta (visual significance)
• Grayscale/intensity delta
• Absolute values overlaid over grayscale image
• Texture LOD visualizer

In order to save some ALU, and more importantly, save register pressure, it would be great to use FP16 in some of the data-parallel friendly parts of the checkerboard resolve (velocity and color processing).

Reference notes here: https://gpuopen.com/first-steps-implementing-fp16/

The swapchain is created with VK_FORMAT_B8G8R8A8_UNORM in order to set the STORAGE image usage flag.
The internal renderpasses uses UNORM as well, but should be converted to SRGB, and then have the final compute composite handle the conversion to the correct color space.

Right now, we use add_custom_command to build shaders. However, add_custom_command doesn't care about dependencies triggering shader compiles (e.g. modifying a header).

I'm not entirely sure what the right solution is here. I was thinking of using add_custom_target, but that just builds all the time, which I don't want either. I don't want to just treat it as HLSL, because I can't control the DXC compiler, and that doesn't work for Ninja. Which maybe isn't a huge deal.

Right now we calculate color information for the reconstructed pixels, whether the pixels are moving or not. If the entire wave isn't moving, maybe we can just end the entire wave early and pass the previous results through.

Instead of hand-coding the binding indices, we should be grabbing the info from reflection. We'll have to some app-specific metadata (like this texture should bind to the 'NormalTexture' or whatever), but that's way more maintainable than what we have now

Alternatively, we could use a shared header for the shaders and Vulkan code

Right now we are using

set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++14")

To make sure the GGP VS generator works correctly.

But it should be

set(CMAKE_CXX_STANDARD 14)
set(CMAKE_CXX_EXTENSIONS OFF)

Details here: chaoticbob/CMake#1

Right now, all we got it start/stop of the animation. There should be property control + manual manipulation.

Could be either Sponza, Breakfast room, Bistro, or Damaged Helmet
https://github.com/GPUOpen-LibrariesAndSDKs/Cauldron-Media
https://casual-effects.com/data/

Initial model will be Damaged Helmet
https://github.com/KhronosGroup/glTF-Sample-Models/tree/master/2.0/DamagedHelmet

https://github.com/GPUOpen-Effects/FidelityFX/tree/master/FFX_CAS

Right now, we follow this pattern in the app code:

VkDeviceCreateInfo device_ci = {
  VK_STRUCTURE_TYPE_DEVICE_CREATE_INFO,
};

To be more clear (and safe), we should do one of these two patterns instead.

VkDeviceCreateInfo device_ci = {
  .stype = VK_STRUCTURE_TYPE_DEVICE_CREATE_INFO,
};

VkDeviceCreateInfo device_ci = {};
device_ci .stype = VK_STRUCTURE_TYPE_DEVICE_CREATE_INFO;

Ideally some set of common techniques that we could use to interact with the internal and target images

Possible techniques:
Ambient Occlusion
AA
Bloom
Blur
DOF
Tonemap
Grain

Would likely leverage that infrastructure for a temporal resolve for dynamic scaling