summaryrefslogtreecommitdiffstats
path: root/src/gallium/winsys
diff options
context:
space:
mode:
authorRoland Scheidegger <[email protected]>2018-11-23 02:31:24 +0100
committerRoland Scheidegger <[email protected]>2018-11-29 18:39:40 +0100
commitfbf95ce0742a4683d6a1a1a101fc7ef104c29886 (patch)
treec07f58fedadf9ccbefea5a3ee886454dec3ed711 /src/gallium/winsys
parent94bfb8bf386b560e8e6095727ed1cf08522a027d (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