[Mesa-dev] Gallium Vulkan state tracker?

[Rob Clark]

On Wed, Feb 17, 2016 at 10:04 AM, Jose Fonseca <jfonseca at vmware.com> wrote:
> 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).

heh, I was going to call it "vallium" :-P

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

One use-case I do care about, and I think would be easier with this
sort of approach, is supporting multiple generations of gpu which have
a lot of shared code.  The internal germanium/vallium layer wouldn't
have to support all the features of vulkan to still get opengl state
tracker support on older gen's..  I guess that is the one advantage
compared to mesa-internal extensions exposed thru vulkan..

BR,
-R

> - 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
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev