You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
On Apple hardware, the following near-cusp test case from the tricky_strokes test scene has this artifact at certain scale factors:
This specifically only seems to happen with the near-cusp defined as [(0., 0.01), (128., 127.999), (128., 0.01), (0., 127.99)]. The bug itself is in the flatten stage, specifically the cubic-to-es subdivision loop in flatten_euler. I debugged this over a couple days and here are my findings so far:
For that specific cubic, the issue is only present for a (uniform) scale factor within the range 5.3332 and 113.5797. Scale factors outside that range do not exhibit the issue. This can be verified by hard-coding a scale factor right before testing the scaled error estimate against the error tolerance:
...
scale = 5.3332;
if cubic_params.err * scale <= tol || dt <= SUBDIV_LIMIT {
...
The issue is not present when fastmath is disabled. The Metal compiler enables optimizations on floating-point arithmetic (which may violate the IEEE-754 standard) by default. I verified this by setting fastMathEnabled = NO on MTLCompilerOptions directly on Skia-Graphite's Metal backend (which uses the shaders directly and doesn't use wgpu).
The issue is not present on CPU shaders (which doesn't use fastmath).
The text was updated successfully, but these errors were encountered:
On Apple hardware, the following near-cusp test case from the
tricky_strokes
test scene has this artifact at certain scale factors:This specifically only seems to happen with the near-cusp defined as
[(0., 0.01), (128., 127.999), (128., 0.01), (0., 127.99)]
. The bug itself is in theflatten
stage, specifically the cubic-to-es subdivision loop inflatten_euler
. I debugged this over a couple days and here are my findings so far:5.3332
and113.5797
. Scale factors outside that range do not exhibit the issue. This can be verified by hard-coding a scale factor right before testing the scaled error estimate against the error tolerance:fastMathEnabled = NO
onMTLCompilerOptions
directly on Skia-Graphite's Metal backend (which uses the shaders directly and doesn't use wgpu).The text was updated successfully, but these errors were encountered: