- Dron09
- Постоялец
MrShoor
> Надо сделать 8 рендеров в 8 окон
fixed
Я делаю так для каждого окна вида (я убрал код рендер системы, написав то главное, что происходит у меня в коде:
hDC = GetDC(hWnd); wglMakeCurrent( hDC, m_hRC); // Делаем контекст текущим, который создан один раз на все окна вида //рисуем SwapBuffers( hDC); wglMakeCurrent( NULL, NULL); ReleaseDC( hWnd, hDC);
m_hRC - это контекст рендера - член класса рендер-системы, т.е. он один во всем приложении.
Можно разделять окна горизонтально и вертикально. Я правда не закончил еще эту прогу (для ПАК на работе делаю). Я не знаю, правильно ли я сделал. Но вроде пашет пока.
MrShoor
> Нука нука? Какие проблемы в создании второго контекста и рендера в него?
Чукча не читатель? :) На один пост выше, например.
MrShoor
> На порядок быстрее
Вот чтобы народ не верил в такие мифы и написан этот текст. :)
MrShoor
> делал окошко на весь рабочий стол, и рендерил в него.
Это не годится например потому, что конфигурация окон не обязательно идет стык в стык. Плюс на рабочем столе могут существовать другие окна. и т.п.
Вы придумываете костыли, когда есть вполне годное решение.
wglMakeCurrent занимает 0мс. Да, это переключение может быть долгим, но никак не в обычной ситуации переключения контекста между окнами.
Откуда вы вообще взяли, что MakeCurrent долгий???
Кажется дошло, почему все считают переключение долгим...
OpenGL flushes any previous rendering context that was current to the calling thread.
Ну так то да, может страшно много времени занимать. :))))))
@!!ex
подскажи, что с всинком делать, пожалуйста
Тоесть буфера цвета, глубины привязаны к HDC ? а не к контексту ?
Если окна разного разрешения то нужно будет вызвать ??
wglMakeCurrent(hDC0, context);
glViewport
.... render
SwapBuffers
wglMakeCurrent(hDC1, context);
glViewport
.... render
SwapBuffers
wglMakeCurrent(hDC2, context);
glViewport
.... render
SwapBuffers
И все будет работать хорошо ? Никаких постоянных аллокаций буферов не будет происходить, если окна разного размера ?
ЗЫ как же нормально, а не через жопу сделан ДХ !
SunnyBunny
Я делаю так:
рендерю все окна, без свопа.
потом в цикле делаю своп.
делаю так:
включаю vsync, и вызываю swap для первого окна. vsync отрабатывается.
сразу после этого отключаю vsync и делаю своп для остальных окон.
в итоге получается что первое окно работает по честному vsync'у, а остальные попадают под тот же синхроимпульс, но уже вручную, без ожидания.
естественно, чем больше окон, тем хуже это работает. До 4 - вполне ок.
Arxon
> ЗЫ как же нормально, а не через жопу сделан ДХ !
Ты про тот DX, который только-только избавился от Lost Device и только-только научился из буфера глубины читать? :)))))
И как же он сделан?
Arxon
> И все будет работать хорошо ? Никаких постоянных аллокаций буферов не будет
> происходить, если окна разного размера ?
Все будет работать хорошо. Хотя от драйвера конечно зависит.
@!!ex
Чукча не читатель? :) На один пост выше, например.
Специально перечитал первую страницу. Не нашел того, какие именно возникают проблемы при использовании двух рендерконтекстов?
Вот чтобы народ не верил в такие мифы и написан этот текст. :)
Ну то есть ты утверждаешь, что 8 раз сменить рендер контекст и делать 8 раз SwapBuffers быстрее, чем 8 раз сменить glViewport и сделать 1 раз SwapBuffers? Ха ха.
wglMakeCurrent занимает 0мс. Да, это переключение может быть долгим, но никак не в обычной ситуации переключения контекста между окнами.
Откуда вы вообще взяли, что MakeCurrent долгий???
Я сам лично упирался в это когда рендерил в несколько окон. А судя по комментирующим - далеко не я один. Алсо ты видимо никогда не работал с p-buffer-ами, которые при нескольких переключениях выжирали весь фпс потому что работают через MakeCurrent. Если у тебя там стоит рендерферма, вьюпорты маленькие и рендер легкий - можно и не заметить что он долгий.
Это не годится например потому, что конфигурация окон не обязательно идет стык в стык. Плюс на рабочем столе могут существовать другие окна. и т.п.
Вы придумываете костыли, когда есть вполне годное решение.
Пресмотрел видео, непонял что именно там должно быть не стык в стык. Подход должен зависеть от задачи, то что на видео - можно и нужно реализовать одной формой. И это не костыли, а оптимальное решение под конкретную ситуацию. Скакать же рендер контекстом - универсальное, но отнюдь не оптимальное решение.
@!!ex
>>Ты про тот DX, который только-только избавился от Lost Device и только-только научился из буфера глубины читать? :)))))
>>И как же он сделан?
Только только - это уже лет 5 как назад :)
Лост - вообще не проблема, а вот создание девайса и загрузка всех данных без создания окна вообще - правильное архитектурное решение, до которого ГЛ видимо никогда не дойдет, также как не дойдет до многопоточности. Многие называют ГЛ - апи, но это не совсем справедливо, это больше похоже на набор функций. И всегда можно сказать что ГЛ поддерживает все на свете, нужно лишь вызвать странную функцию glCallSomeStrangeFunctionZZP(GL_I_WANT_BLABLABLA, GL_YES_I_WANT_BLABLABLA, GL_BLABLABLA_PARAMETER_1, rawDataPtr) описанную в в каком-то тестовом документе. И еще есть как минимум 2 аналога glCallSomeStrangeFunctionARB и glCallSomeStrangeFunctionEXT - это чтобы было больше хороших функций :)
ЗЫ Я сам на ГЛ сижу, и вижу в основном косяки и убогость по сравнению с ДХ, за редким исключением конечно.
MrShoor
> Специально перечитал первую страницу. Не нашел того, какие именно возникают
> проблемы при использовании двух рендерконтекстов?
сообщение номер 13.
MrShoor
> Ну то есть ты утверждаешь, что 8 раз сменить рендер контекст и делать 8 раз
> SwapBuffers быстрее, чем 8 раз сменить glViewport и сделать 1 раз SwapBuffers?
> Ха ха.
не быстрее. ровно столько же по времени.
MrShoor
> Я сам лично упирался в это когда рендерил в несколько окон
Криво делал. Как правильно - я выше писал.
MrShoor
> Пресмотрел видео, непонял что именно там должно быть не стык в стык. Подход
> должен зависеть от задачи, то что на видео - можно и нужно реализовать одной
> формой.
Служебные окна, например. Но да, их на видео не видно.
MrShoor
> Скакать же рендер контекстом - универсальное, но отнюдь не оптимальное решение.
Аргументируешь? :)
Еще раз: Нет разницы делать несколько свопов или один. своп блокирует поток только при vsync, который нужен только для первого свопа.
Решение с одним окном не красивое, не универсальное и не имеет преимуществ.
При этом ограничений привносит дофига.
MrShoor
> Алсо ты видимо никогда не работал с p-buffer-ами, которые при нескольких
> переключениях выжирали весь фпс потому что работают через MakeCurrent.
При чем тут pbuffer? ты думаешь переключение одинаково работает во всех случаях? Я же писал "да, может быть медленным. но не в случае переключения между окнами". Напиши простенький тест и сам убедись. ТОьлко не забудь glFlush воткнуть перед переключением. А то да, будет очень медленно работать функция. :)
Arxon
> ногие называют ГЛ - апи, но это не совсем справедливо, это больше похоже на
> набор функций.
Еще раз подумай что ты написал. Потом расшифруй для себя абревиатуру API. И подумай еще раз.
Ну и да, срач OpenGL против DX - это в другой теме.
@!!ex, формально да, фраза звучит не правильно, но смысл думаю понятен.
Arxon
> @!!ex, формально да, фраза звучит не правильно, но смысл думаю понятен.
Ну если смысл в духе "ААА! МНЕ НЕ НРАВИТСЯ". То да, понятен. Какой-то более глубокий пока не вижу.
@!!ex
сообщение номер 13.
Это проблема шаринга ресурсов между контекстами, а не проблема рендера в 2 контекста. Я писал, цитирую:
Ну иногда нужно. В особенности превьюшки всякие в диалоговых окнах и т.п. Правда я в этом случае создаю отдельный рендерконтекст, и рисую в нем, ибо по факту общих данных минимум (а бывает и вообще нет копирования данных).
. Ни слова про шаринг контекстов, если надо какие-то данные отобразить в другом контексте, создаем gl ресурсы.
Криво делал. Как правильно - я выше писал.
У меня все окна в одном потоке, я многопоточного рендера вообще стараюсь избегать, ибо карточка как правило все равно одна.
Служебные окна, например. Но да, их на видео не видно.
Всмысле? Служебные окна поверх основного с видео.
Аргументируешь? :)
Еще раз: Нет разницы делать несколько свопов или один. своп блокирует поток только при vsync, который нужен только для первого свопа.
Решение с одним окном не красивое, не универсальное и не имеет преимуществ.
При этом ограничений привносит дофига.
А при чем тут блокирует или нет? Там куча шлака делается которого можно избежать. Есть например такая штука, как рендерстейты, которые включают/отключают прозрачности, ставят writemask-и, включают/выключают всякие тесты и т.п. Казалось бы, что там тяжолого, надо всего лишь несколько флагов поменять, несколько констант установить, шейдер поменять, десяток байт в шейдер послать и т.п. А по факту менять все и вся - долго. Некоторые вон даже рендерстейт машины пишут, чтобы быстрее ездило. И я не удивлюсь если для каждого окна ГЛ подготавливает свой дефолтный рендерстейт.
Алсо замерить сам wglMakeCurrent ты не сможешь, ибо он тебе сразу управление вернет, и будет якобы 0мс, а на стеке команд после вызова wglMakeCurrent образуется пачка неизвестно чего (известного только вендору), которая будет обработана позже, и которая повлияет на время рендера самой картинки. Именно это проседание я и обнаружил, когда оптимизировал свой проект с рендером в несколько окон.
Ах, да, и по поводу удобства - конечно рендер в одно окно некрасиво, гораздо красивее велосипед из SwapBuffers при VSync. И кстати я совсем не уверен что SwapInterval корректно дергать в пределах одного контекста по 5 раз за кадр.
Тема в архиве.
