plib-devel

[Plib-devel] BUG IN DYNAMIC LINKER

[Steve B. <sjb...@ai...>]

Some time ago, someone reported this message:

  BUG IN DYNAMIC LINKER ld.so: dl-version.c: 210: _dl_check_map_versions:
Assertion `needed != ((void *)0)' failed!

...subsequently, I was hit by the exact same thing.

Finally, I gave in and blew a couple of hours of heavy search engine
thrashing which yielded this:

http://x40.deja.com/getdoc.xp?AN=545891503&CONTEXT=958448712.1788280849&hitnum=29

...in short, it says that there is a problem with dynamically linking
to libraries that in turn dynamically link to the PThreads library.

Since the latest Mesa uses Pthreads but the nVidia OpenGL for Linux
does not, this is a spot-on diagnosis for my peculiar symptoms.

A viable work-around appears to be to add '-lpthread' into the linker
options for any program that links to Mesa...or might link to Mesa
in the future.

We have to presume that a bug such as this (which features in one
of the Linux fortune cookies!) is going to be around for a while...
so I advise everyone to add -lpthread into their Makefile's.


-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjb...@ai... (home)  http://www.woodsoup.org/~sbaker
sj...@ht...      (work)

[Plib-devel] Ancient history....depth buffer queries

[Scott M. <mcm...@ca...>]

Steve:

I was going through some very old info-performer archives on
depth/range calculations and I came across your formula again, and
I have a question.  Here's what you wrote (I think...as formatting
has garbled the equation):

> This comes up about every 6 months....here is the stock reply...
> 
>   The 'official' SGI solution to this is...
> 
>     z = value in z buffer after rendering (input)
>     range = distance to pixel in database units (output)
> 
>     np = distance to near clipping plane
>     fp = distance far clipping plane
> 
>     nz = near-clip z value
>     fz = far-clip z value
>                 (as read from glGetIntegerv ( GL_DEPTH_RANGE,...) for OpenGL)
> 
>     For each Z-buffer value:
> 
>                      fp*np(fz-nz)
>                      ------------
>                         fp-np
>     - range = --------------------------
>                   (fp+np)(fz-nz)   fz+nz
>               z - -------------- - -----
>                      2(fp-np)        2
> 

My questions are:
1) has this formatting been restored correctly?
2) Could you explain the nz/fz equations more clearly...
   Did you really mean glGetIntegerv, or do I do something
   like the following?:

   float depth_range[2];
   glGetFloatv(GL_DEPTH_RANGE, depth_range);
   nz = near_clip - depth_range[0];   // indices
   fz =  far_clip - depth_range[1];

   With integers I get 0,2147482496 (not MAX_INT)
   With floats   I get 0,1

3) What format should I read the depth buffer in in the first place?

Note that I am querying the depth buffer as floats with the following:

GLfloat *depthData3 = (GLfloat *) malloc(sizeX*sizeY*sizeof(GLfloat));
glReadPixels(0, 0, sizeX, sizeY,
             GL_DEPTH_COMPONENT, GL_FLOAT, depthData3);

Any help is greatly appreciated,
scott

-- 
Scott McMillan
mailto:mcm...@ca...

SGL Home Page:       http://sgl.sourceforge.net
DynaMechs Home Page: http://dynamechs.sourceforge.net

[Plib-devel] Re: Ancient history....depth buffer queries

[Scott M. <mcm...@ca...>]

I apologize profusely...my previous email should have gone
to Steve directly.  However, I will take input from anyone
on this list, especially if they know whether or not the
equations in question are specific to SGIs only or if they
apply to all OpenGL implementations.

Thanks and sorry again,
scott

--
Scott McMillan
mailto:mcm...@ca...

SGL Home Page:       http://sgl.sourceforge.net
DynaMechs Home Page: http://dynamechs.sourceforge.net

Re: [Plib-devel] Ancient history....depth buffer queries

[Steve B. <sjb...@ai...>]

Scott McMillan wrote:

> I was going through some very old info-performer archives...

*VERY* old!

> ...on depth/range calculations and I came across your formula again...

Actually the formula came from SGI - but it seems to be right for
other systems.

> I have a question.  Here's what you wrote (I think...as formatting
> has garbled the equation):
> 
> > This comes up about every 6 months....here is the stock reply...
> >
> >   The 'official' SGI solution to this is...
> >
> >     z = value in z buffer after rendering (input)
> >     range = distance to pixel in database units (output)
> >
> >     np = distance to near clipping plane
> >     fp = distance far clipping plane
> >
> >     nz = near-clip z value
> >     fz = far-clip z value
> >                 (as read from glGetIntegerv ( GL_DEPTH_RANGE,...) for OpenGL)
> >
> >     For each Z-buffer value:
> >
> >                      fp*np(fz-nz)
> >                      ------------
> >                         fp-np
> >     - range = --------------------------
> >                   (fp+np)(fz-nz)   fz+nz
> >               z - -------------- - -----
> >                      2(fp-np)        2
> >
> 
> My questions are:
> 1) has this formatting been restored correctly?

Hmmm - not sure.  I'd have to be at work to answer that one.
I'll have to let you know sometime tomorrow.

> 2) Could you explain the nz/fz equations more clearly...

Sorry - it's not my equation - I just regurgitated it from
a previous email from Micheal Jones - who no longer works
at SGI.

I'll try to dig out some actual code where I used the
equation and email it to you tomorrow.  Are you actually
using Performer or is this really an OpenGL problem?

If it's OpenGL, then I wrote a FAQ about Z buffer values
here:

  http://web2.airmail.net/sjbaker1/omniv.html

...that has the inverse equation (for OpenGL - not Performer).

-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjb...@ai... (home)  http://www.woodsoup.org/~sbaker
sj...@ht...      (work)

Re: [Plib-devel] Ancient history....depth buffer queries

[Stephen J B. <sj...@ht...>]

> I have a question.  Here's what you wrote (I think...as formatting
> has garbled the equation):
> 
> > This comes up about every 6 months....here is the stock reply...
> >
> >   The 'official' SGI solution to this is...
> >
> >     z = value in z buffer after rendering (input)
> >     range = distance to pixel in database units (output)
> >
> >     np = distance to near clipping plane
> >     fp = distance far clipping plane
> >
> >     nz = near-clip z value
> >     fz = far-clip z value
> >                 (as read from glGetIntegerv ( GL_DEPTH_RANGE,...) for OpenGL)
> >
> >     For each Z-buffer value:
> >
> >                      fp*np(fz-nz)
> >                      ------------
> >                         fp-np
> >     - range = --------------------------
> >                   (fp+np)(fz-nz)   fz+nz
> >               z - -------------- - -----
> >                      2(fp-np)        2
> >
> 
> My questions are:
> 1) has this formatting been restored correctly?
 
Yes. That's correct.

> > 2) Could you explain the nz/fz equations more clearly...
 
Here is what I use in an actual Performer application:

--------------------------- CUT HERE ---------------------------
/*
  This routine calculates the terms:
 
              fp*np(fz-nz)
     z_top =  ------------
                 fp-np

  and
              (fp+np)(fz-nz)   fz+nz
     z_bot =  -------------- + -----
                 2(fp-np)        2
 
  So the actual per-pixel z-to-range math can be boiled down to:  z_top / ( z - z_bot )
*/


void read_z ( pfChannel *chan )
{
  float z_top ;
  float z_bot ;
  float np, fp ;
  float nz, fz ;
  int width  = ...whatever... ;
  int height = ...whatever... ;
  int top, bot, left, right = ...whatever... ;
  unsigned long z_result [ height * width ] ;
  float result [ height * width ] ;
  GLint z_vals[ 2 ] ;
 
  /* Set up the math... */

  pfGetChanNearFar ( chan, & np, & fp );
  glGetIntegerv    ( GL_DEPTH_RANGE, z_vals ) ;

  nz = (float) z_vals [ 0 ] ;
  fz = (float) z_vals [ 1 ] ;

  z_top = -fp*np *(fz-nz) /  (fp-np) ;
  z_bot = (fp+np)*(fz-nz) / ((fp-np) * 2.0 ) + (fz+nz) / 2.0 ;

  /* Read the Z buffer... */

  glReadBuffer ( GL_BACK ) ;
  glReadPixels ( left, bot, right-left+1, top-bot+1,
                 GL_DEPTH_COMPONENT, GL_INT, z_result ) ;

  /* Convert to real-world units... */

  for ( ...each Z value to convert... )
    result[...whatever...] = z_top / ( (float) z_result[...whatever...] - z_bot ) ;
}
---------------------- CUT HERE ------------------------------


Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sj...@ht...            http://www.hti.com
Home: sjb...@ai...       http://web2.airmail.net/sjbaker1

Re: [Plib-devel] Ancient history....depth buffer queries

[Scott M. <mcm...@ca...>]

In answer to a previous question: This is an OpenGL question and
not a Performer one.

I have been having problems with the approach below on one piece
(so far) of NT/PC hardware:

   the AccelGalaxy card and/or its OpenGL driver.

The culprit is the following piece of code that I am not sure is valid
OpenGL code:

   glGetIntegerv( GL_DEPTH_RANGE, z_vals ) ;

The OpenGL 1.1 manual says to use glGetFloatv for this enum, and
AccelGalaxy drive truncates the floating point values to ints and
reports 0 and 1 for near far (where as an SGI O2 would report 0 and
something close to MAX_INT).

The way I did get this to work is to sample the depth buffer as
GL_FLOAT (instead of int) and use the results of 

   glGetFloatv(GL_DEPTH_RANGE, z_vals);

I still need to do timing to see if sampling the depth buffer as
GL_FLOATs incurs an extreme penalty (not sure I have much choice
though as I need not only a cross platform solution but a cross
OpenGL driver solution).

scott


Stephen J Baker wrote:
> 
> > I have a question.  Here's what you wrote (I think...as formatting
> > has garbled the equation):
> >
> > > This comes up about every 6 months....here is the stock reply...
> > >
> > >   The 'official' SGI solution to this is...
> > >
> > >     z = value in z buffer after rendering (input)
> > >     range = distance to pixel in database units (output)
> > >
> > >     np = distance to near clipping plane
> > >     fp = distance far clipping plane
> > >
> > >     nz = near-clip z value
> > >     fz = far-clip z value
> > >                 (as read from glGetIntegerv ( GL_DEPTH_RANGE,...) for OpenGL)
> > >
> > >     For each Z-buffer value:
> > >
> > >                      fp*np(fz-nz)
> > >                      ------------
> > >                         fp-np
> > >     - range = --------------------------
> > >                   (fp+np)(fz-nz)   fz+nz
> > >               z - -------------- - -----
> > >                      2(fp-np)        2
> > >
> >
> > My questions are:
> > 1) has this formatting been restored correctly?
> 
> Yes. That's correct.
> 
> > > 2) Could you explain the nz/fz equations more clearly...
> 
> Here is what I use in an actual Performer application:
> 
> --------------------------- CUT HERE ---------------------------
> /*
>   This routine calculates the terms:
> 
>               fp*np(fz-nz)
>      z_top =  ------------
>                  fp-np
> 
>   and
>               (fp+np)(fz-nz)   fz+nz
>      z_bot =  -------------- + -----
>                  2(fp-np)        2
> 
>   So the actual per-pixel z-to-range math can be boiled down to:  z_top / ( z - z_bot )
> */
> 
> void read_z ( pfChannel *chan )
> {
>   float z_top ;
>   float z_bot ;
>   float np, fp ;
>   float nz, fz ;
>   int width  = ...whatever... ;
>   int height = ...whatever... ;
>   int top, bot, left, right = ...whatever... ;
>   unsigned long z_result [ height * width ] ;
>   float result [ height * width ] ;
>   GLint z_vals[ 2 ] ;
> 
>   /* Set up the math... */
> 
>   pfGetChanNearFar ( chan, & np, & fp );
>   glGetIntegerv    ( GL_DEPTH_RANGE, z_vals ) ;
> 
>   nz = (float) z_vals [ 0 ] ;
>   fz = (float) z_vals [ 1 ] ;
> 
>   z_top = -fp*np *(fz-nz) /  (fp-np) ;
>   z_bot = (fp+np)*(fz-nz) / ((fp-np) * 2.0 ) + (fz+nz) / 2.0 ;
> 
>   /* Read the Z buffer... */
> 
>   glReadBuffer ( GL_BACK ) ;
>   glReadPixels ( left, bot, right-left+1, top-bot+1,
>                  GL_DEPTH_COMPONENT, GL_INT, z_result ) ;
> 
>   /* Convert to real-world units... */
> 
>   for ( ...each Z value to convert... )
>     result[...whatever...] = z_top / ( (float) z_result[...whatever...] - z_bot ) ;
> }
> ---------------------- CUT HERE ------------------------------
> 
> Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
> L3Com/Link Simulation & Training (817)619-2466 (Fax)
> Work: sj...@ht...            http://www.hti.com
> Home: sjb...@ai...       http://web2.airmail.net/sjbaker1
> 
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> http://lists.sourceforge.net/mailman/listinfo/plib-devel

-- 
Scott McMillan                        mailto:mcm...@ca...
Cambridge Research Associates         http://www.cambridge.com
1430 Spring Hill Road, Ste. 200       Voice: (703) 790-0505 x7235
McLean, VA 22102                      Fax:   (703) 790-0370

Re: [Plib-devel] Ancient history....depth buffer queries

[Steve B. <sjb...@ai...>]

Scott McMillan wrote:

> In answer to a previous question: This is an OpenGL question and
> not a Performer one.

OK - I gave the Performer answer because you mentioned that you'd
seen something of mine on the Performer mailing list...and also because
I can't think of any occasion where I've actually done this in raw
OpenGL.
 
> I have been having problems with the approach below on one piece
> (so far) of NT/PC hardware:
> 
>    the AccelGalaxy card and/or its OpenGL driver.
> 
> The culprit is the following piece of code that I am not sure is valid
> OpenGL code:
> 
>    glGetIntegerv( GL_DEPTH_RANGE, z_vals ) ;

Yes - I have to say that this *looks* like it should be glGetFloatv,

> The OpenGL 1.1 manual says to use glGetFloatv for this enum...

No - it doesn't.  The OpenGL 1.1 'Blue Book' says:

  "Type conversion is performed if params has a different type
   than the state variable value being requested."

However, it notes that:

  "If glGetIntegerv is called...most floating-point values are
   rounded to the nearest integer value."

*most*?!?  Well, it goes on to explain that colours and normals
are exceptions.

However, a bit later on:

  "GL_DEPTH_RANGE  params returns two values: the near and far mapping
   limits for the depth buffer.  Integer values, if requested, are
   linearly mapped from the internal floating-point representations
   such that 1.0 returns the most positive representable integer
   value and -1.0 returns the most negative representable integer
   value.  The initial vlaue is (0,1)."

...so, glGetFloatv should return (0,1) and glGetIntegerv should
return (0,2147483647)

> ..., and
> AccelGalaxy drive truncates the floating point values to ints and
> reports 0 and 1 for near far (where as an SGI O2 would report 0 and
> something close to MAX_INT).

Exactly.  So the AccelGalaxy OpenGL is buggy - presumably because someone
didn't read the fine print about this peculiar exception to the glGetInteger
rules.

> The way I did get this to work is to sample the depth buffer as
> GL_FLOAT (instead of int) and use the results of
> 
>    glGetFloatv(GL_DEPTH_RANGE, z_vals);

...but you need to multiply the results by MAX_INT before you plug them
into my equation.
 
> I still need to do timing to see if sampling the depth buffer as
> GL_FLOATs incurs an extreme penalty (not sure I have much choice
> though as I need not only a cross platform solution but a cross
> OpenGL driver solution).

Well, reading back the Z buffer is always expensive - it's just
a matter of degree!

-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjb...@ai... (home)  http://www.woodsoup.org/~sbaker
sj...@ht...      (work)

Re: [Plib-devel] Ancient history....depth buffer queries

[Scott M. <mcm...@ca...>]

Steve Baker wrote:
> 
> Scott McMillan wrote:
> 
> > The OpenGL 1.1 manual says to use glGetFloatv for this enum...
> 
> No - it doesn't.  The OpenGL 1.1 'Blue Book' says:
> 
>   "Type conversion is performed if params has a different type
>    than the state variable value being requested."

Actually I meant to say "the 1.1 Red book implies...."

 
> However, it notes that:
> 
>   "If glGetIntegerv is called...most floating-point values are
>    rounded to the nearest integer value."
> 
> *most*?!?  Well, it goes on to explain that colours and normals
> are exceptions.
> 
> However, a bit later on:
> 
>   "GL_DEPTH_RANGE  params returns two values: the near and far mapping
>    limits for the depth buffer.  Integer values, if requested, are
>    linearly mapped from the internal floating-point representations
>    such that 1.0 returns the most positive representable integer
>    value and -1.0 returns the most negative representable integer
>    value.  The initial vlaue is (0,1)."
> 
> ...so, glGetFloatv should return (0,1) and glGetIntegerv should
> return (0,2147483647)

If I only had a blue book.....However on the 02 I don't get what
you state above.  I get something slightly different:

   (0,2147482496)  - not MAX_INT

> > The way I did get this to work is to sample the depth buffer as
> > GL_FLOAT (instead of int) and use the results of
> >
> >    glGetFloatv(GL_DEPTH_RANGE, z_vals);
> 
> ...but you need to multiply the results by MAX_INT before you plug them
> into my equation.

Actually no...after some brief units cancellation analysis, I think I
should do everything with floats as reported from GL_DEPTH_RANGE and
glReadPixels and get what appears to be a proper range value (within
the accuracy of the depth buffer, of course).  No multiplication by
MAX_INT is necessary.  Here is my code:

        GLfloat depthRange[2];
        glGetFloatv(GL_DEPTH_RANGE, depthRange);

        GLfloat *depthData = (GLfloat *) malloc(sizeX*sizeY*sizeof(GLfloat));
        glReadBuffer(GL_BACK);
        glReadPixels(0, 0, sizeX, sizeY,
                     GL_DEPTH_COMPONENT, GL_FLOAT, depthData);

        for (a given index into the depthData array)
        {
                float dz = depthRange[1] - depthRange[0];
                float dp = farClip - nearClip;

                float range =
                    -((farClip*nearClip*dz)/dp)/
                    (depthData[index] - ((farClip + nearClip)*dz)/(2.0*dp) -
                     (depthRange[1] + depthRange[0])/2.0);
        }

If I am misunderstanding your last statement please clarify with
some math.

> > I still need to do timing to see if sampling the depth buffer as
> > GL_FLOATs incurs an extreme penalty (not sure I have much choice
> > though as I need not only a cross platform solution but a cross
> > OpenGL driver solution).
> 
> Well, reading back the Z buffer is always expensive - it's just
> a matter of degree!

When they want a depth buffer image, you don't have too many
choices.  I was wondering if there was an extra penatly incurred
by reading floats instead of ints.  I am not really sure where
to go to read up on technical aspects of the depth buffer and
read backs.

scott

P.S. should we take this discussion off-line...it is straying a
bit from PLIB development?

-- 
Scott McMillan                        mailto:mcm...@ca...
Cambridge Research Associates         http://www.cambridge.com
1430 Spring Hill Road, Ste. 200       Voice: (703) 790-0505 x7235
McLean, VA 22102                      Fax:   (703) 790-0370

Re: [Plib-devel] Ancient history....depth buffer queries

[Steve B. <sjb...@ai...>]

Scott McMillan wrote:

> If I only had a blue book.....

If you have an O2, you don't need the Blue Book - the SGI 'man' pages
are the exact same thing as the corresponding Blue Book entries.

> However on the 02 I don't get what
> you state above.  I get something slightly different:
> 
>    (0,2147482496)  - not MAX_INT

Yep - there is a reason for that.  It's because of the way glPolygonOffset
works - they need a little extra depth range beyond far-Z to allow for
glPolygonOffset and accumulated roundoff error in iterating Z across
a polygon.

They made a mistake about that on the old VGXT machines and it could
cause *MAJOR* hassles.  The slightly curtailed depth range is a kludge
to get around that....I *think*...  :-)

> If I am misunderstanding your last statement please clarify with
> some math.

...if you understand what's going on - you are one step ahead of
me!   I just regurgitate that equation on demand.
 
> When they want a depth buffer image, you don't have too many
> choices.  I was wondering if there was an extra penatly incurred
> by reading floats instead of ints.  I am not really sure where
> to go to read up on technical aspects of the depth buffer and
> read backs.

Well, you can be sure the hardware is 'int' deep down inside -
so it'll certainly take some extra math to convert it to float...
but then you'd have to convert it to float anyway - so you might
as well let OpenGL do it - just on the offchance that you might
one day find a machine with a floating point Z buffer and save
yourself a ton of time.

I think the conversion time will be small compared to the readout
time.

> P.S. should we take this discussion off-line...it is straying a
> bit from PLIB development?

Maybe...This list isn't exactly overrun with techy stuff recently.
I don't think we'll get too many complaints - and there is an
off-chance that someone out there will *know* what they are
talking about!

-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjb...@ai... (home)  http://www.woodsoup.org/~sbaker
sj...@ht...      (work)

Re: [Plib-devel] Ancient history....depth buffer queries

[Scott M. <mcm...@ca...>]

All:

Just a followup on the discussion below.  I have been able to
test this under NT for a few more OpenGL boards out there.
This seems to be a more pervasive error than I would have
guessed (SGI given for reference):

board                     glGetIntegerv(GL_DEPTH_RANGE,...);
--------------------      --------------------------------------
SGI O2 IRIX 6.5.7         0,2147482496
SGI iR IRIX 6.5.5         0,2147483647  (MAX_INT)

nVidia TNT2               0,2147482496
HP - FX6+                 0,2147483647  (MAX_INT)
AccelGalaxy(NT)           0,1           (incorrect)
Intergraph Wildcat 4000   0,1           (incorrect)
Diamond FireGL            0,1           (incorrect)



Steve Baker wrote:
> 
> Scott McMillan wrote:
> 
> > I have been having problems with the approach below on one piece
> > (so far) of NT/PC hardware:
> >
> >    the AccelGalaxy card and/or its OpenGL driver.
> >
> > The culprit is the following piece of code that I am not sure is valid
> > OpenGL code:
> >
> >    glGetIntegerv( GL_DEPTH_RANGE, z_vals ) ;
> 
> Yes - I have to say that this *looks* like it should be glGetFloatv,
> 
> > The OpenGL 1.1 manual says to use glGetFloatv for this enum...
> 
> No - it doesn't.  The OpenGL 1.1 'Blue Book' says:
> 
>   "Type conversion is performed if params has a different type
>    than the state variable value being requested."
> 
> However, it notes that:
> 
>   "If glGetIntegerv is called...most floating-point values are
>    rounded to the nearest integer value."
> 
> *most*?!?  Well, it goes on to explain that colours and normals
> are exceptions.
> 
> However, a bit later on:
> 
>   "GL_DEPTH_RANGE  params returns two values: the near and far mapping
>    limits for the depth buffer.  Integer values, if requested, are
>    linearly mapped from the internal floating-point representations
>    such that 1.0 returns the most positive representable integer
>    value and -1.0 returns the most negative representable integer
>    value.  The initial vlaue is (0,1)."
> 
> ...so, glGetFloatv should return (0,1) and glGetIntegerv should
> return (0,2147483647)
> 
> > ..., and
> > AccelGalaxy drive truncates the floating point values to ints and
> > reports 0 and 1 for near far (where as an SGI O2 would report 0 and
> > something close to MAX_INT).
> 
> Exactly.  So the AccelGalaxy OpenGL is buggy - presumably because someone
> didn't read the fine print about this peculiar exception to the glGetInteger
> rules.

-- 
Scott McMillan                        mailto:mcm...@ca...
Cambridge Research Associates         http://www.cambridge.com
1430 Spring Hill Road, Ste. 200       Voice: (703) 790-0505 x7235
McLean, VA 22102                      Fax:   (703) 790-0370

Re: [Plib-devel] Ancient history....depth buffer queries

[Steve B. <sjb...@ai...>]

Scott McMillan wrote:
> 
> All:
> 
> Just a followup on the discussion below.  I have been able to
> test this under NT for a few more OpenGL boards out there.
> This seems to be a more pervasive error than I would have
> guessed (SGI given for reference):
> 
> board                     glGetIntegerv(GL_DEPTH_RANGE,...);
> --------------------      --------------------------------------
> SGI O2 IRIX 6.5.7         0,2147482496
> SGI iR IRIX 6.5.5         0,2147483647  (MAX_INT)
> 
> nVidia TNT2               0,2147482496
> HP - FX6+                 0,2147483647  (MAX_INT)
> AccelGalaxy(NT)           0,1           (incorrect)
> Intergraph Wildcat 4000   0,1           (incorrect)
> Diamond FireGL            0,1           (incorrect)

Yikes!

Well, it's kinda comforting that the 'big name' companies
like SGI, nVidia and HP are getting it right.

So, You should certainly report this to the offenders
(that's the only way things get better) - and switch
to the glGetFloatv version.

-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjb...@ai... (home)  http://www.woodsoup.org/~sbaker
sj...@ht...      (work)