diff options
author | Iago Toral Quiroga <[email protected]> | 2015-06-10 09:07:32 +0200 |
---|---|---|
committer | Iago Toral Quiroga <[email protected]> | 2015-06-11 08:32:07 +0200 |
commit | f9a18acb56c69b24c1e47cd326dc98e14fadcf94 (patch) | |
tree | 51d836afe08fb2fd1befa460ab4e73bd480ac351 /doxygen | |
parent | f83b9e58f6e8a748def367c7d523eb7285b1aeb7 (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