Seems like the OpenGL UBO implementation doesn't work as advertised, or I'm doing something wrong here.
Using Catalyst 12.6 on a 7850
OpenGL Hardware Device Context
* Vendor: ATI Technologies Inc.
* Renderer: AMD Radeon HD 7800 Series
* Version: 4.2.11733 Compatibility Profile Context
* GLSL Version: 4.20
The code in question is here:
uint_t block_index = glGetUniformBlockIndex(m_id, "minstanceparams");
if (GL_INVALID_INDEX != block_index)
int_t block_size = 0;
glGetActiveUniformBlockiv(m_id, block_index, GL_UNIFORM_BLOCK_DATA_SIZE, &block_size);
const int kMaxInstances = 256;
layout( std140 ) uniform minstanceparams
The size of the UBO should be 256 * sizeof(mat4) * 3 = 49152. This gets correctly reported on my other workstation which has a Nvidia card.
On my 7850 I'm getting -16384. Upon testing and reducing the number of instances to kMaxInstances = 128, I'm getting the correct size. An interesting fact is that when I tried different values for kMaxInstances (e.g. 192) I've gotten different results in block_size.
My questions are:
a) The spec says ( I believe, at least I've read this a few times while doing research) you should have at least 64 KB for UBO available, but that doesn't seem to be the case here (seems to be limited more to 32 KB)
b) The spec says that if an error occurs nothing gets written to block_size. That definitely doesn't happen here.
c) Lastly, am I'm missing anything in my setup, or the way I'm trying to use the UBOs isn't advised?
Thanks for your time
This looks like a sign extension error. 49152 decimal as unsigned short = 1100000000000000 binary. -16386 as signed short also = 1100000000000000 binary. It seems like somewhere (most likely in the driver) we are sign extending an unsigned short quantity to an integer. I'll get it checked out. As a workaround, if you see a negative number, try subtracting it from 65536 to get the right answer. The good news is that it looks like we are correctly calculating the size even if we are reporting incorrectly, and the shader should work in spite of the erroneous information given by the query.
I'll get an update back on this thread when I have more information.
Thanks for the quick response. I got it to work with the workaround provided with a slight change (add 64*1024 to the negative value). What is the driver's behavior if you exceed the maximum size (is there any?) of the UBO in respect of reported size, shader compilation/linking, and what is the current maximum size supported by the driver?