[Mesa-dev] Gallium Vulkan state tracker?

[Dave Airlie]

> 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

Yup I agree with Jason here after I spent some time investigating it.

mapping things onto pipeline state objects without ending up with a lot of them,
gets messy quick.

If we had plans for a DX12/Mantle then an abstraction layer might be a
good thing,
but for now at least I'd like to see someone prove that GL over Vulkan
is in anyway
a nice thing, and what compromises and internal vulkan would need to
make it performant.

Dave.