Это материал, который не попал в книгу по тем или иным причинам. Поднял черновики и немного сократил и упростил, выкинул примеры, а на написание самого текста ушло вечера четыре
В основном gdc, но все интересное обычно платное, много в книгах и блогах разработчиков. Часть материала лежит или лежала в сети, к каким-то материалам был или есть доступ.
Шрейер написал вторую книгу "Нажми Reset" и она ещё мрачнее, и там про закрытие Irrational Games, Visceral, 2K Marin и что происходит с людьми после того как студию закрывают. "Мясорубка игровой индустрии" Уолта Уильямса, про то как большие деньги и большие корпорации выгоняют несогласных из студий. "Повелители DOOM" Дэвида Кушнера про Кармака и Ромеро, классика игровой журналистики о том как студия разрушается изнутри.
"Кодзима гений" и "Хидео Кодзима. Гены гения" пока лежат в закладках
Так написана большая часть «военного» софта, что касается гидроакустики и подводной связи (тут мои данные ограничены 10-м годом). И проблема здесь не в том, что не хотят писать документацию, а специально не пишут, и специально делают кучу мэджик-намберов и левого кода. Это гарантия того, что с проекта тебя не кикнут пока идёт разработка. Более того, это вообще негласная стратегия выживания в небольших командах, которые подвизались чтото делать для гаранта. Чем непонятнее ты пишешь, тем ты ценнее как специалист. Потому что заменить тебя нельзя, переписать с нуля дорого, а сроки... ну кто смотрит на сроки если у вас басфактор 0.5? Я знаю людей, которые до сих пор сидят на одном изделии только потому, что кроме них никто не разберётся, что там внутри творится. И они этим открыто гордятся, мол, вот моя пенсия, написана на С с вкраплениями асма, а то и вовсе на асме. Документация если и есть, то либо устаревшая лет на десять, либо написана так, что без автора её читать бесполезно, потому что половина терминов внутренние, половина отсылок к разговорам в курилке году эдак в 98-м. Когда такой человек уходит, хорошо на пенсию, и хуже если в другую контору , то начинается веселье. Либо проект тихо умирает, либо приходит очередной энтузиаст и несколько лет занимается костылеархеологией вместо разработки. И ничего с этим не сделаешь, потому что система так устроена и пока ты незаменим, то ты при деле, как только всё стало красиво, понятно и задокументировано, ну ты свободен искать новый проект. Вот люди и страхуются как умеют.
А тут все очень интересное начинается, физически память одна, но это не значит что ВСЕ читают из одного места одинаково. У текущего Xbox каждый "читатель" cpu, gpu, декомпрессор, h264 модуль подключен своим каналом к единому мемори контроллеру. Это уже получается больше "звезда", чем шина, но исторически просто консоли более оптимизированы с точки зрения латенси, да и шишки уже все набили и знают чего делать не надо. На стимдек другая проблема, приходится агрессивно сжимать таргет рендер и текстуры чтобы выдавать стабильные 60фпс, но экран маленький и игрок этого попросту не видит. Опять же на всех консолях с единой памятью вылазит другая проблема overhead memory visibilty, на дискретной карточке как было, видяхе данные отправил, сабмит или как там его вызвал и они там сами както варятся, про них можно забыть. А с единой памятью gpu и cpu могут смотреть на одну страницу, и cpu уже положил туда данные, т.е. они там физически изменились, а вот когда их "увидит" gpu теперь полностью зависит от протокола когерентности кешей. И получается что если ты хочешь быть уверен что gpu сразу увидит эти данные, то приходится либо флашить кеш, либо использовать когерентные области, которые гпу/цпу видят одинаково, что сильно дороже обычной аллокации. Как обычно бесплатный сыр бывает только мышке ловкой, так что unified memory никак не отменяет необходимости думать о доступе к памяти, просто меняет точку где надо думать.
Это пример, он очень простой и очень явный. Так бывает в 0.00001% багов. Но покопайтесь в кодовой базе проекта старше хотя бы пяти лет и там такого неявного добра навалом с горочкой, просто оно более менее оперативно правится. А если не правится, да фиг с ним, не мешает же.
В далёком 2003 это емнип были предвестники ECS, на объект вешались флаги по которым из разных контейнеров они разбирались по разным системам. Второй это flat-driven сцена, где все объекты лежат в одном или нескольких массивах, считайте это инвертнутыми флагами. Spatial Structuring - это тоже фактически обычный массив, но объекты выбираются кластерами (квадро дерево, октодерево) внутри уже отдельные сортировки. Было еще пару лекций по render graph, не путать со scene graph, когда мы описываем не связь родитель-ребенок, а зависимость машина-колеса. Tile-based - рендер разбивается на мелкие задачи, каждая из которых заполняет кадр независимыми данными (подход в Doom3) и некоторые игры Sony.
По опыту на батарейку смотрят в самую последнюю очередь (я про игры), если вашей батарейки хватает на 15 минут игры (примерно столько сейчас длится одна сессия), то никто даже не будет про это думать.
Процессор при branch prediction спекулятивно читает данные ещё до разрешения условия, но результат спекулятивного load при page fault не коммитится в retired состояние и исключение откладывается до момента, когда ветка "станет настоящей", что не противоречит обычному исполнению, неважно прочитали вы нулл из обычной ветки или спекулятивной. Но есть другой нюанс, что компилятор может использовать CMOVcc только если "доказал" что оба оберанда валидны
Ну обычно мы тут в игрушки играем :) И новомодные E-коры ведут себя крайне коварно начиная тротлить в самый неподходящий момент, если вы про это. Поэтому основные потоки все забинжены на P-ядра, а на E-отдается всякая мелочь, вроде подгрузки текстур, распаковки банков и т.д. На консолях можно выставлять желаемую частоту ядра, если очень хочется, но я таких изысков пока не встречал. Задается максимум для двух первых ядер, а остальные под ОС живут.
cmp keys[i], target
jne skip
mov result, values[i]
сделав обычное ветвление, это тоже зависит от включенных оптимизаций, целевой архитектуры,вероятности ветки по собранной эвристике истоимости операций в этом месте. А еще это зависит от данных, и если VALUES[i] требует загрузки из памяти, то предпочитаетс JNE именно потому что CMOV в этом случае всё равно должен загрузить значение до выполнения, и латенси памяти попадает в хотпас независимо от условия. То есть CMOV с load-зависимостью иногда будет хуже, чем ветвление и компилятор это знает. CMOV условно перемещает значение из источника в регистр, но источник должен быть УЖЕ готов до выполнения, сам CMOV не может условно отменить уже начатую загрузку из памяти, а только условно записывает результат.
Это материал, который не попал в книгу по тем или иным причинам. Поднял черновики и немного сократил и упростил, выкинул примеры, а на написание самого текста ушло вечера четыре
Сделаю. Хорошая идея
В основном gdc, но все интересное обычно платное, много в книгах и блогах разработчиков. Часть материала лежит или лежала в сети, к каким-то материалам был или есть доступ.
чуть выше список книг есть, там и про инвесторов, и про рынок и про все остальное хорошо написано.
Шрейер написал вторую книгу "Нажми Reset" и она ещё мрачнее, и там про закрытие Irrational Games, Visceral, 2K Marin и что происходит с людьми после того как студию закрывают.
"Мясорубка игровой индустрии" Уолта Уильямса, про то как большие деньги и большие корпорации выгоняют несогласных из студий.
"Повелители DOOM" Дэвида Кушнера про Кармака и Ромеро, классика игровой журналистики о том как студия разрушается изнутри.
"Кодзима гений" и "Хидео Кодзима. Гены гения" пока лежат в закладках
Так написана большая часть «военного» софта, что касается гидроакустики и подводной связи (тут мои данные ограничены 10-м годом). И проблема здесь не в том, что не хотят писать документацию, а специально не пишут, и специально делают кучу мэджик-намберов и левого кода. Это гарантия того, что с проекта тебя не кикнут пока идёт разработка. Более того, это вообще негласная стратегия выживания в небольших командах, которые подвизались чтото делать для гаранта. Чем непонятнее ты пишешь, тем ты ценнее как специалист. Потому что заменить тебя нельзя, переписать с нуля дорого, а сроки... ну кто смотрит на сроки если у вас басфактор 0.5? Я знаю людей, которые до сих пор сидят на одном изделии только потому, что кроме них никто не разберётся, что там внутри творится. И они этим открыто гордятся, мол, вот моя пенсия, написана на С с вкраплениями асма, а то и вовсе на асме. Документация если и есть, то либо устаревшая лет на десять, либо написана так, что без автора её читать бесполезно, потому что половина терминов внутренние, половина отсылок к разговорам в курилке году эдак в 98-м. Когда такой человек уходит, хорошо на пенсию, и хуже если в другую контору , то начинается веселье. Либо проект тихо умирает, либо приходит очередной энтузиаст и несколько лет занимается костылеархеологией вместо разработки. И ничего с этим не сделаешь, потому что система так устроена и пока ты незаменим, то ты при деле, как только всё стало красиво, понятно и задокументировано, ну ты свободен искать новый проект. Вот люди и страхуются как умеют.
Он безусловно человек уважаемый, но нет, это не первоисточник. Но за ссылку спасибо, прочитал с удовольствием.
Спасибо.
угу, вы правы без мапера там только 32кб. Емнип для хомбрю массово использовали MMC3, который позволял как раз адресовать 512кб. Сейчас поправлю.
Интересно, расскажето поподробнее? просто с PSP никогда не сталкивался вообще. Более-менее близко с консолями работаю только от третьей плойки
А тут все очень интересное начинается, физически память одна, но это не значит что ВСЕ читают из одного места одинаково. У текущего Xbox каждый "читатель" cpu, gpu, декомпрессор, h264 модуль подключен своим каналом к единому мемори контроллеру. Это уже получается больше "звезда", чем шина, но исторически просто консоли более оптимизированы с точки зрения латенси, да и шишки уже все набили и знают чего делать не надо.
На стимдек другая проблема, приходится агрессивно сжимать таргет рендер и текстуры чтобы выдавать стабильные 60фпс, но экран маленький и игрок этого попросту не видит.
Опять же на всех консолях с единой памятью вылазит другая проблема overhead memory visibilty, на дискретной карточке как было, видяхе данные отправил, сабмит или как там его вызвал и они там сами както варятся, про них можно забыть.
А с единой памятью gpu и cpu могут смотреть на одну страницу, и cpu уже положил туда данные, т.е. они там физически изменились, а вот когда их "увидит" gpu теперь полностью зависит от протокола когерентности кешей. И получается что если ты хочешь быть уверен что gpu сразу увидит эти данные, то приходится либо флашить кеш, либо использовать когерентные области, которые гпу/цпу видят одинаково, что сильно дороже обычной аллокации.
Как обычно бесплатный сыр бывает только мышке ловкой, так что unified memory никак не отменяет необходимости думать о доступе к памяти, просто меняет точку где надо думать.
Это пример, он очень простой и очень явный. Так бывает в 0.00001% багов. Но покопайтесь в кодовой базе проекта старше хотя бы пяти лет и там такого неявного добра навалом с горочкой, просто оно более менее оперативно правится. А если не правится, да фиг с ним, не мешает же.
В далёком 2003 это емнип были предвестники ECS, на объект вешались флаги по которым из разных контейнеров они разбирались по разным системам. Второй это flat-driven сцена, где все объекты лежат в одном или нескольких массивах, считайте это инвертнутыми флагами. Spatial Structuring - это тоже фактически обычный массив, но объекты выбираются кластерами (квадро дерево, октодерево) внутри уже отдельные сортировки. Было еще пару лекций по render graph, не путать со scene graph, когда мы описываем не связь родитель-ребенок, а зависимость машина-колеса. Tile-based - рендер разбивается на мелкие задачи, каждая из которых заполняет кадр независимыми данными (подход в Doom3) и некоторые игры Sony.
Может еще чтото есть, но я забыл
Нужно, очень.
По опыту на батарейку смотрят в самую последнюю очередь (я про игры), если вашей батарейки хватает на 15 минут игры (примерно столько сейчас длится одна сессия), то никто даже не будет про это думать.
Когда у вас на E-core частота скачет от 100Мгц до 2Ггц вас мало что спасет, поэтому туда только таски, которым пофиг на задержки
Процессор при branch prediction спекулятивно читает данные ещё до разрешения условия, но результат спекулятивного load при page fault не коммитится в retired состояние и исключение откладывается до момента, когда ветка "станет настоящей", что не противоречит обычному исполнению, неважно прочитали вы нулл из обычной ветки или спекулятивной.
Но есть другой нюанс, что компилятор может использовать CMOVcc только если "доказал" что оба оберанда валидны
Ну обычно мы тут в игрушки играем :) И новомодные E-коры ведут себя крайне коварно начиная тротлить в самый неподходящий момент, если вы про это. Поэтому основные потоки все забинжены на P-ядра, а на E-отдается всякая мелочь, вроде подгрузки текстур, распаковки банков и т.д. На консолях можно выставлять желаемую частоту ядра, если очень хочется, но я таких изысков пока не встречал. Задается максимум для двух первых ядер, а остальные под ОС живут.
Компилятор может превратить это в CMOV
Но это не гарантия и может сделать так
сделав обычное ветвление, это тоже зависит от включенных оптимизаций, целевой архитектуры, вероятности ветки по собранной эвристике и стоимости операций в этом месте. А еще это зависит от данных, и если VALUES[i] требует загрузки из памяти, то предпочитаетс JNE именно потому что CMOV в этом случае всё равно должен загрузить значение до выполнения, и латенси памяти попадает в хотпас независимо от условия. То есть CMOV с load-зависимостью иногда будет хуже, чем ветвление и компилятор это знает.
CMOV условно перемещает значение из источника в регистр, но источник должен быть УЖЕ готов до выполнения, сам CMOV не может условно отменить уже начатую загрузку из памяти, а только условно записывает результат.
Мы не властны над легаси