[Mesa-dev] GLSL 1.40 and fixed function

[nobled]

On Fri, Apr 13, 2012 at 5:52 PM, Ian Romanick <idr at freedesktop.org> wrote:
> On 04/13/2012 02:35 PM, Eric Anholt wrote:
>>
>> On Tue, 27 Mar 2012 10:41:09 -0700, Kenneth Graunke<kenneth at whitecape.org>
>>  wrote:
>>>
>>> On 03/27/2012 10:31 AM, Ian Romanick wrote:
>>>>
>>>> On 03/26/2012 01:35 PM, Eric Anholt wrote:
>>>>>
>>>>> I've got a question for GLSL 1.40 that could use some interpretation:
>>>>>
>>>>> Section 1.2.5 in the spec says:
>>>>> "The following features, previously deprecated, are removed:
>>>>> ...
>>>>> Fixed functionality for a programmable stage. Supply shaders for
>>>>> all stages currently being used."
>>>>>
>>>>> What exactly does this mean? Undefined results? Link error? Draw
>>>>> time error? I couldn't find anything explicit in the 3.1 core spec
>>>>> (since it doesn't have fixed function, so it doesn't really explain
>>>>> interaction with it) or the compat spec (since it has
>>>>> ARB_compatibility, so that deprecated functionality is re-allowed).
>>>>
>>>>
>>>> At the bottom of that list is also the line:
>>>>
>>>> "Removed features were recast under the ARB_compatibility
>>>> extension, within this specification."
>>>>
>>>> I believe this implies the same link error as in ES 2.0. The wording is
>>>> weird. I thought we ended up saying something more clear than this, but
>>>> it was a long time ago.
>>>>
>>>>> I think my resolution would be: Don't expose GLSL 1.40 outside of a GL
>>>>> 3.1+ core context, thus dodging the question of how to interact between
>>>>> the FF and GLSL 1.40 without GL_ARB_compatibility exposed.
>>>>
>>>>
>>>> I think that's reasonable. Though, this may lead to people wanting
>>>> EXT_gpu_shader4 to get UBOs in some apps. I guess we can cross that
>>>> bridge when we come to it.
>>>>
>>>> There is also a requirement that shaders from different stage must have
>>>> the same version. We could just enable the same all-stages linker check
>>>> if any stage is 1.40 that we already have for ES shaders.
>>>>
>>>> It's not a huge deal to me either way.
>>>
>>>
>>> Yeah, I think the linker needs to mandate all stages be present, like
>>> ES.  That said, I'm still unclear what happens if you do a draw call
>>> without a UseProgram.  Undefined results?  GL error?
>>
>>
>> Yeah, I haven't found any mandate there.  I would think a
>> GL_INVALID_OPERATION?
>
>
> I believe that ES says GL_INVALID_OPERATION.  I think OpenGL 3.1 is
> ambiguous, but I have a vague recollection that it was cleaned up in some
> later spec.  There's some complexity in later 3.x versions because:
>
> 1. You can have a VS+FS without a GS.
>
> 2. You can have a VS or VS+GS with transform feedback and rasterizer
> discard.
>
> Of course, it gets even more complicated with the tessellation stages.
>
>> The link error makes sense, at least until
>> GL_ARB_separate_shader_objects.  And we just won't expose GL_EXT_sso on
>> a 3.1 core context.
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev

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."

I'm not sure if "undefined" is used in the "undefined rendering
results" sense or the "summoning nasal demons" sense, though.