Вперёд в п(р)ошлое. Geforce FX. The Dawn of War

в 23:30, , рубрики: 3dfx, ati, Nvidia, Видеокарты, игры, старое железо, метки:

Со дня своего основания в Microsoft умели две самые важные вещи в жизни: вовремя проанализировать что-то чужое и сделать на этом какие-то свои деньги. Во многом именно благодаря Microsoft как главному генератору самых максималистских идей вся IT-индустрия шла (и до сих пор идёт) выгодными прежде всего самому Microsoft путями развития. Результатом реализации множества таких идей стало не только банкротство многих гигантов IT-индустрии, но и стремительная всеобщая унификация. Все компоненты в PC от железа до софта становились всё более универсальными и похожими, теряя возможности выгодно отличаться. И вот, в 2002 году, когда Microsoft в очередной раз приложила свои шаловливые монополистические ручонки к 3D-индустрии, по производителям 3D-чипов громовой волной раскатилась спецификация DirectX9…

И как все мы хорошо помним :) уже следующий 2003 год ознаменовал приход киношной графики на PC. Ну да, ведь так всё и было: WinXP, игры на DVD, требующие установить DirectX9, и… одинаковые видеокарты с какими-то там шейдерами. Условно можно сказать, что спецификация DX9 должна была положить конец различиям результатов рендеринга одного и того же изображения на картах разных производителей. Тем не менее, даже эта спецификация не смогла тогда окончательно обуздать NVIDIA. И правильно, иначе зачем NVIDIA было вкладывать во что-то перспективное деньги?

И вот тут мы подходим к тому, что побудило меня в очередной раз ткнуть труп палкой и таки написать этот обзор.

Возможно, вы тоже не знали:


David Kirk adds a bit of back-story as to how this technology was brought into GeForce FX:

When we did the acquisition of 3dfx, NV30 was underway, and there was a project [code-named Fusion] at 3dfx underway. The teams merged, and the projects were merged. We had each team switch to understand and present the other’s architecture and then advocate it. We then picked and chose the best parts from both.


www.extremetech.com/computing/52560-inside-the-geforcefx-architecture/6

К моменту этого высказывания GeForce FX уже был знатным долгостроем и сильно опаздывал на рынок. Можно сказать, NVIDIA однажды удалось избежать того самого дня,

когда умолкнут все песни
Вперёд в п(р)ошлое. Geforce FX. The Dawn of War - 1

Краем глаза

Вперёд в п(р)ошлое. Geforce FX. The Dawn of War - 2

Действительно… Первое, что бросалось в край нашего глаза при виде легендарного дастбастера (GeForce FX 5800) — это габариты.

image

Вот это двухслотовое чудовище рядом с Radeon 9800:

image

Чтобы понять причину столь неординарного решения нам придётся посмотреть поближе…

Ближе к сердцу

image

GeForce FX хоть и не был первым суперскалярным GPU в мире, но, без сомнения, был самым сложным суперскалярным GPU своего времени и (оставался таковым ещё долгое время). Настолько сложным, что точная информация о, казалось бы, простейших составляющих его внутренней архитектуры до сих пор отсутствует. Как следствие, его выход на рынок переносился… переносился… И вот, наконец, он явился, долгожданный.

NV30: The Dawn of CineFX

Вперёд в п(р)ошлое. Geforce FX. The Dawn of War - 6

Если быть точным, эта самая сложная архитектурная часть NV30 называлась CineFX (1.0) Engine. Маркетологи NVIDIA тогда решили, что это будет звучать привлекательнее nfiniteFX III Engine. Спорно, но факт.

CineFX (кто не понел: Cinematic Effects) — во многом заслуга инженеров 3dfx (вспомним нашумевший T-Buffer). Несёт в себе всё необходимое для рендеринга кинематографических спец-эффектов у вас дома.
Вы спросите: что же нужно начинающему кинематографу? Всё просто. Начинающему кинематографу потребуется только самое необходимое: 128-битная точность представления данных для работы с плавающей точкой и полностью программируемый графический конвеер с поддержкой Shader Model 2.0, позволяющий наложить до 16 текстур. Заинтригованы? Да, этого есть здесь:

  • 64/128 bit depth rendering — the Dawn of Cinematic Computing
    В мире труколора такое маркетинговое заявление звучало бы несколько странно. Всем несведующим сообщу лишь, что с этого момента тусклый мир труколора остался в прошлом. И, если вы до сих пор думаете, что все новые игры рендерят изображение в 32-битном цвете… Вы, конечно, правы… Лишь отчасти. Потому что, на самом деле, многие (если не все) «части» в играх теперь просчитываются на пути к вашему монитору с сильно большей точностью, получившей название Floating Point Color Accuracy.

    Разумеется, я не поверил. И, как оказалось, не поверил не я один, потому что в сети нашлась даже такая нужная программулина ShaderMark 2.1, которая, как следует из названия, была создана именно для этого самого: тестирования производительности шейдерных блоков gpu. И вот, представьте себе, действительно есть разница не только в скорости, но и в цвете с разными пресетами точности! Качество при конвертации шотов в gif, конечно, упало, но менее не тем «исправленному верить»:

    Вперёд в п(р)ошлое. Geforce FX. The Dawn of War - 7

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

    Кому лень читать, я покажу
    Вперёд в п(р)ошлое. Geforce FX. The Dawn of War - 8

    На анимации выше вы можете наглядно наблюдать эффект, который называется Tone mapping. Тут всё как в жизни: когда многоуважаемый Мистер Фримен смотрит прямо на источник света (солнце), оно кажется ему очень ярким, а всё окружающее от этого кажется сильно темнее солнца. Когда же многоуважаемый Мистер Фримен соизволит неспеша отвернуть голову (в сторону), его глаза постепенно привыкают к новому балансу яркости: теперь уже солнце находится несколько сбоку и не кажется таким уж ярким, а всё остальное становится ярче.

    Кстати, что ещё важно отметить: благодаря тому, что теперь весь графический конвеер в GeForce FX работает как минимум с точностью FP16, даже старые игрушки (где активно применялся мультитекстуринг и прочие техники, требующие операции смешивания цветов пикселей в кадре) будут выглядеть качественнее.

  • Shader Model 2.0+
    Да-да, это те самые пресловутые «шейдеры», благодаря которым вам в своё время наверняка приходилось идти в магазин менять свою видеокарту или только что купленную игру. Для начала давайте определимся: эти самые шейдеры… да кому они вообще нужны?
    Ответ на этот вопрос в общем случае будет зависеть от контекста, в котором он задаётся, т. к. термин «шейдеры» вообще многозначен. По обыкновению для начала предлагается определиться с тем, для чего они нужны. То есть, если высказывание «шейдеры — это программы для затенения» для вас целиком олицетворяет шейдеры, настоятельно рекомендую вам прочесть хотя бы вот это:

    очень упрощённое представление
    До того, как мы с вами двинемся по конвееру, вот вам его алгоритм:

    image

    Даже, если вы нэ бельмэ, полагаю, уже догадались, что есть два варианта обработки геометрии сцены и её прорисовки: с шейдерами и без… Окей, а теперь немного истории.

    Что было до шейдеров?
    На заре развития 3D-рендеринга было принято решение жёстко стандартизировать 3D-пайплайн (он же — "Графический конвеер"). Таким образом, видеокарты можно было рассматривать как «pixel-blaster'ы», потому как всё, что они тогда делали — это ели команды драйвера и выплёвывали вам на экран пиксели. В результате разработчики игр (гейм-девелоперы) были жёстко ограничены лишь теми возможностями рендеринга, которые предоставлял им тот или иной видеочип.

    Скажем, наглядно ситуацию можно было посмотреть в Unreal или в Quake II, в каждом из которых есть на выбор несколько API (API — программный интерфейс для «рисования» видеокартой).

    Так вот, например, в Quake II при выборе API OpenGL использовались аппаратные 3D-возможности видеочипа. Таким образом, в этом случае видеочип самостоятельно будет накладывать текстуры на объекты и рассчитывать спецэффекты. И всё в игре было красиво, вот только вода выглядела похожей на стекло:

    Вперёд в п(р)ошлое. Geforce FX. The Dawn of War - 10

    John Carmack предлагал вам альтернативный вариант: API Software, который использовал центральный процессор (CPU) вместо видеокарты для расчёта эффектов и наложения текстур. В этом случае в игре можно было реализовать абсолютно произвольные спецэффекты, а видеокарта только рисовала уже готовые пиксели. Красок особенно не видать (ведь затратно!), но вот вода была подвижной (имитация волн). Обратите внимание на искажение дна или стены на горизонте:

    Вперёд в п(р)ошлое. Geforce FX. The Dawn of War - 11

    Почему? Всё дело было в стандартизации графического конвеера видеокарт. В каждый конкретный видеочип был жёстко вшит определённый набор фич, например, спец-эффектов. Точно такой эффект подвижных волн было невозможно получить, используя аппаратный 3D-рендеринг (возможно, можно было получить схожий, но не такой же).

    Чего ещё не было до шейдеров?
    Абсолютной власти (над конвеером)! В те годы использовать, скажем, эффект bump-mapping (рельефное текстурирование) чипа вы могли, но чип сделает его только по вершинам фигуры. И этот алгоритм изменению не подлежит! То есть, вы получите только то, что чип умеет делать.

    Рассмотрим на примере любимого доната и DX6-видеокарты Voodoo, которая не умеет шейдеры:

    Вот донат, состоящий из 20 000 полигонов:

    Вперёд в п(р)ошлое. Geforce FX. The Dawn of War - 12

    Вот Voodoo набросал на него текстуру:

    Вперёд в п(р)ошлое. Geforce FX. The Dawn of War - 13

    А вот, что будет, если Voodoo наложит на него эффект рельефного текстурирования:

    Вперёд в п(р)ошлое. Geforce FX. The Dawn of War - 14

    Красиво? Это потому, что полигонов, из которых сделан наш бублик, достаточно много. Но это сильно уменьшает скорость прорисовки (FPS). А чего мы хотим, так это прежде всего её увеличить. Чтож, придётся уменьшить количество полигонов до 1352:

    Вперёд в п(р)ошлое. Geforce FX. The Dawn of War - 15

    Отлично, вот он — наш свежеиспечённый бублик:

    Вперёд в п(р)ошлое. Geforce FX. The Dawn of War - 16

    Теперь вуду наложит ему рельеф:

    Вперёд в п(р)ошлое. Geforce FX. The Dawn of War - 17

    Видите, как рельеф «поехал» по ближнему к вам краю? Т.е. с уменьшением количества полигонов FPS растёт, но рельефное текстурирование на вуду начинает выглядеть хуже. Потому что применяется оно по вершинам полигонов, которых здесь сильно меньше.

    Так как же нам получить более приемлемый результат, не увеличивая количество вершин? Для этого нам нужно применить bump-mapping по-пиксельно. На данной видеокарте это невозможно, так как она не умеет шейдеры. Конечно, вы всё ещё вольны сделать по-пиксельный bump-mapping программным путём через CPU (не используя аппаратные возможности видеочипа). И это будет ой как медленно, знаете…

    Всё это и привело к тому, что вскоре в 3D-индустрии придумали шейдеры и постепенно начали внедрять их в графический конвеер.

    Что именно дают нам шейдеры?
    Как вы, верно, уже догадались, шейдеры позволяют нам получить некоторый контроль над тем, как именно видеочип применит тот или иной спец-эффект. Если быть точным, то стало возможным даже применять абсолютно любые спец-эффекты силами видеочипа, а не CPU. Таким образом, шейдеры потенциально дают нам возможность рендерить точно те эффекты, которые мы хотим получить. А также многое другое, но об этом здесь не будем.

    Какие они — эти шейдеры?
    Существует множество версий и типов этих самых шейдеров. Версии обычно характеризуются как Shader Model x.x (например, SM2.0), а самые распространённые типы шейдеров — это пиксельные, вершинные и геометрические. Очевидно, чем выше поддерживаемая версия SM, тем более абсолютную власть чип нам предоставит. А оперировать этой властью вы сможете с помощью программирования.

    То есть, с точки зрения гейм-девелопера, шейдер — это некий написанный им программный код, объясняющий видеочипу, что ему нужно будет сделать, например, с конкретным полигоном в сцене. Вдобавок, шейдерные программы могут вычислять (и очень часто это делают в играх) какие либо сложные математическе уравнения с целью дальнейшего использования полученных значений. То есть совершенно необязательно, что каждая шейдерная программа что-нибудь вообще «затенит».

    Как бы там ни было, шейдеры прочно вошли в нашу жизнь и начали всё больше развиваться. В частности в NV30 поддержка Shader Model 2.0 (далее SM2.0) — это обобщённый термин, означающий, что NV30 теперь поддерживает спецификации Pixel & Vertex Shaders 2.0. Но NVIDIA на этом не остановились и тот самый "плюс" в названии был призван прибавить свободы гейм-девелоперам за счёт расширения спецификации DX9 до полигонов возможностей.

    Всё это очень интересно… скажете вы, но как же вообще эти шейдеры использовать? Ну а тут всё ещё интереснее :)

    С появлением SM2.0 для обоих видов шейдеров (пиксельные и вершинные) стало возможным писать достаточно сложные программы с условиями и циклами. Вопрос только в том, на каком языке вы предпочитали это делать. В эпоху SM1.x выбор был невелик и писали в основном на ARB assembly или на DirectX ASM, которые, как становится ясно даже из названий, являются низкоуровневыми и достаточно сложными в освоении и применении. С приходом же SM2.0 появилось как минимум три C-подобных языка высокого уровня, писать шейдерные программы на которых значительно проще:

    • OpenGL Architecture Review Board разработали GLSL;
    • NVIDIA разработала C for Graphics (причём не только для себя);
    • Microsoft разработала HLSL.

    Но какой из языков шейдеров предпочесть и что от этого зависит? С такими нюансами, увы я не познакомлю. Давайте лучше вспомним о реализации этих самых шейдеров в NV30.

Реализация

Большинство мирных дискуссий о производительности того или иного девайса чаще всего так или иначе сваливается в холивар на тему «Что же важнее: Железо или Софт?» На самом деле, как бы многим не хотелось уйти от реальности, но железо без софта — оно железо и есть :)

На момент выхода GeForce FX 5800 (NV30) на дворе уже более квартала забавлялся конкурент в лице Radeon 9700 Pro (ATI R300). Это был февраль 2003 года. Сегодня такое промедление смерти подобно, и вот именно поэтому можно смело назвать 2003 год не иначе, как годом NVIDIA.

Было примерно так: Приходит NV30 на биржу труда, а там в списке вакансий ни одной со знанием DirectX9 и нет. Получается, что NV30 как бы никуда и не опаздывал вроде… И правда, первые сколько-нибудь известные мощные игры под DX9 (такие как DooM3, HL2, NFS Underground 2) появились лишь в 2004 году. Долгожданный Сталкер так и то аж в 2007 году.

Это я всё к тому, что сравнивать производительность карт обзорщикам в 2003 году было просто не в чем. Буду откровенным: при написании статьи я долго анализировал картину, но так и не встретил ни единого обзора NV30 с живыми тестами DX9. В основном возможности DX9 тестировали в 3DMark

И с этим связана одна кулстори
Если кто помнит, это началось ещё с GeForce 4:

image

Суть:


NVIDIA debuted a new campaign to motivate developers to optimize their titles for NVIDIA hardware at the Game Developers Conference (GDC) in 2002. In exchange for prominently displaying the NVIDIA logo on the outside of the game packaging, NVIDIA offered free access to a state-of-the-art test lab in Eastern Europe, that tested against 500 different PC configurations for compatibility. Developers also had extensive access to NVIDIA engineers, who helped produce code optimized for NVIDIA products


en.wikipedia.org/wiki/GeForce_FX_series

В итоге всё это, как и любая другая благотворительность, породило увлекательную драму… Вкратце, если на NV30 свернуть с рельс в 3DMark 2003 (нужна девелоперская версия), можно было запросто увидеть результаты таких оптимизаций:

Вперёд в п(р)ошлое. Geforce FX. The Dawn of War - 19

Можно предположить, что оптимизации заключались в том, чтобы не рисовать то, чего не должно быть видно на рельсах. А можно предположить, что всё дело в плохо отлаженной оптимизации исполнения шейдерного кода в драйверах, о которой ниже поговорим тоже.

… Кстати ATI тоже была замечена за подобными оптимизациями в то же время. Тем не менее, всё вышеназванное ещё можно было назвать таковыми, если сравнивать с тем, с чего вообще всё начиналось:

ATI Quake III optimizations
Вперёд в п(р)ошлое. Geforce FX. The Dawn of War - 20

Как следствие, в те годы очень часто можно было слышать что-то навроде:


NV30's apparent advantages in pixel processing power and precision might make it better suited for a render farm, which is great for Quantum3D, but these abilities may mean next to nothing to gamers. Developers tend to target their games for entire generations of hardware, and it's hard to imagine many next-gen games working well on the NV30 but failing on R300 for want of more operations per pass or 128-bit pixel shaders.

techreport.com/review/3930/radeon-9700-and-nv30-technology-explored/6

И, хотя тот же John Carmack запросто поспорил бы с этим утверждением, в любом случае, это наглядное подтверждение того, что железо — ничто без софта. Более того, на деле выяснилось, что производительность шейдеров у NV30 была катастрофически зависима в первую очередь от того, как написан код шейдерных программ (важна даже последовательность инструкций). Вот тогда-то NVIDIA и стала всячески продвигать оптимизацию кода шейдеров под NV30.
Зачем это было нужно? А затем, что у NV30 с реализацией шейдеров не всё так просто:


Its weak performance in processing Shader Model 2 programs is caused by several factors. The NV3x design has less overall parallelism and calculation throughput than its competitors. It is more difficult, compared to GeForce 6 and ATI Radeon R3x0, to achieve high efficiency with the architecture due to architectural weaknesses and a resulting heavy reliance on optimized pixel shader code. While the architecture was compliant overall with the DirectX 9 specification, it was optimized for performance with 16-bit shader code, which is less than the 24-bit minimum that the standard requires. When 32-bit shader code is used, the architecture's performance is severely hampered. Proper instruction ordering and instruction composition of shader code is critical for making the most of the available computational resources.


en.wikipedia.org/wiki/GeForce_FX_series

То есть, архитектура NV30 не давала ему полностью раскрыть себя, используя код стандарта SM2.0. Но вот, если немного перетасовать инструкции перед выполнением, может быть, даже заменить одну на другую (привет, 3DMark 2003)… Но в NVIDIA понимали: гораздо эффективнее бороться с причиной, а не с последствиями.

Take Two. NV35: The Dusk

Это не было новым архитектурным решением, но очень грамотным усовершенствованием. Инженеры NVIDIA так фанатично исправляли свои ошибки, что даже попутно наследили в истории развития шейдеров официально задокументированной Shader Model 2.0a (SM2.0a), которая так и была названа — NVIDIA GeForce FX/PCX-optimized model, DirectX 9.0a. Панацеей NV35, конечно, не стал, но его запомнили:

Вперёд в п(р)ошлое. Geforce FX. The Dawn of War - 21

Впрочем, в силу той самой чрезвычайной сложности микроархитектуры NV30 некоторые весьма любопытные нюансы в NV35 остались без изменений. Поэтому в его спецификациях обзорщики часто указывали что-то навроде:

Vertex pipeline design: FP Array
Pixel pipeline design: 4x2

Вот это — и есть те самые «простейшие составляющие», о которых я упоминал ещё в начале статьи. Да, терминология несколько странная, но это ещё полбеды. На самом деле таким образом маркетологи просто пытались донести до нас простейшие вещи: сколько же вершинных и пиксельных конвееров (шейдерных блоков, если хотите) есть у чипа.

Как и у любого нормального человека, прочитавшего такую спецификацию, моя нормальная реакция: ну так и сколько же их? Так вот вся штука в том, что этого никто не знает :) Казалось бы, самые ординарные характеристики графического чипа, по которым сразу можно было бы сделать какие-то выводы о производительности?

Ну да, вон у того же ATI R300 всё прозрачно: 8 пиксельных и 4 вершинных шейдера… Ок, можно было бы запустить тот же GPU-Z и он, следуя устоявшейся терминологии, сказал бы вам, что у NV35 против этого имеется всего 4 пиксельных и 3 вершинных шейдера. Но это было бы не совсем точно, потому что на заре киноигр у NVIDIA был свой

альтернативный взгляд на шейдеры
Когда я решил попробовать разобраться, начали всплывать просто умопомрачительные вещи. Но так как официально это нигде не подтверждается, я сразу оговорюсь здесь, что всё нижеизложенное — просто убедительная гипотеза.

Начнём с Vertex pipeline — конвеера с вершинными блоками.

В спецификации выше видимо неслучайно упоминается термин "design", потому что:


Whereas the GeForce4 had two parallel vertex shader units, the GeForce FX has a single vertex shader pipeline that has a massively parallel array of floating point processors

www.anandtech.com/show/1034/3

Да, похоже на то, что чип (NV35) был спроектирован таким образом, чтобы максимально эффективно справляться с задачами, распределяя свободные транзисторы в зависимости от востребованности. Т. о., если в NV35 есть три больших отсека с вершинными блоками, то каждый такой отсек можно трансформировать как угодно: можно объединить все силы и задействовать «как бы один мощный вершинный процессор», а можно распараллелить задачи, разделив отсек на несколько блоков. Таким образом, сколько точно будет задействовано вершинных блоков зависит от случая :) Минимальное же их число в NV353. Между прочим, даже випипипендия намекает!


The GeForce FX Series runs vertex shaders in an array


en.wikipedia.org/wiki/List_of_Nvidia_graphics_processing_units#GeForce_FX_.285xxx.29_Series

Pixel pipeline.

Если сведения о Vetrex pipeline по крайней мере оглашались самими NVIDIA, то здесь всё несколько интереснее. Изначально NVIDIA заявляли, что вышедший NV30 имеет 8 пиксельных конвееров, и у каждого из них по одному TMU (текстурному блоку). Это и называется "8x1 design" Однако почти сразу же после выхода были проведены интригующие независимые расследования, отмечавшие явное несоответствие реальной скорости заполнения экрана пикселями заявленной в спецификации. Мне несколько удивительно было узнать о подобных расследованиях, но людей можно было понять: ведь больше делать с DX9-картами тогда было нечего…

Так вот, после интриг и расследований всё же выяснилось, что «дизайн» пиксельных конвееров у NV30/NV35 на самом деле 4x2 (4 пиксельных конвеера по 2 TMU на каждом). Всё это сами NVIDIA косвенно подтвердили таким заявлением:


«Geforce FX 5800 and 5800 Ultra run at 8 Pixels per clock for all of the following:

a) z-rendering
b) Stencil operations
c) Texture operations
d) shader operations

For most advanced applications (such as Doom3) most of the time is spent in these modes because of the advanced shadowing techniques that use shadow buffers, stencil testing and next generation shaders that are longer and therefore make apps “shading bound” rather than “color fillrate bound. Only Z+color rendering is calculated at 4 pixels per clock, all other modes (z, stencil, texture, shading) run at 8 pixels per clock. The more advanced the application the less percentage of the total rendering is color, because more time is spent texturing, shading and doing advanced shadowing/lighting»


www.beyond3d.com/content/reviews/10/5

Но даже этого исповедования фанатикам не хватило и последовали скандалы и, как следствие, шокирующие интервью с чистосердечными признаниями:


Beyond3D:
We've seen the official response concerning the pipeline arrangement, and to some extent it would seem that you are attempting to redefine how 'fill-rate' is classified. For instance, you are saying that Z and Stencils operate at 8 per cycle, however both of these are not colour values rendered to the frame buffer (which is how we would normally calculate fill-rate), but are off screen samples that merely contribute to the generation of the final image — if we are to start calculating these as 'pixels' it potentially opens the floodgates to all kinds of samples that could be classed as pure 'fill-rate', such as FSAA samples, which will end up in a whole confusing mess of numbers. Even though we are moving into a more programmable age, don't we still need to stick to some basic fundamental specifications?

Tony Tamasi:
No, we need to make sure that the definitions/specifications that we do use to describe these architectures reflect the capabilities of the architecture as accurately as possible.

Using antiquated definitions to describe modern architectures results in inaccuracies and causes people to make bad conclusions. This issue is amplified for you as a journalist, because you will communicate your conclusion to your readership. This is an opportunity for you to educate your readers on the new metrics for evaluating the latest technologies.

Let's step through some math. At 1600x1200 resolution, there are 2 million pixels on the screen. If we have a 4ppc GPU running at 500MHz, our «fill rate» is 2.0Gp/sec. So, our GPU could draw the screen 1000 times per second if depth complexity is zero (2.0G divided by 2.0M). That is clearly absurd. Nobody wants a simple application that runs at 1000 frames per second (fps.) What they do want is fancier programs that run at 30-100 fps.

So, modern applications render the Z buffer first. Then they render the scene to various 'textures' such as depth maps, shadow maps, stencil buffers, and more. These various maps are heavily biased toward Z and stencil rendering. Then the application does the final rendering pass on the visible pixels only. In fact, these pixels are rendered at a rate that is well below the 'peak' fill rate of the GPU because lots of textures and shading programs are used. In many cases, the final rendering is performed at an average throughput of 1 pixel per clock or less because sophisticated shading algorithms are used. One great example is the paint shader for NVIDIA's Time Machine demo. That shader uses up to 14 textures per pixel.

And, I want to emphasize that what end users care most about is not pixels per clock, but actual game performance. The NV30 GPU is the world's fastest GPU. It delivers better game performance across the board than any other GPU. Tom's Hardware declared «NVDIA takes the crown» and HardOCP observed that NV30 outpaces the competition across a variety of applications and display modes.


www.beyond3d.com/content/reviews/10/24

Так как же так вышло?
Здесь я даже могу предложить вам своё видение вопроса…

В очередной раз разгромив всех конкурентов на рынке, NVIDIA решили подойти к разработке DX9-чипа с размахом, ибо возможности позволяли. Архитектура чипа NV3x должна была стать самой обаятельной и привлекательной революционной и инновационной в истории:

  • NV3x обязательно должен превзойти все требования спецификации DX9, пусть для этого понадобится очень много транзисторов… пусть даже слишком много!
  • NV3x обязательно должен поднять рекордную планку рабочей частоты до 500МГц!
  • Карты на NV3x должены оснащаться памятью DDR2!

На деле архитектурное решение, превзошедшее все требования DX9 и поднявшее планку рабочей частоты до 500 МГц, насобирало аж 125 миллионов транзисторов (по тем временам рекордная планка) в первом своём исполнении. С этой армией деталей нужно было что-то делать: грелась она непомерно. Приняли решение использовать техпроцесс 0.13мкм (новаторский по тем временам), который снизил бы тепловыделение. Однако и этого оказалось недостаточно — пришлось применить для охлаждения пылесос.

Ладно, здесь пофиксили, как быть с памятью? Спецификаций DDR2 тогда ещё официально не было, но Samsung вызвался помочь: любой каприз за ваши деньги! В итоге были изготовлены дорогущие микросхемы DDR2, но вот беда: ширина шины памяти контроллера получилась 128 бит. Чем же это плохо?
Это не очень хорошо, потому что изначально планировалось, что NV3x будет иметь 8 честных пиксельных конвееров, по одному TMU на каждом (8x1). Однако в таком случае возникала бы проблема. Как известно, буфер кадра, в котором хранятся все выводимые пиксели, содержится именно в этой вот памяти видеокарты. Также мы знаем, что размерность типичного выводимого на экран пикселя = 32 бита.
Ежели у нас есть 8 пиксельных конвееров, то мы можем передавать в наш буфер кадра одновременно до 8-ми 32-битных пикселей (=256 bit) за один такт. Беда в том, что для этого нам потребуется пропускная способность шины памяти как минимум равная 256 бит. Но у нас в распоряжении только 128-битная шина памяти, что означает, что для передачи 8-ми 32-битных пикселей по этой шине нам потребуется два такта. Это называется переполнение шины и это потеря мнимых fps.
Как же выйти из положения? Да очень просто: оставить только 4 пиксельных конвеера, но каждому выдать по 2 TMU (4x2). Конечно, не только вам сейчас показалось, что вас где-то обманывают:


Beyond3D:
Our testing concludes that the pipeline arrangement of NV30, certainly for texturing operations, is similar to that of NV25, with two texture units per pipeline — this can even be shown when calculating odd numbers of textures in that they have the same performance drop as even numbers of textures. I also attended the 'Dawn-Till-Dusk' developer even in London and sat in on a number of the presentations in which developers were informed that the second texture comes for free (again, indicating a 2 texture units) and that ddx, ddy works by just looking at the values in there neighbours pixels shader as this is a 2x2 pipeline configuration, which it is unlikely to be if it was a true 8 pipe design (unless it operated as two 2x2 pipelines!!) In what circumstances, if any, can it operate beyond a 4 pipe x 2 textures configuration, bearing in mind that Z and stencils do not require texture sampling (on this instance its 8x0!).

Tony Tamasi:
Not all pixels are textured, so it is inaccurate to say that fill rate requires texturing.

For Z+stencil rendering, NV30 is 8 pixels per clock. This is in fact performed as two 2x2 areas as you mention above.

For texturing, NV30 can have 16 active textures and apply 8 textures per clock to the active pixels. If an object has 4 textures applied to it, then NV30 will render it at 4 pixels per 2 clocks because it takes 2 clock cycles to apply 4 textures to a single pixel.


www.beyond3d.com/content/reviews/10/24

И вот здесь я с NVIDIA согласен, чёрт побери! Нельзя в эпоху шейдеров принимать во внимание тупое окрашивание пикселей, потому что это не есть показатель производительности. Гораздо важнее, сколько текстурных операций за такт успевает чип.

А теперь желающие могут взять в руки (у кого есть) свой Жираф FX, вдумчиво посмотреть на чип и произнести "Всё гениальное — просто!" Мне вся эта история очень напоминает логичного Хэппи Гилмора (Happy Gilmore), который "… единственный снял коньки, чтобы подраться!" :)

image

Как бы там ни было, если главной целью инженеров NVIDIA в те дни было ярко наследить в истории, — без сомнения, им это удалось! Более того, в NV35 появилась ещё одна интересная фишка, аналога которой у конкурентов не было: UltraShadow Technology, о которой, впрочем, позже :) Но давайте прекратим болтать о прекрасном и вернёмся

С небес на землю

К счастью, дастбастера у меня нет… (но поглазеть на музейный экспонат вы всегда можете). К счастью, потому что уши дороже. К тому же стоил он и его усовершенственный брат GeForce FX 5900 несоразмерно кошельку простого человека с простыми потребностями. А для таких людей NVIDIA предлагали варианты GeForce FX 5600 на чипе NV31, но мне и его не досталось.

И вот, волею случая, спустя 12 лет, мне, можно сказать, «втюхали» вот такой офисный огрызочек:

Вперёд в п(р)ошлое. Geforce FX. The Dawn of War - 23

Зато не жужжит!
То есть, помимо урезанного NV31 был выпущен ещё и NV34, который отнюдь не отличался производительностью, а, скорее, был браком NV31.

Вперёд в п(р)ошлое. Geforce FX. The Dawn of War - 24

Теперь кратко о том, чего интересного в NV34 не поместилось :(

Вперёд в п(р)ошлое. Geforce FX. The Dawn of War - 25

  • NV30/NV35 имели 4x2 дизайн пиксельных конвееров, а тут осталось всего 4x1
  • Что интересно, Everest и GPU-Z вам скажут, что Vertex-шейдеров у него 2 штуки, тогда как по википедии вроде бы 1. Вот вам и закрытая архитектура FP Array ;)
  • В NV30/NV35 ввели параноидальное сжатие всего, что только попадало на графический конвеер. Сюда входили не только текстуры, но даже z-buffer и значения цвета каждого пикселя в буфере кадра! Так вот в NV34 этот сложнейший алгоритм lossless-сжатия 4:1 не поместился :)
  • UltraShadow Technology тоже не вошла (GeForce FX 5900 and 5700 models only). Но расстраиваться не стоит, всё покажу ;)
  • Этот экземпляр имеет ширину шины памяти аж 64bit (да, как у старых 2D-видеокарт)

Как видно, не поместилось почти ничего :) Но самое страшное было даже не в этом. Все знают это слово.

Драйвера

Вот здесь сейчас очень многие из вас, должно быть, улыбаются. Это, наверное, была самая эпичная реализация после TNT2.

Если даже вы не помните это:

image

… то уж точно должны вспомнить это:

image

Что и говорить, с приходом DX9 вендоры стали штамповать драйвера с невероятной скоростью, а про WHQL вспоминали только в крайнем случае. Производительность одной и той же DX9-карты могла плясать так динамично, что порой её партнёром могла стать DX8-карта. Так было, например, с GeForce MX 440 (NV18), которому с определённой версии дров запилили эмуляцию аж SM2.0, но позже зарезали обратно. Ибо как-то неприлично получается: NV18 выигрывает у NV34 в шейдерах, которых у неё даже нет…
Вот, например, хорошая статистика популярных траблов с GeForce FX.

И тем не менее, было чем гордиться. Например:

  1. Adaptive Texture Filtering

    К слову сказать, из всего огромного множества обзоров NV30 в 90% при тестировании использовали анизотропную фильтрацию вкупе с трилинейной! Сначала это показалось мне какой-то массовой эпидемией. Ну, то есть, я понимаю, что в виду столь долгих ожиданий хотелось выжать из карты всё до последней капли, но о практическом смысле тоже надо было как-то подумать?

    Однако всё оказалось намного интереснее. Копнув глубже, можно было уяснить себе две вещи: есть общепринятые стандарты фильтрации текстур, а есть такие «адаптивные» вещи, как, например, Intellisample. Поскольку в данном случае алгоритм той или иной фильтрации задаётся драйвером, то тут у NVIDIA был ещё один полигон возможностей. Производительность и качество фильтрации текстур различались практически с каждой новой версией дров…

    Что интереснее, во всех обзорах тех дней часто можно было найти сравнение алгоритмов работы так жадной до fps анизотропки у ATI и у NVIDIA. Так вот ATI ещё более преуспели на данном поприще: они не только действительно использовали трилинейную фильтрацию вкупе с анизотропной (не поверите: ради экономии!), но даже умудрились придумать гибридный термин: brilinear filtration.

    И в общем-то те же ATI были правы: если не видно разницы,- зачем платить больше? Понятно, если у меня бюджетная карта, я буду рад дополнительным 10 кадрам без видимой потери качества. Однако этот замечательный принцип почему-то распространялся и на топовые чипы (NV30 / R300), тогда как вот здесь-то нам хотелось бы получить лучшую в мире картинку. «Да, все эти оптимизации должны быть отключаемыми» — твердили тогда обозреватели. Вендоры же были непреклонны и с каждой версией алгоритмы становились всё бесплатнее и оптимизированнее. В ответ на такое наплевательское отношение к покупателям дорогих карт был выдвинут такой транспарант:

    image

    "As long as this is achieved, there is no «right» or «wrong» way to implement the filtering..."

    Конечно же, все драйвера тестировать я не стал, ибо нахожу это абсолютно бессмысленным занятием. Хотя бы потому, что в последних в мире 175.19 для GeForce FX всё честно:

    Вперёд в п(р)ошлое. Geforce FX. The Dawn of War - 29

  2. Поддерживаемые API (и немного о новых способах оптимизаций под конкретные видеочипы).

    С тех пор, как все проприетарные закрытые API (за исключением Direct3D) приказали долго жить в пользу открытых API, видеокарты должны были постепенно становиться более универсальными. Производители видеочипов обязались отныне в первую очередь поддерживать общеизвестные API и уметь полноценно работать с ними. Одной из первых серьёзный шаг в направлении стандартизации сделала Microsoft. Повторюсь:

    спецификация DX9 должна была положить конец различиям результатов рендеринга одного и того же изображения на картах разных производителей

    Здорово, но на самом деле нас по-прежнему ждали сюрпризы. Их можно было разделить на несколько типов:

    • Собственно-разработанные расширения OpenGL.
      Например (выделено):

      Вперёд в п(р)ошлое. Geforce FX. The Dawn of War - 30

      Конечно, это можно считать оптимизацией под свою продукцию лишь наполовину. Ведь расширение зачастую хоть и работает только на картах этого производителя, но является частью спецификации. Ничто не мешает конкурентам реализовать то же самое в следующей серии :)

    • Game Codepaths. Кодпас в игре применительно к видеочипу — это отдельный код для поддержки работы именно с этим чипом для обеспечения его максимальной производительности в данной игре. По сути это так или иначе существовало всегда, но наиболее полно раскрылось теперь.


      Некоторые компании, такие как Valve, отказались от Shader Model 2.x на NV30 и использовали Shader Model 1.х для них в Half-Life 2.


      ru.wikipedia.org/wiki/GeForce_FX

      Это, пожалуй, самый яркий пример, но были и другие. Даже сегодня не утихают такие многочисленные споры о производительности Half-Life 2 на разных видеокартах. Так что, если вы тоже уверены, что играли на FX 5600 (или даже на MX 440) в тот же самый Half-Life 2, что и я на RV350, — настоятельно рекомендую ознакомиться.

    • Следствие портирования с приставки.
      Отличный пример — Tom Clancy’s Splinter Cell:


      Q: Why does Splinter Cell have a special mode for NV2x/NV3x graphic chips?

      A: Splinter Cell was originally developed on XBOXTM. Features only available on NV2x chips were used and it was decided to port them to the PC version even if these chips would be the only one able to support them. Considering the lighting system of XBOXTM was well validated, it was easy to keep that system intact.


      Patchinfo.rtf (from patch 1.3)

Прикладной уровень

Вперёд в п(р)ошлое. Geforce FX. The Dawn of War - 31

В этот раз я не буду измерять производительность и показывать вам скучные шоты с мониторингом fps. Это совсем не то, что меня интересует в этом поколении видеокарт. По большому счёту на этом поколении видеокарт мой интерес к ним заканчивается, потому как Geforce FX были последними картами, у которых было что-то уникальное, чего не было у конкурентов. Вот именно об этом в первую очередь.
Заодно решил много разнообразить: посмотрим разные фичи в разных играх :) Если интересно, то настройки графики в играх: «максимум сочных красок»! Кино всё-таки или где? Правда, киношных разрешений в играх тогда ещё не было предусмотрено…

Но перед тем, как мы с вами помчимся по шейдерам, я бы хотел предостеречь: картинки на самом деле много больше, чем показаны на странице. Там, где это мне показалось необходимым, я предусмотрел возможность клика по картинке с целью открыть исходник — не пренебрегайте, если заинтересовались! Также ниже будет несколько гифок. Гифки — такие гифки, что качество при конвертации неумолимо снижается. Это нужно принять, ведь основная их функция — анимация в вебе, а не фотопрезентация в музее. Но кликать их тоже можно!

Итак, игры…

DooM3

  • Renderers: OpenGL 1.5
  • Shadowtech: Stenciled Shadow Volumes (via Carmack's Reverse) + UltraShadow Technology
  • Shading Language: ARB ASM

UltraShadow… Звучит, а? Вот о ней здесь и поговорим. Существует такая легенда:


Фактически, некоторые опции линейки GeForceFX были специально разработаны для ускорения Doom3, хотя и другие игры их могут использовать в той же мере. Примером может служить функция UltraShadow, реализованная в GeForceFX 5900. Но, возможно, лучше просто привести высказывание Джона из недавнего интервью на QuakeCon 2003:
«GeForce FX на данный момент является самой быстрой картой, где мы тестировали технологию Doom, и в немалой степени это связано с тесным сотрудничеством с nVidia во время разработки алгоритмов, используемых в Doom. Они знают, что используемая нами техника построения теней будет очень важна для многих игр, поэтому nVidia решила внести соответствующие оптимизации в своё „железо“, чтобы оно смогло в должной мере её поддерживать».


www.thg.ru/graphic/20030924/nvidia_interview-01.html

Хотя тут начать хочется с того, что как и у меня всех серьёзных людей на этой планете, у John Carmack'а тоже был свой весьма занятный .план. Оно и понятно, а как же иначе работать? ;)

Во-первых, благодаря этому dotплану, John Carmack поступил несколько честнее, чем Gabe Newell. Он просто отказался от каких-либо проприетарных расширений OpenGL при программировании движка DooM3, сделав упор на общедоступные расширения ARB_***. Хотя для совместимости движка со старыми не-DX9-картами и были написаны соответствующие кодпасы (codepath), с новыми картами всё было честно: в его движке они должны были биться на равных. Сейчас многие из вас запротестуют, мол, а как же:


At the moment, the NV30 is slightly faster on most scenes in Doom than
the R300, but I can still find some scenes where the R300 pulls a little bit
ahead. The issue is complicated because of the different ways the cards
can choose to run the game.

The R300 can run Doom in three different modes: ARB (minimum exten-
sions, no specular highlights, no vertex programs), R200 (full featured,
almost always single pass interaction rendering), ARB2 (floating point
fragment shaders, minor quality improvements, always single pass).

The NV30 can run DOOM in five different modes: ARB, NV10 (full fea-
tured, five rendering passes, no vertex programs), NV20 (full featured,
two or three rendering passes), NV30 ( full featured, single pass), and
ARB2.


John Carmack's .plan_2003
content.atrophied.co.uk/id/johnc-plan_2003.pdf

Давайте же разберём этот момент подробнее. На самом деле, дальше экспериментов с NV30 так и не ушло. Возможно, у John'а просто не выдержали перепонки:


The current NV30 cards do have some other disadvantages: They take up two
slots, and when the cooling fan fires up they are VERY LOUD. I'm not usually
one to care about fan noise, but the NV30 does annoy me.


John Carmack's .plan_2003
content.atrophied.co.uk/id/johnc-plan_2003.pdf

Как бы там ни было, но в релиз попало лишь 6 «рабочих» кодпасов ( и 1 экспериментальный :) ).

Вперёд в п(р)ошлое. Geforce FX. The Dawn of War - 32

NV10, NV20, R200. Как следует из названия, эти три из них специфичны для некоторых чипов.
Cg, ARB, ARB2. Эти трое универсальные. И даже несмотря на то, что ATI всё-таки обучены Cg, этот кодпас всё же отключили (для честноты эксперимента?). Так что ARB2 здесь — самый навороченный рендерер.

Что же касается рендерера NV30, он остался в Альфе.

Вперёд в п(р)ошлое. Geforce FX. The Dawn of War - 33

Так что тут всё было в общем-то честно. На NV30/R300 вы видели DooM3 таким:

Вперёд в п(р)ошлое. Geforce FX. The Dawn of War - 34

Тогда как на каком-нибудь GeForce MX 440 (NV18), например, DooM3 был таким:

Вперёд в п(р)ошлое. Geforce FX. The Dawn of War - 35

Но вернёмся к тому, что dotплан не затронул…

Знаменитый "Carmack's Reverse algorithm" и поддержка NVIDIA UltraShadow.
Тут интересно. Про алгоритм можно было прочесть по ссылке, но вообще, сам «хак Кармака на тени» представляет из себя ни что иное, как способ получать тени «от обратного». Оно и кстати не удивительно, учитывая, как устроен сам движок DooM3 — id Tech 4 — он ведь сам по сути сплошная тень :) А у NV35 как раз есть аппаратная поддержка для таких махинаций, кстати как и у всех последующих карт NVIDIA. Например, у моей GTS 450 (выделено):

Вперёд в п(р)ошлое. Geforce FX. The Dawn of War - 36

Но что же это за технология?

Говоря простым языком, техника UltraShadow позволяет программерам установить границы освещения в 3D-сцене. Это позволяет ограничить вычисления эффектов от каждого из источников освещения. В итоге резко сокращается объём вычислений, затрачиваемый на просчёт эффектов освещения и затенения.

Вперёд в п(р)ошлое. Geforce FX. The Dawn of War - 37

И вроде бы в фичеревью UltraShadow II даже представлены шоты DooM3 и заверяется, что технология используется. На деле при релизе DooM3 оказалось, что не до конца:


Anthony’Reverend’Tan
What’s the situation with regards to depth bounds test implementation in the game? Doesn’t appear to have any effect on a
NV35 or NV40 using the cvar.

John Carmack
Nvidia claims some improvement, but it might require unreleased drivers. It’s not a big deal one way or another.


web.archive.org/web/20040813015408/http://www.beyond3d.com/interviews/carmack04/

И всё-таки недостающее всё же можно сегодня включить принудительно (а в последнем патче даже включено по умолчанию). По факту вы получаете лишь буст в производительности, но никаких визуальных отличий. Чтож, и на том спасибо…

Если кому интересно наглядно (r_showshadows 1)
Вот как рассчитываются тени без Ultrashadow:

Вперёд в п(р)ошлое. Geforce FX. The Dawn of War - 38

Если же включить Ultrashadow:

Вперёд в п(р)ошлое. Geforce FX. The Dawn of War - 39

Need for Speed: Most Wanted

  • Renderers: Direct3D9
  • Shadowtech: Shadow Mapping
  • Shading Language: HLSL

Раз уж заговорили о тенях, как тут не вспомнить так прогремевший NFS:MW? Понимаю, странный выбор, но это только на первый взгляд…

… В те дни очень популярно было говорить, что NFS:MW — наглядный пример того, как можно дёшево и сердито сэмулировать HDR.


К сожалению, графическим движком игры не поддерживается «настоящий» HDR рендеринг с использованием форматов повышенной точности, как могут подумать некоторые, глядя на bloom и нечто подобное динамическому tone mapping в процессе игры. Это всего лишь простые LDR эффекты постобработки: bloom (overbright), увеличивающий яркость светлых участков, и псевдо HDR (фальшивый динамический tone mapping) эффект, динамически изменяющий параметры фильтра bloom таким образом, чтобы результат был похож на имитацию восприятия освещения человеческим зрением, его адаптацию к различным условиям освещения.

Эффект больше всего заметен при выезде из тоннелей или из-под мостов. Сначала интенсивность свечения ярких поверхностей велика, но постепенно яркость снижается. Это похоже на HDR рендеринг и эффект от работы оператора tone mapping, но без использования формата хотя бы с 16-бит на цвет добиться «настоящего» HDR не получится, некоторые и 16-битные форматы называют лишь средним динамическим диапазоном. Поэтому можно сказать, что в Need For Speed: Most Wanted применяется хитрая эмуляция, на самом деле, даже снижающая количество одновременно видимых цветов.


www.ixbt.com/video2/tech_nfsmw.shtml

Казалось бы, правда, что мы видим на протяжении всей игры?

Overbright (Bloom):

Вперёд в п(р)ошлое. Geforce FX. The Dawn of War - 40

Motion Blur:

Вперёд в п(р)ошлое. Geforce FX. The Dawn of War - 41

и, может быть, иногда замечаем World Reflections:

Вперёд в п(р)ошлое. Geforce FX. The Dawn of War - 42

При большом желании можно было запросто превратить киношный наряд (Visual treatment = high):

Вперёд в п(р)ошлое. Geforce FX. The Dawn of War - 43

в элегантные шорты (Visual treatment = low):

Вперёд в п(р)ошлое. Geforce FX. The Dawn of War - 44

И всё же обвинения в эмуляции здесь незаслуженны, потому как тот же Bloom (без сомнения взятый здесь за основу) — всё же тоже HDR-эффект. Просто многие другие вещи в этой игре, например, эффект дождя или настройка детализации теней, доступны только обладателям видеокарт помощнее NV34.

Ну и вот мы зацепились за то, с чего начали. Особо внимательные могли всё же заметить очень обидную реализацию карт теней. Есть мнение, что в игре попросту применяются карты теней низкого разрешения. Возможно, это был компромисный вариант, возможно, на реализацию более детальной настройки теней не хватило времени, а, возможно, опять дело в кодпасах… Кто знает? Кому как не утилите проверки совместимости от EA знать это лучше:

Вперёд в п(р)ошлое. Geforce FX. The Dawn of War - 45

Итого на NVIDIA GTS 450 сцена выглядит так:

Вперёд в п(р)ошлое. Geforce FX. The Dawn of War - 46

Чтож, на первый взгляд всё логично: на NV34 теней явно поменьше (смотрим тень под машиной):

Вперёд в п(р)ошлое. Geforce FX. The Dawn of War - 47

А теперь проверим наличие кодпасов. Для этого нам понадобится 3D-Analyze:

Вперёд в п(р)ошлое. Geforce FX. The Dawn of War - 48

Подменили NV34 (FX 5200) на NV35 (FX 5900), пуск:

Вперёд в п(р)ошлое. Geforce FX. The Dawn of War - 49

Как видно, теперь разницы с GTS 450 особо нет. Налицо искусственные ограничения с целью обеспечения лучшей производительности. Правда, качество теней всё равно сложно назвать хорошим :)

Кстати на Radeon 9600 (RV350) это выглядит так:

Вперёд в п(р)ошлое. Geforce FX. The Dawn of War - 50

Far Cry

  • Renderers: Direct3D9; OpenGL 2.0
  • Shadowtech: Stenciled Shadow Volumes + Shadow Mapping
  • Shading Language: Cg

Есть мнение, что Far Cry стал первой полноценной игрой, по-настоящему поддерживающей HDR-рендеринг (в отличие от Half-Life 2: Lost Coast). По крайней мере его последняя официальная версия (1.4). Да вы сами посмотрите, как шикарно выглядит знаменитая водичка в Far Cry с использованием HDR:

Вперёд в п(р)ошлое. Geforce FX. The Dawn of War - 51

Вперёд в п(р)ошлое. Geforce FX. The Dawn of War - 52

Водичку без HDR тоже можно посмотреть.
Вперёд в п(р)ошлое. Geforce FX. The Dawn of War - 53

Вперёд в п(р)ошлое. Geforce FX. The Dawn of War - 54

Вообще в Far Cry после выхода патча 1.4 был полный набор всех модных эффектов, среди которых можно ещё вспомнить, например, тот же Heat Haze (смотреть на надпись на стене или на лампу на потолке):

Вперёд в п(р)ошлое. Geforce FX. The Dawn of War - 55

Кстати Ubisoft тогда активно ратовали за новомодный AMD64, так что Far Cry выпускался в двух вариантах: x86 и x64 (кстати точно так же было с half-life 2). Для x64-версии был также выпущен Exclusive Content. Как следствие, сразу же появился неофициальный 64-to-32 bit Convertor Mod, позволявший посмотреть этот Exclusive Content на 32-битной системе. Много позднее появился неофициальный патч до версии 1.6, в котором, возможно, этот Exclusive Content наконец перекочевал и в x86-версию Far Cry. Проверить этот момент вам предлагаю самостоятельно.

Да, если вам и этого мало, вы можете поиграться с экспериментальным OpenGL-рендерером, входящим в комплект поставки. Как сделать, написано здесь (читать со слов System.cfg).

S.T.A.L.K.E.R.: SHOC

  • Renderers: Direct3D8 — Direct3D9
  • Shadowtech: Shadow Mapping
  • Shading Language: HLSL

Вот уж действительно «ШОК», учитывая что сначала разрабатывалась одна игра, потом другая, а в итоге получили Shadow of Chernobyl. Но 7 лет разработки, так или иначе, дали свои плоды: X-Ray Engine стал первым движком, использовавшим революционную концепцию рендеринга Deferred Shading. Есть мнение, что S.T.A.L.K.E.R. — больше DX8-игра с некоторыми элементами DirectX9-возможностей. Так вот это в корне неверно. Если быть точным, то верно ровно обратное. Движок X-Ray содержит три полноценных рендерера: r1 (Static Lighting — DX8), r2 (Objects Dynamic Lighting — DirectX9) и r2a (R2 + Full Dynamic Lighting). Достаточно заглянуть в консоль и набрать «help», чтобы увидеть масштаб опций для каждого рендерера.

Можно долго рассказывать про эту потрясающую со всех точек обзора игру, но давайте ограничимся уже сказанным выше… и всё-таки добавим, что S.T.A.L.K.E.R. — одна из первых игр, где была применена техника рендеринга объёмных текстур — Parallax Mapping. Однако есть нюанс. В оригинальной версии игры (с последним патчем 1.0006) этой техникой невозможно управлять через консоль (или я не заметил изменений) и вообще есть мнение, что код шейдеров, отвечающий за её применение, не работает как надо. Поэтому нашлась куча любителей, переписавших эти и многие другие шейдерные эффекты S.T.A.L.K.E.R., чтобы конечному юзеру стало ясно, что и его систему можно серьёзно загрузить бесполезными вычислениями… ну и, конечно же, чтобы было с чем сравнить. Например, можно сравнить оригинал и кастомный код STALKER Shaders MAX 1.05

Вперёд в п(р)ошлое. Geforce FX. The Dawn of War - 56

Спорно, конечно. Но раз уж заговорили о кастомных шейдерах, есть ещё одна штука, о которой хотелось бы поведать. Эффект размытия заднего плана при фокусировке на объекте — Depth of Field. Об этом заговорили 3dfx ещё во времена DirectX6, но до полноценной реализации тогда не дошло. В оригинале и здесь его не было, но в STALKER Shaders MAX 1.05 он наконец появился. Гифка сделана некачественно, но переделывать уже лень, так что смотреть на то, как уплывает фон при прямом взгляде на сталкера:

Вперёд в п(р)ошлое. Geforce FX. The Dawn of War - 57

Пожалуй, тоже не самая красивая реализация, но ведь любительская, так что сойдёт :)
Теперь о чём хотел рассказать: в S.T.A.L.K.E.R. есть две замечательные реализации HDR-эффекта Bloom. Дефолтная и так называемая Fast-Bloom, которая включается отдельно. Вот они в действии:

Bloom

Вперёд в п(р)ошлое. Geforce FX. The Dawn of War - 58

Fast-Bloom

Вперёд в п(р)ошлое. Geforce FX. The Dawn of War - 59

В виду того, что Fast-Bloom включается отдельно, возможно, здесь имеет место какая-то сложная реализация, а не аппроксимация простым размытием по Гаусcу. Или же это отголоски тестирования.

А ещё в S.T.A.L.K.E.R. был реализован Motion Blur! Чтобы его включить, нужно запустить игру с ключом -mblur, а также прописать в консольке эффект. Тогда вы получите что-то навроде:

Вперёд в п(р)ошлое. Geforce FX. The Dawn of War - 60

Но и на этом закончить было бы совсем несправедливо по отношению к такому движку, как X-Ray… Дело в том, что разработка итак затянулась и это не было до конца отлажено, но

всем несведующим сообщу лишь,

что в S.T.A.L.K.E.R. присутствует даже Global Illumination. Т.е., если вам кажется, что в комнате явно недостаёт переотражения света:

Вперёд в п(р)ошлое. Geforce FX. The Dawn of War - 61

… то вы можете сказать r2_gi 1 и тогда это будет выглядеть так:

Вперёд в п(р)ошлое. Geforce FX. The Dawn of War - 62

На сладенькое: Tom Clancy’s Splinter Cell

  • Renderers: Direct3D8
  • Shadowtech: Projection Shadows или Shadow Buffers

Ещё со времён GeForce4 Ti в картах Nvidia появилась неприметная фишечка Shadow Buffers. Полного списка игр, использующих эту технологию, я найти не сумел (вероятно потому, что его нет), но любой счастливый обладатель так нашумевшего тогда Xbox точно знал, как выглядят тени нового поколения. Ну вот и мы теперь посмотрим на фирменную фичу в действии, только уже на ПК… но сначала немного теории:


Splinter Cell Dynamic lighting system

Splinter Cell shadow system is a major part of the game. On NV2x/NV3x hardware, it runs using a technique called Shadow Buffers. This technique is rendering the scene from every shadow casting light and store a depth buffer that represent each pixel viewed by this light source. Each pixel has an X, Y, Z coordinate in the light system and these coordinates can be transformed, per pixel, in the viewer coordinate system. It’s then easy to compare with the actual depth stored in the Z buffer to figure out if the pixel viewed by the camera is the same or is occluded by the pixel viewed by the light. If they are the same, it means the pixel is lighted, if the light pixel is in front of the viewer pixel, it means the pixel is in the shadow. On all other current hardware, the game is using another technique called projected shadows (shadow projectors). The technique is somewhat similar, we render the scene from the light point of view but instead of storing the depth, we are storing the color intensity in a texture. That texture is then mapped per vertex on each object that is going to receive the shadow. To be able to have objects casting shadows on other objects that are themselves casting shadows, Splinter Cell is using a 3-depth levels shadow casting algorithm. In general, the first level is used to compute the shadow to be used on the dynamic actors like Sam. The second level is used to compute the shadow used by the static meshes like a table or boxes. The final level is used for the projection on the BSP. This system is allowing Sam to receive the shadow of a gate on him, then Sam and the gate can cast on a box and finally all three objects can cast on the BSP (ground). This system also has a distance check algorithm to determine if Sam’s shadow should be projected on a static mesh (like a box) or if it shouldn’t base on their relative position. Both systems have their own strength/weaknesses. The main advantage of the Shadow Buffer algorithm is how easy it is to work with. Shadow Projectors are tricky and difficult to use.


Patchinfo.rtf (from patch 1.3)

Думаю, принцип кастинга теней был описан достаточно ясно. Из вышесказанного следует нижеследующее:

  • Shadow Buffers — это такой обыкновенный сегодня Shadow Mapping, аппаратно ускоренный на картах NVIDIA благодаря наличию в них специального буфера под карты теней.
  • Tom Clancy’s Splinter Cell — прекрасная игра на прекрасном движке с такими же прекрасными оптимизациями:


    Splinter Cell has 3 different rendering pipes:

    Class 2 Graphic Adaptors:
    NV2x/NV3x chips
    Dynamic Lighting system = Shadow Buffer
    Vertex position modifiers = Yes
    Light beams stopped by depth texturing = Yes
    Pixel Shader effects/filters/water = Yes
    Reflection/Details texturing/Specular = Yes

    Class 1 Graphic Adaptors:
    R2xx/R3xx/Parhelia/Xabre 200/Xabre 400/Xabre 600/chips/Creative P9
    Dynamic Lighting system = Shadow Projector
    Vertex position modifiers = No
    Light beams stopped by depth texturing = No
    Pixel Shader effects/filters/water = Yes
    Reflection/Details texturing/Specular = Yes

    Class 0 Graphic Adaptors:
    R1xx/NV1x chips
    Dynamic Lighting system = Shadow Projector
    Vertex position modifiers = No
    Light beams stopped by depth texturing = No
    Pixel Shader effects/filters/water = No
    Reflection/Details texturing/Specular = No


    Patchinfo.rtf (from patch 1.3)

    Впрочем, этого следовало ожидать, ведь игра портирована с приставки Xbox, а там живёт NV20A. Хотя всё это не может оправдывать тот факт, что прямые конкуренты NVIDIA того времени — карты на R300 — здесь считаются второсортными. Такие вот оптимизации :)

Ну и вот как в итоге это выглядит на NVIDIA GeForce FX 5200 (NV34):

Projection Shadows:

Вперёд в п(р)ошлое. Geforce FX. The Dawn of War - 63

Shadow Buffers:

Вперёд в п(р)ошлое. Geforce FX. The Dawn of War - 64

Для верности я попробовал посмотреть на ATI Radeon 9600 (RV350). Действительно, Shadow Buffers здесь не включится и 3D-Analyze не спасёт. Режим Projection Shadows выглядит идентично NV34:

Вперёд в п(р)ошлое. Geforce FX. The Dawn of War - 65

Интересно, что на GeForce GTS 450 игра в режиме Shadow Buffers всё же запустится, но выглядеть это будет уже так:

Вперёд в п(р)ошлое. Geforce FX. The Dawn of War - 66

Что из этого правильно (на GeForce FX 5200 или на GTS 450) до сих пор неизвестно, так как существует мнение, что в самой игре есть неисправленный баг с тенями. Но существует и мнение, что дело в драйверах nvidia, поэтому для полноценного погружения нужно использовать именно старые карты (ведь новые карты просто не работают со старыми драйверами).

К счастью, те же самые проблемы с тенями в последующей части сплинтера (который Pandora Tomorrow) сегодня частично решены фанатским враппером.

Кстати
Возможно, для кого-то будет новостью, но для первого Tom Clancy’s Splinter Cell существует официальный Mission Pack. Сам не играл, так как европейский найти не смог, а американка мне не подойдёт. Однако сегодня вы уже можете не заморачиваться и просто купить GOG-версию.

На этом можно было бы начать заканчивать, но, кажется мне, рассказ был бы неполным без упоминания о ещё одной примечательной технике…

Higher-Order Surfaces

Начнём, пожалуй, с того, как ATI наследили в истории с их аппаратной технологией TruForm. По-научному это называется N-Patches (или, что то же самое,- PN Triangles). Появилась она ещё в Radeon 8xxx, но пик популярности пришёл, пожалуй, как раз во времена Radeon 9xxx (R300). Я могу понять, если вам уже лень было пройти по очередной ссылке, так что в двух картинках о сути TruForm:

из вот такого чайничка

Вперёд в п(р)ошлое. Geforce FX. The Dawn of War - 67

TruForm, самостоятельно увеличив количество примитивов, сделает вам вот такой:

Вперёд в п(р)ошлое. Geforce FX. The Dawn of War - 68

Это называлось адаптивной тесселяцией — использованием чипа видеокарты для увеличения изначального количества примитивов на основе заранее заданных, передаваемых приложением (игрой). Обещалось, что можно будет увидеть действие сразу же во всех играх и никакой поддержки со стороны игры не требуется. В надежде на это я долго гонялся за полигонами в любимых и не очень играх, пытаясь лицезреть это на деле. Так вот на деле оказалось, что в последних дровах для RV350 (Catalyst 10.2) TruForm тупо забанили. Понимаете ли, есть мнение, что умная техника TruForm скругляла абсолютно всё, что было в сцене квадратного, и те же деревянные ящики с припасами становились круглыми. Технику сначала дорабатывали, но потом просто выкинули из драйверов.

Но у нас-то с вами исторический интерес, так что вот как на самом деле это выглядело в драйверах Catalyst 5.7:

Вперёд в п(р)ошлое. Geforce FX. The Dawn of War - 69

Таким образом, вопреки нашим ожиданиям, увидеть TruForm можно было только при условии, что игра её действительно поддерживает. Ох уж эти маркетологи, а! Ладно, раз форсировать её на все игры подряд нельзя, то где же тогда можно её посмотреть? На той же википедии нам предлагают небольшой список из, в основном, игр со сторонними патчами под TruForm, что несколько неаутентично. Если же говорить про игры с родной поддержкой TruForm, без сомнения, большинство впервые увидело истинные формы Серьёзного Сэма. Поскольку я лично к его формам никакой симпатии не питаю, рискну предложить вам взглянуть на истинные формы Neverwinter Nights:

Вперёд в п(р)ошлое. Geforce FX. The Dawn of War - 70

А вот как на самом деле было с ящиками:

Вперёд в п(р)ошлое. Geforce FX. The Dawn of War - 71

И всё бы хорошо, но уже в версии Catalyst 5.8 действительно можно было наблюдать их величество артефакты:

Вперёд в п(р)ошлое. Geforce FX. The Dawn of War - 72

А затем фичу окончательно похоронили.

Так вот к чему это я… Видите ли, примерно в то же время NVIDIA тоже наследили в истории подобной технологией. Они стали использовать технику под названием Rectangular and Triangular Patches (RT-Patches) ещё в Geforce 3 Ti, причём аппаратно.

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

Вероятно поэтому RT-Patches и не нашли поддержки со стороны гейм-девелоперов, но всё же утверждается, что их можно было увидеть в Aquanox.

Правда, есть и мнение, что:


Драйверы NV20 и NV25 уже достаточно давно перестали поддерживать аппаратную тесселяцию гладких поверхностей (HOS на основе RT-Patches). Причина этого кроется в DirectX — в случае, когда карта не поддерживает аппаратно N-Patches, API пытается эмулировать их с помощью RT-Patches. Что, несомненно, вызывает очень медленную работу N-Patches, даже более медленную чем толковая программная эмуляция. NVIDIA была вынуждена отключить RT-Patches, дабы игры с поддержкой N-Patches не впадали в трудно объяснимый для рядового пользователя ступор на ее последних продуктах.


www.ixbt.com/video/gf4ti.shtml

Пару человеков на OG честно пытались найти драйвера, которые бы поддерживали RT-Patches (! и такие были найдены!), но дальше как-то не сдвинулось.

Заинтересовавшимся вопросом:

  • Поддержка RT-Patches определяется наличием расширения GL_NV_evaluators для OpenGL и наличием капса Rectangular and Triangular Patches для DirectX:

    Вперёд в п(р)ошлое. Geforce FX. The Dawn of War - 73

    Вперёд в п(р)ошлое. Geforce FX. The Dawn of War - 74

  • Поддержка N-Patches (TruForm) определяется наличием расширения GL_ATI_pn_triangles для OpenGL и наличием капса N-Patches для DirectX:

    Вперёд в п(р)ошлое. Geforce FX. The Dawn of War - 75

    Вперёд в п(р)ошлое. Geforce FX. The Dawn of War - 76

  • Список игр с родной поддержкой TruForm можно почерпнуть здесь. Список игр с поддержкой RT-Patches почерпнуть, увы, негде.

    Когда будете искать карту с поддержкой TruForm, обратите внимание, что, начиная с DirectX 11, технике hardware tessellation (суть TruForm) подарили вторую жизнь!
    Если же карту найти не удалось, не расстраивайтесь: вполне вероятно, что вы сможете дожить до враппера.

В целом всё, н-но…

A little bit of disclosure

GeForce FX. Как много в этом слове :)

Известно, что GeForce — это сокращение от Geometric Force. Так был назван ещё NVIDIA GeForce256 в виду наличия на борту революционного GPU (Geometric Processor Unit), который тогда часто называли Hw T'n'L.

А вот откуда FX:


The inclusion of the ‘FX’ on the end was from two areas. First off, NVIDIA are touting this as “The Dawn of Cinematic Computing” so film Special Effects goes with the name. Secondly, this is the first design that the former 3dfx engineers have had serious input into an NVIDIA design, and so in some senses its homage to their input (not, of course, a way of leveraging more recognition from their strong brand name!).


www.beyond3d.com/content/interviews/26

Ah, Sure not! :)

Совместимость с Glide

Пока инженеры NVIDIA упорно допиливали своё детище (NV30) до работоспособного состояния, маркетологи продавали предзаказы как в рекламе Vaporone. Для увеличения потенциальных покупателей был даже разработан новый API NvBlur, одной из главных фишек которого была обратная совместимость с API Glide. Конечно, NvBlur существовал не больше, чем 3dfx Voodoo 590 или 3dfx Voodoo Reloaded.

A new Dawn

Ну да, если кто помнит, в 2012 году NVIDIA воскресили демку.

Вперёд в п(р)ошлое. Geforce FX. The Dawn of War - 77

Когда смотришь на такие вещи, порой кажется, что это реально снятое видео. Это был DirectX11. Но даже это уже не там, где игровая индустрия сейчас…

Ну так вот, знаете...

Вообще, конечно, вся эта эпопея с восходом в плавающих красках навеивала примерно следующее:

На очередной GDC гейм-девелопер с отвращением смотрит демонстрацию Дума3 на экране 1024х768. FPS даже не демонстрируют.
Девелопер: — Ну вот скажите мне, почему после стольких стараний я опять вижу худ на пол экрана и монстров размером с миникарту?
NVIDIA: — Это из-за ATI мы ничего не успели!
ATI: — Да это Microsoft опять задач понаставил…
Microsoft: — Между прочим, красивые слайды — тоже кино!

В целом восход действительно получился спорным, но закат всё же был что надо:

Вперёд в п(р)ошлое. Geforce FX. The Dawn of War - 78

На том самом закате NVIDIA удалось-таки вернуть себе статусность со своим следующим чипом NV40, который вышел в срок и героически сражался с ATI R420 в двоеборье по Half-Life 2. Но все мы знаем: всё благодаря тому, что NV40 хоть и считался новым архитектурным решением, всё же минимум на 70% состоял из воды NV30.

Вот где на самом деле пригодилась FP32-точность
Вперёд в п(р)ошлое. Geforce FX. The Dawn of War - 79

GeForce6 6600 — одна из самых популярных карт NVIDIA тех лет, а её сердце — NV43 стал одним из самых успешных чипов NVIDIA в её истории.

THX

Администрации old-games.ru за возможность быстро и бесплатно скачать 20 игр скопом только ради того, чтобы заценить структуру файлов и однажды запустить.

Человеку, который в порыве заинтригованности моими предстоящими к написанию обзорами, всучил мне сей бесценный во всех смыслах неинженерный образец былого ажиотажа и величия :)

...?TBC?...

Использованная литература
Главный спонсор трансляции — Википедия! и nvidia.com

Неоценимую помощь в таком жизненно необходимом деле, как игрокопание, оказал человек по имени Koroush Ghazi (интересно, что из этого всё-таки имя, а что фамилия?)

Типичные обзоры NV30 до его фактического выхода и после. DX9-игры всё ещё где-то на горизонте.

Как устроен R300.

Архитектура NV30 на пальцах. О причинах низкой производительности SM2.0 и попытках их исправить (в т. ч. силами NV35). А вот как Tony Tamasi объяснял тонкости архитектуры NV30.

Замечательная ретроспектива своего времени о том, как кинематографическая графика пришла в дом к простому юзеру.

Качественный обзор различных HDR-техник на примере Need For Speed: Most Wated.

Единственный более-менее годный тест NV35 vs R350, что удалось нагуглить. Если спросите моё мнение, конечно, я бы всё по-другому оттестировал :)

Весьма занятный .план John Carmack'а. И до кучи все (или почти все) самые значимые интервью John'а Carmack'а.

Отличный мини-гайд по основным техникам рендеринга теней.

Подробный туториал по 3D-пайплайну.

Автор: Goblinit

Источник

Поделиться новостью

* - обязательные к заполнению поля