[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