diff options
author | Roland Scheidegger <[email protected]> | 2014-01-17 19:39:19 +0100 |
---|---|---|
committer | Roland Scheidegger <[email protected]> | 2014-01-20 17:45:53 +0100 |
commit | 8c0368abb9474d092e33f79773bfbb457d4d9edd (patch) | |
tree | 4efb0151a29e6f6c7a5cad98f55e70397444e0ae /docs/relnotes/7.11.1.html | |
parent | 799abb271a248f646faa5cc859968f8c71e1ef16 (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