<div dir="ltr"><div><div><div><div><div><div><div><div><div><div>All,<br></div>With Topi's gen8/9 blorp patches on the list, I wanted to start a brief discussion about the future of blorp in the hopes of us all being on the same page and not stepping on each other's toes.  I think everyone is now agreed that blorp is the future and GL meta should die.<br><br></div>As we continue to work on the Vulkan driver, its need for blorp-like things increases.  We currently have all of the blits and resolves implemented in a Vulkan-based meta scheme.  While Vulkan doesn't have the same meta problems as GL (It's actually fairly clean), it still isn't a perfect fit.  The illusion of being able to use a hardware-agnostic API breaks down fairly quickly when you start doing hardware-specific things.  One example is HiZ resolves on gen7:  We can, in theory, add HiZ op bits to our side-band data structure that we pass to create_pipeline but a HiZ resolve pipeline isn't really that much like a normal pipeline.  You can make the argument that "we're re-using the normal pipeline creation code" or you can make the argument that "we're duplicating blorp".  In my brain, the second argument is starting ti win.<br><br></div>Where am I going with this?  What I think I'd eventually like to see is some sort of a unified blorp that can be used in both drivers.  (Note: That unified blorp might still end up being Vulkan meta; I'm still not sure.)  Sure, it may mean doing state setup 3 places instead of 2 but it also means getting the HiZ and fast-clear pipelines right 1 place instead of 2 and I feel that's a bit more important.<br><br></div>As it currently stands, here's my plan:<br><br></div> 1) Get Topi's gen8/9 blorp patches reviewed and merged.<br><br></div> 2) Rework blorp to start using NIR shaders whenever possible.  I know Topi had a project at one point that tried to get us using GLSL shaders in blorp which ran into some problems.  With the compiler APIs refactored to accept NIR directly, turning a NIR shader into a binary is trivial.  We've had great success using NIR directly for building shaders for Vulkan meta and I think doing that in blorp would also be good.  This would also provide our first blorp code-sharing point between Vulkan and GL as a lot of the NIR code to build those shaders could be shared.<br><br></div> 3) Start using the XML-generated packing structs for doing blorp state setup.  Again, we've had great success in the Vulkan driver with Kristian's XML-generated packing structs.  Using them in blorp where it's practical would substantially reduce the amount of code we have for blorp state setup and possibly let us unify gen7-9 (not sure how much we can unify, but certainly some).<br><br></div> 4) Figure out how to make blorp work in both drivers.  This is a bit open-ended as the two drivers have vastly different batch-submission and relocation-tracking models.  That said, I've been kicking this one around in my brain quite a bit lately and I think I'm starting to converge on something resembling a solution.<br><br>I think each of the changes listed above has merit without the others, so if 
we decide to bail on the unified blorp plan at some point, we've still accomplished something. Thoughts?  Opinions?  Rotten tomatoes?<br><br>As far as who does it, I'm more than willing to pick up the work and make it happen.  If others want to chip in, that's fine too.<br><br></div></div>--Jason<br></div>