diff options
author | Roland Scheidegger <[email protected]> | 2018-11-23 02:31:24 +0100 |
---|---|---|
committer | Roland Scheidegger <[email protected]> | 2018-11-29 18:39:40 +0100 |
commit | fbf95ce0742a4683d6a1a1a101fc7ef104c29886 (patch) | |
tree | c07f58fedadf9ccbefea5a3ee886454dec3ed711 /src/gallium/winsys | |
parent | 94bfb8bf386b560e8e6095727ed1cf08522a027d (diff) |
draw: fix infinite loop in line stippling
The calculated length of a line may be infinite, if the coords we
get are bogus. This leads to an infinite loop in line stippling.
To prevent this test for this explicitly (although technically
on at least x86 sse it would actually work without the explicit
test, as long as we use the int-converted length value).
While here also get rid of some always-true condition.
Note this does not actually solve the root cause, which is that
the coords we receive are bogus after clipping. This seems a difficult
problem to solve. One issue is that due to float arithmetic, clip w
may become 0 after clipping if the incoming geometry is
"sufficiently degenerate", hence x/y/z ndc (and window) coords will
be all inf (or nan). Even with w not quite 0, I believe it's possible
we produce values which are actually outside the view volume.
(Also, x=y=z=w=0 coords in clipspace would be not considered subject
to clipping, and similarly result in all NaN coords.) We just hope for
now other draw stages (and rasterizers) can handle those relatively
safely (llvmpipe itself should be sort of robust against this, certainly
converstion to fixed point will produce garbage, it might fail a couple
assertions but should neither hang nor crash otherwise).
Reviewed-by: Jose Fonseca <[email protected]>
Diffstat (limited to 'src/gallium/winsys')
0 files changed, 0 insertions, 0 deletions