[Mesa-dev] i965: The future of blorp

[Jason Ekstrand]

All,
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.

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.

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.

As it currently stands, here's my plan:

 1) Get Topi's gen8/9 blorp patches reviewed and merged.

 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.

 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).

 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.

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?

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.

--Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20160416/7010e5e7/attachment.html>