[Bug 89650] New: dEQP-GLES3: incorrect wide line rasterization after clipping

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Wed Mar 18 01:28:21 PDT 2015


https://bugs.freedesktop.org/show_bug.cgi?id=89650

            Bug ID: 89650
           Summary: dEQP-GLES3: incorrect wide line rasterization after
                    clipping
           Product: Mesa
           Version: git
          Hardware: Other
                OS: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Drivers/DRI/i965
          Assignee: idr at freedesktop.org
          Reporter: itoral at igalia.com
        QA Contact: intel-3d-bugs at lists.freedesktop.org

Affected tests:

dEQP-GLES3.functional.rasterization.primitives.line_strip_wide
dEQP-GLES3.functional.rasterization.primitives.line_loop_wide

In these cases it looks like one of the edges of a line is outside the viewport
(right end of the viewport). The hardware seems to clip using the rightmost
edge of the line as reference, but this means that the leftmost side is clipped
before it should according to dEQP.

Enabling the guardand test in gen7 fixes this, but a comment in the code
suggests that we should not do this to prevent rendering to the underlying
surface outside the viewport region (gen8 hw fixes this apparently), so if the
guardband is not disabled for this case in gen8 this may be fixed for gen8+.

The OpenGL spec is not clear as to how clipping should work with wide lines,
but it suggests that for xmajor lines, columns of pixels should be rendered,
and that is not what is happening here (but that section does not consider
clipping to any extent). Some texts seem to suggest that OpenGL expects wide
lines to be rendered as multiple width=1 lines. If this is the case, then deqp
is right and intel rendering is bogus (intel renders a paralelogram), but
nothing in the OpenGL spec seems to make this clear. I think clipping with wide
lines is not clearly specified.

So this might be a bogus tests or incorrect. We had some discussion on this
topic in the mailing list:
http://lists.freedesktop.org/archives/mesa-dev/2015-February/076072.html

Although I don't think there is a clear conclusion I believe that the spirit of
the spec is the one represented by dEQP expectations.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/intel-3d-bugs/attachments/20150318/ad73452e/attachment.html>


More information about the intel-3d-bugs mailing list