Mesa Starts Shiva Common Vulkan Framework, Targets Results in Two Years

Development has begun on Shiva, a new common foundation for Vulkan drivers in the Mesa project. According to reporting by Michael Larabel of Phoronix, Faith Ekstrand of Collabora presented the concept at XDC 2026, held in Toronto, Canada, on September 28, 2026. Shiva is an attempt to provide for Vulkan what Gallium3D provides for OpenGL drivers. While it will take time to realize, it is expected to promote code sharing and improve the developer experience.

Mesa hosts multiple Vulkan drivers, including Intel’s ANV, AMD’s RADV, NVK for NVIDIA, and PanVK for Arm Mali. While each driver pursues its own optimizations, implementation of extension support, translation handling, and helper functionality is duplicated. Vulkan specification extensions continue to grow, and the burden of validation layers and conformance testing is also increasing. As a result, knowledge sharing among developers has become difficult, and barriers to entry for newcomers have risen.

The proposal is based on the recognition that it has become difficult to continue individual responses while maintaining the current fragmented development. Ekstrand noted that the cost of implementing Vulkan is structurally increasing. The presentation materials emphasized the gap between early Vulkan and present-day Vulkan.

– Vulkan was fun and easy to implement in 2016…– Vulkan in 2026 is full of backwards compatibility cruft.

She indicated that future specification extensions will make implementation even more difficult. The remark serves less as a personal impression than as a premise for design decisions. As backward compatibility is maintained in parallel with new features, branching logic on the driver side keeps growing.

Vulkan Bloat and Development Limits

When Vulkan debuted in 2016, it was characterized by explicit control and thin abstraction. Its design, which simplified driver processing and placed responsibility on applications, was well regarded. After ten years, however, the number of extensions has grown substantially. Its scope has expanded to areas such as ray tracing, video encoding, and cooperative matrices for machine learning.

As shown by Vulkan Video Encode Returns on Intel Alchemist GPUs, video-related implementations are also within the scope of driver work. Helper mechanisms for memory allocation, synchronization, and descriptor management have also become more complex. Handling differences in GPU architectures across vendors weighs heavily on individual drivers. Translation handling for the same functionality is duplicated and maintained across multiple drivers.

Ekstrand analyzed that fragmentation will advance if the current situation continues. Common translation and helper logic is not organized and remains scattered across drivers. Bug fixes and specification updates require per-driver responses, increasing overall maintenance costs. This structure also affects how quickly new GPUs can be supported.

Gallium3D’s Record and Its Application to Vulkan

Gallium3D has become established as the common foundation for OpenGL drivers in Mesa. It consolidated state management, shader translation, and draw-call abstraction into an intermediate layer. GPU-specific code was confined to later stages, while front-end state tracking was shared. This separation shortened development time for new drivers.

After the introduction of Gallium3D, multiple OpenGL drivers used the shared mechanisms. Bug fixes were concentrated in the intermediate layer, stabilizing overall quality. Developers were able to focus on GPU-specific optimizations. Duplicated maintenance was reduced, and validation work became more efficient.

Shiva is a plan to apply that success to the Vulkan domain. Its target, however, is Vulkan drivers, not OpenGL. It will not simply carry over the OpenGL state machine. Abstraction suited to Vulkan’s explicit resource management and extension mechanisms is required.

The presentation used the phrase “Gallium3D for Vulkan.” It is an explanation that existing Mesa developers can readily understand. The goal is to share code and unify development procedures. The design is premised on independence from any specific vendor or GPU architecture.

The Abstraction Role Shiva Will Play

Shiva is a foundation placed between the Vulkan application interface and drivers. Mesa Vulkan drivers will target Shiva’s interface rather than addressing the Vulkan specification directly. Shiva will handle backward compatibility and organize extensions. Drivers will focus on GPU-specific command generation and resource handling.

With this separation, specification-tracking work will be consolidated on the foundation side. Each driver will no longer need to carry compatibility handling individually. Duplication of translation and helper logic will be reduced. The paths to be validated will be organized, improving test reusability.

Ekstrand positioned Shiva as a framework and foundation. It is more than a single library; it is a structure for driver development. It includes guidance on interface design, resource abstraction, and extension management. Standardization of development procedures is also in view.

The key design issue is the granularity of abstraction. If the granularity is too coarse, it will hinder GPU-specific optimization. If it is too fine, the benefits of sharing will diminish. Interface design that balances performance and shareability is required.

Rollout to Start with Nouveau and Panfrost

Development is planned to start in the near future. The initial targets are Nouveau and Panfrost for Arm Mali. Nouveau is the open driver base for NVIDIA. Panfrost is the open driver base for Arm Mali.

Both have already been developed within Mesa. With different GPU architectures, they are suitable for validating the abstraction. Effectiveness can be tested across structures from different vendors. Gaps or excesses in the shared mechanisms can be found early.

User-visible results were estimated to take about two years. Foundation design, migration of existing drivers, and validation will take time. It will not be replaced in a short period. Repeated gradual migration and evaluation are expected.

At XDC 2026, slide decks and recorded video were made public. Design details will be fleshed out in future discussions. Many aspects, such as interface specifications and migration procedures, remain undecided. Discussions are expected to continue at developer conferences and on mailing lists.

Design Philosophy with Rust Support in Mind

Shiva also looks ahead to future driver development in Rust. Mesa is already experimenting with drivers written in Rust. Memory safety and expressiveness for concurrent programming are drawing attention. Coexistence with existing C assets is a challenge.

If resource and lifetime management can be organized on the foundation side, affinity with Rust will improve. A clear interface can confine the coupling between languages. Sharing of validation mechanisms will also become easier. Barriers to entry for new developers will also fall.

Rust support is, however, a secondary benefit. The primary goal is to resolve fragmentation among Vulkan drivers. Language-neutral interface design is important. Abstraction independent of any specific language is required.

It will also affect maintenance across Mesa as a whole. Once the common foundation stabilizes, duplicated work for extension support will decline. Maintainers of individual drivers can focus on optimization. This could lead to improved long-term sustainability.

Editorial Opinion

Over the next three to six months, debate over Shiva’s interface design will become central to Mesa development. While maintenance burdens for existing drivers will not change immediately, identification of candidates for sharing is expected to progress. If policies for handling extensions are clarified, it could help curb duplicated implementations.

Over one to three years, quality gaps between drivers will narrow. If Rust-based driver development becomes more accessible, the pool of maintenance contributors will broaden. Progress in sharing validation infrastructure could lead to lower long-term maintenance costs.

How to prevent the abstraction layer itself from bloating will be a key issue. Whether the lessons of Gallium3D can be applied will depend on rigorous boundary design. Which to prioritize, performance or maintainability, will test the judgment of developers in the field.

References

• ““Shiva” Being Developed For Mesa Vulkan Drivers, Akin To Gallium3D”, by Michael Larabel — Phoronix, 2026-09-29T00:32:08.000Z (ARR)
• Source URL: https://www.phoronix.com/news/Mesa-Shiva-For-Vulkan