On Wed, 19 Oct 2011 11:26:02 -0700, Paul Berry <stereotype...@gmail.com> wrote: Non-text part: multipart/alternative > On 18 October 2011 17:33, Eric Anholt <e...@anholt.net> wrote: > > > A driver trying to set up builtin uniforms is faced with a problem: > > How do I walk the ir_variable structure (representing an array of > > structs, or array of matrices, or struct, or whatever), and set up > > driver structures so that dereference of that uniform gets the > > corresponding ParameterValues[] entry. The rule in general is that > > each corresponding vector-sized field of an array of structs is one > > builtin uniform state slot. i965 relied on another invariant: each > > state slot has a number of unique channel swizzles corresponding to > > the number of elements in the field's vector, to avoid needing to walk > > the glsl_type in parallel to get at vector_elements. > > > > Since only the i965 driver relies on this invariant, it would be easy for a > mesa core developer to mess this up in the future and not notice. Can we > add an assertion to ir_variable.cpp's add_uniform() function to verify the > invariant? That would also serve as a nice place to document why the > invariant is necessary.
That would require the same walking of the glsl_type that we're trying to avoid in the driver. Also, apparently idr's going to be rebuilding how this is hooked up anyway, so that the driver doesn't care any more.
pgpxavB1hqwWK.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
