Krita 5.3/6.0 is the result of many years of work by the Krita developers. Some features have been rewritten from the ground up, others make their first appearance.

Enjoy the completely new text feature: on canvas editing, full opentype support, text flowing into shapes. It is now easier than ever to create vector-based panels for comic pages. Tools got extended: for instance, the fill tool now can close gaps. The liquify mode of the transform tool is much faster. There are new filters: a propagate colors filter and a reset transparent filter. Support for HDR painting has been improved. The recorder docker can now work in real time. There is improved support for file formats, like support for text objects in PSD files. And much, much, much more!

Depending which version of Qt and KDE Frameworks you build, the same source will result in one of the other. Both versions are almost functionally identical, with 6.0.0 having more Wayland functionality. But note that since Krita 6 is still considered rather experimental.

Welcome to the "Building a Simple Engine" tutorial series! This series marks a transition from the foundational Vulkan concepts covered in the previous chapters to a more structured approach focused on building a reusable rendering engine.

A New Learning Approach

While the previous tutorial series focused on introducing individual Vulkan concepts step by step, this series takes a different approach:

This series targets readers who have completed the Vulkan Tutorial and feel comfortable with the fundamentals. We’ll emphasize architectural concepts and design patterns over exhaustive API permutations, so you develop an engine mindset rather than a collection of snippets. Expect to do more independent work: fill in smaller gaps, experiment, and lean on the Vulkan Guide, Samples, and Specification as primary references. If a topic feels too advanced, revisit the original tutorial and return when ready.

What to Expect

The "Building a Simple Engine" series is designed as a starting point for your journey into engine development, not a finishing point. We’ll cover:

1. Engine Architecture - How to structure your code for flexibility, maintainability, and extensibility.

2. Resource Management - More sophisticated approaches to handling models, textures, and other assets.

3. Rendering Techniques - Implementation of modern rendering approaches within an engine framework.

4. Performance Considerations - How to design your engine with performance in mind.

5. Publication Considerations - How to prepare your application for distribution in a professional environment, including packaging, deployment, and platform-specific considerations.

Throughout this series, we encourage you to experiment, extend the provided examples, and even challenge some of our design decisions. The best way to learn engine development is by doing, and sometimes by making (and learning from) mistakes.

Throughout our engine implementation, we’re using vk::raii dynamic rendering and C20 modules. The vk::raii namespace provides Resource Acquisition Is Initialization (RAII) wrappers for Vulkan objects, which helps with resource management and makes the code cleaner. Dynamic rendering simplifies the rendering process by eliminating the need for explicit render passes and framebuffers. C20 modules improve code organization, compilation times, and encapsulation compared to traditional header files.

Cross posted from https://kbin.earth/m/gpu@programming.dev/t/2363483

Can we use WebGPU to compute real-time global illumination with surface patches called surfels? Does it look good enough? Is it fast enough? And can we finally construct viable compute-heavy rendering pipelines right here on the open web? Join me on this journey and let's find out!

The Khronos Vulkan API is in continuous development, and today the Vulkan Working Group has released two important updates to the API and ecosystem: an entirely new Descriptor system and the Vulkan Roadmap 2026 Milestone.

These new features and more will be discussed at the forthcoming Vulkanised 2026 conference, taking place in San Diego on February 9-11.

Initial support for these features is expected in the next Vulkan SDK release planned for Q1 2026.

Descriptor Heaps: The new VK_EXT_descriptor_heap extension represents a complete overhaul of the current Vulkan descriptor system, providing direct access to descriptor memory while preserving compatibility with legacy descriptor sets and other APIs. This extension is intended to completely replace Vulkan’s existing descriptor set mechanism, and the working group is actively seeking developer feedback before finalizing the API as a KHR extension targeting a future Vulkan Roadmap milestone.

Vulkan Roadmap 2026 Milestone: The latest roadmap milestone marks a significant increase in required functionality for high-end implementations beyond Vulkan 1.4 and previous milestones - requiring several long-standing optional features that developers have requested and raising a number of limits, including required support for:

• Variable rate shading
• Shader clock queries
• Host image copies
• Compute shader derivatives
• Various swapchain improvements
• Higher descriptor and shader interface limits

Most Vulkan adopters supporting the Vulkan 2026 milestone will offer conforming devices by the end of this year.

See the Vulkan Roadmap 2026 Milestone for full details.

This repository and the accompanying tutorial demonstrate ways of writing a Vulkan graphics application in 2026. The goal is to leverage modern features to simplify Vulkan usage and, while doing so, create something more than just a basic colored triangle.

Vulkan was released almost 10 years ago, and a lot has changed. Version 1.0 had to make many concessions to support a broad range of GPUs across desktop and mobile. Some of the initial concepts like render passes turned out to be not so optimal, and have been replaced by alternatives. The API matured and new areas like raytracing, video acceleration and machine learning were added. Just as important as the API is the ecosystem, which also changed a lot, giving us new options for writing shaders in languages different than GLSL and tools to help with Vulkan.

And so for this tutorial we will be using Vulkan 1.3 as a baseline. This gives us access to several features that make Vulkan easier to use while still supporting a wide range of GPUs and platforms.

One of the more unexpected talks at last week's Ubuntu Summit 25.10 in London was by Antonio Salvemini of Bolt Graphics, who introduced the company's forthcoming range of Zeus graphics accelerator hardware. These are very unlike any conventional GPUs – or indeed anything else.

[…]

Bolt's Zeus hardware will use an entirely different model, and we found it refreshing that the company's How it works page doesn't mention the dreaded initialism "AI" once. These accelerators are aimed at producing graphics using a specific rendering method called path tracing.

[…] Path tracing is a step further on from simple ray tracing. A few decades ago, ray tracing was a favorite way to demonstrate high-resolution, multi-color computer graphics, taking hours to days to render scenes of shiny spheres.

As Salvemini put it: "The problem with ray tracing is that each light wave only bounces one way. In path tracing, they can bounce anywhere, and you randomly select just some of these paths to display." Thus, Monte Carlo path tracing (MCPT) – as described in this 2024 UCSD computer graphics lecture [PDF] – uses Monte Carlo simulation, as invented by John von Neumann and Stanislaw Ulam during World War II.

There’s no shortage of examples of beginners rendering a simple triangle (or a cube), and with the new APIs having completely displaced the oxygen of older APIs, there is a certain expectation of ridiculous complexity and raw grit required to tickle some pixels on the display. 1000 lines of code, two weeks of grinding, debugging black screens etc, etc. Something is obviously wrong here, and it’s not going to get easier.

I would argue that trying to hammer through the brick wall of graphics is the wrong approach in 2025. Graphics itself is less and less relevant for any hopeful new GPU programmer. Notice I wrote “GPU programmer”, not graphics programmer, because most interesting work these days happens with compute shaders, not traditional “graphics” rendering.

Instead, I would argue we should start teaching compute with a debugger/profiler first mindset, building up the understanding of how GPUs execute code, and eventually introduce the fixed-function rasterization pipeline as a specialization once all the fundamentals are already in place. The raster pipeline was simple enough to teach 20 years ago, but those days are long gone, and unless you plan to hack on pre-historic games as a hobby project, it’s an extremely large API surface to learn.

In this series, we enhance a Vulkan renderer with ray tracing features to implement real-time pixel-perfect shadows (with and without transparency) and a bonus reflection effect. You will work with provided scaffolded code (based on the Vulkan Tutorial) and fill in key shader functions following step-by-step instructions.

Slides available here.

By the end, you’ll learn how to:

• Use Vulkan dynamic rendering (no pre-defined render passes) and verify it with RenderDoc.
• Create bottom-level and top-level Acceleration Structures (BLAS and TLAS) for ray tracing.
• Implement ray query based shadow rays (first with all-opaque geometry, then with alpha-test transparency).
• Debug/inspect the acceleration structures in Nsight Graphics.
• (Bonus) Implement ray query based reflections.

Prerequisites: This series targets intermediate Vulkan programmers. We assume you have completed the basic Vulkan Tutorial (graphics pipeline, descriptor sets, etc.). If not, you can still follow along conceptually. A Windows machine with up-to-date Vulkan SDK (1.4.311), a GPU supporting ray tracing (Vulkan Ray Query), plus RenderDoc and Nsight Graphics is provided.

Vcc - the Vulkan Clang Compiler, is a proof-of-concept C and C++ compiler for Vulkan leveraging Clang as a front-end, and Shady our own research IR and compiler. Unlike other shading languages, Vcc aims to stick closely to standard C/C++ languages and merely adds a few new intrinsics to cover GPU features. Vcc is similar to CUDA or Metal in this regard, and aims to bring the advantages of standard host languages to Vulkan shaders.

Key Features

Vcc supports advanced C/C++ features usually left out of shading languages such as HLSL or GLSL, in particular raising the bar when it comes to pointer support and control-flow:

• Unrestricted pointers
  • Arithmetic is legal, they can be bitcasted to and from integers
• Generic pointers
  • Generic pointers do not have an address space in their type, rather they carry the address space as a tag in the upper bits.
• True function calls
  • Including recursion, a stack is implemented to handle this in the general case
• Function pointers
  • Lets you write code in a functional style on the GPU without limitations
• Arbitrary goto statements - code does not need to be strictly structured !

Many of these capabilities are present in compute APIs, but are not supported in most graphics APIs such as DirectX or Vulkan. We aim to address this gap by proving these features can and should be implemented. More on why we think that’s important.