Quantcast
Channel: AMD Developer Forums: Message List - OpenGL & Vulkan
Viewing all 631 articles
Browse latest View live
↧

imageAtomicAdd on R16I textures

March 27, 2015, 3:12 am
$
0
0

In my application I use single-channel signed integer texture of the format R16I to store data. Attempting to use imageAtomicAdd() on the image the texture is bound to fails, with debug output as:

 

Compute shader failed to compile with the following errors:

ERROR: 0:23: error(#370) Missing or invalid layout qualifier for image variable

ERROR: error(#273) 1 compilation errors.  No code generated

 

(Apologies, I don't know how to format text as code here).

 

Changing the format in the layout() to r32i or removing the imageAtomicAdd() use results in a successful compilation.

 

As far as I can read in the OpenGL specification, there is no restriction on imageAtomicAdd() (or any other image functions) based on format.

 

Basic test shader:

 

#version 430 core

 

layout(binding = 1, r16i) uniform iimage2D sampleTexture; //fail

//layout(binding =1, r32i) uniform iimage2D sampleTexture; //success

 

void main(void){

ivec2 pix = ivec2(gl_GlobalInvocationID.xy);

  imageAtomicAdd(sampleTexture, pix, 1); //if this is commented out/removed, success

}

↧
Search

Re: imageAtomicAdd on R16I textures

March 27, 2015, 6:28 am
$
0
0

I'll pass on to the OpenGL team.

 

For the "how do I format code..."

 

When you reply, toward the upper right of the Reply box you should see "Use Advanced Editor." Click that.

 

You now have real formatting options, like ability to pick a font.

 

What I would so is copy and paste the code in place, select it, and apply Courier.

 

#version 430 core

 

layout(binding = 1, r16i) uniform iimage2D sampleTexture; //fail

//layout(binding =1, r32i) uniform iimage2D sampleTexture; //success

 

void main(void){

ivec2 pix = ivec2(gl_GlobalInvocationID.xy);

  imageAtomicAdd(sampleTexture, pix, 1); //if this is commented out/removed, success

}

 

(I have to go see if there's any way to create a code "style" and make this happen a bit more easily. Probably not, but what the hey... I can dream)

↧

Re: imageAtomicAdd on R16I textures

March 27, 2015, 11:57 am
$
0
0

peppercat wrote:

 

As far as I can read in the OpenGL specification, there is no restriction on imageAtomicAdd() (or any other image functions) based on format.

 

Referring to the latest GLSL specification, version 4.50, revision 5 (although this language has always existed), section 8.12, bottom of page 175, it says:

 

Atomic memory operations are supported on only a subset of all image variable types; image must be either:

• a signed integer image variable (type starts “iimage”) and a format qualifier of r32i, used with a data argument of type int, or

• an unsigned image variable (type starts “uimage”) and a format qualifier of r32ui, used with a data argument of type uint.

 

Image atomics are only accepted on integer image types with a format qualifier of r32i or r32ui.

 

Cheers,

 

Graham

↧

Re: imageAtomicAdd on R16I textures

March 27, 2015, 3:26 pm
$
0
0

Oh wow, I didn't even think of reading the GLSL spec.

 

Thank you very much for the clarification.

↧

Mantle Headers

March 29, 2015, 5:19 pm
$
0
0

With the release of the seemingly complete Mantle guide, I'm surprised that there are no distributed headers to go along with it.

The purpose of using Mantle at this stage, with Vulkan and D3D12, is to simply familiarize with modern concepts that OpenGL doesn't contain. With Vulkan being quite close to Mantle, I would also imagine very little having to change from one code base to another.

I realized I can hand generate headers based off the guide. Would there be any issues (legal or morally) with this?

Alternatively, is there any chance headers can be released so I don't have to go through much anguish?

↧
↧

Re: GLSL compute shader incompatibilities

March 30, 2015, 2:02 am
$
0
0

About the First, Have you tried without std430? Or to try std140.

If possible, please supply your GLSL shader source.

↧

Re: Re: GLSL compute shader incompatibilities

March 30, 2015, 3:59 am
$
0
0

As I said, I have workarounds. I am able to use the std430 layout in shaders while clearing the buffer with same default for the three (RGB) channels. The function glClearBufferData works without any problem when supplied with parameters GL_R32UI, GL_RED_INTEGER, GL_UNSIGNED_INT. Originally, I wanted to clear the buffer with different default values for each channel.

 

The GLSL code for the second case follows. I also tried with the default value 0 instead of 0xffffffff, but the result was the same.

 

struct entry {    uint key;    uint k;    uint index;
};

layout(std430) buffer Hashes {
    entry hashes[];
};

uint hash(uint value, uint iteration, uint capacity) {
    value = ((value ^ 65521) + 2039) % 65537;    return (value + iteration * iteration) % capacity; // quadratic probing
}

void main() {
   // writeHash is used
}

void writeHash(uint i, uint j, uint k, uint elemIdx) {
    uint key = i * maxCount + j; // compute 1D index of 2D data    bool written = false;    uint iteration = 0;    uint maxIterations = min(maxHashIterations, 3 * maxNumTotalElements);    while (!written && iteration < maxIterations) {        uint index = hash(key, iteration, 3 * maxNumTotalElements);        //uint oldKey = atomicCompSwap(hashes[index].key, INVALID_KEY, key); // NVIDIA follows OpenGL spec        uint oldKey = atomicCompSwap(hashes[index].key, key, INVALID_KEY); // ATI atomicCompSwap BUG        if (oldKey == INVALID_KEY) { // INVALID_KEY == 0xffffffff (default value)            hashes[index].k = k;            hashes[index].index = elemIdx;            written = true;        }        iteration++;    }    if (!written) {        atomicCounterIncrement(hashErrorCount); // count not hashed elements    }
}
↧

Re: Mantle Headers

March 30, 2015, 7:51 am
↧
Search

Re: Mantle Headers

March 30, 2015, 8:18 am
$
0
0

And to answer your specific questions....

 

I realized I can hand generate headers based off the guide. Would there be any issues (legal or morally) with this?

No.

 

Alternatively, is there any chance headers can be released so I don't have to go through much anguish?

No.

 

Hope this helps.

↧
↧

Re: GLSL compute shader incompatibilities

March 30, 2015, 11:58 am
$
0
0

FYI: The engineering team has opened up a defect report internally. In case we ever need to refer back to this, it is #416936.

↧

glDebugMessageCallback AMD ids ( 3rd param ) meaning

April 5, 2015, 8:55 am
$
0
0

Is there some list what the id codes sent to glDebugMessageCallback 3rd param mean ? Couldn't find anything.

In particular, I am getting ids 2003 and 1000 with these messages:

GL_DEBUG:

    source    : GL_DEBUG_SOURCE_API

    type        : GL_DEBUG_TYPE_ERROR

    severity   : GL_DEBUG_SEVERITY_HIGH

    id            : 2003

    message : glDrawElements failed because the currently active shader combination is invalid (GL_INVALID_OPERATION)

 

GL_DEBUG:

    source    : GL_DEBUG_SOURCE_API

    type        : GL_DEBUG_TYPE_ERROR

    severity   : GL_DEBUG_SEVERITY_HIGH

    id            : 1000

    message : glDrawElements has generated an error (GL_INVALID_OPERATION)

↧

Re: glDebugMessageCallback AMD ids ( 3rd param ) meaning

April 6, 2015, 6:12 am
$
0
0

Hi,

 

The ID is driver assigned and is implementation dependent. It's much like compiler warning numbers. You can chose to ignore specific items by ID, sort errors by their IDs and so on, but there is no cross-vendor meaning to the number.

 

Cheers,

 

Graham

↧

Re: Violation access with cl_event from GLsync usage

April 6, 2015, 6:31 am
$
0
0

Does your application create multiple OpenGL contexts? Are you using a toolkit to set up OpenGL or is it your own code?

 

Thanks,

 

Graham

↧
↧

Re: Violation access with cl_event from GLsync usage

April 6, 2015, 3:37 pm
$
0
0

I'm using glfw3 to create the Windows context. Since I create a GL 4.3 context I think it creates a fake context to get a pointer to wglCreateContextAttribsARB.

I use GLEW too.

↧

SAMPLE_ALPHA_TO_ONE shows no effect

April 6, 2015, 5:03 pm
$
0
0

Hello,

 

I ran into this issue on both an old HD4890, as well as on a R9 290, Catalyst 14.12, Win7, so it has been around for some time.

 

Rendering into a multisampled FBO (tried both RGBA8 and RGBA fp16). GL_SAMPLE_ALPHA_TO_COVERAGE is enabled, the fragment shader writes the coverage value to alpha. After resolving the MSAA'ed FBO, the color channels behave as expected (the expected dithered patterns on the parts with fractional coverage values). The alpha channel is problematic. GL_SAMPLE_ALPHA_TO_ONE is enabled, and that should set the destination alpha to 1 regardless of the coverage alpha supplied by the shader. However it looks like this is completely ignored by the driver. The resulting alpha in the FBO is the coverage value, not 1. The same code works as expected on NVidia hardware (resulting alpha is always 1).

 

Is this a known issue ?

 

Thanks,

Alex

↧
Search

Re: GLSL compute shader incompatibilities

April 7, 2015, 12:24 am
$
0
0

The issue of "atomicCompSwap" has been found in the driver. The second and third parameters are disordered. It may be fixed released in some days.

 

I have wrote these code to test glClearBufferData. It seems the buffer is cleared with 0. with no GL_INVALID_VALUE error.

    glGenBuffers(8, bo);

    glBindBufferBase(GL_SHADER_STORAGE_BUFFER, 0, bo[0]);

    glBindBuffer(GL_SHADER_STORAGE_BUFFER, bo[0]);

    glBufferData(GL_SHADER_STORAGE_BUFFER, 32 * 16, &data[0], GL_DYNAMIC_COPY);

    glGetBufferSubData(GL_SHADER_STORAGE_BUFFER, 0, 32 * 16, &data[0]);

    CHECKGL("");

    glClearBufferSubData(GL_SHADER_STORAGE_BUFFER, GL_RGB32UI, 0, 0x100, GL_RGB_INTEGER, GL_UNSIGNED_INT, 0);

    CHECKGL("");

    glGetBufferSubData(GL_SHADER_STORAGE_BUFFER, 0, 32 * 16, &data[0]);

    CHECKGL("");

 

If you still have some problem please attach your application piece also.

↧

Re: glDebugMessageCallback AMD ids ( 3rd param ) meaning

April 7, 2015, 1:19 am
$
0
0

Hi Graham,

 

thanks for your reply, I knew that ( from your book :-) ) already and that is also the reason why I asked here in AMD forum. My GL Context is running on an AMD Kaveri 7800 and I thought those IDs do mean something vendor ( AMD ) specific. So they don't give deeper insights into the error source, other than being sortable and switchable.

 

Cheers, ParticlePeter

↧
↧

Re: Driver 14.12 - Pure virtual function call error causes application crash at start

April 8, 2015, 2:34 pm
$
0
0

I bought Leadwerks today and sucks to know this is still a thing. I hope AMD fixes it soon.

↧

Re: When is the next driver going to be released?

April 8, 2015, 2:37 pm
$
0
0

Do you have any news regarding this? I wonder if it's better for me to wait one or two weeks or downgrade to 14.9.

 

Thanks!

↧

Re: Driver 14.12 - Pure virtual function call error causes application crash at start

April 8, 2015, 2:59 pm
↧
Viewing all 631 articles
Browse latest View live
More Pages to Explore .....
Search