- Cheb
- Постоялец
В общем, давно носился с идеей динамической детализации всего-всего-всего (оченно меня в своё времz Morrowind FPS Optimizer впечатлил) -- и пришёл к интересной идейке. Кроме LOD'ов, основной фактор, влияющий на нагрузку - это разрешение. А его обычно меняют через меню. Но! Поскольку у нас поголовно LCD мониторы, то совершенно что совой об пень, что пнём об сову. Я имею в виду, не важно - переключаем мы видеорежим в неродной, или рендерим в текстуру неродного размера.
Собственно, за ким бесом рендера в текстуру берут соотношение пиксел - в пиксел? Можно же больше. И чем больше, тем больше выборок из ея мы делаем, чтобы получить красивое сглаживание. Конечно, только в случае дешёвого, ненавороченного рендера. Например, для клона майнкрафта какого-нибудь.
И это даёт намм плавную регулировку MSAA на лету, в очень широких пределах.
+ меньше грузить хомячков настройками
+ уменьшает уязвимость к узким местам где возможно проседание FPS из-за пропускной способности по пикселям/текселям
Проверил на встроенной видяхе ноута (Intel core i5) - всё летает, пересоздание FBO имеет вес пера. Т.е. заметно только по выкакиванию лога на экран.
Проверил на встроенной, древней видяхе gF 7025 на линуксовом сервере - ползёт, но на ней FBO через задницу. Всё подвисает, рендер идёт рывками от 2 до 100 FPS. И GL_RGBA8 эта хрень не поддерживает! Только GL_RGB8 и GL_RGBA16 (отчего последний и использую).
Проверил на пыльном музейном экспонате gF FX 5200 c 128 Мб памяти, вообще без поддержки NPOT. Кряхтело, но ползло. Првда, упало, попытавшись создать FBO 4096x4096. Запретил создавать буфер больше, чем ближайшая степень двойки от размеров вьюпорта, и прибил гвоздями на соотношении пиксел-в-пиксел. Так что шейдер на подобном добре даже не включится (хотя может, на 15 FPS).
И тут! У меня кончилось на чём тестировать. :( Игровую зверь-машину лень со шкафа доставать.
http://chebmaster.ru/downloads/chentrah_test_016.zip - исходники не даю, не от жадности (всё под GPL будет) а потому что там всё вздрючено, и сериализация почти не рабочая. Вы же нестираное бельё на всеобщее обозрение не выкладываете?
F12 + Q переключает коэффициент (qf) с автомата на колесо мыши. 100..120 - дефолт (пиксел в пиксел, нет шейдера), выше - начинает сглаживать, увеличивая размер FBO (предел - около 3х размер вьюпорта и 8-9 выборок). qf меньше 100 - это разновидность мазохизма, для случая "несколько вьюпортов на эпически слабом железе"
Автомат ориентируется на усреднённое время выполнения SwapBuffers (swb), медленно подгоняя qf к расчётному значению: нельзя ориентироваться на FPS, т.к. в норме искусственно ограничивается до 30 (или 60 если было событие мыши). Для этого теста лимит отключён. Опять же, тестировал мало, возможно возникновение резонансных колебаний.
На автомате qf резко проседает если поверх окна программы наложится любое прозрачное окно Aero.
Консоль (только лог, read-only) вкл/выкл. по ScrollLock.
Шейдер крайне топорный - просто чтобы идею проверить. Точки берутся по кругу вокруг исходных текстурных координат по радиусу в 1 пиксел экранных координатах, с одинаковыми весами. Шейдеры я практически не умею, поэтому он создаётся каждый раз заново, исходник шейдера генерится программно и координаты всех точек забиваются гвоздями (выставьте debug_mode=1 в ini файле, если вам надоело спокойно спать по ночам).
P.S. индикатор "cpu" это пережиток. Показывает частоту RDTSC проца, а она на всех современных прибита гвоздями (инвариантность TSC), и считает не реальную тактовую частоту, а максимальную.
P.P.S. Тьфу. Вот что значит код клонировать копипастой на ночь глядя! Очепятался, и построение мип-уровней меня верхом на голубе выполнялось шиворот-навыворот.
Исправил, обновил архив.
То что ты реализуешь называется SSAA, MSAA это немного другая вещь
А вообще время кадра берется в худшем случае, поэтому нет особого смысла делать что-то отдельно , когда смотришь в пол
Cheb
Да, это называется Super Sampling. И это всё плохая идея - оптимизировать нужно боттлнэки и для фрагментов есть другие методы, а дергать разрешение это отвратительно.
> пересоздание FBO имеет вес пера.
Пересоздание рендертаргетов это очень дорогая операция.
> Кроме LOD'ов, основной фактор, влияющий на нагрузку - это разрешение.
Плохой подход.
Зависает, видимо железо совсем уж древнее.
Лог:
>оптимизировать нужно боттлнэки и для фрагментов есть другие методы, а дергать разрешение это отвратительно.
Я говорю не об оптимизации, а о выравнивании нагрузки. Конечно, в кривых руках это будет лишь поводом забить на нормальные оптимизации и ни к чему хорошему.
>Пересоздание рендертаргетов это очень дорогая операция.
Из какого источника? Я ничему не верю пока руками не пощупаю.
Да, дорогая. На железе 2003 года, которое голый кубик еле 50 FPS тянет. Современная видеокарта под рукой была одна - "Intel(R) HD Graphics Family". На ней стоимость этой операции незаметна. Для чистоты надо на нивидевской и амдшной протестировать.
P.S. Переработал, добавил отображение длительности операций. Если не насиловать видеокарту (при чём FPS проседайе до 15), то удаление и создание создание FBO занимает 3..6 милисекунд. Компиляция шейдера - 7..10 милисекунд. И это для операций, которые в худшем случае происходят раз в неесколько секунд!
Вес пера.
P.P.S. Достал с полки игровую машину, протестил на gF GTX 460. Результаты очень интересные:
- создание FBO занимает 11 милисекунд +/- с копейками, независимо от размера.
- шейдеры кешируются. Первая компиляция любого занимает 5-6 милисекунд, когда он же компилируется второй раз - уже 350..450 микросекунд.
Чтобы не было вопросов: чем я мерю тайминги:
>Зависает, видимо железо совсем уж древнее.
Если в логе ничего больше нет - значит, действительно зависло. Посмотрел про эту карточку - должна по идее тянуть.
Наверно, где-то формат не совпал, или в программе какой ляп.
Короче, понятно, что надо радеон себе добывать иначе нормально не протестируешь.
А зависает как - полностью, или автохаракири по истечении 60 секунд срабатывает?
А если debug_mode=0 поправить на 1 ?
Cheb
> Первая компиляция любого занимает 5-6 милисекунд, когда он же компилируется
> второй раз - уже 350..450 наносекунд.
уверен насчёт нано? может микро? Просто разница в 4 порядка это круто
Cheb
Вроде не зависает а безбожно тормозит, если долго ждать появляется картинка голубя.
Может че-то с очередью сообщений намутил или там слипы лишние?
Либо может чего с таймером, попробуй вместо rdtsc прикрутить timeGetTime, ради интереса, проверить.
>Просто разница в 4 порядка это круто
[facepalm] Конечно же микро. Поправил.
>Вроде не зависает а безбожно тормозит, если долго ждать появляется картинка голубя.
Упс... Вот она:
>инвариантность TSC: не поддерживается
У меня просто процессора такого под рукой нет, наверно где-то древний говнокод вылезает и от этого всё глючит. Но, по идее, должно пытаться мерить частоту TSC на лету и подстраиваться под её изменения.
а еще видеодрайвер менеджит на vista+ системах видеопамять совсем нет так как под ХР..
а почему аллокация видеопамяти должна быть дорогой?
+
и в какой момент оценивается дороговизна?
исполнение команды так асинхронно.
>и в какой момент оценивается дороговизна?
Вся пачка удаление старой текстуры - удаление старого буфера глубины - удаление FBO - создание текстуры + создание буфера глубины + связывание с FBO + bind
Главное - время "на ощупь" тоже не заметно, кубик вращается плавно.
>исполнение команды так асинхронно.
непохоже. Если выбрать конские размеры текстуры (где-то 4500х4500 и выше для GTX 460) то и врямя будет конское, 40..70 милисекунд.
Хотя, может быть, там ещё часть времени действительно откладывается до SwapBuffers.
Cheb
Я так и не понял в чём проявляется динамичность.
> Вся пачка удаление старой текстуры - удаление старого буфера глубины - удаление
> FBO - создание текстуры + создание буфера глубины + связывание с FBO + bind
> Главное - время "на ощупь" тоже не заметно, кубик вращается плавно.
Ну если удалять и создавать не каждый кадр, а при смене каких-то настроек, то это нормально.
А если ты это делаешь каждый кадр, то плохо.
Погляди демки про SSAA, например вот:
http://developer.amd.com/wordpress/media/2013/01/SSAA11_v1.0.zip
А то ты какой-то велосипед непонятный изобретаешь. :)
>Я так и не понял в чём проявляется динамичность.
В программе есть глобальная настройка "коэффициент качества" qf, которая медленно изменяется со временем в зависимости от нагрузки (в настоящий момент на неё влияет в основном длительность SwapBuffers).
В зависимости от qf подстраиваются всякие ресурсоёмкие вещи, типа размера FBO. То есть, FBO пересоздаётся а) когда меняется размер вьюпорта или б) когда qf заметно изменится.
В будущем, когда доползу, от qf будут зависеть LOD'ы, тесселяция, размеры текстур и прочая.
На идею натолкнула утилита Morrowind FPS Optimizer: в моровинде лодов не было, и fps были очень неровными, завися в основном от дальности тумана. Добрые люди создали утилитку, которая присасывалась к процессу морровинда, находила в его памяти переменную глубины тумана, и подстраивала её на лету, добиваясь указанных fps.
>А то ты какой-то велосипед непонятный изобретаешь. :)
Я почётный изобретатель велосипедов, начиная с реальной многопоточности, которую изобрёл в MS-DOS на 386-м :)
на лету пересоздаешь FBO?
при понижении качества местами подвисает, при повышении качества до бесконечности вылетает)
>, при повышении качества до бесконечности вылетает
Вчера начал делать реакцию на подобное, аварийный дроп до 256х256 + сброс qf вдвое, но пока не доделал
>при понижении качества местами подвисает,
Там ещё, к сожалению, непроработанная перегрузка фоновой текстуры встревает. Кадый раз грузит из файла картинку 2048x1024, потом ресемплит её вниз.
Руки пока не дошли заменить эту фигню красивым динамическим шейдером.
в каком-то пейпере я видел уменьшение размеров рендер таргета в моменты повышения нагрузки и растягивание результата на весь экран но там это делалось через glVieport, поэтому пересоздавать ничего не нужно было
Тема в архиве.