summaryrefslogtreecommitdiffstats
path: root/doxygen
diff options
context:
space:
mode:
authorIago Toral Quiroga <[email protected]>2015-06-10 09:07:32 +0200
committerIago Toral Quiroga <[email protected]>2015-06-11 08:32:07 +0200
commitf9a18acb56c69b24c1e47cd326dc98e14fadcf94 (patch)
tree51d836afe08fb2fd1befa460ab4e73bd480ac351 /doxygen
parentf83b9e58f6e8a748def367c7d523eb7285b1aeb7 (diff)
i965: do not round line width when multisampling or antialiaing are enabled
In commit fe74fee8fa721a we rounded the line width to the nearest integer to match the GLES3 spec requirements stated in section 13.4.2.1, but that seems to break a dEQP test that renders wide lines in some multisampling scenarios. Ian noted that the Open 4.4 spec has the following similar text: "The actual width of non-antialiased lines is determined by rounding the supplied width to the nearest integer, then clamping it to the implementation-dependent maximum non-antialiased line width." and suggested that when ES removed antialiased lines, they removed "non-antialised" from that paragraph but probably should not have. Going by that note, this patch restricts the quantization implemented in fe74fee8fa721a only to regular aliased lines. This seems to keep the tests fixed with that commit passing while fixing the broken test. v2: - Drop one of the clamps (Ken, Marius) - Add a rule to prevent advertising line widths that when rounded go beyond the limits allowed by the hardware (Ken) - Update comments in the code accordingly (Ian) - Put the code in a utility function (Ian) Fixes: dEQP-GLES3.functional.rasterization.fbo.rbo_multisample_max.primitives.lines_wide Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90749 Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Cc: "10.6" <[email protected]>
Diffstat (limited to 'doxygen')
0 files changed, 0 insertions, 0 deletions