У блога сегодня день рождения - ему исполнился один год.
За это время я написал о разных вещах: некоторые из них закончены, какие-то не удалось довести до конца (думаю, я ещё вернуть к ним). К сожалению, следующий год вряд ли будет таким же плодотворным, т. к. большую часть моего времени стала занимать работа, а в оставшееся хочется отдохнуть/отвлечься, т. к. это в принципе замкнутый круг и нужно уметь восстанавливать силы.
Но я не собираюсь бросать свои начинания, и обещаю, что в блоге появится ещё немало интересных описаний, демок и скриншотов.
четверг, 27 мая 2010 г.
вторник, 25 мая 2010 г.
пятница, 21 мая 2010 г.
First Self-Replicating Synthetic Bacterial Cell
Интернет будоражит от нового открытия: впервые создана синтетическая клетка с искусственно собранной ДНК!
За основу была взята структура генома бактерии Mycoplasma mycoides. В нее добавили дополнительные последовательности ДНК, таким образом отметив искусственное происхождение генома.
BBC: Первая искусственная форма жизни
Membrana.ru : Впервые создана искусственная форма жизни
Страница проекта: jcvi
За основу была взята структура генома бактерии Mycoplasma mycoides. В нее добавили дополнительные последовательности ДНК, таким образом отметив искусственное происхождение генома.
BBC: Первая искусственная форма жизни
Membrana.ru : Впервые создана искусственная форма жизни
Страница проекта: jcvi
вторник, 18 мая 2010 г.
Hitler reacts to the Hitler parodies being removed
Youtube по требованию Constantin Film AG удаляет все юзверские пародии "Hitler reacts...", основой для которых послужила весьма характерная сцена из малоизвестного ранее фильма "Downfall" (у нас - "Бункер"). Если кто не в курсе, то Youtube до недавнего времени буквально лихорадило от самых разных пародий со сценой разноса высшего военного командования в бункере, в том числе и made in Russia. В ответ на эти действия появилась очередная смешливая пародия, где Гитлер узнаёт, что пародии на него самого удаляются с Youtube. Не знаю, сколько будет жить это видео, поэтому просто привожу ссылку:
Hitler reacts to the Hitler parodies being removed from YouTube
В одном авторы пародии безусловно правы: фильм "Downfall" стал популярным именно из-за пародий "Hitler reacts...", до этого о нём знали единицы, в широкий прокат картина не вышла. Я сам посмотрел этот фильм только после того, как случайно наткнулся на одну из таких пародий в прошлом году. И вот теперь Constantin Film AG так платит юзверям Youtub-a за пиар фильма.
P.S. А всё-таки видео "Hitler Fermi" было лучшее!
Hitler reacts to the Hitler parodies being removed from YouTube
В одном авторы пародии безусловно правы: фильм "Downfall" стал популярным именно из-за пародий "Hitler reacts...", до этого о нём знали единицы, в широкий прокат картина не вышла. Я сам посмотрел этот фильм только после того, как случайно наткнулся на одну из таких пародий в прошлом году. И вот теперь Constantin Film AG так платит юзверям Youtub-a за пиар фильма.
P.S. А всё-таки видео "Hitler Fermi" было лучшее!
понедельник, 17 мая 2010 г.
Дождь
Вчера рискнул пройтись в аптеку и чуть было не попал под сильнейший дождь, пришлось бежать до ближайшего подъезда и стоять там под козырьком.
Я был в джинсах и лёгенькой маечке (потому что май месяц) и сильно продрог.
Я был в джинсах и лёгенькой маечке (потому что май месяц) и сильно продрог.
Packed A-buffer
В презентации AMD можно найти совет по оптимизации работы с A-буфером:
Узел связанного списка имеет три поля типа uint - RGBA color, depth и address. Как вариант предлагается хранить цвет в формате 565 (альфа - константная) и объединить его с 16-bit depth. Таким образом можно сэкономить один uint. Следуя по стопам приверженцев deferred shading-а, которые любят мозгодробительные комбинации упаковки G-буфера, я решил поиграться в "упаковку A-буфера", благо начиная с SM 4.0 появилась прекрасная возможность маскировать и двигать битики на GPU.
Итак, наша цель - два uint вместо трёх, но попиксельная альфа (не константная), хорошая точность цвета и глубины. Основная возможность сжатия заключается в том, что нам не нужен полный 32-битный адрес для индексации A-буфера требуемых размеров. Это, кстати, ещё та проблема - определить, буфер каких размеров будет достаточным, и сколько бит необходимо для его адресации. Я остановился на 23 битах, т. к. в этом случае можно адресовать 8 388 608 элементов, т. е. буфер размером 1024x1024, 8x overdraw в (каждом) пикселе. Думаю, для спрайтов, огня и дыма этого будет вполне достаточно. Для значения глубины я решил отвести демократичные 16 бит (такая точность иногда использовалась для буфера глубины). Т. к. у нас свободны 9 бит второго поля, которые ранее занимал адрес, то теперь в них можно поместить старшие 9 бит глубины.
Младшие 7 бит придётся делить с цветом в первом поле. Значит, под цвет остаётся 25 бит. Для последнего я решил выбрать "дьявольский" формат хранения 666_7, т. е. для RGB компонентов отводится по 6 бит, для альфы - 7. Считаю, что бандинг альфы при большом overdraw может привести к ухудшению transparency, поэтому необходимо хранить альфу как можно большей точности, к тому же в этой раскладке нет перекосов с точностью RGB-компонент.
Возможны варианты. Например, рядом со мной стоит iMac, монитор которого поддерживает разрешение 2560x1440. Не думаю, что даже hi-end видеокарты смогут быстро работать с A-буфером такого разрешения, но надо смотреть в будущее. Лучшим подходом будет на практике замерять, сколькими элементами оперирует A-буфер, для этого в Direct3D 11 можно воспользоваться методом ID3D11DeviceContext::CopyStructureCount(). Если 23 бит окажется недостаточно для адресации, можно выделить дополнительные два бита, понизив на один бит точность глубины и точность альфы цвета. Но при любой раскладке, вполне реально сэкономить одно поле в узле списка, при минимальных потерях в качестве рендеринга. А это значит, что можно сэкономить треть отводимой под A-буфер видеопамяти и ускорить чтение/запись.
Обновлённое демо: oit_packed_dx11
Update: HD 5850, прирост скорости составляет 5-10%, значит, bottleneck в сортировке. Ну хоть видеопамять сэкономил, она ведь не резиновая.
Optimize performace by reducing amount of data to write to/read from UAV.
Узел связанного списка имеет три поля типа uint - RGBA color, depth и address. Как вариант предлагается хранить цвет в формате 565 (альфа - константная) и объединить его с 16-bit depth. Таким образом можно сэкономить один uint. Следуя по стопам приверженцев deferred shading-а, которые любят мозгодробительные комбинации упаковки G-буфера, я решил поиграться в "упаковку A-буфера", благо начиная с SM 4.0 появилась прекрасная возможность маскировать и двигать битики на GPU.
Итак, наша цель - два uint вместо трёх, но попиксельная альфа (не константная), хорошая точность цвета и глубины. Основная возможность сжатия заключается в том, что нам не нужен полный 32-битный адрес для индексации A-буфера требуемых размеров. Это, кстати, ещё та проблема - определить, буфер каких размеров будет достаточным, и сколько бит необходимо для его адресации. Я остановился на 23 битах, т. к. в этом случае можно адресовать 8 388 608 элементов, т. е. буфер размером 1024x1024, 8x overdraw в (каждом) пикселе. Думаю, для спрайтов, огня и дыма этого будет вполне достаточно. Для значения глубины я решил отвести демократичные 16 бит (такая точность иногда использовалась для буфера глубины). Т. к. у нас свободны 9 бит второго поля, которые ранее занимал адрес, то теперь в них можно поместить старшие 9 бит глубины.
Младшие 7 бит придётся делить с цветом в первом поле. Значит, под цвет остаётся 25 бит. Для последнего я решил выбрать "дьявольский" формат хранения 666_7, т. е. для RGB компонентов отводится по 6 бит, для альфы - 7. Считаю, что бандинг альфы при большом overdraw может привести к ухудшению transparency, поэтому необходимо хранить альфу как можно большей точности, к тому же в этой раскладке нет перекосов с точностью RGB-компонент.
Возможны варианты. Например, рядом со мной стоит iMac, монитор которого поддерживает разрешение 2560x1440. Не думаю, что даже hi-end видеокарты смогут быстро работать с A-буфером такого разрешения, но надо смотреть в будущее. Лучшим подходом будет на практике замерять, сколькими элементами оперирует A-буфер, для этого в Direct3D 11 можно воспользоваться методом ID3D11DeviceContext::CopyStructureCount(). Если 23 бит окажется недостаточно для адресации, можно выделить дополнительные два бита, понизив на один бит точность глубины и точность альфы цвета. Но при любой раскладке, вполне реально сэкономить одно поле в узле списка, при минимальных потерях в качестве рендеринга. А это значит, что можно сэкономить треть отводимой под A-буфер видеопамяти и ускорить чтение/запись.
Обновлённое демо: oit_packed_dx11
Update: HD 5850, прирост скорости составляет 5-10%, значит, bottleneck в сортировке. Ну хоть видеопамять сэкономил, она ведь не резиновая.
среда, 12 мая 2010 г.
A-buffer through per-pixel linked lists
Написал новую демку OIT, использующую предложенную ATI методику работы с A-буфером.
Ссылка: oit_ppll_dx11.
Доступны четыре режима: стандартный блендинг, A-буфер с построением префиксной суммы, A-буфер с построением связанных списков, K-буфер. Отлаживал в reference rasterizer на своём ноутбуке.
Как и ожидалось, подход ATI оказался более эффективным. Тестирование на HD 5850 в разрешении 1024x1024 показало прирост скорости в районе 2x-3x. Для более сложных моделей с высоким overdraw отрыв должен быть ещё больше.
Я применил одну банальную оптимизацию для снижения GPR usage. В A-буфере цвета теперь упакованы в uint, и в шейдере сортировки массив цветов, определённый как float4 a[8] заменён на uint a[8], что позволяет оперировать существенно меньшим объёмом данных при сортировке. Распаковка цвета осуществляется непосредственно перед смешиванием. GPU Shader Analyzer показывает такие цифры для Cypress (5870):
Вариант с float4 - 36 GPR, 125 ALU.
Вариант с uint - 26 GPR, 100 ALU.
Для сортируемых массивов малого размера это даёт хоть и небольшой, но всё же прирост скорости. Думается, для массива из 64 элементов прирост скорости будет ощутимым, т. к. без оптимизации мультипроцессор GPU может упереться в величину регистрового файла.
Как ещё одно средство оптимизации сортировки сложных моделей можно предложить маскировать стенселем участки кадра с разным overdraw и запускать несколько сортирующих шейдеров, рассчитанных на определённое количество слоёв (8, 16, 32, 64). Это должно быть быстрее, т. к. максимальный overdraw обычно достигается редко.
Досадным фактом является то, что сортировка методом K-буфера даёт артефакты в изображении, при том что сам алгоритм реализован без ошибок. В первый раз я списал это на проблемы "сырых" драйверов для ATI 5xxx, но теперь они вновь всплыли, уже на дискретной ATI HD 4330. Более того, отлаживая код под reference rasterizer, я обнаружил, что артефакты остаются, и это натолкнуло меня на мысль, что причина кроется в чём-то ином.
Заинтересовавшись проблемой K-буфера, я попытался локализовать причину артефактов, или хотя бы получить мнение о их природе. Я решил ограничиться двумя плоскостями и просмотреть два отрисованных слоя отдельно, без сортировки и блендинга. Вот что получилось:
На первый взгляд всё правильно, но при внимательном рассмотрении можно заметить, что второй слой растеризатор отрисовал несколько иным образом, заметны различия в ступеньках между первой перекрывающей плоскостью (красной), и перекрытой (зелёной), которая попала во второй слой. Между ступеньками есть gap:
Причина подобного поведения растеризатора стала загадкой. Случайно я вспомнил, что до сих пор отлаживал код только под reference rasterizer и в feature level 10.1, тогда как мои первые реализации K-буфера работали в feature level 10.0. Я поменял level на 10.0, запустил демку и о чудо, никаких артефактов!
(Note: небольшие артефакты в месте пересечения плоскостей обусловлены тем, что задействован depth буфер с форматом пониженной точности R16_UNORM).
Переключив несколько раз feature level и убедившись, что артефакты то исчезают, то появляются вновь, я заглянул в справку DirectX SDK, а именно, в Windows Graphics/Direct3D 10/Programming Guide/Direct3D 10.1 Features. Там нашёлся следующий пункт:
Rasterization Rules - The rules for rasterization have changed for lines, in addition, new functionality has been added.
MultisampleEnable only affects line rasterization (points and triangles are unaffected), and is used to choose a line drawing algorithm. This means that some multisample rasterization from Direct3D 10 are no longer supported.
Ссылка: oit_ppll_dx11.
Доступны четыре режима: стандартный блендинг, A-буфер с построением префиксной суммы, A-буфер с построением связанных списков, K-буфер. Отлаживал в reference rasterizer на своём ноутбуке.
Как и ожидалось, подход ATI оказался более эффективным. Тестирование на HD 5850 в разрешении 1024x1024 показало прирост скорости в районе 2x-3x. Для более сложных моделей с высоким overdraw отрыв должен быть ещё больше.
Я применил одну банальную оптимизацию для снижения GPR usage. В A-буфере цвета теперь упакованы в uint, и в шейдере сортировки массив цветов, определённый как float4 a[8] заменён на uint a[8], что позволяет оперировать существенно меньшим объёмом данных при сортировке. Распаковка цвета осуществляется непосредственно перед смешиванием. GPU Shader Analyzer показывает такие цифры для Cypress (5870):
Вариант с float4 - 36 GPR, 125 ALU.
Вариант с uint - 26 GPR, 100 ALU.
Для сортируемых массивов малого размера это даёт хоть и небольшой, но всё же прирост скорости. Думается, для массива из 64 элементов прирост скорости будет ощутимым, т. к. без оптимизации мультипроцессор GPU может упереться в величину регистрового файла.
Как ещё одно средство оптимизации сортировки сложных моделей можно предложить маскировать стенселем участки кадра с разным overdraw и запускать несколько сортирующих шейдеров, рассчитанных на определённое количество слоёв (8, 16, 32, 64). Это должно быть быстрее, т. к. максимальный overdraw обычно достигается редко.
Досадным фактом является то, что сортировка методом K-буфера даёт артефакты в изображении, при том что сам алгоритм реализован без ошибок. В первый раз я списал это на проблемы "сырых" драйверов для ATI 5xxx, но теперь они вновь всплыли, уже на дискретной ATI HD 4330. Более того, отлаживая код под reference rasterizer, я обнаружил, что артефакты остаются, и это натолкнуло меня на мысль, что причина кроется в чём-то ином.
Заинтересовавшись проблемой K-буфера, я попытался локализовать причину артефактов, или хотя бы получить мнение о их природе. Я решил ограничиться двумя плоскостями и просмотреть два отрисованных слоя отдельно, без сортировки и блендинга. Вот что получилось:
На первый взгляд всё правильно, но при внимательном рассмотрении можно заметить, что второй слой растеризатор отрисовал несколько иным образом, заметны различия в ступеньках между первой перекрывающей плоскостью (красной), и перекрытой (зелёной), которая попала во второй слой. Между ступеньками есть gap:
который и порождает артефакты:
Причина подобного поведения растеризатора стала загадкой. Случайно я вспомнил, что до сих пор отлаживал код только под reference rasterizer и в feature level 10.1, тогда как мои первые реализации K-буфера работали в feature level 10.0. Я поменял level на 10.0, запустил демку и о чудо, никаких артефактов!
(Note: небольшие артефакты в месте пересечения плоскостей обусловлены тем, что задействован depth буфер с форматом пониженной точности R16_UNORM).
Переключив несколько раз feature level и убедившись, что артефакты то исчезают, то появляются вновь, я заглянул в справку DirectX SDK, а именно, в Windows Graphics/Direct3D 10/Programming Guide/Direct3D 10.1 Features. Там нашёлся следующий пункт:
Rasterization Rules - The rules for rasterization have changed for lines, in addition, new functionality has been added.
MultisampleEnable only affects line rasterization (points and triangles are unaffected), and is used to choose a line drawing algorithm. This means that some multisample rasterization from Direct3D 10 are no longer supported.
Подписаться на:
Сообщения (Atom)
