The following tests all fail: dEQP-GLES3.functional.state_query.floats.blend_color_getinteger64 dEQP-GLES3.functional.state_query.floats.color_clear_value_getinteger64 dEQP-GLES3.functional.state_query.floats.depth_clear_value_getinteger64 It looks like we're converting the numbers from float to 64-bit integer incorrectly (or at least differently than the test expects).
According to the GL 4.4 core specification, section 2.2.2 ("Data Conversions For State Query Commands"): "If a command returning integer data is called, such as GetIntegerv or GetInteger64v, a boolean value of TRUE or FALSE is interpreted as one or zero, respectively. A floating-point value is rounded to the nearest integer, unless the value is an RGBA color component, a DepthRange value, or a depth buffer clear value. In these cases, the query command converts the floating-point value to an integer according to the INT entry of table 18.2; a value not in [−1, 1] converts to an undefined value." The INT entry of table 18.2 shows that b = 32, meaning the expectation is to convert it to a 32-bit integer value. This also matches what dEQP expects, fixing all three tests. It seems a little silly for glGetInteger64v to return a 32-bit number, but then again it's probably more reasonable to request floating point data via glGetFloat()... This has apparently been broken in Mesa since 2009.
Patch on list: https://lists.freedesktop.org/archives/mesa-dev/2016-March/109466.html
Fixed on master by: commit 3823b53ff88b36cfe0c46a2207abe8568237283d Author: Kenneth Graunke <kenneth@whitecape.org> Date: Tue Mar 8 20:45:26 2016 -0800 mesa: Make glGetInteger64v convert float/doubles to 32-bit integers. Thanks to Dave for reviewing!
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.