> 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. _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
