<div dir="ltr"><div dir="ltr">On Wed, Nov 25, 2020 at 8:19 PM Ian Romanick <<a href="mailto:idr@freedesktop.org">idr@freedesktop.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I was looking at the dlist-beginend subtest test_illegal_begin_mode.<br>
The test compiles a display list with GL_COMPILE_AND_EXECUTE mode.  The<br>
glBegin in the test uses an invalid mode.  This should generate a<br>
GL_INVALID_OPERATION error immediately.  The test checks this, and that<br></blockquote><div><br></div><div>GL_INVALID_ENUM, actually, but anyway..</div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
seems correct.<br>
<br>
The test then tries to execute the display list and checks for<br>
GL_INVALID_OPERATION again.  I believe this is incorrect.  Section 5.4<br>
("Display Lists") of the OpenGL 1.0 spec (this is a gl-1.0 test, after<br>
all!) says:<br>
<br>
    If mode is COMPILE_AND_EXECUTE then commands are executed as they<br>
    are encountered, then placed in the display list.<br>
<br>
Section 2.5 ("GL Errors") of the OpenGL 1.0 spec says:<br>
<br>
    In other cases, the command generating the error is ignored so that<br>
    it has no effect on GL state or framebuffer contents.<br></blockquote><div><br></div><div>Unfortunately, the spec doesn't clearly define what's meant by "ignored" here.  That is, does it mean the command is not compiled into the display list?  My intuition is that even if a command has invalid args at compile time, the command should still be compiled into the list.  If the spec doesn't spell out the answer, I'd opt to do whatever other vendors do (hoping they're consistent).<br></div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
While the section numbers and titles have changed, every later version<br>
of the GL (compatibility profile) spec says the exact same thing.<br>
<br>
To me, this indicates that the errant glBegin should not be included in<br>
the display list.  Assuming this test passes on other implementations, I<br>
think it does so only by luck.  The mis-matched glEnd in the display<br>
list will generate the same error.  Am I missing some spec language to<br>
justify this test?<br></blockquote><div><br></div><div>I haven't searched, but I suspect the spec doesn't explicitly describe this situation.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I noticed this because I was adding a test that does<br>
<br>
        glNewList(list, GL_COMPILE_AND_EXECUTE);<br>
        glColor4fv(green);<br>
        glBegin(GL_QUADS);<br>
        glBegin(GL_QUADS);<br>
        glVertex2f(-1, -1);<br>
        glVertex2f( 1, -1);<br>
        glVertex2f( 1, 0);<br>
        glVertex2f(-1, 0);<br>
        glEnd();<br>
        glEndList();<br>
<br>
I expected an error while compiling the list, but I expected glCallList<br>
to not generate an error.  Errors are generated in both places.<br></blockquote><div><br></div><div>I guess my instinct is that errors should be generated both at list compile and execute time.  I wonder if there's any API function / argument combinations that would be errant at compile time but not at execute time, depending on some other state.  If so, that would indicate that calls should always be compiled into the list, even if they generate an error at compile time.<br></div><div><br> </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I think it gets worse.  There's a second part to this new subtest that<br>
replaces the errant glBegin call with glReadPixels.  glReadPixels is not<br>
allowed between glBegin and glEnd, so it should generate an error in<br>
GL_COMPILE_AND_EXECUTE mode.  It does not.<br></blockquote><div><br></div><div>Sound like a run of the mill bug.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
These changes are in the top commit of:<br>
<br>
    <a href="https://gitlab.freedesktop.org/idr/piglit/-/commits/display-list-hell" rel="noreferrer" target="_blank">https://gitlab.freedesktop.org/idr/piglit/-/commits/display-list-hell</a><br>
<br>
I don't have any systems currently available with closed-source drivers,<br>
but I would be very interested to see the results of<br>
gl-1.0-dlist-beginend from that branch on any closed source drivers (on<br>
any platform).<br><br></blockquote><div><br></div><div>I can check on Nvidia next week when I'm back.  Maybe someone else can test in the mean time.</div><div><br></div><div>-Brian</div><div><br></div></div></div>