I don't remember implementing anything in the GLSL linker for colors not to be counted against the maximum varying count limit.
R500 supports GL_ARB_color_buffer_float, but not GL3.0. R300 and R500 have special slots for colors. Marek On Wed, Sep 18, 2013 at 10:30 PM, Paul Berry <stereotype...@gmail.com> wrote: > On 18 September 2013 13:04, Ian Romanick <i...@freedesktop.org> wrote: >> >> On 09/13/2013 01:45 PM, Paul Berry wrote: >> > On 11 September 2013 16:28, Ian Romanick <i...@freedesktop.org >> > <mailto:i...@freedesktop.org>> wrote: >> > Another question which we haven't really addressed is how Mesa's front >> > end linker should check these limits, given the fact that some >> > implementations have dedicated locations for certain shader >> > inputs/outputs. I have a few ideas about this, but it's probably >> > something that we should save for a future patch series. >> >> Maybe the 39th time will be the charm. :( The last time this came up >> was w.r.t. gl_Color and gl_SecondaryColor. Most (all?) SM2 hardware >> (i915, r300, and probably others) have special slots that can be used >> for *clamped* fragment shader inputs. So, gl_Color can use those slots >> if the API setting of CLAMP_VERTEX_COLOR is TRUE. This control is added >> by the GL_ARB_color_buffer_float extension and OpenGL 3.0 > > > So i915, r300, and others even support GL_ARB_color_buffer_float/GL3.0? > > If so that's a bit of a difficult wrinkle because that means we can't > determine at link time whether the shader will fit in the available slots. > Given that these older hardware models are frequently pretty tightly > constrained on their number of varyings, and the fact that most apps > probably leave vertex color clamping on, it's probably best to do the link > error checking under the assumption that the special slots can be used. > Kind of lame since it means that a shader tha linked without error might not > be guaranteed to execute correctly in all GL states, but I'm guessin for > these older pieces of hardware that's the least of our worries :) > >> >> >> I think we need a flag for each special variable that says whether or >> not it is counted. I think Marek implemented something like this for >> gl_Color. >> > > Yeah, that seems reasonable. I was thinking along similar lines. We could > have bitfields called something like ctx->Const.DedicatedFsInputs and > ctx->Const.DedicatedVsOutputs. The convention would be: set the bit if your > hardware has a dedicated slot for the given input/output (and therefore it > doesn't need to be counted). That way a default value of 0 would correspond > to the conservative assumption that there are no dedicated slots at all. > > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
