On Wed, Dec 30, 2015 at 8:55 PM, Roland Scheidegger <srol...@vmware.com> wrote: > Am 30.12.2015 um 21:26 schrieb Matt Turner: >> The OpenGL specifications for these functions say: >> >> The result will be undefined if <offset> or <bits> is negative, or if >> the sum of <offset> and <bits> is greater than the number of bits >> used to store the operand. >> >> Therefore passing bits=32, offset=0 is legal and defined in GLSL. >> >> But the earlier DX11/SM5 bfi/ibfe/ubfe opcodes are specified to accept a >> bitfield width ranging from 0-31. As such, Intel and AMD instructions >> read only the low 5 bits of the width operand, making them not compliant >> with the GLSL spec, so we have to special case the bits=32 case. >> >> Checking that offset=0 is not necessary, since for any other value, >> <offset> + <bits> will be greater than 32, which is specified as >> generating an undefined result. > What about offset=32, bits=0, will that work? > >> >> Fixes: >> ES31-CTS.shader_bitfield_operation.bitfieldInsert.uint_2 >> ES31-CTS.shader_bitfield_operation.bitfieldInsert.uvec4_3 >> ES31-CTS.shader_bitfield_operation.bitfieldExtract.uvec3_0 >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92595 >> --- >> Yuck. Suggestions welcome. > Do blob drivers do that correctly? Otherwise make it a spec bug? > (Albeit I can see from a theoretical point of view why those 0/32 cases > make sense so it probably really is intentional.)
Intentional might be an overstatement (given that hardware from major vendors couldn't implement it with the intended instructions...), but I don't think it's a spec bug and I really don't think it's fixable there since it's tested in the ES 3.1 conformance suite. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
