OpenGL Discussion and Help Forums - OpenGL drivers

Quality of Implementation: Debug shader variable locations

Alfonse Reinheart — Fri, 17 May 2013 02:34:04 GMT

Now that OpenGL's debug context concept is a bit more well-defined (thanks to language in KHR_debug and the like), let's expand on this. NVIDIA already starts spamming stdout when you're in debug, so let's close another source of errors:

Accidentally using the correct variable locations.

Unless you explicit assign a variable location in OpenGL, you must query its location to know where it is. However, most implementations will assign locations sequentially, starting from 0. Which means that code can be written which accidentally does the right thing.

I would suggest that, upon every shader compilation (in debug only), generating a random number and starting the location assignments from there. This will help show where a program is accidentally forgetting an explicit assignment or a query.

Catalyst 13.1 Legacy: possible ubo/struct bug

yousry — Thu, 09 May 2013 16:47:01 GMT

Could not post this bug on devgurus so I try it here:

Code :

Create a struct:
struct Something {
...
    float a;
    float b;
    float c;
};

Create an uniform block:

Code :

uniform wonderful {        
    mat4 has;
     mat4 heppend;
    Something dontPanik;
};

try to query the offsets with:

Code :

glGetActiveUniformsiv(programId, uboSIze, uNames, GL_UNIFORM_OFFSET, ubOffsets);

All floats are assigned to the same offset.

If the struct is alterated:

Code :

Create an struct:
struct SomethingElse {
...
    float a;
    vec3 cute;
    float b;
    vec3 little;
    float c;
    vec3 problems;
 
};

The floats are accessible.

AMD catalyst: set GL_UNPACK_ROW_LENGTH will lead to corrupted texture

jianliang79 — Tue, 07 May 2013 03:09:37 GMT

It seems that there is a bug in Catalyst driver, when I set GL_UNPACK_ROW_LENGTH to a value other than zero, under some specific image width, the texture copied from PBO will be corrupted. I have an AMD radeon HD 7770 card and use Catalyst 13.1 driver in Windows 7 x64. I have uploaded a sample program in http://devgurus.amd.com/servlet/Jive...estPBO.rar.zip, the sample project can reproduce this issue. Please build it with VS 2010 in 64 bit mode, run the program and two bmp files named "correct.bmp" and "bad.bmp" will be generated, you can see the corrupted image in bad.bmp

AMD Catalyst 13.4 - GL_ARB_multi_draw_indirect BUG

YarUnderoaker — Fri, 03 May 2013 17:31:09 GMT

I noticed the MultiDrawElementsIndirect ignores baseInstance in commands. It always has zero value.
Dear AMD's residents, please fix it. This feature is very useful.

Poser and the Firepro V3900 graphics card

ElZagna — Thu, 02 May 2013 16:50:41 GMT

I hope this is the right place to ask. These issues are way outside my knowledge base.

I recently purchased a FirePro V3900 card specifically to use with Poser. My previous card worked fine but got fried.

I am finding that with this card the Preview window frequently hangs when in OpenGL mode. Sometimes when I try to move the camera nothing happens, but sometimes part of the window responds to the camera movement and part doesn't. After much experimentation I have figured out how to replicate the problem:

1. Place a second window (e.g Library window) over the Preview window.
2. Move the second window just a bit.
3. Rotate the camera. Once you move the second window out of the way you can see that the part of the Preview window behind the second window had moved as it should, but the visible part had not.

I have updated the drivers several times and have cleaned out the registry of any orphaned driver settings.

I have posted this issue to the technical support staffs at both AMD and Smith Micro (Poser), but they seemed to be stumped. I am hoping you folks might have some ideas.

My OS is Windows Vista Business 32-bit Service Pack 2. The device driver for the card is version 8.982.8.3000 released on 9/30/2012. I've also tried this with version 9.3.3.3000 released 2/6/2013 with the same results.

Bugs in 13.4 GL 4.3 exts:compute shader, SBOs and no_attachments

oscarbg — Mon, 29 Apr 2013 12:43:48 GMT

Hi,
I have been testing new OGL compute shader and storage buffer objects extension and found following bugs (13.4 on 7950):
(please note all the samples I use for testing this work correctly on Nvidia OGL 4.3 cards)
*using atomicMax and atomicMin on shared variables hang the GLSL compiler others like atomicOr are OK!

groupshared uint ldsZMax;
uint z;
atomicMax( ldsZMax, z );

*using a compute shader with following launch size and shared arrays usage:
#define BLOCK_SIZE 32
layout (local_size_x = BLOCK_SIZE, local_size_y = BLOCK_SIZE) in;
shared double As[BLOCK_SIZE*BLOCK_SIZE];
shared double Bs[BLOCK_SIZE*BLOCK_SIZE];
crashes with:
Compute shader(s) failed to link.
Compute link error: HW_UNSUPPORTED.
Compute shader not supported by hardware

diminishing BLOCK_SIZE to less than 32 seems to work.. I have tested using
layout (local_size_x = 32, local_size_y = 32) in;
isn't a issue so 32 should work as for this conf each of this two shared arrays is size 8192 (sizeof(double)*32*32) so total shared mem usage is 2*8192 and is equal to reported max

size (GL_MAX_COMPUTE_SHARED_MEMORY_SIZE: 32768).. I verify this issue is on shared mem size usage as using something like
(with BLOCK_SIZE=32):
shared double As[BLOCK_SIZE*BLOCK_SIZE-1];
shared double Bs[BLOCK_SIZE*BLOCK_SIZE];
seems to compile so please fix to be able to use not only 32767 bytes of shared mem but full 32768 bytes..

*using sbo on non compute shaders (like fragment shaders seems no be not correct)
*getting GL_MAX_COMPUTE_WORK_GROUP_COUNT and GL_MAX_COMPUTE_WORK_GROUP_SIZE I get using debug_output bug:
glGetIntegerv parameter has an invalid enum '0x91be' (GL_INVALID_ENUM)
other new like GL_MAX_COMPUTE_ATOMIC_COUNTERS seem to work..

Related altough no_attachments extension is not adversited new entry points are present so I played with it using default and seems a simple test works on 79xx but not on 58xx

series..
glGenFramebuffers(1,&noat);
glBindFramebuffer(GL_FRAMEBUFFER_EXT,noat);
glFramebufferParameteri(GL_FRAMEBUFFER_EXT,GL_FRAM EBUFFER_DEFAULT_WIDTH, w);
glFramebufferParameteri (GL_FRAMEBUFFER_EXT,GL_FRAMEBUFFER_DEFAULT_HEIGHT, h);
a sample using this works on 7xxx series but not on 5xxx series..

Trouble with OpenGL version

YurySerdyuk — Mon, 22 Apr 2013 18:56:29 GMT

Hi !

I have machine under CentOS 5.6 with Nvidia Tesla C1060 GPU:

>01:00.0 3D controller [0302]: nVidia Corporation GT200 [Tesla C1060] [10de:05e7] (rev a1)
> Subsystem: nVidia Corporation Device [10de:066a]
> Kernel driver in use: nvidia
> Kernel modules: nvidiafb, nvidia

I have installed 310.32 driver for Tesla:

> Installing 'NVIDIA Accelerated Graphics Driver for Linux-x86_64' (310.32):

I expect, at least, 2.1 version of OpenGL for this machine, but glxinfo gives me:

OpenGL vendor string: Mesa Project
OpenGL renderer string: Software Rasterizer
OpenGL version string: 1.4 (2.1 Mesa 7.11-devel)

What is wrong in my installation?

In particular, I have another similar machine without GPU Tesla and only
with ATI controller:

0a:01.0 VGA compatible controller: ATI Technologies Inc ES1000 (rev 02)

And the OpenGL version is the same on it:

OpenGL vendor string: Mesa Project
OpenGL renderer string: Software Rasterizer
OpenGL version string: 1.4 (2.1 Mesa 7.11-devel)

How to provide OpenGL version >= 2.0 on the first machine?

Thanks.

AMD Catalyst 13.3 Beta Linux - Interface Block Redeclaration - GLSL Bugs

thokra — Mon, 22 Apr 2013 15:37:15 GMT

Ahoi. Reading this thread triggered my curiosity once again. So I tried my luck with redeclaration of built-in interface blocks and, if I haven't fallen victim to my own incredible stupidity here, the GLSL compiler seems to violate a multitude of compilation/linkage rules from the spec (all quotes from the GLSL 4.30 Spec):

Quote:

The gl_PerVertex block can be redeclared in a shader to explicitly indicate what subset of the fixed pipeline interface will be used. This is necessary to establish the interface between multiple programs. [..] It must be a subset of the built-in members of gl_PerVertex.

First of all, the wording is awful. The words can and necessary don't go well together. They can be redeclared when using non-separable programs, they are necessary, however, when using a program pipeline. Maybe a spec bug - maybe a driver. At least the driver seems to be sure that can isn't the right wording. Anyway, using the following shaders separably works just fine, even though as per the GLSL spec it shouldn't:

Code :

// vertex shader
#version 420
layout(location = 0) in vec4 position;
 
out gl_PerVertex
{
    vec4 gl_Position;
    vec2 wtf_AMD;
};
 
void main()
{
    gl_Position = position;
    wtf_AMD    = position.xy;
}
 
// geometry shader
#version 420
 
layout(points) in;
layout(points, max_vertices = 1) out;
 
in gl_PerVertex
{
    vec4 gl_Position;
    vec2 wtf_AMD;
} gl_in[];
 
out gl_PerVertex
{
    vec4  gl_Position;
    float  gl_PointSize;
};
 
void main()
{
    gl_PointSize = 5.f;
    gl_Position  = gl_in[0].gl_Position + vec4(gl_in[0].wtf_AMD, 0.0, 0.0);
 
    EmitVertex  ();
    EndPrimitive();
}

No complaints whatsoever - not even when insulting the compiler with a nasty "WTF". Clearly, the vec2 is not a built-in member of gl_PerVertex and therefore does not belong to aforementioned subset.

Quote:

If a built-in interface block is redeclared, it must appear in the shader before any use of any member included in the built-in declaration, or a compile-time error will result.

Unless my interpretation is wrong, this simply means, the block needs to appear before any use of any of its members. However, this compiles and works:

Code :

#version 420
in vec4 position;
 
void main()
{
    gl_Position = position;
    amd_WTF  = position.xy;
}
 
out gl_PerVertex
{
    vec4  gl_Position;
    vec2  amd_WTF;
};

This seems to violate the spec on two counts... As I understand it, I should not be able to use a member of a redeclared interface prior to its redeclaration and I assumed this goes for gl_Position as well. However, the compiler will only complain about the vec2 not being declared at that point.

Now, what happens if we do all this with an old-school, linked program? The following will compile fine even though it clearly violates the rules of interface matching (which don't only apply to separable programs):

Quote:

Matched block names within an interface (as defined above) must match in terms of having the same number of declarations with the same sequence of types and the same sequence of member names, as well as having the same member-wise layout qualification (see next section).[..] Any mismatch will generate a link-time error.

Consider the following clearly mismatching interfaces:

Code :

// vertex shader
out gl_PerVertex
{
    vec4 gl_Position;
    float wtf_AMD_float;
    vec2 wtf_AMD;
    float wtf_Padding;
};
 
// geometry shader
in gl_PerVertex
{
    vec4 gl_Position;
    vec2 wtf_AMD;
    float wtf_AMD_float;
} gl_in[];

The only thing that matches is the number of declarations. Neither the type sequence nor the sequence of names match. Two violations. Does the linker complain is it should? No. Actually it compiles, links and runs but generates no primitives - at least not until wtf_AMD_float is actually used:

Code :

// write position in the GS
gl_Position  = gl_in[0].gl_Position + vec4(gl_in[0].wtf_AMD * gl_in[0].wtf_AMD_float, 0.0, 0.0);

This will link and run just as fine but, oh wonder, generate incorrect output primitives for which actual fragments are rasterized which can addtionally be controlled by adjusting the point size... It shouldn't even link - and seriously, if for linked programs it also applies that the redeclared members must be a subset of the built-in members of gl_PerVertex, it should even compile IMHO. Too bad the spec doesn't explicitly state that the latter actually should occur.

Please, someone tell me that I'm making some horrible mistakes above. Otherwise, the whole redeclaration thing seems broken as ****.

EDIT: Just some of it with 13.1 again. The first example simply flickers, i.e. sometimes it generates primtives and sometimes it doesn't but the compiler/linker still don't complain. The last example, ironically, generates the correct primitives. Obviously, 13.3 has regressed from incorrect to even more incorrect behavior.