Re: [Mesa-dev] i965: The future of blorp
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. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] i965: The future of blorp
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 :) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] i965: The future of blorp
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 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
