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

....
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.

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

• 64/128 bit depth rendering - the Dawn of Cinematic Computing
  В мире труколора такое маркетинговое заявление звучало бы несколько странно. Всем несведующим сообщу лишь, что с этого момента тусклый мир труколора остался в прошлом. И, если вы до сих пор думаете, что все новые игры рендерят изображение в 32-битном цвете... Вы, конечно, правы... Лишь отчасти. Потому что, на самом деле, многие (если не все) "части" в играх теперь просчитываются на пути к вашему монитору с сильно большей точностью, получившей название Floating Point Color Accuracy.
  
  Разумеется, я не поверил. И, как оказалось, не поверил не я один, потому что в сети нашлась даже такая нужная программулина ShaderMark 2.1, которая, как следует из названия, была создана именно для этого самого: тестирования производительности шейдерных блоков gpu. И вот, представьте себе, действительно есть разница не только в скорости, но и в цвете с разными пресетами точности! Качество при конвертации шотов в gif, конечно, упало, но менее не тем "исправленному верить":
  
  
  
  
  Но главное, именно благодаря такой разрядности графического конвеера, мы наконец смогли наблюдать киношную графику в играх. Суть HDR-рендеринга не только в тупом просчёте пикселей с точностью до тысячных. HDR-рендеринг - это прежде всего адаптивное освещение.
  
  Кому лень читать, я покажу
  
  
  
  На анимации выше вы можете наглядно наблюдать эффект, который называется Tone mapping. Тут всё как в жизни: когда многоуважаемый Мистер Фримен смотрит прямо на источник света (солнце), оно кажется ему очень ярким, а всё окружающее от этого кажется сильно темнее солнца. Когда же многоуважаемый Мистер Фримен соизволит неспеша отвернуть голову (в сторону), его глаза постепенно привыкают к новому балансу яркости: теперь уже солнце находится несколько сбоку и не кажется таким уж ярким, а всё остальное становится ярче.
  
  
  
  Кстати, что ещё важно отметить: благодаря тому, что теперь весь графический конвеер в GeForce FX работает как минимум с точностью FP16, даже старые игрушки (где активно применялся мультитекстуринг и прочие техники, требующие операции смешивания цветов пикселей в кадре) будут выглядеть качественнее.
  
  
• Shader Model 2.0+
  Да-да, это те самые пресловутые "шейдеры", благодаря которым вам в своё время наверняка приходилось идти в магазин менять свою видеокарту или только что купленную игру. Для начала давайте определимся: эти самые шейдеры... да кому они вообще нужны?
  
  Ответ на этот вопрос в общем случае будет зависеть от контекста, в котором он задаётся, т. к. термин "шейдеры" вообще многозначен. По обыкновению для начала предлагается определиться с тем, для чего они нужны. То есть, если высказывание "шейдеры - это программы для затенения" для вас целиком олицетворяет шейдеры, настоятельно рекомендую вам прочесть хотя бы вот это:
  
  Очень упрощённое представление
  
  
  До того, как мы с вами двинемся по конвееру, вот вам его алгоритм:
  
  
  
  Даже, если вы нэ бельмэ, полагаю, уже догадались, что есть два варианта обработки геометрии сцены и её прорисовки: с шейдерами и без... Окей, а теперь немного истории.
  
  Что было до шейдеров?
  На заре развития 3D-рендеринга было принято решение жёстко стандартизировать 3D-пайплайн (он же - "Графический конвеер"). Таким образом, видеокарты можно было рассматривать как "pixel-blaster'ы", потому как всё, что они тогда делали - это ели команды драйвера и выплёвывали вам на экран пиксели. В результате разработчики игр (гейм-девелоперы) были жёстко ограничены лишь теми возможностями рендеринга, которые предоставлял им тот или иной видеочип.
  
  Скажем, наглядно ситуацию можно было посмотреть в Unreal или в Quake II, в каждом из которых есть на выбор несколько API (API - программный интерфейс для "рисования" видеокартой).
  
  Так вот, например, в Quake II при выборе API OpenGL использовались аппаратные 3D-возможности видеочипа. Таким образом, в этом случае видеочип самостоятельно будет накладывать текстуры на объекты и рассчитывать спецэффекты. И всё в игре было красиво, вот только вода выглядела похожей на стекло:
  
  
  
  John Carmack предлагал вам альтернативный вариант: API Software, который использовал центральный процессор (CPU) вместо видеокарты для расчёта эффектов и наложения текстур. В этом случае в игре можно было реализовать абсолютно произвольные спецэффекты, а видеокарта только рисовала уже готовые пиксели. Красок особенно не видать (ведь затратно!), но вот вода была подвижной (имитация волн). Обратите внимание на искажение дна или стены на горизонте:
  
  
  
  Почему? Всё дело было в стандартизации графического конвеера видеокарт. В каждый конкретный видеочип был жёстко вшит определённый набор фич, например, спец-эффектов. Точно такой эффект подвижных волн было невозможно получить, используя аппаратный 3D-рендеринг (возможно, можно было получить схожий, но не такой же).
  
  Чего ещё не было до шейдеров?
  Абсолютной власти (над конвеером)! В те годы использовать, скажем, эффект bump-mapping (рельефное текстурирование) чипа вы могли, но чип сделает его только по вершинам фигуры. И этот алгоритм изменению не подлежит! То есть, вы получите только то, что чип умеет делать.
  
  Рассмотрим на примере любимого доната и DX6-видеокарты Voodoo, которая не умеет шейдеры:
  
  Вот донат, состоящий из 20 000 полигонов:
  
  
  
  Вот Voodoo набросал на него текстуру:
  
  
  
  А вот, что будет, если Voodoo наложит на него эффект рельефного текстурирования:
  
  
  
  Красиво? Это потому, что полигонов, из которых сделан наш бублик, достаточно много. Но это сильно уменьшает скорость прорисовки (FPS). А чего мы хотим, так это прежде всего её увеличить. Чтож, придётся уменьшить количество полигонов до 1352:
  
  
  
  Отлично, вот он - наш свежеиспечённый бублик:
  
  
  
  Теперь вуду наложит ему рельеф:
  
  
  
  Видите, как рельеф "поехал" по ближнему к вам краю? Т.е. с уменьшением количества полигонов 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 4:



Суть:

....
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

....
https://en.wikipedia.org/wiki/GeForce_FX_series

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



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

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

ATI Quake III optimizations

......
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.
......
http://techreport.com/review/3930/radeon-9700-and-nv30-technology-explored/6

....
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.

....
https://en.wikipedia.org/wiki/GeForce_FX_series

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

• 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-видеокарт)

• Adaptive Texture Filtering
  
  К слову сказать, из всего огромного множества обзоров NV30 в 90% при тестировании использовали анизотропную фильтрацию вкупе с трилинейной! Сначала это показалось мне какой-то массовой эпидемией. Ну, то есть, я понимаю, что в виду столь долгих ожиданий хотелось выжать из карты всё до последней капли, но о практическом смысле тоже надо было как-то подумать?
  
  Однако всё оказалось намного интереснее. Копнув глубже, можно было уяснить себе две вещи: есть общепринятые стандарты фильтрации текстур, а есть такие "адаптивные" вещи, как, например, Intellisample. Поскольку в данном случае алгоритм той или иной фильтрации задаётся драйвером, то тут у NVIDIA был ещё один полигон возможностей. Производительность и качество фильтрации текстур различались практически с каждой новой версией дров...
  
  Что интереснее, во всех обзорах тех дней часто можно было найти сравнение алгоритмов работы так жадной до fps анизотропки у ATI и у NVIDIA. Так вот ATI ещё более преуспели на данном поприще: они не только действительно использовали трилинейную фильтрацию вкупе с анизотропной (не поверите: ради экономии!), но даже умудрились придумать гибридный термин: brilinear filtration.
  
  И в общем-то те же ATI были правы: если не видно разницы,- зачем платить больше? Понятно, если у меня бюджетная карта, я буду рад дополнительным 10 кадрам без видимой потери качества. Однако этот замечательный принцип почему-то распространялся и на топовые чипы (NV30 / R300), тогда как вот здесь-то нам хотелось бы получить лучшую в мире картинку. "Да, все эти оптимизации должны быть отключаемыми" - твердили тогда обозреватели. Вендоры же были непреклонны и с каждой версией алгоритмы становились всё бесплатнее и оптимизированнее. В ответ на такое наплевательское отношение к покупателям дорогих карт был выдвинут такой транспарант:
  
  
  
  

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

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

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

  Здорово, но на самом деле нас по-прежнему ждали сюрпризы. Их можно было разделить на несколько типов:
  • Собственно-разработанные расширения OpenGL.
    
    Например (выделено):
    
    
    
    Конечно, это можно считать оптимизацией под свою продукцию лишь наполовину. Ведь расширение зачастую хоть и работает только на картах этого производителя, но является частью спецификации. Ничто не мешает конкурентам реализовать то же самое в следующей серии :)
    
    
    
  • Game Codepaths.
    
    Кодпас в игре применительно к видеочипу - это отдельный код для поддержки работы именно с этим чипом для обеспечения его максимальной производительности в данной игре. По сути это так или иначе существовало всегда, но наиболее полно раскрылось теперь.
    
    

    ....
    Некоторые компании, такие как Valve, отказались от Shader Model 2.x на NV30 и использовали Shader Model 1.х для них в Half-Life 2.
    
    ....
    https://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)

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

....
Фактически, некоторые опции линейки GeForceFX были специально разработаны для ускорения Doom3, хотя и другие игры их могут использовать в той же мере. Примером может служить функция UltraShadow, реализованная в GeForceFX 5900. Но, возможно, лучше просто привести высказывание Джона из недавнего интервью на QuakeCon 2003:

"GeForce FX на данный момент является самой быстрой картой, где мы тестировали технологию Doom, и в немалой степени это связано с тесным сотрудничеством с nVidia во время разработки алгоритмов, используемых в Doom. Они знают, что используемая нами техника построения теней будет очень важна для многих игр, поэтому nVidia решила внести соответствующие оптимизации в своё "железо", чтобы оно смогло в должной мере её поддерживать".

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

....
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
http://web.archive.org/web/20160316120824/http://content.atrophied.co.uk/id/johnc-plan_2003.pdf

....
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
http://web.archive.org/web/20160316120824/http://content.atrophied.co.uk/id/johnc-plan_2003.pdf

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

....
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.

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

Вот как рассчитываются тени без Ultrashadow:



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

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

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

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

....
http://www.ixbt.com/video2/tech_nfsmw.shtml

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

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

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

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

....
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 - здесь считаются второсортными. Такие вот оптимизации :)

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

....
http://www.ixbt.com/video/gf4ti.shtml

• Поддержка RT-Patches определяется наличием расширения GL_NV_evaluators для OpenGL и наличием капса Rectangular and Triangular Patches для DirectX:
  
  
  
  
  
  
• Поддержка N-Patches (TruForm) определяется наличием расширения GL_ATI_pn_triangles для OpenGL и наличием капса N-Patches для DirectX:
  
  
  
  
  
  
• Список игр с родной поддержкой TruForm можно почерпнуть здесь. Список игр с поддержкой RT-Patches почерпнуть, увы, негде.
  
  Когда будете искать карту с поддержкой TruForm, обратите внимание, что, начиная с DirectX 11, технике hardware tessellation (суть TruForm) подарили вторую жизнь!
  
  Если же карту найти не удалось, не расстраивайтесь: вполне вероятно, что вы сможете дожить до враппера.

....
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!).

....
http://www.beyond3d.com/content/interviews/26/

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