On Tue, 27 Mar 2012 10:41:09 -0700, Kenneth Graunke <kenn...@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? 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.
pgpE1yCsJVRdr.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev