On Mon, Apr 16, 2012 at 1:01 PM, Paul Berry <stereotype...@gmail.com> wrote: > On 16 April 2012 09:44, Ian Romanick <i...@freedesktop.org> wrote: >> >> On 04/15/2012 03:25 AM, nobled wrote: >> >>> I'm not sure if I'm missing something, but the non-compatibility >>> OpenGL 3.1 Specification seems pretty straightforward about this: >>> >>> page 42/55 section 2.11 "Vertex Shaders": >>> "If the program object >>> has no vertex shader, or no program object is currently in use, the >>> results of vertex >>> shader execution are undefined." >>> >>> page 160/173 section 3.9 "Fragment Shaders": >>> "If the program >>> object has no fragment shader, or no program object is currently in >>> use, the results >>> of fragment shader execution are undefined." >>> >>> page 45/58 section 2.11.2 "Program Objects": >>> "If UseProgram is called with program set to 0, then the current >>> rendering state refers to an invalid program object, and the results >>> of vertex and >>> fragment shader execution are undefined. However, this is not an error." >> >> >> Right. It looks like this language persists all the way through OpenGL >> 4.2. >> >> I did a bit more spec spelunking, and it seems the only link error >> required by desktop OpenGL is for geometry shaders and tessellation shaders. >> >> "Linking will also fail if the program object contains objects >> to form a geometry shader (see section 2.12), and >> >> * the program contains no objects to form a vertex shader; >> >> ..." >> >> >> "Linking can fail for a variety of reasons as specified in the >> OpenGL Shading Language Specification, as well as any of the >> following reasons:" >> >> * ... >> >> * The program object contains objects to form a tessellation >> control shader (see section 2.12.1), and >> >> - the program is not separable and contains no objects >> to form a vertex shader; >> >> ..." >> >> >>> I'm not sure if "undefined" is used in the "undefined rendering >>> results" sense or the "summoning nasal demons" sense, though. >> >> >> That's not defined. :p Sorry, I couldn't resist. >> >> Here's my new proposal: >> >> * Don't generate a linker error or warning for incomplete programs. >> >> * For draw calls that use incomplete programs, drop the rendering on >> the floor and emit a message to the debug log. That makes sense as a conservative approach. If it's truly undefined behaviour, then emitting INVALID_OPERATION would also be legal. I'm surprised that isn't required, since there's already something *almost* like that anyway in the standard for *other* conditions that make a program non useable--
"validation is done when the first rendering command is issued, to determine if the currently active program object can be executed. If it cannot be executed then no fragments will be rendered, and the error INVALID_OPERATION will be generated." > > > A point of clarification: if the program is incomplete because it lacks a > fragment shader, is transform feedback expected to work? My read of the > spec is that the phrase "the results of fragment shader execution are > undefined" means that transform feedback is still expected to work in this > situation. So we need to make sure that we only drop fragments on the > floor, not vertices. Yep-- page 71/84 section 2.11.7 "Shader Execution": "Undefined behavior results if the program object in use has no fragment shader unless transform feedback is enabled, in which case only a vertex shader is re- quired." _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
