On 17/02/16 10:24, Dave Airlie wrote:
On 17 February 2016 at 18:31, Ernst Sjöstrand <[email protected]> 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 Germanium (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
_______________________________________________
mesa-dev mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
