Главная - Видеосистема - Direct3D 8.0: Вопросы и ответы

На закрытом ftp-сайте Microsoft для зарегистрированных разработчиков уже с 20 мая доступна для загрузки DirectX8 beta1. Большинство наших читателей не относятся к этой категории пользователей продукции Microsoft, но всем интересно, что нового будет в DX8 и в Direct3D 8.0 в частности. Мы решили не писать статью в традиционном стиле, а подготовить материал в виде вопросов и ответов на них. Получился в некотором роде FAQ.

Q: Выход D3D8 -- это ожидаемое событие? Нужен ли он вообще? И если да, то почему?

Для тех разработчиков, которые ориентируются на API DirectX при разработке своих приложений, это, конечно, ожидаемое событие.

А по поводу того, нужен ли он - а нужен ли 600-й "Мерседес", если есть "Запорожец"? В DX8 всё, ну не то, чтобы лучше, но по-другому, нежели в DX7. Причём, местами различия столь же сильные, как между DX7 и DX3. При этом многие вещи стали удобнее и универсальнее... Плюс ещё большее ориентирование на аппаратное обеспечение (Pure HAL Device). Кстати, HAL = Hardware Abstraction Level, т.е., проще говоря, унифицированный уровень обращения к железу.

Q: Что принципиально нового появится в D3D8?

Вот что появилось нового, по пунктам:

1. Все 3D devices заменены на три: HAL Device, Pure HAL Device and Reference Rasterizer
2. Index Buffer (в дополнение к Vertex Buffer)
3. Pixel Shader
4. Несколько input geometry streams (несколько VB+IB на входе и один на выходе)
5. Vertex Shader
6. Z-buffer отделён от render surface
7. Добавлен debug device

Теперь рассмотрим каждый пункт подробно, и что это даёт разработчикам.

Все 3D devices заменены на три: HAL Device, Pure HAL Device and Reference Rasterizer

В DX7 существовали:

HAL Device

Если не T&L device, то через SW выполняется только T&L функции. Всё остальное всегда идёт через HW. Только на пути от API вызова до драйвера стоит существенная прослойка от D3D, которая что-то там делает (что именно, Microsoft не признаётся).

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

T&L HAL Device

Всё производилось через HW accelerator.

Reference Rasterizer

Полностью SW - то, на что должны равняться производители железа при реализации на аппаратном уровне тех или иных функций, т.е. нужен только для HW developers. Полностью непригоден к использованию в играх, т.к. тормозит безбожно (на PIII 500 простенькая сцена с вращающейся Землёй из демок по D3D даёт около 1 fps).

RGB SW Emulation

Лёгкая версия SW растеризатора. Это значит, что она не умеет делать некоторые advanced features (EMBM, Dot Product3), поддерживает не все текстурные форматы (DXT#, etc.) и т.д. А лёгкая она по сравнению с Reference Rasterizer (который вообще невозможно использовать для interactive visualization).

От RGB SW Emulation требуется возможность формирования изображения, не столь качественного, как в референс, и необязательна поддержка всех функций (референс потому и референс, что реализует ВСЕ возможности и делает это максимально корректно), но главное, чтобы все работало с приемлемой скоростью.

В DX8 будет следующий расклад

HAL Device

Это некое объединение HAL и T&L HAL Device из DX7, но Microsoft мягко намекает, что этот device может не поддерживать все функциональные особенности аппаратной части - этот device ориентирован на графические акселераторы прошлых поколений и не обязан поддерживать super advanced features :)

Pure HAL Device С появлением GeForce 256 (я не рассматриваю малораспространённые карточки от 3Dlabs и дорогие экземпляры от SGI) игровое железо стало способно полностью изолировать остальной компьютер от нужд отображения 3-х мерной сцены на плоском экране. Имеется в виду, что видеокарты освобождают CPU/FPU/SSE/3DNow!/… от проблем преобразования 3-х мерного объекта в 2-х мерную картинку.

Иными словами, все стадии классического конвейера 3D графики, начиная с определенной, проходят вообще без участия центрального процессора системы. Создали буферы, поместили в них описание сцены, света, текстуры, запустили ускоритель -- и все. Далее он сам преобразовал, выбрал, отсек, осветил, нарисовал. Даже не надо организовывать какое-то промежуточное управление или контроль, ускоритель понимает структуры данных D3D и сам с ними работает.

Только для большей эффективности в этот процесс всё равно приходится вмешиваться (на уровне выбора объектов для рендеринга, сортировки объектов по глубине - т.е. менеджмент всей сцены), но это около 5% от CPU (это вместо 30-60% раньше).

Теперь можно даже и сами данные полностью хранить в видеопамяти. Поэтому ребята из Microsoft задумались и сделали т.н. Pure HAL Device. Это такой же D3Ddevice с точки зрения API, но внутри он существенно отличается от своих предшественников тем, что все вызовы НАПРЯМУЮ передаёт в драйвер карточки, минуя все стадии предобработки данных. Таким образом, если игра написана под использование Pure HAL Device, то все её тормоза будут исключительно на совести разработчиков - уже нельзя будет сказать, что тормозит D3D - его прослойка будет настолько тонкой, что заметить её уже нельзя.

Единственное ограничение - Pure HAL Device может делать то и только то, что позволяет HW accelerator. Этот device создан для карточек нового поколения - GeForce 256 и последующие. И работает он только с Vertex Buffer и Index Buffer (т.е. никаких данных из user-memory он не принимает!)

На старых карточках (без HW T&L) возможности этого device будут сильно ограничены.

Reference Rasterizer

Он как был, так и остался, но, как я уже говорил, нужен он только для HW developers.

Index Buffer (в дополнение к Vertex Buffer)

Основной преградой на пути получения пресловутых 15M tris/sec на GeForce 256 в реальной сцене (на тестовой специально подобранной сцене мы получали 13-15M tris/sec) было ограничение по скорости закачивания индексов для indexed primitive в локальную видеопамять, т.к. брались они из user system memory и качались по шине… С появлением Index Buffer стало возможно хранить индексы к indexed primitive непосредственно в локальной видеопамяти. Это действительно очень важно, т.к. без этого пределом было 5-6 M tris/sec на AGP 2x. Теперь же (с использованием Index Buffer) пределом будет то, что написано в спецификации графического акселератора (т.е. 15M tris/sec для GeForce 256, например). В принципе, это то, что давно ожидалось многими.

Pixel Shader

Это универсальная программируемая замена того, что в DX7 называлось texture stage state. От последнего осталось только typedef enum _D3DTEXTURESTATETYPE {

• D3DTSS_BUMPENVMAT00 = 7,
• D3DTSS_BUMPENVMAT01 = 8,
• D3DTSS_BUMPENVMAT10 = 9,
• D3DTSS_BUMPENVMAT11 = 10,
• D3DTSS_TEXCOORDINDEX = 11,
• D3DTSS_ADDRESS = 12,
• D3DTSS_ADDRESSU = 13,
• D3DTSS_ADDRESSV = 14,
• D3DTSS_BORDERCOLOR = 15,
• D3DTSS_MAGFILTER = 16,
• D3DTSS_MINFILTER = 17,
• D3DTSS_MIPFILTER = 18,
• D3DTSS_MIPMAPLODBIAS = 19,
• D3DTSS_MAXMIPLEVEL = 20,
• D3DTSS_MAXANISOTROPY = 21,
• D3DTSS_BUMPENVLSCALE = 22,
• D3DTSS_BUMPENVLOFFSET = 23,
• D3DTSS_TEXTURETRANSFORMFLAGS = 24, // PROJECTED flag is in shader

Microsoft придумал некий псевдо-ассемблер для программирования мультитекстурных эффектов. Он (псевдо-ассемблер) включает в себя следующие понятия:

• registers (vertex color registers, factor registers and temporary registers),
• инструкции (add, sub, mult, madd(mult + add и 3 arguments), blend, dp3 (dot product 3), cmul ((ARG0.A > 0.5 ? ARG2 : ARG1*ARG2) ),
• Texture Address Operations (ie Perturbations): texcoord (sample texture directly at given texcoords), kill (mask out pixel if any texcoord <0), bumpenvmap (2x2 scene-wide-matrix multiply, add, and dependent read), beml (above with luminance correction), indexar (use specified input as texcoords to this stage), indexgb (use specified input as texcoords to this stage), mat2x3 (2x3 interpolated matrix multiply/read), mat3x3 (3x3 interpolated matrix multiply/read), reflect (reflection calculation),
• модификаторы инструкций (bias/unbias (+0.5/-0.5), 2x, 4x, 8x, 1/2, 1/4, 1/8),
• модификаторы аргументов инструкций (inv (1-color for each component), alpha (replicate alpha), blue (use blue component as alpha channel)).

Теперь multitexture effect ограничен только фантазией автора… + в некоторых случаях это может спасти текстурное пространство, т.к. порой делались промежуточные текстуры для реализации эффектов, а теперь они не понадобятся Покажем, как можно использовать Pixel Shaders на практике. Эффект 'embossing' без применения программируемого pixel shader'а делается следующим образом:

• Из текстуры с bump-информацией (просто height map) заранее делается две - half height map (т.е. hm/2) и half inverted height map (т.е. (1-hm)/2).
• Далее последовательность накладывания текстур следующая:
  • накладывается half height map текстура по основным texture coords,
  • прибавляется half inverted height map текстура по сдвинутым texture coords,
  • в заключение это умножается на основную текстуру (по основным texture coords) и умножается на 2.

Фактически, это ( ( hm(1) + (1-hm(2)) ) / 2 ) * mt * 2 == ( ( hm(1) - hm(2) )/2 + 0.5 ) * mt * 2.

Просто на pre-defined shaders это сделать невозможно, поэтому и приходилось заранее делать инвертированную текстуру. Теперь для первой и второй стадий можно использовать только одну текстуру (т.е. на одну текстуру меньше, чем раньше). Т.о., мы держим только одну height map текстуру вместо двух для этого эффекта…

NOTE: это просто пример экономии текстур на использовании pixel shader.

Раньше не было такого произвола в смешении, мы не могли сделать сложную формулу сразу, а реализовывали ее из готовых, но в несколько шагов. Как следствие приходилось использовать промежуточные текстуры. В действительности, большинство ускорителей уже давно имеют тот или иной механизм программирования смешения, но DX8 впервые декларирует нормальный стандартный API для доступу к этой приятной возможности. Тот же Radeon 256 может быть запрограммирован для работы сразу с 3 разными текстурами в одной формуле без ущерба для производительности. GeForce2 GTS может работать сразу с 4-мя текстурами в одной формуле (2 бесплатно, а 4 - это в 2 раза медленнее), а вот GeForce 256 -- только с двумя.

Несколько input geometry streams + Vertex Shader

Vertex shader чем-то похож на pixel shader по своей концепции, но только работает он с vertices, а не с texels. Это очень полезная и нужная вещь, т.к. даёт широкие возможности по использованию optimized vertex buffers. Если в DX7 optimized vertex buffers можно было использовать только для статических объектов, то теперь можно и для некоего подмножества динамических, динамику которых можно описать в рамках предложенных операций…

Вот операции, поддерживаемые vertex shader:

• MOV copy inputs to outputs
• ADD add
• MAD multiply and add
• MUL multiply
• RCP multiplicative inverse of source.x (21-bit)
• RSQ inverse square-root of source.x (21-bit precise)
• DP3 3-element dot-product
• DP4 4-element dot-product
• MIN returns min of both args for each component
• MAX returns max on per component basis
• SLT returns 1.0 if < else 0.0 for each component
• SGE returns 1.0 if >= else 0.0 for each component
• EXP exponential for specular lighting 10-bit precision
• LOG inverse of above (10-bit precision)
• LIT lit colors given diffuse and specular dot
• DST (1, x, x^2, 1/x) given 1/x and x^2 For distance attenuation
• FRC fractional portion [0.0 to 1.0) of each component

Хочу отдельно отметить, что vertex shader работает как на карточках без HW T&L, так и с ним (последнее справедливо для карточек поколения от GeForce 256 и далее). Т.е. это метод перепрограммировать T&L pipeline на понятном ему языке (как pixel shader есть метод перепрограммировать растеризатор).

Входными регистрами являются данные от вертекса, постоянными регистрами - матрицы трансформаций, а выходными - screen position, color, fog…

А теперь самое интересное: на вход можно подавать НЕСКОЛЬКО наборов вертексов, которые потом можно преобразовывать через vertex shader. Например, можно делать blending между несколькими моделями, и т.д. На выходе должен остаться только один (… и имя ему Дункан Маклауд :-) ) результирующий набор.

NOTE: programmable vertex and pixel shaders не отменяют полностью fixed pre-defined vertex and pixel shaders, а могут заменять их.

Z-buffer отделён от render surface

С DX6 появилась интересная функциональная возможность - render to texture. Но для использования её надо было создавать для текстуры свой собственный z-buffer (если z-buffer использовался и для основного rendering). Это было неудобно и криво… Теперь в DX8 z-buffer уже не является принадлежностью render surface, они объединяются вместе вызовом функции SetRenderTarget, в которую передаётся z-buffer и render surface. Теперь можно при одном и том же z-buffer'е менять render target!

Добавлен debug device

Эта функциональность введена исключительно для отладки программы с DX - этот debug device позволяет устанавливать break points на события внутри драйверов и получать всяческие внутренние переменные…

Q: Как обстоит дело с поддержкой AntiAliasing?

Ещё в DX6 (или даже в DX5) было введено два понятия: edge antialias и full scene antialiasing.

Первое - это размывание линий при отрисовке в режиме line. Для получения эффекта antialiasing необходимо было после отрисовки сцены нарисовать её ещё раз в режиме line с включенным edge antialias. Но так как режим line на многих карточках поддерживался криво, то этот метод antialiasing практически не использовался.

Второе - это antialiasing на краях треугольников непосредственно при отрисовке сцены. Он есть двух типов: sort dependent - это когда надо отсортировать треугольники по глубине для достижения эффекта, и sort independent - т.е. никакой предобработки на треугольниках не надо. Даже TNT и TNT2 способны это делать (правда, fps падают примерно в 4 раза).

Зато в D3D8 Microsoft обещает ввести поддержку T-Buffer, правда, названо это как поддержка продвинутой реализации anti-aliasing через multi-sample rendering techniques. Это не только FSAA, как у карт серии Voodoo5, но и поддержка массы интересных эффектов, например, Motion Blur.

Q: Как обстоит дело с поддержкой T-Buffer?

Поддержка заявлена, правда, говорится не прямо о T-Buffer, а о поддержке техники мультисемплирования при рендеринге и, соответственно, об эффектах, которые можно реализовать с помощью этой техники. Такая техника рендеринга поддерживается в картах серии Voodoo5 и позволяет реализовать FSAA и ряд интересных эффектов. Microsoft подчеркивает, что описанная техника рендеринга представляет собой ограниченную форму accumulation buffer, что позволяет использовать ее в большом количестве приложений при скромных требованиях к аппаратной части и без излишнего усложнения API.

Среди специальных эффектов, которые доступны при использовании этой техники, можно отметить Motion Blur, Depth of Field и Blur Reflections, впрочем, все эти эффекты являются частными случаями пространственного сглаживания (FSAA). Будут ли они широко использоваться - пока трудно судить.

Несомненным является то, что предлагаемый метод FSAA, по сравнению с edge-antialiasing и sort-dependent требует существенно меньших трудозатрат от разработчика игры.

Q: Чем простым игрокам грозят нововведения в D3D8?

Хочу ещё раз отметить, что DX8 создаётся для карточек от GeForce 256 и выше (т.е. для успешной работы с DX8 РЕКОМЕНДУЕТСЯ иметь HW T&L на карточке). Все его новые функции будут поддерживаться только в новых карточках. Как следствие при использовании новых функций на старых карточках это будет выполняться через software, т.е. повышения производительности в этом случае ждать не приходится.

После выхода DX8 современными картами могут считаться только те, чей класс соответствует GeForce 256, как минимум. После выхода X-Box аппаратная поддержка всех DX функций может стать просто "required configuration", т.е. просто необходимой.

Трудно сказать, чем грозят простым игрокам нововведения в D3D8… (как трудно сказать и об улучшении качества, например, КАМАЗ'ов при закупке заводом КАМАЗ новых станков :)). Ведь много зависит от кривизны рук разработчиков…

Если разработчик будет использовать ВСЕ функции DX8, причём оптимально (не совать их в каждую дырку, а использовать только там, где без этого будет хуже), то это, несомненно, даст и повышение качества, и повышение скорости ОДНОВРЕМЕННО. Время покажет.

Q: Чем все нововведения грозят разработчикам? Будут ли они их сразу использовать, или не все еще на D3D7 перешли?

Разработчикам D3D8 грозит многим :).

Во-первых, это перестроенная архитектура (в который раз…), а, значит, переписывание render-модуля под неё.

Во-вторых, это серьёзно изменённая концепция мультитекстурирования (pixel shaders) - здесь есть как недостатки (переписывание уже работающего multitexture модуля под новую, должен сказать, отнюдь не самую легко понимаемую, концепцию), так и несомненные достоинства - можно самому создавать multitexture effect, не ограничиваясь подмножеством, реализованным изначально.

Так же при помощи pixel shader можно создавать точные тени, но, к сожалению, с резкими границами (sample можно скачать с сайта nVidia).

А по поводу перехода разработчиков на DX8 и DX7 - так это зависит от потребностей, есть масса разработчиков, которые работают на DX3, и им этого достаточно! Но то, что D3D8 будет использоваться многими - это не вызывает сомнений.

Q: Чего не хватает в D3D8?

По моему мнению, если рассматривать D3D как low level graphics API, то ему уже ничего не нужно. Другое дело -- "Fahrenheit", но это уже уровнем (и не одним) повыше.

Q: Если сравнивать D3D8 с OGL, то какой интерфейс более удобен для разработчиков?

Это дискуссия на много сотен страниц (что круче C или Pascal?; GeForce или Napalm? и т.д.). Можно сделать подробный анализ, но не в рамках данной статьи. Возможно в следующий раз.

Q: Не секрет, что API Fahrenheit уже не за горами, вроде в D3D8 уже API ScenGraph от Fahrenheit, так ли это?

Microsoft обещает, что в D3D8 будет включена первая версия Scene Graph от "Fahrenheit", но в основном для того, чтобы разработчики его "пощупали", т.к. он ещё не доведён до хорошего состояния - это пока некая сырая beta

Q: Нет ли ощущения, что OGL перестанет использоваться вообще для игр, т.к. все аппаратное обеспечение будет рассчитано на D3D? Особенно в свете ориентации XBox на D3D.

Например, Tim Sweeney сказал, что в дальнейшем они ставят приоритетным API D3D, а OGL может будет поддерживаться, а может и нет... а Glide вообще они не будут больше поддерживать.

Вообще, на Linux только OGL и есть, так что там ему замены в ближайшее время не предвидится.

А что касается Windows, то лучше D3D сейчас нет по всем параметрам, что бы ни говорили любители OGL (да и не предвидится в обозримом будущем).

Q: Какие требования предъявляет Microsoft к аппаратной части современных и будущих графических ускорителей?

Это самое интересное место… Просто процитируем некоторые фрагменты из спецификации Microsoft. Самые интересные и близкие к сердцу параметры…

Требования к производительности

Ниже в таблице приведены данные об ожидаемой производительности графических акселераторов High-End игрового класса:

Fill Rate: Определяет отрисовку одной текстуры с билинейной фильтрацией в секунду. В драйверах для многих современных графических процессоров билинейную фильтрация не используется, а используется трилинейная или наложение сразу двух текстур (что позволяет повысить качество). В этом случае величина fillrate снижается вдвое. Предполагается, что альфа-смешивание и z-буферизация используются.

Polygon Rate: Определяет число полигонов в секунду, с одной текстурой, с использованием z и alpha, с преобразованными координатами вершин, с установленным освещением от одного источника света типа directional, 200 vertices per batch, indexed polygon mesh data.

Texture Load Rate: Число байтов в секунду, показывающее, с какой скоростью текстурные данные могут быть загружены из системной памяти в видеопамять.

Note: производительность для конца 2000 года была экстраполирована на основе данных о возможностях аппаратного обеспечения конца 1999 года исходя из примерно троекратного увеличения показателей, что обычно происходит в этой области. Прогноз может быть чересчур консервативным.

Note: требуемая полоса пропускания для передачи вертексов может превосходить возможности основной шины данных в ближайший год.

Объем локальной видеопамяти:

Тут комментарии не требуются.

Поддерживаемые разрешения

• Графический адаптер должен поддерживать воспроизведение в формате NTSC, 60Hz в разрешении 640x480
• Также необходима поддержка частоты вертикальной развертки 59.94Hz во всех разрешениях
• Графический адаптер должен поддерживать разрешение 1600x1200
• Графический адаптер должен поддерживать HDTV разрешения вплоть до 1900x1080p при частоте вертикальной развертки 60Hz.
• При работе с 3D графикой должна быть возможность использования 24-bit двойной буферизации и 32-bit depth буфер (24 bit для z и 8 bit для stencil буферов). Это означает необходимость использования не менее 32 Мб локальной видеопамяти, из которых 8Мб отводится под хранение текстур.
• DAC должен поддерживать загрузку трехканальных таблиц гаммы и ICM.
• Графический адаптер должен поддерживать VESA DDC

Поддержка 2D графики

С целью отсутствия разрывов в изображении (tearing) графический ускоритель должен поддерживать:

• все режимы BLTs и Flips при синхронизации с частотой вертикальной развертки дисплея. Для этого необходима возможность повторного чтения текущей горизонтальной линии выводимого изображения,
• аппаратный курсор с размером 256x256 и 24-bit цветом.

Поддержка 3D графики

• Необходима поддержка FSAA
• Устройство должно поддерживать рендеринг в текстуре для следующих форматов:
  • 32-bit: 888 RGB и 8888 RGBA,
  • 16-bit: 565 RGB и 5551 RGBA.
• Необходимо сохранение информации о alpha канале
• Необходима поддержка 16-bit и 32-bit (24/8) буферов глубины
• Требуется поддержка 8-bit буфера шаблонов, как минимум
• Требуется поддержка методов затенения Flat и Gouraud
• Должен поддерживаться w-based fog (туман)
• Необходима поддержка реализации тумана на уровне пикселей и вертексов
• Рекомендуется поддержка Range-based тумана
• Необходима поддержка текстур размером 2kx2k, как минимум
• Должны поддерживаться текстуры с размерностью некратной 2
• Необходима поддержка Mip Mapping с трилинейной фильтрацией между уровнями
• Необходима поддержка спроецированных текстур

Производительность в 3D графике

• Скорость загрузки текстур должна соответствовать пиковой пропускной способности шины не менее чем 800 Мб в сек. Преобразование форматов текстур должно происходить в видеопамяти аппаратно и автоматически без ущерба производительности.
• Пиксельный fillrate должен соответствовать величине в 1.2GPixels/sec при однопроходном текстурировании с билинейной фильтрацией (или 600 Mp/s при трилинейной фильтрации или наложении двух текстур на пиксель; 400 Mp/s при трилинейной фильтрации одной текстуры и билинейной второй; 300 Mp/s при наложении двух текстур с трилинейной фильтрацией обоих.)
• Скорость расположения полигонов в пространстве отображения должна быть на уровне 50M Poly/s.
• Скорость преобразования координат вершин должна быть на уровне 25M вершин в сек

Q: Как обстоит дело с масштабируемостью D3D8?

Все зависит от того, что подразумевать под словом "масштабируемость".

Microsoft заявляет, что для дальнейшего расширение набора команд и операндов в shader'ах все они (команды и операнды) кодируются в DWORD (т.е. в 32 бита) -- соответственно, их может быть около 4 млрд. Т.е. на ближайшее тысячелетие работы хватит (это если каждый год добавлять 4 миллиона новых команд и операндов :)). В принципе, новая концепция shader'ов (как pixel, так и vertex) полностью охватывает весь спектр задач "масштабируемости" на уровне работы с вершинами и текстурами.

Если подниматься на уровень выше (т.е. на уровень геометрических объектов), то здесь есть основная задача - создание эффективного LOD и его поддержка со стороны железа (т.е. унифицированные вызовы API для этого).

Ещё уровнем выше (сцена) - задача менеджмента сцены (scene graph, etc.) для быстрого выделения объектов, которые надо обрабатывать на этом кадре на нижележащих уровнях (т.е. на уровне объектов и на уровне вершин и текстур).

Но последние два уровня как раз и не входят в D3D, т.к. последний является низкоуровневым API (про D3D Retained Mode лучше даже и не упоминать - неудачная попытка Microsoft создать высокоуровневый API для работы с объектами).

То, что раньше называлось загадочным словом "Fahrenheit" как раз и призвано обеспечить последние два уровня абстракции при работе со сценой. А пока эти два уровня, в основном, и отличают графические движки по степени удобства использования и модификации.

Предусмотрена в начальном виде и такая вещь, как масштабирование текстур. Полноценная поддержка этого будет, вероятно, уже в DX9. Идея в том, чтобы текстуры могли динамически подгружаться с адаптацией их разрешения. Это должно работать на манер того, как организован менеджмент текстур в DX7, но уже с использованием таких интерфейсов, как жесткий диск-память, CD-жесткий диск. Это позволит создать интегрированное решение для существующего конвейера загрузки текстур. Все это позволит приложениям и их содержанию масштабироваться в зависимости от уровня производительности механизма загрузки текстур. Таким образом, нужно создать механизм управления, который бы выбирал оптимальный метод, и место, откуда текстуры загружаются (c HDD, с DVD, из системной или видеопамяти), основываясь не на их количестве, а на скорости загрузки. Цель всего этого - сократить до минимума, а лучше вообще сделать незаметными паузы между загрузками разных уровней игры.

Q: Какое существующее и уже анонсированное аппаратное обеспечение наилучшим образом соответствует возможностям D3D8?

Ну, это просто, хотя список невелик:

• NVIDIA GeForce2 GTS
• ATI RADEON 256
• Неплохо подходит и GeForce 256