[Mesa-dev] Gallium Vulkan state tracker?
jfonseca at vmware.com
Wed Feb 17 15:04:16 UTC 2016
On 17/02/16 10:24, Dave Airlie wrote:
> On 17 February 2016 at 18:31, Ernst Sjöstrand <ernstp at gmail.com> wrote:
>> Sorry if this is a silly question but I was thinking that there would
>> be a Vulkan Gallium state tracker in development behind closed doors
>> somehow. However I guess that's not the case?
> It doesn't make sense to write a vulkan state tracker for gallium, as
> vulkan is a lower level interface
> than gallium,
> The only thing that makes sense is to refactor pieces of the gallium
> drivers out into some shared
> driver code, usually the compiler and memory layout stuff (like Intel
> have done).
> You could in theory write a vulkan level gallium layer, but it really
> would end up looking like
> vulkan so would just be an abstraction of an abstraction.
I still need to catch up reading the final version of the Vulkan specs.
But wouldn't it be useful to have abstraction that is a superset of Vulkan?
That is a Vulkan-like API that exposes additional state that was in
OpenGL but was removed from Vulkan API, and that the existings GPU HW
supports, and makes live it easier to implement OpenGL.
Just for the sake of this explanation I'm going to call this new
abstraction Germanium (just so there's a name, but it really doesn't
We'd have three ways of assembling things:
- a Vulkan driver
---------> Trivial glue ----------> shared driver
- a classic Mesa driver
---------> Mesa -> Germanium ------> shared driver
- and maybe for a transitory period a Gallium->Germananium adapter
------> existing statetrackers --> Germanium gallium driver --> shared
But eventually Gallium would just disappear and the difference between
classic/Gallium driver would go away. New drivers would be coded
against the Vulkan-like Germanium interface, and target both GL/Vulkan
We could fix an IR for Germanium (e.g, SPIR-V, or NIR), or instead let
Germanium IR be switchable (eg, allow TGSI, LLVM), and let drivers plug
compilers as needed.
Of course, people could just try to implement a Mesa -> Vulkan adapter.
And when writing new drivers people would just write a Vulkan driver.
But there are probably lots of technical challenges in implementing
full OpenGL (or D3D) on top of pure Vulkan.
Another solution would be to expose the
bits-useful-for-GL/D3D-but-missing-in-Vulkan as "Mesa-internal" Vulkan
More information about the mesa-dev