Войти
ПрограммированиеФорумГрафика

OpenGL, VAO и тормоза (2 стр)

Страницы: 1 2 3 4 5 Следующая »
#15
(Правка: 14:29) 14:28, 14 сен. 2020

glQueryCounter - 3.2

glBeginQuery/glEndQuery с таргетом gl_time_elapsed - 3.3

> Уточняю. ОС Win7 x64, ОЗУ 8 ГБ, видео встроенное в Core i7, разрешение 1920x1080, OGL 4.0.


#16
14:32, 14 сен. 2020

0xc0de
Intel HD Graphics 4600 может и поддерживает это расширение, но не зависимо от gl версии его там может и не быть.

#17
18:40, 14 сен. 2020

Провел такие эксперименты. Замерил время SwapBuffers так:

  wglMakeCurrent(FDC, FRC);
  glClearColor(0.0, 0.0, 0.0, 0.0);
  glClear(GL_COLOR_BUFFER_BIT);

  glMatrixMode(GL_MODELVIEW);
  glLoadIdentity;
  glScalef(FScale, FScale, 1.0);
  glTranslatef(FPanX, FPanY, 0.0);

  glBindVertexArray(FLines.FVao);
  glDrawArrays(GL_LINES, 0, FLines.FBuffersItemsCount);
  glBindVertexArray(0);

  QueryPerformanceFrequency(FClockRate);
  QueryPerformanceCounter(FStartDrawTime);

  SwapBuffers(FDC);

  QueryPerformanceCounter(FEndDrawTime);
  FTimeDraw:= (FEndDrawTime - FStartDrawTime) / FClockRate;

  wglMakeCurrent(0, 0);
Результат - 19 мс.

Убрал PFD_DOUBLEBUFFER из dwFlags в SetDCPixelFormat и SwapBuffers из отрисовки:

  QueryPerformanceFrequency(FClockRate);
  QueryPerformanceCounter(FStartDrawTime);

  wglMakeCurrent(FDC, FRC);
  glClearColor(0.0, 0.0, 0.0, 0.0);
  glClear(GL_COLOR_BUFFER_BIT;

  glMatrixMode(GL_MODELVIEW);
  glLoadIdentity;
  glScalef(FScale, FScale, 1.0);
  glTranslatef(FPanX, FPanY, 0.0);

  glBindVertexArray(FLines.FVao);
  glDrawArrays(GL_LINES, 0, FLines.FBuffersItemsCount);
  glBindVertexArray(0);

  wglMakeCurrent(0, 0);

  QueryPerformanceCounter(FEndDrawTime);
  FTimeDraw:= (FEndDrawTime - FStartDrawTime) / FClockRate;
Общее время отрисовки - 20 мс.

Далее, после инициализации OpenGL воткнул wglSwapIntervalEXT(0);
Общее время отрисовки - теже 20 мс.

Выкинул

  glMatrixMode(GL_MODELVIEW);
  glLoadIdentity;
  glScalef(FScale, FScale, 1.0);
  glTranslatef(FPanX, FPanY, 0.0);
Картинка ес-но перестала панорамироваться, но макс. общее время отрисовки - аж 24 мс.

#18
18:41, 14 сен. 2020

Да, толщина линии - по умолчанию, 1 пиксел.

#19
(Правка: 19:59) 19:13, 14 сен. 2020

greencad
> Убрал PFD_DOUBLEBUFFER из dwFlags в SetDCPixelFormat и SwapBuffers из отрисовки:
Вместо SwapBuffers нужно ставить glFlush. Но это замена шила на мыло. У тебя в любом случае 20мс будут вылазить в других местах - это твоя нагрузка на видеокарту при текущей геометрии.

greencad
> Картинка ес-но перестала панорамироваться, но макс. общее время отрисовки - аж
> 24 мс.
По умолчанию обычно стоит единичная матрица и весь твой объект рисуется "внутри" камеры.

greencad
> cColorBits:= 24;
Это еще что за гадость? 32 нужно ставить! У тебя скорее всего установлен не поддерживаемый формат экрана, и весь твой пример рисуется эмуляцией.

24 бита это косокриворукожопый какашко формат, ни когда его не используй.

greencad
> cDepthBits:= 32;
Конкретно твоя видеокарта не поддерживает глубину в 32 бита, максимум 24.

классика:

  pfd.nVersion = 1;
  pfd.dwFlags = PFD_DRAW_TO_WINDOW | PFD_SUPPORT_OPENGL | PFD_DOUBLEBUFFER;
  pfd.iPixelType = PFD_TYPE_RGBA;
  pfd.cColorBits = 32;
  pfd.cDepthBits = 16;
  pfd.iLayerType = PFD_MAIN_PLANE;

Нужно конечно опрашивать операционку на предмет поддерживаемых железом форматов. Но этот распространен практически везде.

#20
20:06, 14 сен. 2020

greencad
Все же убери активацию контекста каждый раз в кадре, сделай один раз, лет 10 назад, в одном коммерческом проекте я убрал
wglMakeCurrent из цикла, у меня это отжирало десяток мс как минимум.

#21
20:23, 14 сен. 2020

foxes
pfd ставил и так и сяк. Не помогает.
Andrey
Если wglMakeCurrent убираю, панорамирование не работает.
Может дело в том, что частота обновления экрана 60 Гц (предельная для моего монитора)?

#22
(Правка: 20:32) 20:27, 14 сен. 2020

greencad
> pfd ставил и так и сяк. Не помогает.
То что у тебя стоит сейчас абсолютно точно не поддерживается и не использует OpenGL, используй DescribePixelFormat чтобы определить поддерживаемые форматы. А заодно можешь вызвать DescribePixelFormat после ChoosePixelFormat и посмотреть стоит ли флаг поддержки OpenGL.

#23
21:16, 14 сен. 2020

foxes
Задавал разные настройки в SetPixelFormat, вызвал после этого DescribePixelFormat. Результат такой.
PFD_DOUBLEBUFFER, PFD_DRAW_TO_WINDOW, PFD_SUPPORT_OPENGL и PFD_SWAP_EXCHANGE ставятся. PFD_GENERIC_ACCELERATED - нет. cColorBits = 32, cDepthBits = 24.

#24
(Правка: 22:21) 21:59, 14 сен. 2020

greencad
Значит такова производительность твоей видеокарты при отрисовки линий. С этим вряд ли что то можно сделать.

greencad
> Может дело в том, что частота обновления экрана 60 Гц
Ты сделай три строчки и замерь время на них.

  QueryPerformanceFrequency(FClockRate);
  QueryPerformanceCounter(FStartDrawTime);

  wglMakeCurrent(FDC, FRC);
  SwapBuffers(FDC);
  wglMakeCurrent(FDC, 0);

  QueryPerformanceCounter(FEndDrawTime);
  FTimeDraw:= (FEndDrawTime - FStartDrawTime) / FClockRate;

Если wglSwapIntervalEXT правильно отработал и в настройках видеокарты не стоит "установить на сильную синхронизацию", то должно получиться меньше 1000/60 = 16.666 миллисекунд.

wglSwapIntervalEXT нужно вызывать после wglMakeCurrent(FDC, FRC).

#25
8:12, 15 сен. 2020

foxes

> Ты сделай три строчки и замерь время на них.

Сделал. Получилось 0,3 мс.
Еще эксперимент. Нарисовал 5 линий, панорамируются без тормозов. Замерил время полного цикла отрисовки, как в моем посте #0. Получилось 0,5 мс.
> Значит такова производительность твоей видеокарты

Это и не понятно, т.к. AutoCAD те же 20 тыс. линий панорамирует бодро, без тормозов (при выключенном сглаживании, так у себя и не включал).
#26
9:43, 15 сен. 2020

foxes
> Это еще что за гадость? 32 нужно ставить!
Я уже забыл почему, но после долгих экспериментирований стал передавать 0.
Знать, так стабильнее работало.

        FillChar(pfd, SizeOf(pfd), 0);
        
        { NOTE: We do not need a depth buffer since we render everything using FBO!
          Sadly, the Windows implementations of OpenGL tend to ignore that
           and create a depth buffer anyway. See the log file or console,
           the pixel format description should ideally state depth and stencil = 0
        }
        with pfd do
        begin
          nSize           := SizeOf(TPIXELFORMATDESCRIPTOR); // Size Of This Pixel Format Descriptor
          nVersion        := 1;                    // The version of this data structure
          dwFlags         := PFD_DRAW_TO_WINDOW    // Buffer supports drawing to window. Should be off for Voodoo2 ?..
                             or PFD_SUPPORT_OPENGL // Buffer supports OpenGL drawing
                             or PFD_DOUBLEBUFFER;  // Supports double buffering

          iPixelType      := PFD_TYPE_RGBA;        // RGBA color format
          //cColorBits      := 32;                   // OpenGL color depth
          //cDepthBits      := 16;
          iLayerType      := PFD_MAIN_PLANE;       // Ignored
        end;
#27
(Правка: 10:01) 9:58, 15 сен. 2020

greencad
> Макс. время полного цикла отрисовки = 37 мс. Макс. время непосредственно
> отрисовки = 0,14 мс!
наверняка уже писали, но современный драйвер оставляет за собой право рендерить тогда, когда ему захочется, а не тогда, когда ты ему говоришь. то есть glDrawBlabla() может вообще ничего не рендерить до тех пор, пока ты не произведёшь какие-нибудь манипуляции с таргетом, например. ты не имеешь права предполагать, что рендеринг заканчивается после того, как ты вызываешь свой glDrawBlabla(), ты даже не имеешь права предполагать, что он к этому моменту начнётся. а SwapBuffers всегда обозначает, что время пришло и рендеринг нужно, собственно, заканчивать здесь и сейчас, а программа не будет выполняться дальше, пока он не закончится.

поэтому если ты хочешь узнать, сколько времени занимает сам рендеринг, то рисуй 1 линию и 10000000 линий и сравнивай разницу. время рендеринга 1 линии — это, считай, оверхед на всякую очистку, вертикальную, смену состояний, синхронизацию и прочий шлак, который ты можешь оптимизировать. а время рендеринга 10000000 линий (скорее всего) упрётся именно в скорость отрисовки и филлрейт — величины, которые ты оптимизировать не сможешь за вычетом оверхеда.

кстати, в древнем opengl был какой-то шлак вроде glHint(GL_LINE_SMOOTH_HINT, GL_NICEST); или ещё какой-то там горе-анти-алиасинг, который на любом современном железе убивает скорость рендеринга линий раз в 10, да ещё криво с блендингом работает.

#28
10:19, 15 сен. 2020

Cheb
Попробовал. Тормоза остались.
Suslik
Выше я писал: "Нарисовал 5 линий, панорамируются без тормозов. Замерил время полного цикла отрисовки, как в моем посте #0. Получилось 0,5 мс". С 20 тыс. линий - 37 мс. и тормозит.

Далее. wglMakeCurrent(FDC, FRC) вначале Draw и wglMakeCurrent(0, 0) в конце убрал. Не помогло.
Далее. Посмотрел, что делаю в OnMouseMove:

  if ssMiddle in Shift then
  begin
    ScreenToWorld(X, Y, FCurPanX, FCurPanY);
    Pan(FCurPanX - FOrgPanX, FCurPanY - FOrgPanY);
    FOrgPanX:= FCurPanX;
    FOrgPanY:= FCurPanY;
    Draw;
  end;
Где Pan это:
  FPanX:= FPanX + dX / FScale;
  FPanY:= FPanY + dY / FScale;
А вот ScreenToWorld такой:
var
  Viewport: array[0..3] of GLInt;
  ModelMatrix, ProjMatrix: array[0..15] of GLdouble;
  tmpY: GLInt;
  WorldZ: GLdouble;
begin
  wglMakeCurrent(FDC, FRC);
  glMatrixMode(GL_MODELVIEW);
  glLoadIdentity();
  glGetIntegerV(GL_VIEWPORT, @Viewport);
  glGetDoubleV(GL_MODELVIEW_MATRIX, @ModelMatrix);
  glGetDoubleV(GL_PROJECTION_MATRIX, @ProjMatrix);
  tmpY:= ViewPort[3] - ScreenY - 1;
  OpenGL.gluUnProject(ScreenX, tmpY, 0.0, @ModelMatrix, @ProjMatrix, @Viewport, WorldX, WorldY, WorldZ);
  wglMakeCurrent(0, 0);
end;
Похерил в нем wglMakeCurrent, тормоза остались.

#29
(Правка: 10:28) 10:26, 15 сен. 2020

greencad
> С 20 тыс. линий - 37 мс. и тормозит
учитывая, насколько убогий встроенный в интелы видеочип, я не особо удивлюсь, если производительность действительно такая и есть. ещё я бы рекомендовал для тестирования проверить, что именно тормозит — растеризация или обработка вертексов. для этого задай всем вершинам своих 20000 линий одинаковые координаты (например, нулевые), при этом у них будет нулевое время на растеризацию, а всё время рендеринга уйдёт в одну только обработку вершин. тогда ты будешь знать, что дальше можно оптимизировать.

если выяснится, что тормозит растеризация, то оптимизировать надо блендинг, формат пикселя итп. если тормозит обработка вертексов, то самому написать нормальный вершинный шейдер вместо ffp.

Страницы: 1 2 3 4 5 Следующая »
ПрограммированиеФорумГрафика