Многие программисты, как я обнаружил, очень легкомысленно относятся к англоязычным терминам и вместо того, чтобы посмотреть правильное произношение того или иного слова, выдумывают собственное. Понятно что каждый выдумывает что-то своё и в итоге получается дикий разнобой в произношениях. Я же взял себе в привычку стараться правильно произносить термины и аббревиатуры, т. к. считаю это признаком хорошего тона и уважения к своей профессии.
Например, CPU и GPU. Многие произносят их как "Цэ-Пэ-У" и "Гэ-Пэ-У". Я так не могу! Путём некоторых усилий у меня выработалась привычка произносить эти аббревиатуры правильно: "Си-Пи-Ю" и "Джи-Пи-Ю".
Или вот другой пример. Популярное словечко "deferred" я раньше произносил с ударением на второй слог. Мой лид - с ударением на первый. При этом оба произношения можно было записать как "Дэферред". Я решил заглянуть в Google Dictionary и обнаружил, что звучит это слово на самом деле примерно как "Ди'фё(у)р(д)" (ударение на второй слог, "d" практически не слышно):
deferred. Круто.
Сделал вывод: надо не лениться и почаще заглядывать в Google Dictionary, а то стыдно сыпать доморощенными произношениями.
вторник, 29 сентября 2009 г.
четверг, 24 сентября 2009 г.
ID3D11CommandList
Занятно, что в D3D 11 появился этот интерфейс (в 10 его не было, в 9 были какие-то функции для записи/воспроизведения стейтов), в то время как в OpenGL 3.2 дисплейные списки убрали. Слышал, что парни из NVIDIA недовольны таким решением - ещё бы, после стольких лет отладки этих самых списков! Тред на эту тему можно почитать здесь: Siggraph Asia 2008 slides suggestions for OpenGL.
Вся беда в том, что хоть у NVIDIA они и отлажены, но в целом это дикая штуковина. Вот пример:
В общем, комитет отправил эту хрень в преисподнюю, вслед за immediate mode.
В Direct3D 11 схема работы следующая: можно создать один immediate контекст, для которого вызовы складываются в command buffer и выполняются, а можно в дополнение создать множество deferred контекстов, для которых вызовы складываются во внутренний command list, и после вызова ID3D11DeviceContext::FinishCommandList() вы получаете указатель на объект интерфейса ID3D11CommandList, в котором записаны все команды, поданные со времени предыдущего вызова ::FinishCommandList() или со времени создания контекста. Затем этот command list можно выполнить на immediate контексте вызовом ID3D11DeviceContext::ExecuteCommandList().
Сначала я недоумевал, почему есть Finish функция, но нет Begin. Ответ прост - сами по себе любые вызовы для deferred контекста не имеют никакого значения, они не идут в command buffer, а значит, и обрамляющая пара Begin/End - не нужна.
Судя по тому, что написано в SDK, command lists формируются очень быстро (не так медленно, как скажем, стейты через ::Create*State()), их можно формировать каждый кадр, параллельно, на нескольких ядрах в многоядерной системе. Если же драйвер/железо не поддерживают это, то command lists всё равно полезны как средство формирования command buffer, скажем, перед циклом рендеринга. Правда, пока неясно, что именно туда можно складывать - помните, сколько было ограничений в OpenGL с этим: "Certain commands, when called while compiling a display list, are not compiled into the display list but are executed immediately."
Вся беда в том, что хоть у NVIDIA они и отлажены, но в целом это дикая штуковина. Вот пример:
glNewList(42, GL_COMPILE);
glVertex3f(0,1,0);
glColor3f(1,0,0);
glVertex3f(1,1,1);
glEnd();
glEndList();
glBegin();
glColor3f(0,1,0);
glVertex3f(0,0,0);
glColor3f(0,0,1);
glCallList(42);
// note the lack of glEnd() - it's in the display list!
В общем, комитет отправил эту хрень в преисподнюю, вслед за immediate mode.
В Direct3D 11 схема работы следующая: можно создать один immediate контекст, для которого вызовы складываются в command buffer и выполняются, а можно в дополнение создать множество deferred контекстов, для которых вызовы складываются во внутренний command list, и после вызова ID3D11DeviceContext::FinishCommandList() вы получаете указатель на объект интерфейса ID3D11CommandList, в котором записаны все команды, поданные со времени предыдущего вызова ::FinishCommandList() или со времени создания контекста. Затем этот command list можно выполнить на immediate контексте вызовом ID3D11DeviceContext::ExecuteCommandList().
Сначала я недоумевал, почему есть Finish функция, но нет Begin. Ответ прост - сами по себе любые вызовы для deferred контекста не имеют никакого значения, они не идут в command buffer, а значит, и обрамляющая пара Begin/End - не нужна.
Судя по тому, что написано в SDK, command lists формируются очень быстро (не так медленно, как скажем, стейты через ::Create*State()), их можно формировать каждый кадр, параллельно, на нескольких ядрах в многоядерной системе. Если же драйвер/железо не поддерживают это, то command lists всё равно полезны как средство формирования command buffer, скажем, перед циклом рендеринга. Правда, пока неясно, что именно туда можно складывать - помните, сколько было ограничений в OpenGL с этим: "Certain commands, when called while compiling a display list, are not compiled into the display list but are executed immediately."
DirectX 11 первые разборки
Начал копать сабж. Всем кто в теме понятно, что принципиальных отличий от 10-ой версии нет, просто расширен фичелист и включены старые профили. Но не тут-то было.
Первой трудностью стало создание девайса и своп чейна по образу и подобию D3D 10. Портированный 1 к 1 код (заменил только нумерацию токенов и интерфейсов с 10 на 11) не захотел работать. Пришлось воспользоваться готовой функцией D3D11CreateDeviceAndSwapChain(). Смотрел DXUT, но там как-то мудрёно проходит инициализация DXGI, через QueryInterface() и т. д. В общем надо разбираться.
Во-вторых, из ядра убран FX. Т. е. в 10 был интерфейс ID3D10Effect и ещё куча сопутствующих интерфейсов, теперь MS решили перебросить их назад в D3DX. В принципе - правильно, т. к. FX сам по себе - просто толстая обёртка над интерфейсами ядра. Я использовал интерфейсы FX'a в 10 т. к. код с ними получался компактнее, да и примеры из SDK тоже их использовали повсеместно. Теперь же для них придётся таскать за собой d3dx11_NN.dll. Ещё беда в том что в August 2009 SDK нет никаких ID3DX11Effect(XXX) и Create-функций - видимо ещё в разработке (в SDK ни слова об этом, если найдёте - пишите). Проверил для надёжности сэмплы - везде используют функции ядра и свои функции-оболочки загрузки/компиляции шейдеров.
И последнее. В ID3D11Device остались только тяжёлые Create-функции. Вся работа с пайплайном (включая Map/Unmap ресурсов) перенесена в ID3D11DeviceContext, для эффективного формирования command-буфера на многоядерных машинах.
Первой трудностью стало создание девайса и своп чейна по образу и подобию D3D 10. Портированный 1 к 1 код (заменил только нумерацию токенов и интерфейсов с 10 на 11) не захотел работать. Пришлось воспользоваться готовой функцией D3D11CreateDeviceAndSwapChain(). Смотрел DXUT, но там как-то мудрёно проходит инициализация DXGI, через QueryInterface() и т. д. В общем надо разбираться.
Во-вторых, из ядра убран FX. Т. е. в 10 был интерфейс ID3D10Effect и ещё куча сопутствующих интерфейсов, теперь MS решили перебросить их назад в D3DX. В принципе - правильно, т. к. FX сам по себе - просто толстая обёртка над интерфейсами ядра. Я использовал интерфейсы FX'a в 10 т. к. код с ними получался компактнее, да и примеры из SDK тоже их использовали повсеместно. Теперь же для них придётся таскать за собой d3dx11_NN.dll. Ещё беда в том что в August 2009 SDK нет никаких ID3DX11Effect(XXX) и Create-функций - видимо ещё в разработке (в SDK ни слова об этом, если найдёте - пишите). Проверил для надёжности сэмплы - везде используют функции ядра и свои функции-оболочки загрузки/компиляции шейдеров.
И последнее. В ID3D11Device остались только тяжёлые Create-функции. Вся работа с пайплайном (включая Map/Unmap ресурсов) перенесена в ID3D11DeviceContext, для эффективного формирования command-буфера на многоядерных машинах.
среда, 23 сентября 2009 г.
Windows Seven
Приехал домой, решил снести Висту и поставить хоть какую-нить Семёрку из доступных.
Всё началось с того, что пров позакрывал все локальные трекеры за то время, что я отсутствовал в нашей дыре. А т. к. интернет у меня не анлим, и дороговато за метр, то слить образ оказалось невозможным - казлы! Надо сваливать с нашего Ориентала, в конец зажрались... C плясками и перебором апишников нашёл новый трекер в локалке (уже организовали, надолго ли?). В общем нашёл я образ, прожёг, поставил вместо Висты.
Общие впечатления: хороша! У меня до сих пор Athlon 3000+, 1GB RAM и бегает она на этой системе довольно резво (сравнивать есть с чем, сидел на Висте два года). Окна программ открываются без мучительных раздумий, Панель Управления - тоже на удивление быстро. Есть большинство кодеков под разные видеоформаты. Ещё один плюс - наконец-то сделали юзабельным Windows Media Player. OMG! Раньше я пользовался чем угодно, но только не этим г..ом. В общем, в MS наконец-то научились пользоваться профайлером, а заодно сбросили кучу шлака, который они понапихали в Висту, с идиотской мыслью что это кому-то может понадобиться.
Одно огорчило: не заработала сетка. То ли из-за багов в кандидате, то ли из-за драйверов на мамку NVIDIA (они вообще под XP, но под Вистой работали). Пишет: Сбой подключения с ошибкой 651. А поди ты обнови дрова на мамку когда подключения к сети нет. Экая задача!
В общем, пришлось поставить XP второй ОС на D:\, ради сети. При этом она затёрла бут и загружалась одна, пришлось ставить Семёрку на C:\ и вслед за ней всё барахло второй раз :) Тут как кстати невольно появилась возможность сравнить скорость работы свежеустановленных XP и Семёрки. Хрюшка всё-таки чуток быстрее, но учитывая что моя конфигурация уже на айс, это простительно.
А зачем ставил? Ради DirectX 11, конечно же.
PS. Порыскал по инету - баг семёрки. Может быть даже и умышленный :(
Всё началось с того, что пров позакрывал все локальные трекеры за то время, что я отсутствовал в нашей дыре. А т. к. интернет у меня не анлим, и дороговато за метр, то слить образ оказалось невозможным - казлы! Надо сваливать с нашего Ориентала, в конец зажрались... C плясками и перебором апишников нашёл новый трекер в локалке (уже организовали, надолго ли?). В общем нашёл я образ, прожёг, поставил вместо Висты.
Общие впечатления: хороша! У меня до сих пор Athlon 3000+, 1GB RAM и бегает она на этой системе довольно резво (сравнивать есть с чем, сидел на Висте два года). Окна программ открываются без мучительных раздумий, Панель Управления - тоже на удивление быстро. Есть большинство кодеков под разные видеоформаты. Ещё один плюс - наконец-то сделали юзабельным Windows Media Player. OMG! Раньше я пользовался чем угодно, но только не этим г..ом. В общем, в MS наконец-то научились пользоваться профайлером, а заодно сбросили кучу шлака, который они понапихали в Висту, с идиотской мыслью что это кому-то может понадобиться.
Одно огорчило: не заработала сетка. То ли из-за багов в кандидате, то ли из-за драйверов на мамку NVIDIA (они вообще под XP, но под Вистой работали). Пишет: Сбой подключения с ошибкой 651. А поди ты обнови дрова на мамку когда подключения к сети нет. Экая задача!
В общем, пришлось поставить XP второй ОС на D:\, ради сети. При этом она затёрла бут и загружалась одна, пришлось ставить Семёрку на C:\ и вслед за ней всё барахло второй раз :) Тут как кстати невольно появилась возможность сравнить скорость работы свежеустановленных XP и Семёрки. Хрюшка всё-таки чуток быстрее, но учитывая что моя конфигурация уже на айс, это простительно.
А зачем ставил? Ради DirectX 11, конечно же.
PS. Порыскал по инету - баг семёрки. Может быть даже и умышленный :(
четверг, 17 сентября 2009 г.
Всё скисло
Всё. Из-за финансовых проблем Vogster Entertainment заморозил все проекты. Всех распускают, в бессрочный отпуск. Скорее всего, для меня как новичка в этой компании - это КОНЕЦ.
воскресенье, 13 сентября 2009 г.
А вам нравится жить в Гондурасе?
Toute nation a le gouvernement qu'elle mérite.
Joseph de Maistre
Жить в Гондурасе с нашим гарантом становится неуютно!
Надвигаются президентские выборы 2010 года, и конечно же, начнётся старая песня на новый лад! Восток хочет стабильности (вернее - стабильной нищеты) - будет голосовать за марионетку Проффесора, административный ресурс рулит (за одно только публичное упоминание этого термина надо давать срок, я считаю). Центр и Север - за Юлю, т. к. против Проффесора. На у как же ещё??? Бабульки традиционно - за коммунистов... Горбатого могила исправит. 18-ти летнюю школоту и чуть постарше в расчёт не берём, им на всё глубоко... (додумайте сами).
В нашей неньке становится страшно жить, и вовсе не из-за беспредела, который творят чиновники и богатеи, а из-за наc самих. Как послушное стадо овец "сильные мира сего" погонят нас на очередные выборы, где создадут искусную иллюзию будто от наших голосов что-то зависит. Боюсь мы не знали и не знаем, что значит действительно жить в высокоразвитой стране как достойные люди, это превращается в некую призрачную мечту... Люди уже не думают о ней, а в "предвыборных программах" кандидатов в президенты первоочередными пунктами идут возвращение депозитов населению и придание русскому языку статуса второго государственного... Приехали!
Вот вам для примера видео с ютюба (между прочим, этот человек стал мэром вполне законно, получив 40% голосов):
Мэр города Харькова Михаил Добкин
Какую патоку он заливал в уши харьковчан:
Состояние дорог - больное место Харькова в каждой точке города... Харьковчане должны жить в удобном для жизни городе... Проезд по городу станет быстрым, удобным и выгодным - для всех харьковчан... Здоровье харьковчан - главное богатство нашего города... Вместо необдуманного повышения тарифов нужен комплексный подход к жилищно-коммунальной сфере... Мы вернём доверие харьковчан и будем качественно обслуживать жилые дома... Мы сделаем Харьков чистым и благоустроенным... Мы обеспечим для этого необходимое финансирование, а также создадим условия для притока инвестиций в город. В городской бюджен поступит значительно больше денег, и эти средства поступят на благо города и всех харьковчан...
Вдогонку:
Друг Добкина, Геннадий «Гепа» Кернесс
Добкін та Луценко про затримання Кернеса
А вот видео с Леней из Космоса (ну да это баян):
Леонид Черновецкий
Внимательно смотрите и пересматривайте это видео - да, смешно, но на самом деле подобный смех отдаёт быдлизмом. И думайте в конце-концов своей головой, и если не о своём, так о будущем своих детей, прежде чем ставить галочку на бюллетене!
В Гондурасе становится оч-чень не прикольно. Перспектив никаких... Если и дальше так дело пойдёт, придётся отсюда сваливать, как это делают все трезвомыслящие люди.
Каждый народ имеет то правительство, которое он заслуживает.
Жозеф де Местр
PS. Где про СКОРЫЕ ПОМОЩИ, БЛЯТЬ?!! Давай по-новой Миша. Всё хуйня!
суббота, 12 сентября 2009 г.
Apple MacBook Air TV Commercial
Apple MacBook Air TV Commercial
Тонкий и лёгкий. Как и ваш кошелёк, когда вы заплатите за эту чёртову штукенцию :)
Тонкий и лёгкий. Как и ваш кошелёк, когда вы заплатите за эту чёртову штукенцию :)
четверг, 10 сентября 2009 г.
AMD's DirectX 11 GPU Launch
Сегодня, 10 сентября, AMD должна официально представить новое поколение видеокарт - Radeon HD 5870/5850. Они выполнены по 40-нм процессу и носят кодовое название "Evergreen". Ланч должен состояться на авианосце U.S.S. Hornet, пришвартованным в Аламеде, Калифорния. В этот раз, впервые с момента выпуска Radeon 9700, объёдинённые силы AMD/ATI оказались впереди бессменного лидера в лице компании NVIDIA!
AMD “Evergreen” Graphics Chips: You Won’t Believe Your Eyes… Nvidia!
AMD Beats Intel, Nvidia At Supporting Windows 7 High-End Graphics
Это - самое значительное событие в производстве трёхмерных ускорителей с момента их появления и начало заката эры растеризаторов.
воскресенье, 6 сентября 2009 г.
How antialiasing works. Part 3.
AMD/ATI также не стоят на месте. И как обычно, идут к новым вершинам своим путём, отличным от того, что выбрала NVIDIA.
С выходом видеокарт R600 (Radeon HD 2000), AMD/ATI представила новую разновидность антиалиасинга - CFAA (Custom Filter Anti-Aliasing). Его идея заключается в том, чтобы делать resolve не в blit engine видеокарты, а в программируемом шейдерном процессоре, т. к. Direct3D 10 железо способно читать отдельные color сэмплы из текстуры (отдельные depth сэмплы - в Direct3D 10.1). C появлением CFAA видеокарты AMD/ATI владеют cледующими программируемыми фильтрами выборки:
1. Box filter.
2. Narrow tent.
3. Wide tent.
4. Adaptive edge detect.
Нужно сказать, что последний вариант появился только с выходом RV770, потом поддержка распространилась и на предыдущее поколение DX10 видеокарт.
Box filter это стандартный способ выборки нескольких сэмплов в пределах границ фрагмента. Ниже изображён вариант 8xMSAA:
Narrow tent делает выборку 50% дополнительных сэмплов за границами фрагмента. Вариант 12xCFAA:
Wide tent работает так же, как и Narrow tent, но делает выборку 100% дополнительных сэмплов. Т. е. при 8x мультисэмплинге делается выборка из 16 сэмплов (16xCFAA):
Фильтры narrow tent и wide tent как способы сглаживания изображения не являются идеологически правильными, т. к. выборка за пределами фрагмента приводит не только к сглаживанию границ, но и к размытию изображения. AMD не вдаётся в подробное объяснение работы фильтров, но скорее всего усреднение происходит на основе весов, где центральные сэмплы имеют наибольшие веса, а удалённые от центра - наименьшие.
Последний и наиболее продвинутый фильтр - adaptive edge detect:
Программируемый фильтр выборки в случае использования этого режима осуществляет выборку сэмплов только в районе границы трегольника. Это повышает качество сглаживания, что особенно хорошо заметно на мелких деталях и позволяет избежать излишнего «замыливания», свойственного предыдущим фильтрам. AMD заявляет, что edge detect сглаживает не только края треугольников, но и края стенсельных теней и даже пиксели внутри текстур, что позволяет предполагать, что алгоритм использует в своей работе информацию о цвете сэмплов, а не об их Z-значениях. Расход видеопамяти остаётся таким же, как в случае использования обычных режимов MSAA 4x и 8x. В режиме 4xMSAA производится 12 выборок, а в 8xMSAA - 24. Следует отметить, что в последнем случае производительность видеокарты существенно "проседает".
Ниже приводится таблица возможных CFAA-фильтров:
Mode Filter
4x CFAA 2x + Narrow Tent
6x CFAA 2x + Wide Tent or 4x Narrow tent
8x CFAA 4x + Wide Tent
12x CFAA 8x + Narrow Tent
16x CFAA 4x + Wide Tent
24x CFAA 8x + Edge Detect
С выходом видеокарт R600 (Radeon HD 2000), AMD/ATI представила новую разновидность антиалиасинга - CFAA (Custom Filter Anti-Aliasing). Его идея заключается в том, чтобы делать resolve не в blit engine видеокарты, а в программируемом шейдерном процессоре, т. к. Direct3D 10 железо способно читать отдельные color сэмплы из текстуры (отдельные depth сэмплы - в Direct3D 10.1). C появлением CFAA видеокарты AMD/ATI владеют cледующими программируемыми фильтрами выборки:
1. Box filter.
2. Narrow tent.
3. Wide tent.
4. Adaptive edge detect.
Нужно сказать, что последний вариант появился только с выходом RV770, потом поддержка распространилась и на предыдущее поколение DX10 видеокарт.
Box filter это стандартный способ выборки нескольких сэмплов в пределах границ фрагмента. Ниже изображён вариант 8xMSAA:
Narrow tent делает выборку 50% дополнительных сэмплов за границами фрагмента. Вариант 12xCFAA:
Wide tent работает так же, как и Narrow tent, но делает выборку 100% дополнительных сэмплов. Т. е. при 8x мультисэмплинге делается выборка из 16 сэмплов (16xCFAA):
Фильтры narrow tent и wide tent как способы сглаживания изображения не являются идеологически правильными, т. к. выборка за пределами фрагмента приводит не только к сглаживанию границ, но и к размытию изображения. AMD не вдаётся в подробное объяснение работы фильтров, но скорее всего усреднение происходит на основе весов, где центральные сэмплы имеют наибольшие веса, а удалённые от центра - наименьшие.
Последний и наиболее продвинутый фильтр - adaptive edge detect:
Программируемый фильтр выборки в случае использования этого режима осуществляет выборку сэмплов только в районе границы трегольника. Это повышает качество сглаживания, что особенно хорошо заметно на мелких деталях и позволяет избежать излишнего «замыливания», свойственного предыдущим фильтрам. AMD заявляет, что edge detect сглаживает не только края треугольников, но и края стенсельных теней и даже пиксели внутри текстур, что позволяет предполагать, что алгоритм использует в своей работе информацию о цвете сэмплов, а не об их Z-значениях. Расход видеопамяти остаётся таким же, как в случае использования обычных режимов MSAA 4x и 8x. В режиме 4xMSAA производится 12 выборок, а в 8xMSAA - 24. Следует отметить, что в последнем случае производительность видеокарты существенно "проседает".
Ниже приводится таблица возможных CFAA-фильтров:
Mode Filter
4x CFAA 2x + Narrow Tent
6x CFAA 2x + Wide Tent or 4x Narrow tent
8x CFAA 4x + Wide Tent
12x CFAA 8x + Narrow Tent
16x CFAA 4x + Wide Tent
24x CFAA 8x + Edge Detect
суббота, 5 сентября 2009 г.
How antialiasing works. Part 2.
Нетрудно догадаться, что качество сглаживания изображения методом мультисэмплинга зависит от кол-ва сэмплов на фрагмент. Максимальное их кол-во, которое аппаратно поддерживается на сегодня - 8. Хочется больше, но дальнейшее увеличение кол-ва сэмплов приводит к неоправданным расходам памяти а пропускной способности чипов. Возьмём типичное разрешение 1280x1024. Уровень 16xMSAA означает, что нам нужен буфер отсчётов размером 5120х4096. Если предположить, что под Z/stencil буфер отведено 32 бита, а буфер цвета имеет формат R16G16B16A16 (64 бита), то буфер отсчётов займёт 20 971 520 х 96 / 8 = 251 658 240 байт = 240 Мбайт видеопамяти. Это просто нереально, для любого потребительского железа.
Чтобы сдвинуть технологию мультисэмплинга с мёртвой точки, NVIDIA представила в G80 CSAA - Coverage Sampling Anti-Aliasing. Главной особенностью нового метода стало более точное определение, какую площадь фрагмента покрывают границы треугольника. Если MSAA отделил закрашиваемый фрагмент от отдельных сэмплов, экономя на вызове фрагментного шейдера и выборках из текстуры, то CSAA расширил его, отделив значение охвата от color/z/stencil значений в сэмпле. И если кол-во обычных сэмплов в CSAA осталось неизменным (4 или 8), то кол-во сэмплов охвата увеличилось до 8 или 16. А т. к. значение охвата представляет собой всего лишь битовую маску, требования к памяти и пропускной способности возрастают незначительно.
NVIDIA не вдаётся в детали реализации этой технологии, но можно попробовать представить себе, как примерно всё работает. Во-первых, буфер охвата тесно связан с z-буфером, т. к. значения глубины и охвата обновляются одновременно:
1) Читается coverage бит. Если он равен 0, сэмпл охвата пропускается.
2) Если от равен 1, читается цвет из color/z/stencil сэмпла, на который указывает сэмпл охвата.
Т. к. кол-во сэмплов охвата больше, чем обычных сэмплов, то их цвета выбираются и усредняются более точно, в зависимости от площади покрытия фрагмента треугольником.
Конечно, 8xCSAA уступает в качестве изображения 8xMSAA, как и 16xCSAA по сравнению с теоретическим 16xMSAA. Тем не менее, он требует лишь незначительного увеличения памяти для хранения сэмплов охвата и улучшает качество изображения по сравнению с обычным MSAA.
Coverage Sampling Antialiasing
What is CSAA?
Чтобы сдвинуть технологию мультисэмплинга с мёртвой точки, NVIDIA представила в G80 CSAA - Coverage Sampling Anti-Aliasing. Главной особенностью нового метода стало более точное определение, какую площадь фрагмента покрывают границы треугольника. Если MSAA отделил закрашиваемый фрагмент от отдельных сэмплов, экономя на вызове фрагментного шейдера и выборках из текстуры, то CSAA расширил его, отделив значение охвата от color/z/stencil значений в сэмпле. И если кол-во обычных сэмплов в CSAA осталось неизменным (4 или 8), то кол-во сэмплов охвата увеличилось до 8 или 16. А т. к. значение охвата представляет собой всего лишь битовую маску, требования к памяти и пропускной способности возрастают незначительно.
NVIDIA не вдаётся в детали реализации этой технологии, но можно попробовать представить себе, как примерно всё работает. Во-первых, буфер охвата тесно связан с z-буфером, т. к. значения глубины и охвата обновляются одновременно:
Try to avoid updating color and z independently, as CSAA coverage information is only updated when z is being written.Для разработчиков NVIDIA приводит некоторые советы, как правильно осуществлять рендеринг при включенном CSAA - избегать разделения z-буфера между несколькими целями рендеринга без предварительной очистки, избегать частичной очистки z-буфера. Для правильной работы, сэмпл охвата должен знать, с какими сэмплами color/z/stencil он связан. Поэтому к одному coverage биту нужны ещё три, чтобы индексировать один из восьми сэмплов. После того, как в буфере отсчётов будет сформировано изображение, усреднение цветов сэмплов должно происходить так:
1) Читается coverage бит. Если он равен 0, сэмпл охвата пропускается.
2) Если от равен 1, читается цвет из color/z/stencil сэмпла, на который указывает сэмпл охвата.
Т. к. кол-во сэмплов охвата больше, чем обычных сэмплов, то их цвета выбираются и усредняются более точно, в зависимости от площади покрытия фрагмента треугольником.
Конечно, 8xCSAA уступает в качестве изображения 8xMSAA, как и 16xCSAA по сравнению с теоретическим 16xMSAA. Тем не менее, он требует лишь незначительного увеличения памяти для хранения сэмплов охвата и улучшает качество изображения по сравнению с обычным MSAA.
Coverage Sampling Antialiasing
What is CSAA?
пятница, 4 сентября 2009 г.
How antialiasing works. Part 1.
Недавно я осознал, что мои познания в области антиалиаcинга на современных GPU - весьма посредственные. Учитывая, что появляются новые его разновидности, а также то, что теперь можно делать deferred rendering и HDR rendering с включенными антиалиасингом, необходимо разобраться в предмете более подробно. Т. к. тема обширная, разбираться буду постепенно и разобью обзор на несколько частей.
Для начала: cуществует несколько видов антиалиасинга. Простейший из них - это суперсэмплинг (аббревиатура SSAA или FSAA - Full-Scene Anti-Aliasing). Такой вариант антиалиасинга поддерживался, например, в NV10. Суперсэмплинг не требует специальной аппаратной поддержки и реализуется очень просто: сцена рисуется в буфер бОльшего разрешения, а потом сжимается с фильтрацией в меньшее разрешение. Фильтрация осуществляется путём простого усреднения цветов соседних пикселей. Например, если ваше конечное разрешение - 1024х768, то при 4x суперсэмплинге FSAA буфер должен иметь разрешение 2048х1536. Понятно, что этот способ очень сильно нагружает филлрейт - производительность падает примерно пропорционально увеличению разрешения, т. к. расчёт цвета и выборка из текстуры делается для каждого субпикселя. Такое падение производительности происходило на упомянутом GeForce 2. Впрочем, у этого метода есть одно преимущество - он способен сглаживать изображение, которое не было нарисовано с помощью треугольников (а, например, рассчитано в фрагментном шейдере).
Другой, более продвинутый вариант антиалисинга - это мультисэмплинг (MSAA - Multi-Sample Anti-Aliasing). Если копнуть в прошлое, то можно найти расширение OpenGL GL_SGIS_multisample от 1994 года - уже тогда на рабочих станциях SGI была его разновидность. На consumer hardware мультисэмплинг появился впервые, видимо, на видеокартах 3dfx (серия Voodoo 5), для этих видеокарт существовало ограниченное расширение GL_3DFX_multisample. NVIDIA впервые реализовала поддержку этого вида антиалиасинга в NV20 (GeForce 3). С тех пор MSAA с теми или иными вариациями реализуется на всех поколениях графического железа.
При мультисэмплинге фрагмент изображения перестаёт быть своего рода "атомом" (др.-греч. ἄτομος — неделимый). У него появляется внутренняя, невидимая до поры до времени структура - отдельные сэмплы (отсчёты). Говоря образно, у фрагмента появляется своё собственное разрешение (пусть и небольшое), и он способен "видеть" растеризуемые примитивы более подробно. Типичное кол-во сэмплов, которые определяют уровень антиалиасинга - 2, 4, 6 и 8.
Теперь разберём техническую сторону вопроса более подробно (я черпал информацию в основном из расширения GL_ARB_multisample и сверял с другими источниками).
Если формат пикселя кадрового буфера поддерживает мультисэмплинг, то к кадровому буферу добавляется специальный буфер отсчётов (multisample buffer). Такие значения сэмплов фрагмента, как цвет, глубина и значение трафарета сохраняются в этом буфере. Также с каждым фрагментом изображения связывается так называемое значение охвата (coverage value), кол-во бит в котором равно кол-ву сэмплов на фрагмент. Т. е. для каждого сэмпла отводится один бит из значения охвата. Эти дополнительные данные нужны для того, чтобы понять, какая площадь фрагмента перекрывается треугольником.
Сэмплы фрагмента могут располагаться как в пределах его границ, так и за его пределами. Более того, от пикселя к пикселю и от кадра к кадру их положения относительно центра фрагмента могут варьироваться - это зависит от деталей аппаратной реализации. К этому вопросу я вернусь позже.
Если в процессе растеризации сэмпл (как идеальная точка) попадает внутрь растеризуемого примитива или оказывается на его границе, то бит в значении охвата для этого сэмпла устанавливается в 1, иначе в 0. Тесты глубины и трафарета, а также смешивание (blending) цветов выполняются на уровне отдельных сэмплов, а не на уровне фрагмента. Кроме того, они выполняются только для тех сэмплов, для которых бит в значении охвата установлен в 1, иначе все операции для этого сэмпла пропускаются. Если тест трафарета или тест глубины проваливается, прекращается дальнейшая обработка только данного сэмпла, а не всего фрагмента. Фрагментный шейдер (или простая выборка из текстуры в случае FFP на NV20/25) всегда выполяется на уровне фрагмента, и все сэмплы получают одинаковое значение цвета, но значение глубины генерируется растеризатором для каждого сэмпла отдельно. (TODO: неясно, что происходит со значением глубины, если оно модифицируется в шейдере?). Согласно спецификации, значение трафарета генерируется для всего фрагмента, а не для каждого сэмпла отдельно:
После того, как все операции в буфере отсчётов завершены, цвета отдельных сэмплов фрагмента усредняются и результат записывается в буфер кадра. Метод усреднения зависит от конкретной реализации и уровня мультисэмплинга. В спецификации рекомендуется простое усреднение, рассчитанное независимо для каждого компонента цвета.
Как видно, основным преимуществом MSAA метода перед FSAA является меньшее кол-во текстурных выборок и вызовов фрагментного шейдера, хотя требования к памяти и framebuffer bandwidth остаются неизменными. Здесь появляется некоторая свобода, т. к. одно и тоже значение цвета для нескольких сэмплов позволяет задействовать цветовую компрессию:
Недостатком метода является сглаживание только вдоль рёбер треугольников, т. к. только там значения охвата могут отличаться от 1. Внутри треугольников изображение не сглаживается. Обычно это совсем незаметно из-за текстурной фильтрации, но если используется текстура с альфа-тестом, появляется сильный алиасинг.
Для начала: cуществует несколько видов антиалиасинга. Простейший из них - это суперсэмплинг (аббревиатура SSAA или FSAA - Full-Scene Anti-Aliasing). Такой вариант антиалиасинга поддерживался, например, в NV10. Суперсэмплинг не требует специальной аппаратной поддержки и реализуется очень просто: сцена рисуется в буфер бОльшего разрешения, а потом сжимается с фильтрацией в меньшее разрешение. Фильтрация осуществляется путём простого усреднения цветов соседних пикселей. Например, если ваше конечное разрешение - 1024х768, то при 4x суперсэмплинге FSAA буфер должен иметь разрешение 2048х1536. Понятно, что этот способ очень сильно нагружает филлрейт - производительность падает примерно пропорционально увеличению разрешения, т. к. расчёт цвета и выборка из текстуры делается для каждого субпикселя. Такое падение производительности происходило на упомянутом GeForce 2. Впрочем, у этого метода есть одно преимущество - он способен сглаживать изображение, которое не было нарисовано с помощью треугольников (а, например, рассчитано в фрагментном шейдере).
Другой, более продвинутый вариант антиалисинга - это мультисэмплинг (MSAA - Multi-Sample Anti-Aliasing). Если копнуть в прошлое, то можно найти расширение OpenGL GL_SGIS_multisample от 1994 года - уже тогда на рабочих станциях SGI была его разновидность. На consumer hardware мультисэмплинг появился впервые, видимо, на видеокартах 3dfx (серия Voodoo 5), для этих видеокарт существовало ограниченное расширение GL_3DFX_multisample. NVIDIA впервые реализовала поддержку этого вида антиалиасинга в NV20 (GeForce 3). С тех пор MSAA с теми или иными вариациями реализуется на всех поколениях графического железа.
При мультисэмплинге фрагмент изображения перестаёт быть своего рода "атомом" (др.-греч. ἄτομος — неделимый). У него появляется внутренняя, невидимая до поры до времени структура - отдельные сэмплы (отсчёты). Говоря образно, у фрагмента появляется своё собственное разрешение (пусть и небольшое), и он способен "видеть" растеризуемые примитивы более подробно. Типичное кол-во сэмплов, которые определяют уровень антиалиасинга - 2, 4, 6 и 8.
Теперь разберём техническую сторону вопроса более подробно (я черпал информацию в основном из расширения GL_ARB_multisample и сверял с другими источниками).
Если формат пикселя кадрового буфера поддерживает мультисэмплинг, то к кадровому буферу добавляется специальный буфер отсчётов (multisample buffer). Такие значения сэмплов фрагмента, как цвет, глубина и значение трафарета сохраняются в этом буфере. Также с каждым фрагментом изображения связывается так называемое значение охвата (coverage value), кол-во бит в котором равно кол-ву сэмплов на фрагмент. Т. е. для каждого сэмпла отводится один бит из значения охвата. Эти дополнительные данные нужны для того, чтобы понять, какая площадь фрагмента перекрывается треугольником.
Сэмплы фрагмента могут располагаться как в пределах его границ, так и за его пределами. Более того, от пикселя к пикселю и от кадра к кадру их положения относительно центра фрагмента могут варьироваться - это зависит от деталей аппаратной реализации. К этому вопросу я вернусь позже.
Если в процессе растеризации сэмпл (как идеальная точка) попадает внутрь растеризуемого примитива или оказывается на его границе, то бит в значении охвата для этого сэмпла устанавливается в 1, иначе в 0. Тесты глубины и трафарета, а также смешивание (blending) цветов выполняются на уровне отдельных сэмплов, а не на уровне фрагмента. Кроме того, они выполняются только для тех сэмплов, для которых бит в значении охвата установлен в 1, иначе все операции для этого сэмпла пропускаются. Если тест трафарета или тест глубины проваливается, прекращается дальнейшая обработка только данного сэмпла, а не всего фрагмента. Фрагментный шейдер (или простая выборка из текстуры в случае FFP на NV20/25) всегда выполяется на уровне фрагмента, и все сэмплы получают одинаковое значение цвета, но значение глубины генерируется растеризатором для каждого сэмпла отдельно. (TODO: неясно, что происходит со значением глубины, если оно модифицируется в шейдере?). Согласно спецификации, значение трафарета генерируется для всего фрагмента, а не для каждого сэмпла отдельно:
The single fragment color value is used for all sample operations, however, as is the current stencil value.
После того, как все операции в буфере отсчётов завершены, цвета отдельных сэмплов фрагмента усредняются и результат записывается в буфер кадра. Метод усреднения зависит от конкретной реализации и уровня мультисэмплинга. В спецификации рекомендуется простое усреднение, рассчитанное независимо для каждого компонента цвета.
Как видно, основным преимуществом MSAA метода перед FSAA является меньшее кол-во текстурных выборок и вызовов фрагментного шейдера, хотя требования к памяти и framebuffer bandwidth остаются неизменными. Здесь появляется некоторая свобода, т. к. одно и тоже значение цвета для нескольких сэмплов позволяет задействовать цветовую компрессию:
If the color samples in the multisample buffer store fewer bits than are stored in the color buffers (...) presumably a compression scheme is being employed, and is expected to maintain an aggregate resolution equal to that of the color buffers.
Недостатком метода является сглаживание только вдоль рёбер треугольников, т. к. только там значения охвата могут отличаться от 1. Внутри треугольников изображение не сглаживается. Обычно это совсем незаметно из-за текстурной фильтрации, но если используется текстура с альфа-тестом, появляется сильный алиасинг.
Подписаться на:
Сообщения (Atom)
