JBR-5973 Vulkan update

[YaaZ]

• Fixed all validation errors.
• Added proper synchronization and image layout transitions.
• Refactored VKRenderer to hold per-device rendering context. Added per-surface render pass contexts.
• Isolated surface rendering contexts to minimize state changes. Now rendering commands are recorded per-surface.
• Added batching where possible: per-rq-flush commands, per-surface drawing commands, swapchain presentation, pipeline creation.
• Added logic for tracking and reusing arbitrary resources. Implemented for command buffers and semaphores.
• Fixed surface resize, refactored surface initialization to be robust to event order and allow delayed swapchain creation.
• Added proper choice of sRGB surface formats and spec-conformant sRGB->linear conversion for colors coming from Java.
• Added on-demand pipeline creation for actual surface formats.
• Added VK_KHR_dynamic_rendering for dynamic render pass parameters - clear, view format, multisampling(?).
• Added missing destruction logic across all Vulkan code.
• Added macros for easy checking of return codes, logging with source code location.
• Added lazy implicit initialization for dynamic arrays. Implemented ring buffer.
• Moved implementation details out of headers where possible. Stripped dead code.

[bourgesl]

Will review it tomorrow

[YaaZ]

OOM strategy implemented as follows:

• ARRAY_ALLOC returns NULL on failure
• Other macros which may cause allocation call VK_UNHANDLED_ERROR() on failure
• Some of these macros has "ARRAYTRY*" counterparts, which keep previous state on failure
• malloc and calloc calls are checked with VK_RUNTIME_ASSERT()

[avu]

Concerning dynamic rendering, did you check what particular hardware does not support it? For example, this feature is available only in 470.62.07 NVidia drivers.

[avu]

Please have a look at this link https://vulkan.gpuinfo.org/listdevicescoverage.php?extension=VK_KHR_dynamic_rendering Looks like the support for this extension may not be present in some user hardware, so I think we should remove support for dynamic rendering from this pull request. It can be added later as possible optimisation.

[YaaZ]

@avu I just checked the statistics: https://vulkan.gpuinfo.org/displayextensiondetail.php?extension=VK_KHR_dynamic_rendering On Linux it's 47%, which means "well supported on modern HW/drivers"

And this extension is optional, we can work with core render passes as well. I well tested both configurations.

The neccesity for this extension is motivated by dynamic nature of our J2D rendering. We can dynamically specify render pass parameters, like clearing op, which can not be known in advance, as well as removing the need to create separate render pass and framebuffer instances.

[YaaZ]

The same thing with VK_EXT_extended_dynamic_state3: without it we need to compile pipelines multiple times for each alpha composite mode, and this also implies changing pipelines when composite mode is changed. With dynamic states we need much less pipelines and state changes, which is good. But both scenarios are supported and tested, of course.

[YaaZ]

If you are concerned about the increased code complexity these extensions bring, it's in fact very small. Dynamic rendering and blending extensions are meant to replace heavy and verbose core concepts with simpler yet more effective ones. Therefore main burden comes not from supporting the optional extensions, but supporting the default implementation. You can Ctrl+F the "dynamicRendering" and "dynamicBlending" and see it yourself: if we remove these extensions, we would literally get rid of around 25 lines of code for each extension, and also get us rid of more optimal paths of execution.

[YaaZ]

I split the changes into multiple smaller reviews, so I'm closing this one. See https://github.com/JetBrains/JetBrainsRuntime/pull/452