<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - [BDW Bisected]dEQP-GLES3.functional.rasterization.fbo.rbo_multisample_max.primitives.lines_wide fails" href="https://bugs.freedesktop.org/show_bug.cgi?id=90749#c10">Comment # 10</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - [BDW Bisected]dEQP-GLES3.functional.rasterization.fbo.rbo_multisample_max.primitives.lines_wide fails" href="https://bugs.freedesktop.org/show_bug.cgi?id=90749">bug 90749</a> from <a class="email" href="mailto:itoral@igalia.com" title="Iago Toral <itoral@igalia.com>"> Iago Toral</a> <pre>(In reply to Ian Romanick from <a href="show_bug.cgi?id=90749#c9">comment #9</a>) > (In reply to Iago Toral from <a href="show_bug.cgi?id=90749#c2">comment #2</a>) > > From the OpenGL ES 3.1 spec: > > > > "13.4.2.1 Wide Lines > > The actual width of lines is determined by rounding the supplied width to > > the nearest integer, then clamping it to the implementation-dependent > > maximum line width." > > > > This is what the bad commit implements. In section "13.4.4 Line Multisample > > Rasterization", the spec talks about multisampled scenarios in particular > > (which is what the failed test uses), but nothing there seems to contradict > > the above statement. > > > > More over, the test that fails tests multiple line widths, but only fails > > for the one we advertise as maximum (7.375). If I change that value to > > 7.250, 7.125 or 7.000, the dEQP test passes just fine. This, as per ther > > statement in section 13.4.2.1 that I pasted above, is unexpected, since all > > these line widths are supposed to be rounded to 7.0 and produce the exact > > same rendering. The fact that dEQP expects a different rendering for 7.375 > > points to the test being bogus. In fact, not rounding the line-width if > > multisampling is enabled seems to fix the test, but as I say, that seems to > > be against the spec, so my conclusion is that this dEQP test is incorrect. > > I think you could read the spec either way. Section 13.4.2.1 talks about > rendering aliased wide lines, and section 13.4.4 talks about rendering > general multisampled lines. Look at similar text in the desktop OpenGL 4.4 > spec: > > 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. > > When ES removed antialiased lines, they removed "non-antialised" but > probably should not have. I believe removing the quantization for > multisample and antialiased lines is correct. Oh, good catch! I just tested this and works without causing any regressions in any of the dEQP wide line rasterization tests. I sent this patch for review: <a href="http://lists.freedesktop.org/archives/mesa-dev/2015-June/086031.html">http://lists.freedesktop.org/archives/mesa-dev/2015-June/086031.html</a></pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>