[Mesa-dev] GLSL 1.40 and fixed function

[Ian Romanick]

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.