[Mesa-dev] Gallium Vulkan state tracker?

[Jose Fonseca]

On 17/02/16 10:24, Dave Airlie wrote:
> On 17 February 2016 at 18:31, Ernst Sjöstrand <ernstp at gmail.com> wrote:
>> Hi!
>>
>> 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.
>
> Dave.

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 Germa­nium (just so there's a name, but it really doesn't 
matter).


We'd have three ways of assembling things:

- a Vulkan driver


      Vulkan                Germanium
       API                  interface
    ---------> Trivial glue ----------> shared driver


- a classic Mesa driver

      OpenGL
      API
   ---------> Mesa -> Germanium   ------> shared driver
                      statetracker

- and maybe for a transitory period a Gallium->Germananium adapter

  OpenGL/D3D
  ------> existing statetrackers --> Germanium gallium driver --> shared 
driver


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 
simulatnously.


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 
extensions.

Jose