<div dir="ltr"> <div class="gmail_extra"> <div class="gmail_quote">On Wed, Feb 17, 2016 at 7:04 AM, Jose Fonseca <<a href="mailto:jfonseca@vmware.com" target="_blank">jfonseca@vmware.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 17/02/16 10:24, Dave Airlie wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On 17 February 2016 at 18:31, Ernst Sjöstrand <<a href="mailto:ernstp@gmail.com" target="_blank">ernstp@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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? </blockquote> 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. </blockquote> 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.</blockquote><div> </div><div>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. </div><div>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) </div><div>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. </div><div>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. </div></div>--Jason </div></div>