<div dir="ltr"><div><div>I am getting another error regarding explicit locations, which I believe has a one-line fix. If I only have a single uniform in my shader, and that uniform is explicitely given location 1 (or anything above zero), my program will crash if I attempt to give the unnassigned locs a value with glProgramUniform1i().<br>
</div>A quick view into the code appears to reveal reserve_explicit_locations() as the culprit by initializing the remap table entries to NULL instead of INACTIVE_UNIFORM_EXPLICIT_LOCATION, which will allow validate_uniform_parameters() to pass the test "if (shProg->UniformRemapTable[location] ==INACTIVE_UNIFORM_EXPLICIT_LOCATION)" later.<br>
<br></div>Should I open another bug report?<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Aug 27, 2014 at 11:15 AM, Tapani Pälli <span dir="ltr"><<a href="mailto:tapani.palli@intel.com" target="_blank">tapani.palli@intel.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 08/26/2014 10:37 PM, Ian Romanick wrote:<br>
> On 08/23/2014 07:51 AM, Micael wrote:<br>
>> On second thought, the glsl_type::uniform_locations() method comment in<br>
>> the header file says:<br>
>> /**<br>
>>  * Calculate the number of unique values from glGetUniformLocation for the<br>
>>  * elements of the type.<br>
>>  */<br>
>><br>
>> Which makes me believe that maybe we should return at least 1 for every<br>
>> case because this is only called for explicit locations and therefore<br>
>> will not make shaders failing to link unless they've explicitely used<br>
>> more locations than they should.<br>
>> Maybe glsl_type::uniform_locations() should be renamed to something that<br>
>> makes it clear it's only used for explicit locations too, or make it<br>
>> clear that it reflects the size for the API, not GPU memory (since it's<br>
>> only used to fill prog->UniformRemapTable).<br>
> I spent some time this morning looking at this code a bit more closely,<br>
> and I think you're right.  The problem is that GL overloads "locations"<br>
> both to mean the number of "handles" a uniform gets and to mean amount<br>
> of storage space the uniform occupies.  For some things this is the same<br>
> (simple variables, arrays, structures), but for other things it is not<br>
> (matrices, samplers, other opaque types).<br>
><br>
> I think it's weird for uniform_locations to call component_slots at all.<br>
<br>
</div>Yep, at the moment of writing this I have gotten confused of the<br>
locations and actual storage space (resulting in vectors using too many<br>
locs). As this is my mess, I've sent a patch that implements the count<br>
as you describe below + adds a bit more documentation to the header.<br>
<div class="HOEnZb"><div class="h5"><br>
> Looking at the OpenGL 4.2 spec, it seems that everything except atomic<br>
> counters and subroutines (not yet supported by Mesa) should have at<br>
> least one location per array element.<br>
><br>
> Here's what I think would be better: have uniform_locations mirror the<br>
> structure of component_slots.  Eliminate the is_matrix() check at the<br>
> top, and just have all the basic types (e.g., GLSL_TYPE_FLOAT) return 1.<br>
><br>
> Keeping functions separate that count separate kinds of things seems<br>
> like a good idea.<br>
><br>
>> On Sat, Aug 23, 2014 at 2:07 PM, Micael <<a href="mailto:kam1kaz3@gmail.com">kam1kaz3@gmail.com</a><br>
>> <mailto:<a href="mailto:kam1kaz3@gmail.com">kam1kaz3@gmail.com</a>>> wrote:<br>
>><br>
>>     On Fri, Aug 22, 2014 at 9:23 PM, Ian Romanick <<a href="mailto:idr@freedesktop.org">idr@freedesktop.org</a><br>
>>     <mailto:<a href="mailto:idr@freedesktop.org">idr@freedesktop.org</a>>> wrote:<br>
>><br>
>>         I'm not sure this is correct, and I think we need a more complex<br>
>>         fix.<br>
>>         As Dave points out, bindless will make it even more complex.<br>
>><br>
>>         In a non-bindless, static-sampler-array-indexing world, applications<br>
>>         assume that samplers will use zero uniform locations.  The sampler<br>
>>         information is baked into the instructions, and it isn't represented<br>
>>         anywhere else in GPU memory.  As a result, I would not be<br>
>>         surprised to<br>
>>         see previously working applications fail to link (due to using<br>
>>         too many<br>
>>         uniforms) with this change.<br>
>><br>
>>         It seems that the only time a sampler needs non-zero space is<br>
>>         when it is<br>
>>         part of any array samplers (or array of structures containing<br>
>>         samplers,<br>
>>         etc.) or is bindless.  In the array cases, it is probably only<br>
>>         necessary<br>
>>         when the index is dynamic.  I think the array splitting and<br>
>>         structure<br>
>>         splitting passes may make that moot.<br>
>><br>
>><br>
>>     Did you miss the case of assigning an explicit location to a<br>
>>     sampler, or did you ommit on purpose?<br>
>>     I'm not very familiar with mesa source, but as far as I could<br>
>>     analyze it, only reserve_explicit_locations() and<br>
>>     validate_explicit_location() call glsl_type::uniform_locations(),<br>
>>     everything else uses glsl_type::component_slots().<br>
>>     Now I agree with you that simply returning 1 from<br>
>>     glsl_type::uniform_locations() for samplers can be misleading.<br>
>><br>
>>     How about if glsl_type::uniform_locations() takes a "bool<br>
>>     isExplicitLocation" and return at least 1 for every type? I am aware<br>
>>     that this won't solve the bindless textures issue, but it would fix<br>
>>     this bug (and the integer underflows) for now, I think.<br>
>><br>
>><br>
>><br>
>>         The 82921 bug seems to be an orthognal issue.  There is a difference<br>
>>         between the API visible locations assigned to a uniform and the GPU<br>
>>         visible locations where the uniform is stored.  My guess is that<br>
>>         we're<br>
>>         using the same accounting for both in places where we should not.<br>
>><br>
>>         On 08/21/2014 04:25 PM, Micael Dias wrote:<br>
>>         > ---<br>
>>         > If samplers occupy zero locations we can run into a lot of<br>
>>         issues. See #82921.<br>
>>         > I briefly tested this with my own code (which was previously<br>
>>         crashing and<br>
>>         > misbehaving) and also ran other apps and everything seems to<br>
>>         work fine.<br>
>>         > I'm not used to contributing code in this fashion, so please<br>
>>         forgive me if I'm<br>
>>         > making some mistake. Thanks.<br>
>>         ><br>
>>         >  src/glsl/glsl_types.cpp | 2 ++<br>
>>         >  1 file changed, 2 insertions(+)<br>
>>         ><br>
>>         > diff --git a/src/glsl/glsl_types.cpp b/src/glsl/glsl_types.cpp<br>
>>         > index 66e9b13..cc05193 100644<br>
>>         > --- a/src/glsl/glsl_types.cpp<br>
>>         > +++ b/src/glsl/glsl_types.cpp<br>
>>         > @@ -691,6 +691,8 @@ glsl_type::uniform_locations() const<br>
>>         >        return size;<br>
>>         >     case GLSL_TYPE_ARRAY:<br>
>>         >        return this->length *<br>
>>         this->fields.array->uniform_locations();<br>
>>         > +   case GLSL_TYPE_SAMPLER:<br>
>>         > +      return 1;<br>
>>         >     default:<br>
>>         >        break;<br>
>>         >     }<br>
>>         ><br>
>><br>
>><br>
>><br>
>><br>
>>     --<br>
>>     Micael Dias<br>
>><br>
>><br>
>><br>
>><br>
>> --<br>
>> Micael Dias<br>
</div></div><div class="HOEnZb"><div class="h5">> _______________________________________________<br>
> mesa-dev mailing list<br>
> <a href="mailto:mesa-dev@lists.freedesktop.org">mesa-dev@lists.freedesktop.org</a><br>
> <a href="http://lists.freedesktop.org/mailman/listinfo/mesa-dev" target="_blank">http://lists.freedesktop.org/mailman/listinfo/mesa-dev</a><br>
<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Micael Dias
</div>