summaryrefslogtreecommitdiffstats
path: root/docs/relnotes/7.11.1.html
diff options
context:
space:
mode:
authorRoland Scheidegger <[email protected]>2014-01-17 19:39:19 +0100
committerRoland Scheidegger <[email protected]>2014-01-20 17:45:53 +0100
commit8c0368abb9474d092e33f79773bfbb457d4d9edd (patch)
tree4efb0151a29e6f6c7a5cad98f55e70397444e0ae /docs/relnotes/7.11.1.html
parent799abb271a248f646faa5cc859968f8c71e1ef16 (diff)
draw: clean up d3d style point clipping
Instead of skipping x/y clipping completely if there's point_tri_clip points use guard band clipping. This should be easier (previously we could not disable generating the x/y bits in the clip mask for llvm path, hence requiring custom clip path), and it also allows us to enable this for tris-as-points more easily too (this would require custom tri clip filtering too otherwise). Moreover, some unexpected things could have happen if there's a NaN or just a huge number in some tri-turned-point, as the driver's rasterizer would need to deal with it and that might well lead to undefined behavior in typical rasterizers (which need to convert these numbers to fixed point). Using a guardband should hence be more robust, while "usually" guaranteeing the same results. (Only "usually" because unlike hw guardbands draw guardband is always just twice the vp size, hence small vp but large points could still lead to different results.) Unfortunately because the clipmask generated is completely unaffected by guard band clipping, we still need a custom clip stage for points (but not for tris, as the actual clipping there takes guard band into account). Reviewed-by: Jose Fonseca <[email protected]>
Diffstat (limited to 'docs/relnotes/7.11.1.html')
0 files changed, 0 insertions, 0 deletions