Bug 109451 - [IVB,SNB] LINE_STRIPs following a TRIANGLE_FAN fail to use primitive restart
Summary: [IVB,SNB] LINE_STRIPs following a TRIANGLE_FAN fail to use primitive restart
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: 18.3
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Intel 3D Bugs Mailing List
QA Contact: Intel 3D Bugs Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-01-24 19:33 UTC by Dorian Wouters
Modified: 2019-02-20 19:50 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
apitrace of example program (86.91 KB, application/octet-stream)
2019-01-24 19:33 UTC, Dorian Wouters
Details
test program source code (7.14 KB, text/x-csrc)
2019-01-24 19:34 UTC, Dorian Wouters
Details
Mesa patch v1 (4.12 KB, patch)
2019-01-30 10:52 UTC, asimiklit
Details | Splinter Review

Description Dorian Wouters 2019-01-24 19:33:51 UTC
Created attachment 143227 [details]
apitrace of example program

Originally reported as a Blender bug: https://developer.blender.org/T60762
(which it is not)

Using desktop GL 3.3+.

Steps to reproduce:
* prepare a vertex and index buffer
* enable GL_PRIMITIVE_RESTART
* draw a GL_TRIANGLE_FAN using those buffers
* draw any number of GL_LINE_STRIPs with those same buffers

Drawing a GL_TRIANGLE_FAN prior to GL_LINE_STRIPs makes the strip draw calls fail to use restart markers (here, 0xFF), resulting in the line strips' supposedly unconnected strips being connected through a point of invalid coordinates (observed to consistently be (0, 0, 0)).
IOW, restart markers seems to be (re-)considered as normal indices.

Interfering with GL calls that read or write to the index buffer makes the problem go away, hinting at a GL state tracking or cache issue.
Comment 1 Dorian Wouters 2019-01-24 19:34:19 UTC
Created attachment 143228 [details]
test program source code
Comment 2 Denis 2019-01-25 08:25:00 UTC
Hi Dorian. Thanks for the report.
I reproduced issue using provided app.
Results:

Ivi bridge - reproduced on 11.0.0, 17.0.0, 18.3.0, 18.3.2, 19.0.0 git latest

But didn't reproduce on KBL with 18.1.5

Investigating
Comment 3 asimiklit 2019-01-25 15:03:07 UTC
I managed to reproduce this issue on SNB using the latest git mesa.
I am going to continue my investigation)
Comment 4 asimiklit 2019-01-28 15:07:45 UTC
I found out the root cause of the issue. Unfortunately the issue is in mesa. I have been working on a mesa patch and a piglit test for this issue.
Comment 5 asimiklit 2019-01-30 10:52:21 UTC
Created attachment 143256 [details] [review]
Mesa patch v1

Could you please check this mesa patch with this issue if it is possible and confirm if it helps you.

Thanks,
Andrii
Comment 6 asimiklit 2019-02-01 09:40:19 UTC
I reproduce this issue on KBL using the following test:
https://gitlab.freedesktop.org/asimiklit/piglit/commit/118f0999918f67230ab79780186a1c15febafb3b

The solution was suggested:
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/176
Comment 7 Lionel Landwerlin 2019-02-20 19:50:13 UTC
Fixed with :

commit f4f4ec941e1427142656e588244f378e469e996e (HEAD -> master, origin/master)
Author: Andrii Simiklit <andrii.simiklit@globallogic.com>
Date:   Fri Jan 25 15:03:07 2019 +0200

    i965: re-emit index buffer state on a reset option change.
    
    Seems like we forget to update the index buffer (ib) status and
    IndexedDrawCutIndexEnable or CutIndexEnable flag is left unchanged it
    leads to ignoring of glEnable/glDisable functions for GL_PRIMITIVE_RESTART
    in some cases. The index buffer (ib) status should be re-emmited after the
    reset option change to avoid some unexpected behavior.
    
    Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109451
    Cc: <mesa-stable@lists.freedesktop.org>
    Signed-off-by: Andrii Simiklit <andrii.simiklit@globallogic.com>
    Signed-off-by: Andrii Simiklit <asimiklit.work@gmail.com>


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.