<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - dEQP-GLES3.functional.state_query.floats.{blend_color,color_clear_value,depth_clear_value}_getinteger64 fail" href="https://bugs.freedesktop.org/show_bug.cgi?id=94456#c1">Comment # 1</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - dEQP-GLES3.functional.state_query.floats.{blend_color,color_clear_value,depth_clear_value}_getinteger64 fail" href="https://bugs.freedesktop.org/show_bug.cgi?id=94456">bug 94456</a> from <a class="email" href="mailto:kenneth@whitecape.org" title="Kenneth Graunke <kenneth@whitecape.org>"> Kenneth Graunke</a> <pre>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.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are the assignee for the bug.</li> </ul> </body> </html>