Issue 14069 in skia: SkSL: investigate a raster pipeline analysis pass
3 views
Skip to first unread message
johns… via monorail
Jan 25, 2023, 12:23:50 PM1/25/23
to bu...@skia.org
Status: Accepted
Owner: johns...@google.com
Area: SkSL
Priority: Low
Type: Defect
New issue 14069 by johns...@google.com: SkSL: investigate a raster pipeline analysis pass
https://bugs.chromium.org/p/skia/issues/detail?id=14069
Much of SkVM's great optimization ability comes from being able to track the provenance of values, which is a handy built-in property of SSA form.
We could approximate something similar in SkRP if we were to track slots and stack entries in a builder optimization pass. We would enter the code knowing that the inputs (coords or colors) are entirely non-uniform. As items are pushed on the stack, we could keep track of whether they:
- originate from a constant (value is completely known)
- originate from a uniform (value is dynamically uniform)
- originate from the inputs, or come from a child (input is non-uniform)
- originate from a slot (value's provenance is inherited from the slot's provenance)
As stack entries are popped back to slot, the stack entry's provenance would be copied to the slot as well.
In ambiguous cases, the worst case can be assumed ("sometimes uniform" -> "non-uniform").
When execution mask writes are enabled, we would probably need to be pessimistic and assume worst-case (touched slots instantly become non-uniform).
This would require a lot more smarts in the Builder, as it currently only tracks the stack in a very rudimentary way, but it would give us the opportunity to implement many of SkVM's best tricks. For instance, if we were tracking pushes of constants onto the stack, we could detect constant-foldable cases like "push 1, push 2, add" and replace it with "push 3". It would also let us use faster dynamically-uniform ternaries and if statements in more places.
--
You received this message because:
1. The project was configured to send all issue notifications to this address
You may adjust your notification preferences at:
https://bugs.chromium.org/hosting/settings
Owner: johns...@google.com
Area: SkSL
Priority: Low
Type: Defect
New issue 14069 by johns...@google.com: SkSL: investigate a raster pipeline analysis pass
https://bugs.chromium.org/p/skia/issues/detail?id=14069
Much of SkVM's great optimization ability comes from being able to track the provenance of values, which is a handy built-in property of SSA form.
We could approximate something similar in SkRP if we were to track slots and stack entries in a builder optimization pass. We would enter the code knowing that the inputs (coords or colors) are entirely non-uniform. As items are pushed on the stack, we could keep track of whether they:
- originate from a constant (value is completely known)
- originate from a uniform (value is dynamically uniform)
- originate from the inputs, or come from a child (input is non-uniform)
- originate from a slot (value's provenance is inherited from the slot's provenance)
As stack entries are popped back to slot, the stack entry's provenance would be copied to the slot as well.
In ambiguous cases, the worst case can be assumed ("sometimes uniform" -> "non-uniform").
When execution mask writes are enabled, we would probably need to be pessimistic and assume worst-case (touched slots instantly become non-uniform).
This would require a lot more smarts in the Builder, as it currently only tracks the stack in a very rudimentary way, but it would give us the opportunity to implement many of SkVM's best tricks. For instance, if we were tracking pushes of constants onto the stack, we could detect constant-foldable cases like "push 1, push 2, add" and replace it with "push 3". It would also let us use faster dynamically-uniform ternaries and if statements in more places.
--
You received this message because:
1. The project was configured to send all issue notifications to this address
You may adjust your notification preferences at:
https://bugs.chromium.org/hosting/settings
johns… via monorail
Jul 21, 2023, 1:18:43 PM7/21/23
to bu...@skia.org
Updates:
Labels: Priority-Icebox Type-Performance
Comment #1 on issue 14069 by johns...@google.com: SkSL: investigate a raster pipeline analysis pass
https://bugs.chromium.org/p/skia/issues/detail?id=14069#c1
Right now we're not focused on SkRP performance. If we decide that we need to go faster, this would be one approach to look into.
Labels: Priority-Icebox Type-Performance
Comment #1 on issue 14069 by johns...@google.com: SkSL: investigate a raster pipeline analysis pass
https://bugs.chromium.org/p/skia/issues/detail?id=14069#c1
Right now we're not focused on SkRP performance. If we decide that we need to go faster, this would be one approach to look into.
Reply all
Reply to author
Forward
0 new messages