C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено FiEctro 14-02-2020 в 21:03:
Дядя Миша
Все современные процы завязаны на многопоточность, и софт без её поддержки будет тормозить из-за низкой частоты на ядро. Карочи твой софт просто будет крайне не эффективно использовать ресурсы процессора. Тоже самое и с x86 архитектурой, с её дебильным ограничением в 4гб оперативки.
__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!
Какую проблему в данном случае должна решать поддержка многопоточности?
Отправлено Ku2zoff 15-02-2020 в 06:29:
Цитата:
nemyax писал: Какую проблему в данном случае должна решать поддержка многопоточности?
Вот я тоже думаю. Чего распараллеливать-то? Движок нетребовательный, идёт на старых картах семилетней давности на максималках. Ежели было б как в Лост Альфе, тогда другое дело. Они уже после релиза 1.4007 прикрутили многопоточность к рендереру и получили + 20-30 фпс, во. А нагрузка на проц от игровой логики и монстров небольшая, это не 30 ботов на сервере считать. Даже если бы и так, тот же сорс 2013 по-сути однопоточный. У ксго высокие требования к производительности на ядро, особенно при игре с ботами. И ничё, даже на кукурузенах бегает 100+ фпс при бодрой видеокарточке.
Добавлено 15-02-2020 в 13:29:
При низких общих системных требованиях многопоточность нужна ровно для одного: загрузки ресурсов. Чтобы вместо минуты, все сотни текстур грузились 15 секунд. В той же ЛА, в отличие от ТЧ, загрузка локации происходит быстрее, потому что пашет как минимум в 4 потока. Это сама игра в 4 потока, а загрузка, возможно, использует все ядра.
Отправлено nemyax 15-02-2020 в 06:35:
Ku2zoff
Не, ну можно рассовать в разные потоки I/O и рендеринг. Ну а ещё-то что?
Отправлено XaeroX 15-02-2020 в 06:59:
Цитата:
nemyax писал: Ну а ещё-то что?
В волатиле:
- Рендеринг
- Нанесение декалей
- Физика
- Микширование звуков
Ещё можно было бы вынести в поток ИИ (всякие CheckLocalMove нехило жрут цпу), но мне было лень.
Добавлено 15-02-2020 в 13:59:
Цитата:
Ku2zoff писал: многопоточность нужна ровно для одного: загрузки ресурсов
Разве обращение к диску может быть параллельным? И разве всякие glTexImage2D не синхронизируются?
Дядя Миша нет, при увеличении сложности сцены и вычислении на одном ядре в нынешние времена для сносной работы надо эток 3,6-4 Ггц на ядро. Это касается относительно новых процов. При многопоточности, с учётом того что твой двиг действительно не особо требовательный, можно получить высокий фреймрейт даже на старых низкочастотных четырёхядерниках с нормальной видяхой. Типо E5450 и 750Ti.
Отправлено Дядя Миша 15-02-2020 в 09:11:
Цитата:
Ku2zoff писал: Даже если бы и так, тот же сорс 2013 по-сути однопоточный.
У сорса сервер на отдельном ядре бегает.
Цитата:
Ku2zoff писал: В той же ЛА, в отличие от ТЧ, загрузка локации происходит быстрее, потому что пашет как минимум в 4 потока
Ты будешь смеяться, но у меня ЛА грузится раз в пять дольше чем ТЧ.
Товариши, которые полагают, что многоядерная загрузка что-то там оптимизирует, почему-то упорно забывают, что грузят они с одного и того же винчестера, у которого одна голова и грузят в видеокарту, которая тоже не умеет это делать в мультипотоке. Единственное, где это оправдано - фоновая загрузка ресурсов.
На ютубе где-то есть обзор эксодуса со включённым профайлером и там есть расклад поядрам - одно ядро 70%, другое ядро 30%. Отлично распараллелили. Причём я думаю, что 70% это физикс.
Чтобы от параллельных процессов был прирост надо:
1. найти то, что можно считать параллельно
2. не потерять время на синхронизации
Вот в том же Сорсе, как я говорил, сервер тикает отдельно, если энтить довольно много, это вполне себе разумное решение. Но и то - под вопросом. Возьмём мой любимый AD, сипульчер. Там 5000 энтить и 100 фпс. Причём низкий фпс обусловлен неоптимальностью дерева, в первую очередь. Но в любом случае он выше современного стандарта в 30-60 фпс.
Добавлено 15-02-2020 в 11:54:
Цитата:
Lev писал: Это касается относительно новых процов. При многопоточности, с учётом того что твой двиг действительно не особо требовательный, можно получить высокий фреймрейт даже на старых низкочастотных четырёхядерниках с нормальной видяхой. Типо E5450 и 750Ti.
Я смотрю ФиЭктра с тобой шышками поделился? Откуда эта песня про "новые процы" взялась?
Добавлено 15-02-2020 в 11:56:
Есть условно две школы подхода к оптимизации. Старое поколение привыкло это делать алгоритмически, новое свято уверено, что всё можно распараллелить, а сами алогоритмы могут быть сколь угодно неоптимальные, главное - раскидать по ядрам.
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено FiEctro 15-02-2020 в 11:36:
>> Есть условно две школы подхода к оптимизации. Старое поколение привыкло это делать алгоритмически, новое свято уверено, что всё можно распараллелить
Что мешает сочетать и то и другое?
__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!
Отправлено XaeroX 15-02-2020 в 11:54:
Цитата:
Дядя Миша писал: новое свято уверено, что всё можно распараллелить, а сами алогоритмы могут быть сколь угодно неоптимальные, главное - раскидать по ядрам.
Впервые слышу такое мнение. Ни в одной нормальной фирме на код-ревью не пропустят квадратичный алгоритм там, где можно уложиться в линию или нлогн.
Параллелят обычно чтобы меньше нагружать UI-поток. Юзер любит, когда программа отзывчива, а все эти крутящиеся песочные часы желает видеть как можно реже.
Дядя Миша писал: В Унреале-то для динамики тоже LPV используется, просто эпики предпочитают не заострять на этом внимание.
Не используется. "Light Propagation Volumes are a feature in development and not ready for production. " Он даже выключен по умолчанию, нужно конфиг править, чтобы включить.
В твоём же видосе на 27 минуте написано, что нет каскадов, то есть эта хрень не масштабируемая.
Посмотрел демку. Можно подобрать параметры, при которых отдельные места будут выглядеть приемлемо, но при этом все остальные превращаются в тыкву. Есть подозрение, что автор где-то накосячил. Почему, например, отсвет от синего шара разбегается, если увеличивать количество проходов? Оно суммироваться должно по идее. Или это из-за сферических гармоник? Отправлено Дядя Миша 15-02-2020 в 14:01:
Цитата:
FiEctro писал: Что мешает сочетать и то и другое?
Так вопрос был не о сочетании, а о том, что параллельные потоки я непременно должен использовать.
Цитата:
XaeroX писал: Ни в одной нормальной фирме на код-ревью не пропустят квадратичный алгоритм там, где можно уложиться в линию или нлогн.
Ну начинается.
Цитата:
ncuxonaT писал: Не используется. "Light Propagation Volumes are a feature in development and not ready for production. " Он даже выключен по умолчанию, нужно конфиг править, чтобы включить.
В твоём же видосе на 27 минуте написано, что нет каскадов, то есть эта хрень не масштабируемая.
Вообще-то видос 16-го года, а на дворе 20-й. Если ты имеешь дело с UE, то можешь нам рассказать как обстоит ситуация сегодня. И как там вообще реализновано деномическое освещение. Из самого видоса я понял, что SDF используется в качестве ускоряющих структур для трассировки. Ну то есть объект пишут в 3д текстуру и потом по ней выполняется трасса. Это взаместо классических шадов-лодов такая апчхимизация.
Цитата:
ncuxonaT писал: Есть подозрение, что автор где-то накосячил
Да запросто. Я и не говорю, что она идеальная. Я сказал, что вижу потенциал для того, чтобы разобраться с этим. Остальные алгоритмы я не вижу смысла даже рассматривать, они еле-еле ворочаются на своих же тестовых картах.
Цитата:
ncuxonaT писал: Или это из-за сферических гармоник?
гармоники нелинейные же. Ты почитай статью на геймдеве, там даны графики как реальная функция накладывается на производную гармоники и они порой очень сильно не совпадают. Ну да гармоники можно кубемапами заменить, к примеру. И окклюзию подкрепить тестом реальной геометрии. Благо у нас там будут брашы и будет PointContents.
Для моделей, понятное дело, такие вещи нереализуемы.
Добавлено 15-02-2020 в 16:50:
Цитата:
ncuxonaT писал: Можно подобрать параметры, при которых отдельные места будут выглядеть приемлемо
Совсем забыл. Включи propgrid3d 1 - это поможет предотвратить часть утечек.
Добавлено 15-02-2020 в 17:01:
Ну а пока вы тут обсуждаете сложность алгоритмов в нормальных фирмах, я продолжаю работать над компиляторами. После того как было принято решение оставить только динамический свет, сами понимаете, у меня оказались развязаны руки в плане подготовки геометрии к лайтмапам. Поскольку всего этого больше делать не нужно, то и нет смысла хранить параметрические поверхности в карте, их можно сразу превратить в треугольники-стрипы. Што я, собственно и проделал, же.
Теперь этим нашим патчам надо построить клипбрашы. В отличие от моделей с их непредсказуемой топологией, здесь мы можем получить куда больше подсказок. Ну например очень легко задатектировать замкнутый патч, хотя бы одному измерению - это будет труба. Патч, замкнутый по двум измерениям будет уже шар, но Ксерокс сказал, что в Джеке нет такого префаба. Правда сам факт замкнутости еще никоим образом не говорит нам о том, что получившийся патч будет конвексным. Например язык на q3dm1 вполне себе замкнутый, но не конвексный ни разу. Так что надо дополнительно еще проверить на конвексность и соответственно выбрать метод генерации брашей. Идеальный кейс это один колоизационный конвексный браш для одного патча. Чуть более худший - аппроксимация квадами, ну и дефолтный вариант - налепить тонких брашей из треугольников, понятно, что объема в патче так уже не будет, но если патч незамкнутый, то этого и не надо.
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено Crystallize 15-02-2020 в 14:19:
Цитата:
ncuxonaT писал: каша была на формате карт ксаша с настраиваемой плотностью лайтмапы. Лайтбейкер в процессе перехода на рейтрейсинг
А между тем формат с настраиваемой плостностью лайтмапы-это не какое-то экспериментальное недоразумение, и его тоже хорошо бы поддерживать.
Получается на обычной ХЛ та версия не глючила? Ты выкладывал её для скачивания?
Я надеюсь по завершению перехода на рейтрейсинг ты потестишь её вот как раз на громадной карте типа ЧАЭС.
