[Mesa-dev] [PATCH 1/2] mesa/vbo: Fix scaling issue in 10-bit signed normalized packing.

Kenneth Graunke kenneth at whitecape.org
Wed Oct 31 11:45:45 PDT 2012


On 10/15/2012 09:45 AM, Ian Romanick wrote:
> On 10/14/2012 12:02 PM, Kenneth Graunke wrote:
>> For the 10-bit components, the divisor was incorrect.  A 10-bit signed
>> integer can represent -2^9 through 2^9 - 1, which leads to the following
>> ranges:
>>
>>         (float)value.x          -> [ -512,  511]
>> 2.0F * (float)value.x          -> [-1024, 1022]
>> 2.0F * (float)value.x + 1.0F   -> [-1023, 1023]
>>
>> So dividing by 511 would incorrectly scale it to approximately:
>> [-2.001956947, 2.001956947].  To correctly scale to [-1.0, 1.0], we need
>> to divide by 1023.
>
> This is a very annoying part of the desktop GL specification: there are
> two different ways to convert 10-bit and 2-bit normalized integers to
> float.  GLES3 "fixes" this, I believe, by having only one conversion.
> Can you double-check these changes against the GLES3 rules?

Sigh.  You're right...this code implements equation 2.2

    f = (2c + 1)/(2^b - 1).                                (2.2)

which is mandatory and correct for desktop OpenGL 4.1 and earlier. 
Starting with GL 4.2 and GLES 3, the spec changed to instead require 
equation 2.3:

    f = max{c/(2^(b-1) - 1), -1.0}                         (2.3)

It also explicitly marks this as a change in behavior.  So we'll need to 
conditionalize it based on the current context API and version, I guess. 
  Ugh.


More information about the mesa-dev mailing list