Недетерминированный SSBO имеет слишком маленький GL_BUFFER_DATA_SIZE после glBufferData

Кажется, у меня есть недетерминированные данные в моем буфере хранения шейдеров.

Я использовал apitrace для проверки конечного автомата и заметил в трассировке следующую последовательность вызовов функций:

glBindBuffer (GL_SHADER_STORAGE_BUFFER, 3);
glBufferData (GL_SHADER_STORAGE_BUFFER, 36, NULL, GL_DYNAMIC_DRAW);
glBufferSubData (GL_SHADER_STORAGE_BUFFER, 0, 4, [binary data, size = 4 bytes])
glBufferSubData (GL_SHADER_STORAGE_BUFFER, 4, 32, [binary data, size = 32 bytes])

Это кажется правильным в соответствии с кодом приложения более высокого уровня, это соответствует настройке этого

layout (std140) buffer Components
{
    int count;
    vec4 colour [];
}
b_components;

в массив с префиксом длины glm::vec4[2].

Однако apitrace показывает, что GL_BUFFER_DATA_SIZE равно 32, а не 36, на каждом этапе приведенной выше трассировки.

Кроме того, вот проверка SSBO:

Components.colour[0] имеет GL_ARRAY_SIZE=0 (разве это не должно быть ненулевым?) и GL_OFFSET=16 (разве это не должно быть 4?)

Программа очень проста, так что для наглядности вот полная трассировка (это для кадра 1, glBufferData(...,36,...) было в кадре 0 и больше не повторялось):

1. Разве SSBO не должен иметь GL_BUFFER_DATA_SIZE=36, учитывая мой звонок glBufferData? Если да, то это ошибка драйвера? Если его заявленный размер 32 верен, не могли бы вы объяснить, как это имеет смысл?

2. Верны ли GL_ARRAY_SIZE и GL_OFFSET?

3. Учитывая, что при проверке вызовов glBufferSubData мой массив glm::vec4[2] описывает правильные, детерминированные данные, есть ли в этой трассировке что-нибудь, что могло бы объяснить, почему, когда я читаю b_components.colour[i] в for (int i = 0; i < b_components.count; ++i), я получаю недетерминированные результаты?