[Mesa-dev] i965: The future of blorp

Chad Versace chad.versace at intel.com
Tue Apr 19 19:06:25 UTC 2016


On Sat 16 Apr 2016, 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 to win.

In my brain too. As we go down the rabbithole of implementing HiZ and
fast clears in Vulkan meta, I feel that we'll duplicate blorp, and
duplicate it badly.

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

I agree. Getting HiZ and fast-clear right in one place, for both GL and
VK, and having the implementation disentangled from the the normal
pipeline codepaths, is a goal worth pursuing.

> As it currently stands, here's my plan:

[...]

The plan sounds good to me.


More information about the mesa-dev mailing list