[Mesa-dev] [PATCH] glsl: expose textureQueryLod in GLSL 4.00+ fragment shaders

[Marek Olšák]

On Fri, Aug 21, 2015 at 1:10 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
> On Thu, Aug 20, 2015 at 7:08 PM, Timothy Arceri <t_arceri at yahoo.com.au> wrote:
>> On Thu, 2015-08-20 at 14:06 -0400, Ilia Mirkin wrote:
>>> On Thu, Aug 20, 2015 at 2:01 PM, Marek Olšák <maraeo at gmail.com>
>>> wrote:
>>> > On Thu, Aug 20, 2015 at 5:15 PM, Ilia Mirkin <imirkin at alum.mit.edu>
>>> > wrote:
>>> > > So just stick something like
>>> > >
>>> > > """
>>> > > From the ARB_texture_query_lod spec:
>>> > >
>>> > >     (3) The core specification uses the "Lod" spelling, not
>>> > > "LOD". Should
>>> > >         this extension be modified to use "Lod"?
>>> > >
>>> > >       RESOLVED: The "Lod" spelling is the correct spelling for
>>> > > the core
>>> > >       specification and the preferred spelling for use. However,
>>> > > use of
>>> > >       "LOD" also exists, as the extension predated the core
>>> > > specification,
>>> > >       so this extension won't remove use of "LOD".
>>> > > """
>>> > >
>>> > > as the commit message? Fine by me. It seems excessive to put that
>>> > > into
>>> > > builtin_functions.cpp... but if people feel strongly, I can do
>>> > > that
>>> > > too.
>>> >
>>> > People tend to read code more than commit messages, so putting it
>>> > in
>>> > the code is better.
>>>
>>> I don't really see what it adds to either the commit message or the
>>> code... we don't have stuff in the code for like "xyz added by spec
>>> bar". It's pretty obvious from the availability predicate... I don't
>>> see a single other instance of this in builtin_functions.cpp.
>>
>> I don't necessarily think you need to put it in the code, but commit
>> messages are cheap. The code makes it obvious that this is the way it
>> should be done, but its not immediately obvious why this sillyness is
>> forced on us.
>>
>> For example if its a spec bug that was later fixed but applications
>> still expect the old behaviour? or is it a bug that is noted but will
>> not be fixed?
>
> OK, well I don't really care about what goes into the commit message,
> so I'm not going to argue the point, but I don't want to pollute code
> with this stuff for no reason.
>
> Marek, any objections?

No. Feel free to commit.

Marek