[Mesa-dev] [PATCH 2/2] spirv: fix bug when OpSpecConstantOp calls a conversion

Ian Romanick idr at freedesktop.org
Wed Dec 6 20:25:52 UTC 2017


On 11/29/2017 02:17 AM, Samuel Iglesias Gonsálvez wrote:
> On Tue, 2017-11-28 at 13:13 -0800, Ian Romanick wrote:
>> On 11/20/2017 10:25 PM, Samuel Iglesias Gonsálvez wrote:
>>> In that case, nir_eval_const_opcode() will evaluate the conversion
>>> but as it was using destination's bit_size, the resulting
>>> value was just a cast of the source constant value. By passing the
>>> source's bit size, it does the conversion properly.
>>>
>>> Fixes:
>>>
>>> dEQP-VK.spirv_assembly.instruction.*.opspecconstantop.*convert*
>>>
>>> Signed-off-by: Samuel Iglesias Gonsálvez <siglesias at igalia.com>
>>> ---
>>>  src/compiler/spirv/spirv_to_nir.c | 31 ++++++++++++++++++++++++++-
>>> ----
>>>  1 file changed, 26 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/src/compiler/spirv/spirv_to_nir.c
>>> b/src/compiler/spirv/spirv_to_nir.c
>>> index 2cc3c275ea9..ffbda4f1946 100644
>>> --- a/src/compiler/spirv/spirv_to_nir.c
>>> +++ b/src/compiler/spirv/spirv_to_nir.c
>>> @@ -1348,14 +1348,35 @@ vtn_handle_constant(struct vtn_builder *b,
>>> SpvOp opcode,
>>>           bool swap;
>>>           nir_alu_type dst_alu_type =
>>> nir_get_nir_type_for_glsl_type(val->const_type);
>>>           nir_alu_type src_alu_type = dst_alu_type;
>>> -         nir_op op = vtn_nir_alu_op_for_spirv_opcode(opcode,
>>> &swap, src_alu_type, dst_alu_type);
>>> -
>>>           unsigned num_components = glsl_get_vector_elements(val-
>>>> const_type);
>>> -         unsigned bit_size =
>>> -            glsl_get_bit_size(val->const_type);
>>> +         unsigned bit_size;
>>>  
>>> -         nir_const_value src[4];
>>>           assert(count <= 7);
>>> +
>>> +         switch (opcode) {
>>> +         case SpvOpUConvert:
>>> +         case SpvOpConvertFToU:
>>> +         case SpvOpConvertFToS:
>>> +         case SpvOpConvertSToF:
>>> +         case SpvOpConvertUToF:
>>> +         case SpvOpSConvert:
>>> +         case SpvOpFConvert:
>>
>> I'm not sure what we should do here.  Most of these opcodes are not
>> valid in SpvOpSpecConstantOp in a Shader.  Only SpvOpSConvert and
>> SpvOpFConvert are allowed.  I guess it's trivial enough to support
>> the
>> others anyway...
> 
> Right.
> 
>>  do those dEQP-VK.spirv_assembly.instruction.* tests
>> exercise the other opcodes?
>>
> 
> No, they only exercise SpvOpFConvert and SpvOpSConvert. Do you prefer
> to just support these two opcodes for the moment?

Okay... good.  I wanted to make sure they weren't expecting out-of-spec
behavior. :)

> With or without that change, does it get your R-b?

Yes.

Reviewed-by: Ian Romanick <ian.d.romanick at intel.com>

> 
> Sam
> 
>>> +            /* We have a source in a conversion */
>>> +            src_alu_type =
>>> +               nir_get_nir_type_for_glsl_type(
>>> +                  vtn_value(b, w[4], vtn_value_type_constant)-
>>>> const_type);
>>> +            /* We use the bitsize of the conversion source to
>>> evaluate the opcode later */
>>> +            bit_size = glsl_get_bit_size(
>>> +               vtn_value(b, w[4], vtn_value_type_constant)-
>>>> const_type);
>>> +            break;
>>> +         default:
>>> +            bit_size = glsl_get_bit_size(val->const_type);
>>> +         };
>>> +
>>> +
>>> +         nir_op op = vtn_nir_alu_op_for_spirv_opcode(opcode,
>>> &swap, src_alu_type, dst_alu_type);
>>> +         nir_const_value src[4];
>>> +
>>>           for (unsigned i = 0; i < count - 4; i++) {
>>>              nir_constant *c =
>>>                 vtn_value(b, w[4 + i], vtn_value_type_constant)-
>>>> constant;
>>>


More information about the mesa-dev mailing list