Repository navigation
Replaces the InkSparkle shader SPIR-V program from in-memory (List<int> as bytes) to a binary asset (ink_sparkle.spv) - #101699
clocksmith wants to merge 3 commits into
Conversation
|
It looks like this pull request may not have tests. Please make sure to add tests before merging. If you need an exemption to this rule, contact Hixie on the #hackers channel in Chat (don't just cc him here, he won't see it! He's on Discord!). If you are not sure if you need tests, consider this rule of thumb: the purpose of a test is to make sure someone doesn't accidentally revert the fix. Ask yourself, is there anything in your PR that you feel it is important we not accidentally revert back to how it was before your fix? Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing. |
|
It looks like the parts of the change to use the shader asset in the framework were removed? Maybe github is just not loading the change properly for me for some reason, though. |
|
Ah, I misread the PR. The presubmits are failing because of the binary artifact. It looks like we'll need to get the shader compiler pulled in first. I will look into that ASAP. |
|
@zanderso any updates needed on my end? |
|
I think Zach got blocked on #102165, and now will be OOO for a bit. That bug is probably resolved by a PR I'm about to land, but getting impellerc pulled in will probably have to wait for a bit now. |
|
@clocksmith Yeah, this is blocked waiting for impellerc to be available, but as of yesterday, impellerc is already being vended by the engine build. The next step is to consume it in the tool. Using the in-memory SPIR-V is a blocker for Impeller to support InkSparkle. |
|
Thanks @zanderso
To consume this sparkle effect shader? Is there a tracking bug to know when that is unblocked, so this one can be pushed forward? |
|
This is obsolete. |
Replaces the InkSparkle shader SPIR-V program from in-memory (
List<int>as bytes) to a binary asset (ink_sparkle.spv)With this change, the asset is added to runtime assets and loaded asynchronously, right before the compile step, which is already asynchronous.
TODO(reviewers): For WIP, copied asset to cache subdirectory, where material_fonts are read, but where should it be stored instead?
closes: #99783
There are no tests because this is an implementation change, but the behavior is the same, and there are existing tests.
Pre-launch Checklist
///).