glDrawArrays и большое количество объектов

[Feyau]

Здравствуйте, на офсайте Qt есть пример работы с опенгл - http://doc.qt.io/qt-5/qtgui-openglwindow-example.html
Сам по себе он работает, однако если попытаться увеличить количество отображаемых объектов, то очень скоро получаем segfault.

Код:

    int n = 10000;
    if (v.size() < n) {
        v.append((float)(qrand() % 100) / 100);
        v.append((float)(qrand() % 100) / 100);
        v.append((float)(qrand() % 100) / 100);
    }
    qDebug() << v.size();

    glVertexAttribPointer(m_posAttr, 3, GL_FLOAT, GL_FALSE, 0, v.data());
    glVertexAttribPointer(m_colAttr, 3, GL_FLOAT, GL_FALSE, 0, colors);

    glEnableVertexAttribArray(0);
    glEnableVertexAttribArray(1);

    glDrawArrays(GL_TRIANGLE_STRIP, 0, v.size() / 3);

Ошибка стабильно в районе шести с половиной тысяч элементов, в

Код:

d_ptr->f.DrawArrays(mode, first, count);

Это чуть больше двух тысяч вершин - явно очень мало, на какие-то сложные объекты не хватит, даже сферу не построить. Первые мысли конечно по поводу недостатка памяти, но 6.5к флоатов вполне способны уместиться в видеопамяти, а сам процесс вообще не выходит за пределы 40мб, больше никаких идей нет. Подскажите, пожалуйста, в чем причина и как это можно исправить.

[Racheengel]

Скорей всего проблема где-то в Вашем методе f.DrawArrays.
Т.к. у нас подобный код (тоже флоаты, тоже треугольники) выводит под 5 млн вершин.

[Feyau]

Он не совсем мой, это

Код:

inline void QOpenGLFunctions::glDrawArrays(GLenum mode, GLint first, GLsizei count)
{
#ifdef QT_OPENGL_ES_2
    ::glDrawArrays(mode, first, count);
#else
    Q_ASSERT(QOpenGLFunctions::isInitialized(d_ptr));
    d_ptr->f.DrawArrays(mode, first, count);
#endif
    Q_OPENGL_FUNCTIONS_DEBUG
}

из Qt 5.7.0.
Еще один вопрос - каким образом нужно выводить несколько одинаковых объктов? То есть, например, вывести то, что в v.data(), но левее и повернутое на 90 градусов.

[Racheengel]

поворачиваете систему координат, рисуете один объект, поворачиваете систему координат, рисуете второй объект и т.д.

[Igors]

Отлаживапться надо: повтыкать печати gLGetError, убедиться что хендлы m_posAttr и m_colAttr ненулевые, да и вообще для начала может color отключить

[Feyau]

поворачиваете систему координат, рисуете один объект, поворачиваете систему координат, рисуете второй объект и т.д.

С этим разобрался, можете еще посказать какую-нибудь литературу по шейдерам, желательно современную и в кратком виде?

Отлаживапться надо: повтыкать печати gLGetError, убедиться что хендлы m_posAttr и m_colAttr ненулевые, да и вообще для начала может color отключить

Да, проблема действительно в color. Отключил - работает, сделал нормальный массив - тоже. Ладно бы была ошибка сразу как только выходим за пределы массива, а тут стабильно до 6.5к элементов. Объяснимо, конечно, но внимание на это не обратил, до сих пор не приучился внимательно относиться к указателям

[Racheengel]

По шейдерам я не спец, так что увы, тут не подскажу...
Кстати, а почему у Вас цвета через GL_FLOAT задаются? это же избыточно. GL_BYTE пробовали?

[Feyau]

Эту часть я взял из примера в документации, не стал ничего менять, все равно нужно было только продемонстрировать проблему. Хотя если бы попробовал сменить на байт, то скорее всего сразу бы понял, в чем она заключалась.
Сколько вообще вершин должна держать видеокарта уровня gtx 960? У меня доходит до миллиона без мультисэмплинга, маловато по-моему, хотя явно лучше, чем 2к

[Igors]

Сколько вообще вершин должна держать видеокарта уровня gtx 960? У меня доходит до миллиона без мультисэмплинга, маловато по-моему, хотя явно лучше, чем 2к

Про конкретную карту ничего не скажу, но барьер "лимон" преодолен лет эдак 10 назад (если не ранее). И что значит "держит" - если нет то в чем это выражается?

[Feyau]

В падении фпс ниже приемлемого значения, 30 например. Тут, конечно, лишняя нагрузка в виде цикла с добавлением элементов в массив, если сразу все добавить, то быстрее, а с вбо должно быть еще лучше. Сейчас при 1млн вершинах без цикла от 5 до 15 фпс. Как можно удостовериться, что используется именно гпу? Сейчас процесс сильно грузит цп даже если никаких вычислений не происходит.

[Igors]

В падении фпс ниже приемлемого значения, 30 например.

Аппетит неплохой Но все-таки надо быть реалистом и иметь ввиду что

- юзер всегда может создать столько геометрии что fps упадет (см анекдот про бензопилу)
- всегда найдется юзер с очень старой и дохлой картой
- всегда найдется динамическая геометрия которую VBO, увы, не ускорит

Да, и если append, то не забыть reserve для котейнера

[Feyau]

Этого в любом случае не избежать, но на какие-то значения же надо ориентироваться. Хотя бы для того, чтобы знать, когда достигнуты пределы видеокарты, а когда еще есть смысл попытаться что-то оптимизировать.

[Igors]

Этого в любом случае не избежать, но на какие-то значения же надо ориентироваться. Хотя бы для того, чтобы знать, когда достигнуты пределы видеокарты, а когда еще есть смысл попытаться что-то оптимизировать.

Замеры "на холостом ходу" мало о чем говорят. Есть текстуры, источники света, материалы и многое другое. Практически скорость определяется кодом шейдера (точнее его объемом)