Talisman был проектом Microsoft по созданию новой архитектуры 3D-графики , основанной на быстрой компоновке 2D «подизображений» на экране, адаптации мозаичного рендеринга . Теоретически этот подход значительно сократил бы объем пропускной способности памяти, необходимой для 3D-игр, и тем самым привел бы к более дешевым графическим ускорителям . Проект был реализован во время внедрения первых высокопроизводительных 3D-ускорителей, и они быстро превзошли Talisman как по производительности, так и по цене. Системы на основе Talisman никогда не выпускались в продажу, и проект был в конечном итоге закрыт в конце 1990-х годов.
Создание 3D-изображения для отображения состоит из ряда шагов. Сначала объекты, которые должны быть отображены, загружаются в память из отдельных моделей . Затем система отображения применяет математические функции для преобразования моделей в общую систему координат, вид мира . Из этого вида мира создается ряд полигонов (обычно треугольников), которые аппроксимируют исходные модели, видимые с определенной точки зрения, камеры . Затем система композитинга создает изображение, визуализируя треугольники и применяя текстуры к внешней стороне. Текстуры — это небольшие изображения, которые рисуются на треугольниках для создания реализма. Затем полученное изображение комбинируется с различными спецэффектами и перемещается в буферы отображения. Эта базовая концептуальная схема известна как конвейер отображения .
В общих чертах, отображение мало меняется от кадра к кадру; как правило, для любого заданного перехода от кадра к кадру объекты на дисплее, скорее всего, немного сдвинутся, но их форма и текстуры вряд ли изменятся вообще. Изменение геометрии — относительно легкая операция для ЦП , загрузка текстур из памяти значительно более затратная, а затем отправка полученного отрендеренного кадра в буфер кадра — самая затратная операция из всех.
Например, рассмотрим настройки рендеринга той эпохи с 24-битным цветом, с базовым 3D-композитом с трилинейной фильтрацией и без сглаживания : при разрешении 640 x 480 потребуется 1900 Мбит/с пропускной способности памяти; при разрешении 1024 x 768 потребуется 4900 Мбит/с. Даже базовое сглаживание, как ожидается, примерно удвоит эти цифры. [1] Для справки, тогдашние машины SGI RealityEngine2 имели высокую на тот момент пропускную способность памяти около 10 000 Мбит/с, что было причиной того, что эти машины широко использовались в 3D-графике. Типичный ПК той эпохи, использующий AGP 2X, мог предложить только 508 Мбит/с.
Первой атакой на эту проблему стало введение графических ускорителей , которые обрабатывали хранение и отображение текстур. Эти карты, как и оригинальная Voodoo Graphics , заставляли ЦП пересчитывать геометрию для каждого кадра, а затем отправлять результирующий ряд координат на карту. Затем карта обрабатывала остальную часть операции: применяла текстуры к геометрии, визуализировала кадр, применяла фильтрацию или сглаживание и выводила результаты в локальный буфер кадров. Потребности в полосе пропускания в такой системе были значительно снижены; для сцены с 10 000 треугольников могло потребоваться от 500 до 1000 кбит/с, в зависимости от того, сколько точек геометрии могло быть разделено между треугольниками.
По мере увеличения сложности сцены необходимость в повторной генерации геометрии для того, что по сути было фиксированным набором объектов, начала сама по себе становиться узким местом. Гораздо большее улучшение производительности можно было бы получить, если бы видеокарта также хранила и обрабатывала полигоны. В такой системе весь конвейер отображения мог бы работать на карте, требуя минимального взаимодействия с ЦП. Это потребовало бы, чтобы видеокарта была намного «умнее»; в отличие от очень простых операций, связанных с применением текстур, карта теперь должна была бы иметь полный процессор, способный вычислять функции, используемые в 3D-моделировании. В то время ряд компаний исследовали этот путь, так называемые карты « преобразования и освещения » или T&L, но сложность и стоимость систем казались значительными.
Одним из решений, которое изучалось в этот период, была концепция мозаичного рендеринга . Она была основана на наблюдении, что небольшие изменения положения камеры можно имитировать, манипулируя небольшими 2D-изображениями, «плитками». Например, движение камеры в сцене можно имитировать, взяв каждую плитку и сделав ее немного больше. Аналогично, другие движения в сцене можно имитировать с применением соответствующего аффинного преобразования . Однако этот процесс является лишь приблизительным, по мере увеличения движения визуальная точность будет снижаться. Такая система может снизить необходимость пересчета геометрии в среднем до каждых двух-трех кадров.
Проблема с этим подходом заключается в том, что не все плитки обязательно должны быть повторно отрисованы каждый раз, только те, которые содержат объекты близко к камере. Если вся геометрия отправляется на карту, то эта задача может быть полностью обработана на карте, но для этого требуются карты, схожие по сложности с системами T&L. Если геометрия находится под контролем ЦП, то в идеале карта должна иметь возможность попросить ЦП повторно отрисовать только те объекты в плитках, которые устарели. Во многих случаях это потребует изменения конвейера рендеринга ЦП. В любом случае карта и/или драйверы должны знать о порядке и положении объектов, что обычно скрыто в коде.
Talisman представлял собой полный набор программного и аппаратного обеспечения, которое пыталось решить проблему рендеринга плиток. Система делилась некоторой информацией о плитках и объектах внутри них, чтобы выяснить, какие плитки устарели. Если плитка становилась устаревшей, ЦП просили повторно отрисовать объекты в этой плитке и отправить результаты обратно в драйвер, а затем на карту. После того, как конкретная плитка была отрисована на карте, она сохранялась на карте в сжатом формате, чтобы ее можно было повторно использовать в будущих кадрах. Microsoft подсчитала, что каждая плитка могла быть повторно использована в среднем около четырех кадров, тем самым снижая нагрузку на ЦП примерно в четыре раза.
В Talisman буферы изображений были разбиты на «куски» размером 32 x 32 пикселя, которые индивидуально визуализировались с использованием 3D-объектов и текстур, предоставленных центральным процессором. Указатели на куски затем сохранялись в z-упорядоченном (спереди назад) списке для каждых 32 строк сканирования на дисплее. Одна из проблем заключается в том, что куски нельзя чисто «сшить вместе», проблема, которая иногда наблюдалась в различных видеоиграх с использованием программного рендеринга . Чтобы избежать этого, Talisman также хранил отдельный «буфер края» для каждого куска, который хранил область «переполнения», которая покрывала бы пробелы в отображении.
В обычной 3D-системе геометрия периодически генерируется, отправляется на карту для компоновки, компонуется в буфер кадра и затем в конечном итоге подбирается видеооборудованием для отображения. Системы Talisman по сути переворачивают этот процесс; экран делится на полосы по 32 строки, и пока видеооборудование рисует одну из этих полос, оборудование вызывает сторону Talisman и сообщает ей о необходимости подготовить детали для следующей полосы.
Система отреагирует, извлекая любые фрагменты, которые были видны в этой полосе, учитывая текущее местоположение камеры. В типичном случае многие фрагменты будут скрыты другими фрагментами и могут быть проигнорированы во время компоновки, что сэкономит время. Это причина z-сортировки фрагментов, которая позволяет эффективно извлекать их в «порядке видимости». Если фрагменты можно было изменить без искажения, вызывалось соответствующее аффинное преобразование для обновления фрагмента на месте. Если это было невозможно, скажем, потому что камера слишком сильно переместилась с момента последнего полного обновления, процессору предлагалось предоставить новую геометрию для этого фрагмента, которую карта затем визуализировала и помещала обратно в хранилище.
Talisman не имел аналога кадрового буфера, отображая фрагменты по требованию непосредственно на экране по мере продвижения строки сканирования монитора по экрану. Это интересный аналог Atari 2600 , который использует похожую систему для отображения 2D-изображений на экране, метод, известный как «гонка луча». В обоих случаях это уменьшало объем необходимой памяти и пропускную способность памяти, используемую между системой отображения и видеооборудованием. В обоих случаях это также требовало значительно более тесной интеграции между видеосистемой и программами, которые ее запускали. В случае Talisman программы должны были хранить свои объекты в определенном формате, который понимали драйверы программного обеспечения Talisman, что позволяло быстро извлекать их из памяти во время прерываний .
Усилия Talisman были попыткой Microsoft коммерциализировать концепции, над которыми экспериментировали в течение некоторого времени. В частности, система PixelFlow, разработанная в исследовательской лаборатории Hewlett-Packard в Университете Северной Каролины в Чапел-Хилл, может считаться прямым родителем Talisman. [2]
Когда Talisman впервые был широко представлен публике на встрече SIGGRAPH в 1996 году , они обещали резкое снижение стоимости внедрения графической подсистемы. [3] Они планировали работать с вендорами, чтобы продать концепцию Talisman для включения в системы отображения других компаний. То есть, Talisman, как надеялись, станет частью более крупного медиа-чипа, в отличие от целой 3D-системы, которая будет стоять отдельно в системе. Их базовая система будет поддерживать 20-30 000 полигонов на дисплее 1024 x 768 при 32 бит/пиксель, со скоростью рендеринга полигонов 40 Мпикселей/с и скоростью композитинга слоев изображения 320 Мпикселей/с.
В то время Microsoft работала с несколькими поставщиками, чтобы разработать эталонную реализацию, известную как Escalante . Samsung и 3DO работали вместе над разработкой однокристального DSP -подобного «Media Signal Processor» (MSP), объединяющего функциональность Talisman с дополнительной функциональностью мультимедиа. Cirrus Logic должна была предоставить чип VLSI , который извлекал бы данные, помещенные в память MSP, применял эффекты и отправлял бы их на дисплей. Известный как «Polygon Object Processor» (POP), этот чип периодически опрашивался другим чипом Cirrus Logic, «Image Layer Compositor» (ILC), который был связан с видеосхемой. Кроме того, Escalante намеревался представить 4 МБ RDRAM на двух 600 МГц 8-битных каналах, предлагая пропускную способность 1,2 ГБ/с. [4] Позже Philips вступила в борьбу с запланированной новой версией своего процессора TriMedia , который реализовал большую часть Talisman в одном ЦП, и Trident Microsystems с похожими планами.
Именно в разгар проекта Talisman жанр шутеров от первого лица начал выходить на первый план в играх. Это создало рыночный спрос на ускорители, которые можно было бы использовать с существующими играми с минимальными изменениями. К тому времени, как эталонный дизайн Escalante был готов к производству, рыночные силы уже привели к появлению серии новых дизайнов карт с такой улучшенной производительностью, что карты Talisman просто не могли конкурировать. Карты с большим объемом оперативной памяти, организованные для обеспечения чрезвычайно высоких скоростей, решили проблему пропускной способности, просто грубо надавив на проблему вместо того, чтобы попытаться решить ее с помощью умной реализации.
Кроме того, концепция Talisman требовала тесной интеграции между системой отображения и программным обеспечением, которое ее использовало. В отличие от новых 3D-карт, поступавших на рынок в то время, системы Talisman должны были иметь возможность запрашивать у ЦП повторную визуализацию частей изображения, чтобы обновить их фрагменты. Это требовало, чтобы игры имели определенную организацию в памяти, чтобы отвечать на эти запросы. Чтобы помочь разработчикам в этой задаче, Direct3D был изменен, чтобы более точно соответствовать потребностям Talisman. Однако для любой игры, которая уже была написана, или тех, которые не хотели быть привязанными к Talisman, это делало систему D3D медленнее и значительно менее интересной.
В результате этих изменений Talisman так и не стал коммерческим продуктом. Cirrus Logic и Samsung отказались от системы в 1997 году, что привело к тому, что Microsoft отказалась от планов выпустить Escalante в 1997 году, и для внешних наблюдателей казалось, что весь проект мертв. [5]
Однако вскоре после этого произошло краткое возрождение, когда Fujitsu заявила, что работает над одночиповой реализацией, которая будет доступна в 1998 году, и ходили слухи о похожих проектах в S3 Graphics и ATI Technologies . [6] Ни одна из этих систем так и не была отправлена, и Talisman был тихо убит. Это было большой радостью для сторонних поставщиков графических ускорителей, а также для людей в Microsoft, которые поддерживали их на рынке с DirectX .
Тем не менее, несколько идей, впервые реализованных в системе Talisman, с тех пор стали обычными для большинства ускорителей. В частности, теперь широко используется сжатие текстур. На более поздних картах сжатие также использовалось в z-буферах для снижения требований к памяти при сортировке дисплея. Идея использования «кусков» для сортировки дисплея также использовалась в небольшом количестве карт, что называется рендерингом на основе плиток . Многие графические процессоры, специально разработанные для мобильных устройств (например, сотовых телефонов), используют подход на основе плиток. Только одна ключевая идея Talisman, запрашивающая обновления геометрии только «при необходимости», с тех пор не была опробована.