https://bugs.freedesktop.org/show_bug.cgi?id=94456
--- Comment #1 from Kenneth Graunke <kenn...@whitecape.org> ---
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.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug._______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
