[Piglit] [PATCH 2/4] arb_shader_precision: add framework for calculating tolerances for complex functions
Micah Fedke
micah.fedke at collabora.co.uk
Tue Feb 24 09:37:29 PST 2015
On 02/24/2015 11:28 AM, Ilia Mirkin wrote:
> On Tue, Feb 24, 2015 at 12:25 PM, Micah Fedke
> <micah.fedke at collabora.co.uk> wrote:
>>
>>
>> On 02/20/2015 05:31 PM, Ilia Mirkin wrote:
>>>
>>> On Thu, Feb 19, 2015 at 1:06 AM, Micah Fedke
>>> <micah.fedke at collabora.co.uk> wrote:
>>>>
>>>> +def _gen_tolerance(name, rettype, args):
>>>> + """Return the tolerance that should be allowed for a function for
>>>> the
>>>> + test vector passed in. Return -1 for any vectors that would push
>>>> the
>>>> + tolerance outside of acceptable bounds
>>>> + """
>>>> + if name in simple_fns:
>>>> + if name == 'op-mult' or name == 'op-assign-mult':
>>>
>>>
>>> Seems like this should be outside of the if. So like
>>>
>>> if name == 'op-mult' or name == ...:
>>> elif name in simple_fns:
>>> elif name in compelx_fns:
>>>
>>
>> It could work just as well that way, yes. My intent was to first split the
>> names into two mutually exclusive high-level groups (simple_fns and
>> complex_fns), and then treat individual members of those groups as necessary
>> (eg. the mult operations, which only appear within simple_fns). I'd like to
>> leave it this way for clarity, if you agree? I can add a comment line
>> somewhere about the mutual exclusivity of the two groups.
>
> Yeah, but you treat op-mult totally differently than the other simple
> functions. Making them not-simple. Perhaps they should just be in
> complex fns?
>
Haha, yeah, wasn't thinking clearly. The mults are *both* simple and
complex. Simple when float*float or vec*vec, but complex when mats show
up and force matrix multiplication. I'll try a third group :)
>>
>>>> + x_type = glsl_type_of(args[0])
>>>> + y_type = glsl_type_of(args[1])
>>>> + if x_type.is_vector and y_type.is_matrix:
>>>> + mult_func = _vec_times_mat_ref
>>>> + elif x_type.is_matrix and y_type.is_vector:
>>>> + mult_func = _mat_times_vec_ref
>>>> + elif x_type.is_matrix and y_type.is_matrix:
>>>> + mult_func = _mat_times_mat_ref
>>>> + else:
>>>> + return simple_fns[name]
>>>> + ret = _analyze_ref_fn(mult_func, args)
>>>> + return -1.0 if any(ret['badlands']) else map(float,
>>>> ret['component_tolerances'])
>>>> + else:
>>>> + return simple_fns[name]
>>>> + elif name in complex_fns:
>>>> + if name in componentwise_fns:
>>>> + ret = {'errors':[], 'badlands':[],
>>>> 'component_tolerances':[]}
>>>
>>>
>>> Is there some sort of advantage to keeping these in a dict?
>>
>>
>> The dict is for clarity purposes only. I guess I could use a named tuple
>> instead? It seemed like more code . . .
>
> The alternative I had in mind was just 3 separate variables...
>
Will do.
--
Micah Fedke
Collabora Ltd.
+44 1223 362967
https://www.collabora.com/
https://twitter.com/collaboraltd
More information about the Piglit
mailing list