glUniformMatrix4dv doesn't work?

Hi all,
  I used glUniformMatrix4dv() to set the values in a uniform mat4 in my vertex shader.  It kept generating "GL_INVALID_OPERATION".  I finally thought to try converting the double[] containing the 16 matrix values (which did contain the values I wanted) to a float[], and calling glUniformMatrix4fv() instead.  It immediately started working correctly.
Is this a bug in JOGL, a bug in my driver (I did try it on two machines with substantially different cards, though both were nVidia), or something I'm overlooking in the spec somewhere?

Thanks.

On 09/14/2012 12:49 AM, clevengr [via jogamp] wrote:
> Hi all,
>   I used glUniformMatrix4dv() to set the values in a uniform mat4 in my vertex
> shader.  It kept generating "GL_INVALID_OPERATION".  I finally thought to try
> converting the double[] containing the 16 matrix values (which did contain the
> values I wanted) to a float[], and calling glUniformMatrix4fv() instead.  It
> immediately started working correctly.
> Is this a bug in JOGL, a bug in my driver (I did try it on two machines with
> substantially different cards, though both were nVidia), or something I'm
> overlooking in the spec somewhere?

GL3 should provide this method, so I assume you properly setup a context
w/ >= GLProfile.GL3 or >= GLProfile.GL3bc - and not just casting :)

Then, all double precision (64bit floats)
are only supported by the extension 'GL_ARB_gpu_shader_fp64' (depends on GL 3.2).
<http://www.opengl.org/registry/specs/ARB/gpu_shader_fp64.txt>

Hence your code using >= GL3 shall contain:

  if( gl.isExtensionAvailable("GL_ARB_gpu_shader_fp64") ) {
     // use fp64 -> double
  } else {
     // use fp32 -> float
  }

Given the above yes - sure it should work.
Pls provide a unit test if it fails.

~Sven

>
> Thanks.

Aha -- that's what I was missing: that extension is not available on either of my platforms, and I failed to test for that first.
Thanks for the quick reply.

A followup question:  is there any concise way to figure out what methods in, say, a GL3 are always available and which methods require an extension?  The reason I didn't test for the shader_fp64 extension was that I didn't realize glUniformMatrix4dv() required that extension.  I suppose it makes sense in this case, but since the program compiled with a reference to that method I overlooked the possibility that an extension was required to use it.  How would I have known that (in general) without being intimately familiar with all the approved extensions and with what GL3 methods require them?  (Maybe the answer is that I need to have that familiarity, but on the other hand not everyone has the same level of expert familiarity with the entire spec; I'm wondering if there is some obvious way to know that "you can't use method X, even if it compiles, unless you have extension Y"...  like, perhaps, an interface type which is a subset of GL3 that only uses methods that don't require extension? Is there such a thing and I just don't know about it?)

Thanks.

On 09/14/2012 08:50 PM, clevengr [via jogamp] wrote: I guess this extension is the exception to the rule.
Ofc .. the intention is to have validation via the profiles,
nevertheless it's not 100%.

Look at the generated API doc:

  /** Entry point to C language function: <code> void {@native glGetUniformdv}(GLuint program, GLint location, GLdouble *  params); </code> <br>Part of <code>GL_ARB_gpu_shader_fp64</code>   */
  public void glGetUniformdv(int program, int location, double[] params, int params_offset);

GL2 interface for example contains most of all GL2 compatible extensions,
which may not be available on all platforms.
Hence .. still, the developer shall double check (read the API doc and GL spec)
what to use.

Life is easier w/ the GL2ES2 and GL2ES3 interfaces though.

~Sven