[Mesa-dev] Gallium Vulkan state tracker?

[Jason Ekstrand]

On Wed, Feb 17, 2016 at 7: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).
>
>
> 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.


This category of ideas is something that I have given a bit of thought.
The tentative conclusion I've come to is that it would be possible to
implement GL on Vulkan given a few extensions and a few carefully chosen
assumptions about the underlying Vulkan driver.  For instance, we could add
an extension to allow you to pass a nir_shader directly into the driver to
make it easier to patch through GLSL or ARB programs.  Getting it to be
performant, however, will be a bit more difficult.

There are two big hiccups: Subtle API differences, and the pipeline
object.  On the API differences front, there are a number of little things
that Vulkan has done differently.  For instance, Vulkan requires that
gl_FragCoord have an upper-left origin.  (Really good for us because that's
what our HW does.)  There's other things like the fact that
gl_InstanceIndex now takes the base instance into account.  There are other
things like the fact that Vulkan doesn't expose stippling, the
floating-point mode used by ARB programs, or legacy user-specified clip
planes.  These could all be worked around, but there is a lot of work to do
there.  (Probably the kind of work the vmware guys are very familiar with)

Then there's the pipeline object.  Vulkan makes the choice to bake the vast
majority of your state into a single monolithic and immutable pipeline
object.  This is very different from the GL model where you can flip any
state bit you want and the driver is responsible for grabbing state
on-demand.  The object of the pipeline model is to, as far as possible,
avoid late shader recompiles and allow the driver to do as much up-front as
possible.  One result is that, for any given driver, a bunch of that state
isn't actually needed for shader recompiles so you end up creating more
pipeline objects than strictly needed.  Since the set of state needed for
shader compilation differs based on the hardware and Vulkan wanted to
capture it all, the pipeline is rather big.  If someone wanted to make a
GL-on-Vulkan driver, they have basically two options: 1) Make some highly
agressive caching mechanism for caching and re-using pipelines or 2) Have a
contract between the GL-on-Vulkan layer and the driver that creating
pipelines is fast under a certain set of conditions and treat them as
flyweights.  I have no idea what the performance of either of these
approaches would be.

So yeah, it would be an interesting experiment and I've thought about how
you could do it.  That said, I have no plans of actually embarking on such
a project.
--Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20160217/f490f0f5/attachment-0001.html>