[Mesa-dev] i965: The future of blorp

[Pohjolainen, Topi]

On Sat, Apr 16, 2016 at 12:12:46PM -0700, Jason Ekstrand wrote:
>    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.

Sounds good to me. We are missing 16x msaa support in blorp blits. Ken and I
quickly discussed implementing that in glsl later (perhaps using the version
we have for meta). Using NIR would allow us to skip all the scanning and
parsing.
In general moving from blorp hand-crafted compiler to NIR (or glsl) is the
right direction in my opinion.

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

I've been thinking of re-using normal i965 upload logic. I've experimented
with that in past - all that is needed is to make the interface more explicit
instead of just passing current driver state to the emitters.
Having said that I'm equally pro for using something that worked for you guys
in Vulkan.

>     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

I'm at least pretty open how to proceed. Having more eyes on blorp and
especially on the compiler side certainly wouldn't hurt :)