Category PasVulkan

PasVulkan will get a frame graph feature

I'm currently working on a frame graph feature at PasVulkan, which can simplify a lot when using the Vulkan API, because a frame graph has all important informations about a frame like its compute passes, its render passes, its attachments, its inputs, its outputs, its resources and its lifetimes and so on, so that the frame graph compiler can ideally allocate the GPU resources quite optimally (including reusing/aliasing of GPU resources) and so that the frame graph compiler can generate a quite optimal parallelizable processing-ordering directed acyclic graph, where multiple processing-sequences for each previously created Vulkan GPU queue can be created from it then for more optimal usage of the GPU also.

Here you can find further informations about the frame graph concept:

Successful PasVulkan test on an AMD Radeon RX580 8GB graphics card

Successful PasVulkan test on an AMD Radeon RX580 8GB graphics card, so it seems that PasVulkan now seems to work with NVIDIA, AMD, Mali, Adreno and Intel GPUs, although with Intel GPUs it does only under Linux correctly, under Windows however not (due to a still non-fixed Windows Intel graphics driver issue). And with PowerVR GPUs it still crashes right at the startup.


First working versions of TpvGUIColorWheel and TpvGUIColorPicker in the PasVulkan GUI subframework

First working versions of TpvGUIColorWheel and TpvGUIColorPicker in the PasVulkan GUI subframework, where the whole triangle color wheel is rendered by the GPU itself only with two GPU-triangles with help of fragment-shader-side 2D signed-distance-field-stuff, and  where it can be also controlled purely with the keyboard.



PasVulkan GUI subframework now with Window-tabbing feature

PasVulkan GUI subframework now with Window-tabbing feature with Ctrl+(Shift+)Tab


First working version of TpvGUIVulkanCanvas in the PasVulkan GUI subframework

First working version of TpvGUIVulkanCanvas in the PasVulkan GUI subframework, it works completely without render-to-texture tricks, so it is rendered directly to the final framebuffer, but which is a bit tricky with the two-pass front-to-back-opaque and back-to-front transparent GUI rendering strategy, so it is a three-pass GUI rendering strategy here, with a third back-to-front opaque VulkanCanvas render pass as "first" pass.



The two different GUI rendering strategies at PasVulkan with the Vulkan API

Admittedly, the Vulkan API calls could potentially be further optimized and merged.

The Vulkan header generator and Vulkan header of PasVulkan is from this time point on also Vulkan 1.1 ready now

The Vulkan header generator and Vulkan header of PasVulkan are from this time point on also Vulkan 1.1 ready now, which took me about an hour to tweak and fix the PasVulkan Vulkan header generator for the new vk.xml format changes and vk.xml format additions. So have fun! 🙂

Mali T760 MP8 non-working-fragment-discarding issue workarounded

PasVulkan GUI subframework Mali T760 MP8 non-working-fragment-discarding issue is workarounded with VK_DYNAMIC_STATE_SCISSOR now.



Fragment-based discarding clipping issues on Mali GPUs

Mali T760 on Galaxy S6 seems to ignore the GLSL discard command regardless of whether "layout (early_fragment_tests) in;" is defined or not, and Mali seems doesn't support gl_ClipDistance[] in contrast to Adreno and Tegra mobile GPUs.

On mobile GPUs, the PasVulkan GUI renderer uses Z-Buffer-based front-to-back rendering for opaque objects like widgets centers, and back-to-front rendering for transparent objects like widget edges, text, icons, and so on.

And on normal Desktop/Notebook iGPUs/dGPUs the PasVulkan GUI renderer uses brute-force only-alpha-blended back-to-front rendering, because it is faster there than the two-pass-optimization-technique for mobile GPUs but it seems, that at least Mali GPUs has a problem with that two-pass-optimization-technique.

All in all, The PasVulkan GUI renderer uses gl_ClipDistance if it's supported, otherwise it uses fragment discards.

You can see the problem with a Mali GPU and a comparison with a Tegra GPU at


(Galaxy S6 with ARM Mali T760 MP8)

vs


(NVIDIA Tablet K1 with NVIDIA … (read more)

The possible future of PasVulkan on macOS/iOS

Current news:

https://www.khronos.org/news/press/vulkan-applications-enabled-on-apple-platforms
Valve, LunarG, and The Brenwill Workshop join forces with Khronos to release open source SDKs and runtime libraries; Khronos Portability Initiative defines subset of Vulkan 1.0 portable to macOS and iOS
So it seems, that I could make PasVulkan maybe also compatible for macOS/iOS in the near future now, with that new Vulkan portability subset. which is another reason for the PasVulkan GUI subframework as a future cross-platform VCL/LCL/FireMonkey UI framework alternative (including Windows, Linux, Android, and so on), even if without a RAD WYSIWYG UI editor, at least for the first time, because the PasVulkan GUI subframework is rather modelled after the Java Swing & Android UI component model concepts, than after the VCL/LCL/FireMonkey concepts.