<html>
    <head>
      <base href="https://bugs.freedesktop.org/" />
    </head>
    <body>
      <p>
        <div>
            <b><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#c9">Comment # 9</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 <span class="vcard"><a class="email" href="mailto:idr@freedesktop.org" title="Ian Romanick <idr@freedesktop.org>"> <span class="fn">Ian Romanick</span></a>
</span></b>
        <pre>(In reply to Iago Toral from <a href="show_bug.cgi?id=90749#c2">comment #2</a>)
<span class="quote">> 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.</span >

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.</pre>
        </div>
      </p>
      <hr>
      <span>You are receiving this mail because:</span>
      
      <ul>
          <li>You are the QA Contact for the bug.</li>
      </ul>
    </body>
</html>