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

wglShareList и миф рендера в несколько окон (комментарии) (2 стр)

Страницы: 1 2 3 Следующая »
#15
8:05, 22 окт. 2013

MrShoor
> Надо сделать 8 рендеров в 8 окон
fixed


#16
8:18, 22 окт. 2013

Я делаю так для каждого окна вида (я убрал код рендер системы, написав то главное, что происходит у меня в коде:

        hDC = GetDC(hWnd);
        wglMakeCurrent(hDC, m_hRC);    // Делаем контекст текущим, который создан один раз на все окна вида
       //рисуем
        SwapBuffers(hDC);
        wglMakeCurrent(NULL, NULL);
        ReleaseDC(hWnd, hDC);

m_hRC - это контекст рендера - член класса рендер-системы, т.е. он один во всем приложении.
Можно разделять окна горизонтально и вертикально. Я правда не закончил еще эту прогу (для ПАК на работе делаю). Я не знаю, правильно ли я сделал. Но вроде пашет пока.

+ Показать

#17
9:54, 22 окт. 2013

MrShoor
> Нука нука? Какие проблемы в создании второго контекста и рендера в него?
Чукча не читатель? :) На один пост выше, например.

MrShoor
> На порядок быстрее
Вот чтобы народ не верил в такие мифы и написан этот текст. :)

MrShoor
> делал окошко на весь рабочий стол, и рендерил в него.
Это не годится например потому, что конфигурация окон не обязательно идет стык в стык. Плюс на рабочем столе могут существовать другие окна. и т.п.
Вы придумываете костыли, когда есть вполне годное решение.
wglMakeCurrent занимает 0мс. Да, это переключение может быть долгим, но никак не в обычной  ситуации переключения контекста между окнами.
Откуда вы вообще взяли, что MakeCurrent долгий???

#18
10:01, 22 окт. 2013

Кажется дошло, почему все считают переключение долгим...

OpenGL flushes any previous rendering context that was current to the calling thread.

Ну так то да, может страшно много времени занимать. :))))))

#19
10:32, 22 окт. 2013

@!!ex
подскажи, что с всинком делать, пожалуйста

#20
10:37, 22 окт. 2013

Тоесть буфера цвета, глубины привязаны к HDC ? а не к контексту ?
Если окна разного разрешения то нужно будет вызвать ??

wglMakeCurrent(hDC0, context);
glViewport
.... render
SwapBuffers

wglMakeCurrent(hDC1, context);
glViewport
.... render
SwapBuffers

wglMakeCurrent(hDC2, context);
glViewport
.... render
SwapBuffers

И все будет работать хорошо ? Никаких постоянных аллокаций буферов не будет происходить, если окна разного размера ?
ЗЫ как же нормально, а не через жопу сделан ДХ !

#21
10:37, 22 окт. 2013

SunnyBunny
Я делаю так:
рендерю все окна, без свопа.
потом в цикле делаю своп.
делаю так:
включаю vsync, и вызываю swap для первого окна. vsync отрабатывается.
сразу после этого отключаю vsync и делаю своп для остальных окон.

в итоге получается что первое окно работает по честному vsync'у, а остальные попадают под тот же синхроимпульс, но уже вручную, без ожидания.
естественно, чем больше окон, тем хуже это работает. До 4 - вполне ок.

#22
10:40, 22 окт. 2013

Arxon
> ЗЫ как же нормально, а не через жопу сделан ДХ !
Ты про тот DX, который только-только избавился от Lost Device и только-только научился из буфера глубины читать? :)))))
И как же он сделан?

Arxon
> И все будет работать хорошо ? Никаких постоянных аллокаций буферов не будет
> происходить, если окна разного размера ?
Все будет работать хорошо. Хотя от драйвера конечно зависит.

#23
10:51, 22 окт. 2013

@!!ex

Чукча не читатель? :) На один пост выше, например.
Специально перечитал первую страницу. Не нашел того, какие именно возникают проблемы при использовании двух рендерконтекстов?
Вот чтобы народ не верил в такие мифы и написан этот текст. :)
Ну то есть ты утверждаешь, что 8 раз сменить рендер контекст и делать 8 раз SwapBuffers быстрее, чем 8 раз сменить glViewport и сделать 1 раз SwapBuffers? Ха ха.
wglMakeCurrent занимает 0мс. Да, это переключение может быть долгим, но никак не в обычной  ситуации переключения контекста между окнами.
Откуда вы вообще взяли, что MakeCurrent долгий???
Я сам лично упирался в это когда рендерил в несколько окон. А судя по комментирующим - далеко не я один. Алсо ты видимо никогда не работал с p-buffer-ами, которые при нескольких переключениях выжирали весь фпс потому что работают через MakeCurrent. Если у тебя там стоит рендерферма, вьюпорты маленькие и рендер легкий - можно и не заметить что он долгий.
Это не годится например потому, что конфигурация окон не обязательно идет стык в стык. Плюс на рабочем столе могут существовать другие окна. и т.п.
Вы придумываете костыли, когда есть вполне годное решение.

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

#24
11:03, 22 окт. 2013

@!!ex
>>Ты про тот DX, который только-только избавился от Lost Device и только-только научился из буфера глубины читать? :)))))
>>И как же он сделан?

Только только - это уже лет 5 как назад :)
Лост - вообще не проблема, а вот создание девайса и загрузка всех данных без создания окна вообще - правильное архитектурное решение, до которого ГЛ видимо никогда не дойдет, также как не дойдет до многопоточности. Многие называют ГЛ - апи, но это не совсем справедливо, это больше похоже на набор функций. И всегда можно сказать что ГЛ поддерживает все на свете, нужно лишь вызвать странную функцию glCallSomeStrangeFunctionZZP(GL_I_WANT_BLABLABLA, GL_YES_I_WANT_BLABLABLA, GL_BLABLABLA_PARAMETER_1, rawDataPtr) описанную в в каком-то тестовом документе. И еще есть как минимум 2 аналога glCallSomeStrangeFunctionARB и glCallSomeStrangeFunctionEXT - это чтобы было больше хороших функций :)
ЗЫ Я сам на ГЛ сижу, и вижу в основном косяки  и убогость по сравнению с ДХ, за редким исключением конечно.

#25
11:11, 22 окт. 2013

MrShoor
> Специально перечитал первую страницу. Не нашел того, какие именно возникают
> проблемы при использовании двух рендерконтекстов?
сообщение номер 13.

MrShoor
> Ну то есть ты утверждаешь, что 8 раз сменить рендер контекст и делать 8 раз
> SwapBuffers быстрее, чем 8 раз сменить glViewport и сделать 1 раз SwapBuffers?
> Ха ха.
не быстрее. ровно столько же по времени.

MrShoor
> Я сам лично упирался в это когда рендерил в несколько окон
Криво делал. Как правильно - я выше писал.

MrShoor
> Пресмотрел видео, непонял что именно там должно быть не стык в стык. Подход
> должен зависеть от задачи, то что на видео - можно и нужно реализовать одной
> формой.
Служебные окна, например. Но да, их на видео не видно.

MrShoor
> Скакать же рендер контекстом - универсальное, но отнюдь не оптимальное решение.
Аргументируешь? :)
Еще раз: Нет разницы делать несколько свопов или один. своп блокирует поток только при vsync, который нужен только для первого свопа.
Решение с одним окном не красивое, не универсальное и не имеет преимуществ.
При этом ограничений привносит дофига.

MrShoor
> Алсо ты видимо никогда не работал с p-buffer-ами, которые при нескольких
> переключениях выжирали весь фпс потому что работают через MakeCurrent.
При чем тут pbuffer? ты думаешь переключение одинаково работает во всех случаях? Я же писал "да, может быть медленным. но не в случае переключения между окнами". Напиши простенький тест и сам убедись. ТОьлко не забудь glFlush воткнуть перед переключением. А то да, будет очень медленно работать функция. :)

#26
11:13, 22 окт. 2013

Arxon
> ногие называют ГЛ - апи, но это не совсем справедливо, это больше похоже на
> набор функций.
Еще раз подумай что ты написал. Потом расшифруй для себя абревиатуру API. И подумай еще раз.
Ну и да, срач OpenGL против DX - это в другой теме.

#27
11:15, 22 окт. 2013

@!!ex, формально да, фраза звучит не правильно, но смысл думаю понятен.

#28
11:17, 22 окт. 2013

Arxon
> @!!ex, формально да, фраза звучит не правильно, но смысл думаю понятен.
Ну если смысл в духе "ААА! МНЕ НЕ НРАВИТСЯ". То да, понятен. Какой-то более глубокий пока не вижу.

#29
11:57, 22 окт. 2013

@!!ex

сообщение номер 13.
Это проблема шаринга ресурсов между контекстами, а не проблема рендера в 2 контекста. Я писал, цитирую:
Ну иногда нужно. В особенности превьюшки всякие в диалоговых окнах и т.п. Правда я в этом случае создаю отдельный рендерконтекст, и рисую в нем, ибо по факту общих данных минимум (а бывает и вообще нет копирования данных).
. Ни слова про шаринг контекстов, если надо какие-то данные отобразить в другом контексте, создаем gl ресурсы.
Криво делал. Как правильно - я выше писал.
У меня все окна в одном потоке, я многопоточного рендера вообще стараюсь избегать, ибо карточка как правило все равно одна.
Служебные окна, например. Но да, их на видео не видно.
Всмысле? Служебные окна поверх основного с видео.
Аргументируешь? :)
Еще раз: Нет разницы делать несколько свопов или один. своп блокирует поток только при vsync, который нужен только для первого свопа.
Решение с одним окном не красивое, не универсальное и не имеет преимуществ.
При этом ограничений привносит дофига.
А при чем тут блокирует или нет? Там куча шлака делается которого можно избежать. Есть например такая штука, как рендерстейты, которые включают/отключают прозрачности, ставят writemask-и, включают/выключают всякие тесты и т.п. Казалось бы, что там тяжолого, надо всего лишь несколько флагов поменять, несколько констант установить, шейдер поменять, десяток байт в шейдер послать и т.п. А по факту менять все и вся - долго. Некоторые вон даже рендерстейт машины пишут, чтобы быстрее ездило. И я не удивлюсь если для каждого окна ГЛ подготавливает свой дефолтный рендерстейт.
Алсо замерить сам wglMakeCurrent ты не сможешь, ибо он тебе сразу управление вернет, и будет якобы 0мс, а на стеке команд после вызова wglMakeCurrent образуется пачка неизвестно чего (известного только вендору), которая будет обработана позже, и которая повлияет на время рендера самой картинки. Именно это проседание я и обнаружил, когда оптимизировал свой проект с рендером в несколько окон.
Ах, да, и по поводу удобства - конечно рендер в одно окно некрасиво, гораздо красивее велосипед из SwapBuffers при VSync. И кстати я совсем не уверен что SwapInterval корректно дергать в пределах одного контекста по 5 раз за кадр.
Страницы: 1 2 3 Следующая »
ПрограммированиеФорумГрафика

Тема в архиве.