The following tests all fail:
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
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:
Fixed on master by:
Author: Kenneth Graunke <firstname.lastname@example.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!
on Mar 27, 2017 at 02:52:04.
(provided by the Example extension).