Вдыхая жизнь в Avatar

http://communities.netapp.com/docs/DOC-6161
  • Перевод
image
Хотя на Хабре уже публиковались некоторые заметки о технической стороне создания фильма Avatar, например в блоге компании HP была заметка о создании рендерфермы, построенной на blade-системах HP, мне показалось, что эта тема остается весьма любопытной для «технарей», как же там все делается «за кадром», в проектах такого масштаба, тем более, что системы NetApp непосредственно участвовали в создании фильма. Поэтому я решил перевести эксклюзивно для Хабра статью из недавно вышедшей свежей «электронной ежемесячной газеты» Tech Ontap. Кстати, можно подписаться и на русскую ее версию.

Фильм Avatar, вышедший на экраны в этом году, побил все рекорды сборов, добравшись до величины в 2.7 миллиардов долларов, и продолжая собирать кассу. Weta Digital, компания создания визуальных эффектов, занимавшаяся созданием спецэффектов и компьютерной анимации для этого фильм, также побила несколько своих собственных рекордов при создании впечатляющего 3D-мира Avatar. Weta Digital получила широкую известность в профессиональной среде после выхода трилогии «Властелин Колец» (The Lord of the Rings) и ряда последующих фильмов, таких, как King Kong и District#9, но создание Avatar потребовало совершенно особых технических усилий.
 
Weta Digital далеко раздвинула границы своих вычислительных инфраструктур и систем хранения, много дальше, чем то, с чем нам приходилось работать ранее. Когда началась работа над Avatar в 2006 году, Weta Digital только завершила работу над фильмом King Kong. В этот момент он располагала примерно 4400 ядрами CPU в своей ферме рендеринга и около 100TB пространства хранения. Завершая производство Avatar, компания имела около 35000 ядер CPU и свыше 3000TB хранилища. Емкость только RAM фермы рендеринга сегодня превышает общую дисковую емкость Weta Digital на момент завершения работ над фильмом King Kong.
 
Я начал работать в Weta Digital в 2003 году системным администратором, когда завершалась работа над последней частью Lord of the Rings. Вскоре моей основной задачей стало руководство отделом инфраструктурных решений Weta Digital. Этот отдел отвечал за все сервера, сети и системы хранения. Нашей задачей было создать такую инфраструктуру, чтобы сделать возможным создание фильма уровня Avatar, а также решать все возникающие в ходе работы над ним проблемы технического плана.

Сражение за рост


Несмотря на тот гигантский рост, который произошел в Weta Digital в ходе работы над Avatar, управление выросшей инфраструктурой не стало такой проблемой, как мы боялись. В значительной степени это была заслуга команды, знающей как работать вместе. Команда держалась вместе, и, когда что-то шло не так, мы подскакивали и неслись это исправлять все вместе. Мы напряженно работали, и, в большинстве случаев, нам удавалось упреждать ситуации, вместо того, чтобы исправлять что-то уже случившееся.
 
Мы быстро поняли, что для того, чтобы справиться с Avatar нам потребуется сделать два важных шага.
  • Построить новый датацентр. Weta Digital использовала до сих пор несколько небольших серверных комнат, разбросанных по нескольким зданиям. Новый датацентр обеспечивает централизованное размещение и консолидацию всей новой инфраструктуры, которую потребуется нарастить в ходе реализации проекта Avatar.
  • Проложить высокоскоростной оптоволоконный канал. Weta Digital не имеет локализованного кампуса. Вместо этого наш «кампус» состоит из нескольких независимых зданий, разбросанных в пригороде Веллингтона. Мы разработали и соорудили высокоскоростное «кольцо» с использованием оптоволокна, которое соединило все эти здания с новым датацентром. Каждое здание соединялось избыточным соединением, с пропускной способностью 10Gbit/s каждое, суммарно образующих EtherСhannel в 40Gbit/s, для соединения системы хранения и серверов фермы рендера.

Эти два элемента дали нам физическую возможность масштабировать нашу инфраструктуру, нарастив ее и пропускную способность, чтобы свободно перемещать данные между локациями. Новая серверная инфраструктура обновленной фермы рендеринга была создана с использованием blade-серверов HP. C 8 ядрами и 24GB RAM на blade, мы получили возможность уместить до 1024 ядер и до 3TB RAM на стойку. Новый датацентр был организован в виде ряда из 10 стоек, суммарно 10240 ядер. Мы установили первые 10000, поработали немного на них, добавили еще 10000, еще поработали, добавили еще 10000, и, наконец, поставили пока на сегодня последние 5000 ядер.

Датацентр имеет ряд уникальных элементов конструкции:
  • Водяное охлаждение. Так как обычная погода в Веллингтоне, Новая Зеландия, городе, где находится Weta Digital, редко бывает очень жаркой, вода большую часть времени прокачивается непосредственно из охлаждаемых ей стоек в расположенные на крыше здания радиаторы, для естественного теплообмена. Сервера работают в относительно «теплом» режиме, при температуре в 23º C.
  • Высокая плотность электропитания. Датацентр обеспечивает подачу мощности до 30 киловатт на стойку.
  • Высокопрочные стойки. Каждая стойка Rittal с встроенным водяным охлаждением выдерживает нагрузку по весу размещенного в ней оборудования и системы охлаждения до одной тонны.

В нашей инфраструктуре хранения мы использовали продукцию нескольких производителей, но ядро ее состоит из систем хранения производства NetApp, на которых находится около 1000TB данных. К концу работы над Avatar, мы заменили все наши старые FAS980 и FAS3050 на кластерные FAS6080. В последние восемь месяцев проекта мы также добавили четыре системы SA600 storage accelerator для того, чтобы решить одну особо болезненную проблему производительности.

Ускорение доступа к текстурным файлам с помощью адаптивного кэширования


В индустрии визуальных спецэффектов «текстуры» это специальные файлы изображений, которые «наносятся» на 3D-модель, делая ее реалистичной. Модель «обернута» текстурами, которые создают необходимые детали, цвет, тени, характер поверхности модели, без которых 3D-модель выглядит всего лишь однотонно серой. «Набор текстур» (texture set) это все разнообразные картинки, которые должны быть нанесены на конкретную модель, чтобы она выглядела как дерево, персонаж или существо. Большинство рендеров включающих в себя объекты, включают также и текстуры, применяемые на эти объекты; таким образом, содержимое файлов текстур постоянно требуются серверам фермы при создании сцены.

Определенная группа наборов текстур может быть запрошена одновременно несколькими тысячами ядер процессоров рендера. Перекрывающаяся по содержимому с первой, другая группа может быть затребована другой тысячей ядер, и так далее. Все что мы можем сделать для улучшения ситуации со скоростью доступа к текстурам, резко увеличит производительность всей фермы рендеринга в целом.
 
Никакой отдельный файловый сервер не может обеспечить достаточную полосу пропускания для подгрузки всех наших наборов текстур, поэтому мы разработали специальный процесс «публикации», который предназначен для создания реплик каждого созданного набора текстур. Это показано на рисунке 1.
 
weta infrastructure before

Рисунок 1) Старый метод увеличения пропускной способности при передаче наборов текстур.

Когда задача рендера запускается на ферме, им требуется доступ к набору используемых в проекте текстур, она выбирает случайный файл-сервер и считывает содержимое текстуры с одной из его реплик. Позволив нам распределить содержимое текстур по нескольким файл-серверам этот процесс значительно увеличил производительность системы. Хотя такое решение было лучше, чем вариант с одним файл-сервером, процесс публикации и репликации был довольно сложен и требовал затрат времени на контроль целостности, чтобы быть уверенным в том, что все реплики на всех серверах абсолютно идентичны.
 
Мы начали использовать NetApp FlexCache и SA600 storage accelerator как простой способ решить проблему с нехваткой производительности, связанной с работой с наборами текстур. ПО FlexCache создает уровень кэширования в инфраструктуре хранения, автоматически обрабатывающий изменяющиеся паттерны доступа и устраняющий «узкое место» производительности. Оно автоматически реплицирует и обслуживает доступ к активным наборам данных, вне зависимости от того, где эти данные находятся в инфраструктуре хранения, с помощью локальных кэширующих томов.
 
Вместо ручного копирования наших текстур на несколько файловых серверов, FlexCache позволяет нам динамически кэшировать используемые в данный момент в проекте текстуры и отдавать их на ферму рендеринга с устройств SA600. Мы протестировали это решение и увидели, что оно работает очень хорошо в условиях нашей системы, поэтому за 8 месяцев до окончания работы над фильмом мы решили рискнуть и установили четыре системы SA600, каждая с двумя модулями Performance Accelerator Modules (PAM) емкостью 16GB каждой. (PAM работает как кэш, снижая время отклика при доступе к данным. подробнее: eng и рус)

weta infrastructure after

Рисунок 2) Улучшенный метод увеличения полосы пропускания для наборов текстур, используя NetApp FlexCache, SA600, и PAM.

Полный размер набора текстур составляет около 5TB, но когда мы включили FlexCache, мы выяснили, что только 500GB из них активно используются в каждый момент времени. Каждый SA600 имеет достаточно пространства на его локальных дисках, чтобы разместить этот активный набор данных, и, когда текстуры в активном наборе данных изменяются, кэш автоматически перезагружает свое содержимое, не требуя от нас ручного вмешательства в этот процесс. Агрегированная полоса пропускания составила 4GB/сек, гораздо больше, чем мы достигали до сих пор.
 
Кэширование текстур с помощью FlexCache оказалось превосходным решением. Все работает быстрее, упрощается работа по управлению текстурами и их наборами. Был заключительный год проекта, занявшего четыре года труда по созданию фильма. Если бы мы решились поставить SA600 и с ними начались бы проблемы, нам бы пришлось срочно менять все назад, чтобы не сорвать сроки. Но после того, как прошла неделя, мы практически забыли о их существовании (исключая, конечно, факт увеличившейся скорости). Это самый простой способ сделать IT-шника счастливым.
 
Производительность подсистемы хранения оказывает значительное влияние на скорость обработки заданий рендера. Узкие места и недостаток производительности не позволяет работать ферме рендеринга в полную мощь. В последний год создания Avatar мы углубились в детали процессов и добавили много возможностей по мониторингу и снятию статистики в каждом задании.
 
Мы постоянно отставали от графика, у нас постоянно висели задержанные задачи, ожидавшие очереди на запуск; каждый день копилось все больше заданий, ожидавших, когда у рендерфермы дойдет до них очередь. Команда так называемых «пастухов» (wranglers) в Weta Digital занимается тем, что наблюдает за тем, чтобы все задания и работы по рендеру шли правильно и в нужном порядке. Наутро, после того, как мы ночью установили и запустили FlexCache, «старший пастух» пришел к нам с отчетом, что все задания выполнены. Все работало так неожиданно быстро, что он решил, что у нас что-то сломалось.

Почему именно NetApp?


Я давний фанат продукции NetApp. Впервые мне довелось использовать системы NetApp, когда я работал в интернет-провайдере на Аляске, во времена «дотком бума» в конце 90-х — я был достаточно впечатлен их возможностями, чтобы последовательно продвигать их в дальнейшем в тех компаниях, где я работал. Я был рад увидеть, что системы хранения NetApp уже используются в Weta Digital, когда я в нее пришел.
 
Для таких компаний, как Weta Digital, вполне обычное дело что-нибудь «сломать», так как обычно никто больше не делает такого с инфраструктурой, как приходится делать нам. Ключевой момент в ситуации состоит в том, что вам может потребоваться помощь вендора, чтобы исправить ситуацию (например в анализе причин возникновения проблемы, или даже срочном выпуске патча для ПО, в случае обнаружения бага). Даже если вы работаете в небольшой компании, в NetApp всегда найдется кто-то, кто будет заниматься вашей проблемой вместе с вами, пока она не будет наконец решена. Вы думаете, что так оно и должно происходить всегда? Мой опыт, показывает, что у других вендоров так получается довольно редко.
 
Хранилища данных могут быть сложны. Технологии NetApp делают системы хранения такими простыми, как это только возможно. Есть вещи, которые мне хотелось бы, чтобы NetApp делал лучше, чем он их делает сейчас, но, в сравнении со всеми другими, я вижу, что NetApp делает надежный и разносторонний продукт, который просто использовать, и который обеспечивается надежной поддержкой. Вот почему мы по прежнему используем именно NetApp.


Adam Shand
Ранее руководитель инфраструктурного отдела
Weta Digital
 
Адам начал свою карьеру в Новой Зеландии где основал одну из первых интернет-компаний страны, совместно со своим отцом. Его следующая работа, в 1997, привела его на Аляску, затем он работал в Портленде, штат Орегон в индустрии EDA. Сходство между EDA и производством визуальных эффектов, плюс возможность работать ближе к дому, привела Адама в 2003 году в Weta Digital. После нескольких лет в Weta Digital Адам решил оставить компанию, и отправился в годичное путешествие по Юго-Восточной Азии.
Метки:
NetApp 30,18
Компания
Поделиться публикацией
Похожие публикации
Комментарии 55
  • +5
    Офигеть… это круто)
    • +7
      а меня перевод впечатлил, очень крутой, даже картинки переписаны, спасибо автору!
    • +4
      На грамотную работу всегда посмотреть приятно.
      • 0
        И сколько же, интересно, рендерился в итоге 1 кадр фильма?
        • 0
          Это же очень сильно зависит от, например, детализации этого кадра. Одно дело — кадр с большим количеством разнообразных деталей, разными текстурами, множеством 3D-моделей в кадре, и т.п., другое — где этих деталей немного. Дмаю, что разница в порядки, поэтому и сказать сложно. Какие-то цифры приводились в сосланной в первом абзаце статье про ферму HP.
          • +4
            Выдержка:
            «Когда актер поднимает руку, чтобы почесаться, его двойник с кожей лазурного цвета – аватар его аватара, если угодно – в точности копирует это действие. Совершенство требует жертв: на обработку каждого кадра в цифровых сценах фильма уходит более 100 часов. Все это происходит в недрах студии Weta – пятом по мощности компьютере на планете с 30 000 процессоров, расположенном в комнате, которая по размерам превосходит The Volume. «Да, это мой собственный Скайнет, – смеется Кэмерон. – Правда, он не мой, а Питера Джексона. Но это удивительная машина...»
            • 0
              Я не очень понимаю: 100 часов на кадр — это более четырех суток на кадр, соответственно, 30 кадров будут рендериться 4 месяца. Даже если «цифровые сцены» рендерили три года, то всего должно было получиться 270 кадров — это секунд 10-15 видео. В чем ошибка?
              • 0
                Все кадры разные. Какие-то очень сложные, какие-то проще. В каких-то только вставляли персонажей в «живой» кадр, или, наоборот, рисовали «цифровой задник» живым актерам.
                • +1
                  Учитывая, что где-то в комментариях написали, что сам рендер длился около года — у них было время только на 5 секунд таких кадров (для фильма в 166 минут, т.е. в 9960 секунд — это категорически мало). В таком случае странно было заявлять, что «на обработку каждого кадра в цифровых сценах фильма уходит более 100 часов», скорее «на обработку в цифровых сценах фильма уходило ДО 100 часов на кадр», хотя на деле 99.9% кадров рендерились вряд ли более часа.
                  • +5
                    Да, насколько я знаю, обычно оперируют так называемыми сценами (англ. «shot»), это такой специфический киношный термин, означающий некую цельную сцену в рамках «кинопродакшна», грубо говоря то, что находится между хлопком хлопушки ассистента и криком «стоп, снято». Это может быть и довольно продолжительный фрагмент, и совсем короткий.
                    К сожалению, часто «shot» переводят как «кадр» (впрочем, насколько я знаю, в российском кинопроизводстве тоже так говорят), и возникает неправильное понимание.
                    То есть, на деле, когда говорят shot, или «кадр», то это часто не тот кадр, которых 24 в секунду, а вот эта вот «сцена».
                    • 0
                      В русском для этого термина есть устоявшийся (насколько я знаю) перевод «план».
                • +1
                  К тому же кадр рендерит не вся ферма, а какой-то ее кусок, например 1000 процесоров (это упоминается в тексте), то есть, если допустить грубо, что в среднем кадый кадр рендерит 1000 процессоров, то 35000 ядер может одновременно параллельно строить 35 кадров.
                  • 0
                    Теперь начал понимать в чем ошибка, спасибо!
            • 0
              Интересно таки сколько времени уходит на рендер одной сцены… Судя по размаху инфраструктуры скорости просто безумные, но все таки цифру хотелось бы знать.
              • 0
                Скорости-то безумные, но их все равно недостаточно, как я понимаю. Были-бы деньги и место — поставили б еще и еще.
                • 0
                  Ну в общем да. Фильм делали 4 года, куда входит много что, активная фаза рендера (читай «съемки» в классическом кинопроцессе) заняла больше года.
                • 0
                  Скорости не поспевают за потребностями — они ведь не HD рендерили, а как минимум 4к, а то и 8к для IMAX (хотя странно, что в нете нет точной инфы сколько именно), для последующей печати на пленку, так что даже на таких мощьностях на каждый кадр времени уходило прилично
                  • 0
                    Ну в общм да, он и рассказывал, что они за год учетверили ферму (покупая по 10 тысяч ядер в четыре приема).
                    В таких делах «дорого яичко к христову дню», экономия может выйти боком, Аватар у Кэмерона и так «долгострой».
                • +1
                  интересно, в квейк поиграть можно на такой системе? :) и сколько фпс бы дало бы? :)
                  • +3
                    Если портировать — наверное можно. Но обычно принято спрашивать не про Quake, а про Crysis ;)
                    • +6
                      нуу, я как бы олд скул. :) с кризис даже и не играл :) а вот на квейк потратил много часов…
                    • +3
                      Конечно же, еще можно запастись грибами и прыгая по стойкам играть в Марио.
                    • +1
                      А ведь за время работ (4 года) система успевает существенно устареть. То есть она одноразовая. Подумать только, одноразовый суперкомпьютер для одного фильма.
                      • +3
                        Как мы видим, оно вполне окупается, тем более что систему можно и дальше использовать, каждый раз наращивая более свежим и мощным оборудованием
                        • +1
                          Ну нет, почему, она же постоянно развивается, расширяется, к тому же обычно в работе параллельно идут несколько фильмов. Устаревшие компоненты системы передвигаются на менее ответственные участки, там же много задач, даже в рамках одного фильма, параллельно идет.

                          Рендер хорош в данном случае тем, что хорошо параллелится. Нужно быстрее — больше ресурсов выделяем, «все для фронта, все для победы». Можно помедленнее (например сценаристы или моделлеры не поспевают) — запустили еще каких-нибудь халтурок рендерить, типа рекламы, параллельно основной задаче.

                          Так что наоборот, это вполне эволюционирующая система.
                        • –1
                          Всё ещё не теряем надежды кроме рекламных статей об одном только NetApp увидеть и сравнительные обзоры.
                          • +4
                            Вы лучше сразу говорите «против кого дружим?» ;)
                            Знаю я все эти просьбы сравнений, если в сравнении победит не ваш любимый вендор — оно будет считаться «рекламной статьей», это безнадежно.
                            Это, так сказать, «моменто уно».

                            «Моменто дуо». Я тут нашел автора, он в Таиланде ошивается, относительно поблизости от меня, может через пару недель доеду до него, пива попьем. ;)
                            Он рассказывал вот какую историю. Где-то в 2006-м году, до того, как купили FAS6080, о которых речь в статье, они покупали BlueArc Titan 2000.
                            «Мы, говорит, и сейчас их используем кое-где у нас в проектах, и, в общем, довольны. Но проблема вот в чем. Да, они шустрые, да, они несколько превосходят NetApp по IOP/$, хотя разрыв постепенно сокращается, но поддержка их в нашем регионе — это один парень, да и тот сидит в Сиднее. Это нас не устраивает.»
                            «Я всем вендорам говорю сразу: мы — киношная компания. Мы все ломаем. Так получается. Наши решения, задачи и условия — уникальны, других таких нет. Так вот сразу вопрос: мы все сломали, ничего не работает, как быстро вы сможете все восстановить? И NetApp по скорости реакции и по компетентности поддержки нас очень радует».

                            Вот я и спрашиваю, как вот такие вещи учесть, в каком сравнении?
                            Неважно насколько быстра ваша система хранения, если в данный момент она не работает.
                            • 0
                              Отличная статья и славная история.

                              Крайне позитивен факт того, что в Новой Зеландии поддержка NetApp «на высоте»: душевна, доступна и действительно помогает.

                              А что касается поддержки в Москве? Кто пользуется устройствами здесь? Есть ли скасесс сториз компаний в Московском регионе? Или, усложняя задачу, в Кирове, Норильске, Туле, Сочи?

                              • 0
                                Чорт! «Скасесс» следует читать как «саксесс»! Чорт. Чорт.
                                • 0
                                  Не парьтесь так. Большинство опечатку и не заметили. Помните про то, что внутри слова порядок букв имеет второстепенное значение?
                                • 0
                                  Есть, конечно, NetApp в России продается с 2002-2003 года, сперва в российские представительства иностранных компаний, а потом уже и в «чисто российские», причем с каждым годом все больше, на днях вот в Казахстане офис официально открыли.

                                  С «саксесс сторями» сложность в том, что российские компании, даже клиенты NetApp, не заинтересованы особенно публиковать свои истории (ну вы знаете как, зачем лишний раз привлекать внимание к дорогостоящей покупке, возникнет внимание у тех, чье внимание привлекать не хочется), а маркетинговое подразделение NetApp традиционно не имеет достаточных бюджетов, чтобы «заинтересовывать» клиентов свои истории публиковать.

                                  Поэтому с «известными именами» клиентов в России и проблема. Они есть, но, увы, «официальных», опубликованных историй немного.
                                • –1
                                  > Знаю я все эти просьбы сравнений, если в сравнении победит не ваш любимый вендор — оно будет считаться «рекламной статьей», это безнадежно.
                                  > Это, так сказать, «моменто уно».
                                  Ещё раз — определите критерии, предложите оценить их сообществу. Естественно, так же нужно будет определить задачу и круг применения, ведь от этого зависит список критериев и методы оценки.

                                  > Он рассказывал вот какую историю.
                                  Вот, пример одного из критерив. В частности для меня этот критерий крайне важный и я очень высоко цену наличие поддержки высокого уровня.
                                  > Вот я и спрашиваю, как вот такие вещи учесть, в каком сравнении?
                                  Предложите свой список, спросите у сообщества.
                                  • 0
                                    Как-то все это чересчур сложно и заумно получается. Процесс получается несоизмеримо сложнее получаемого результата.
                                    При этом результат, в общем, известный.
                                    Какой-то «Нормальные герои всегда идут в обход» :)
                                    • –2
                                      В общем блог для выкладывания переводов рекламных статей заводили?
                                • +2
                                  И, да, «моменто трес»:
                                  Сравнение требует наличие специалиста одинаково компетентных во всех сравниваемых системах. А универсальные специалисты в отрасли не выживают. Нельзя быть равно компетентным во всех областях.

                                  Поэтому неизбежно (и неумышленно, зачастую) сравнение будет в пользу того, специалист какой компании, в данном случае, более компетентен. Обычно это специалист «своей» марки.

                                  Поэтому я давно с большой долей иронии отношусь ко всем этим «тестированиям» и «сравнениям».
                                  Это вон процессоры, или там жесткие диски, или mp3-плееры на ихбете можно сравнивать…
                                  • 0
                                    И да.

                                    Согласен, что «сравнительные тесты» высокотехнологичных устройств — дело довольно сомнительное. Трудно найти параметры, которые бы объективно оценивали систему, да еще и были интересны читателям. Да и трудно это и дорого…

                                    Вот если бы о возможностях рассказали… Лекбез такой. Что, мол, вот NetApp стоимостьюю, скажем, 20000 бакинских, может сделать так: <сдесь ловкое перечисление возможностей> (конкуренты начинают плакать). А потом бы дописали бы, что добавив еще 1000$ можно было бы сделать так и эдак <здесь все конкуренты начинают рыдать от зависти>!

                                    А-то мне тут рассказывали об уникальных возможностях «снэпшотирования» в средствах хранения NetApp. Правда сопровождая рассказ постоянными ссылками на невероятную сложность настройки. «Странно, — думаю. — В „моем“ EMC, купленном лет 5 назад, снэпшоты с клонами уже были. И настроить это было совсем не сложно. Ну пришлось почитать документацию, понятно. Но.»
                                    В общем, не впечатлило!
                                    • +2
                                      Дойдем, конечно, и до этого.
                                      Правда вопрос, насколько такие узкоспециальные темы будут интересны на Хабре, оновная аудитория тут все же довольно далека от темы систем хранения «enterprise class», будет ли «спрос», будет ли понятно?
                                      По NeApp «узкоспециально» коллега вот уже три года пишет в standalone-блоге blog.aboutnetapp.ru/
                                      Полистайте, может найдете для себя полезное и интересное.

                                      Что касается снэпшотов и клонов у EMC и NetApp — так они разные, причем существенно. «Одинаковое одинаковому рознь!» (с)
                                      Но это, конечно, отдельная тема, не для комментов к этой статье.
                                      • 0
                                        Можно делать сравнение немного хитрее, то есть реально описывать системы от нескольких или пары производителей, но и при этом не писать, что лучше, а что хуже. Выводы будет делать сам читатель.
                                        Порой очень хочется узнать в чем разница между железками разных вендоров. А на сайте каждый пишет, что они лидеры всего и всея.
                                    • 0
                                      > Сравнение требует наличие специалиста одинаково компетентных во всех сравниваемых системах.
                                      Потенциальный новый покупатель не будет компетентен, перед ним будет только документация, саппорт и стоящая перед ним задача.
                                      Конечно, совет «забыть» о хитростях, применяемых при конфигурации какого-либо устройства, понимаю, звучал бы глупо, но может попробовать подобрать человека, в достаточной степени компетентного для проведения тестирования, но не слишком глубоко знакомого с особенностями настройки?
                                      • 0
                                        > но не слишком глубоко знакомого с особенностями настройки оборудования NetApp
                                        Исправил.
                                  • 0
                                    и все это хранилось в DAM «Gaia» — www.microsoft.com/microsoftservices/en/us/article_Microsoft_Role_In_Avatar.aspx

                                    суммарно петабайт данных и 40,000 процессоров под DAM
                                    • 0
                                      Вот пусть блог Microsoft на хабре в свою очередь осветит нам и этот аспект :)
                                    • +1
                                      Интересно, а на GPU не было пока попыток переложить киношный рендеринг? Там же терафлопы раз в 10 дешевле получаются. Хотя, конечно, софт сложнее писать и гибкость совсем не та.
                                      • 0
                                        Сомнительно. Мы это уже обсуждали в теме про ферму блейдов HP.
                                        В этом деле главное — чтобы оно работало. Это производство, причем довольно жесткое по условиям. Лучше, если оно будет пусть и медленне, но зато стабильно работает. При наличии денег докупить еще 10 тысяч процессорных ядер в систему, как видите, не такая проблема. А с этими GPU что делать, куда их толкать? Как отлаживать, случись чего? Кто виноват будет, если все встанет?
                                        Все эти штуки с GPU пока все больше эксперименты.Когда-нибудь — возможно, но сейчас думаю, что никто с этим возиться ради призрачного ускорения и вполне реальной нестабильности никто не будет.

                                        ЗЫ. Посчитайте для примера плотность упаковки ядер в HP BL на стойку и достижимые ими мипсы и те же для GPU, при этом не забудьте, что «процессор» это еще не все, его надо:
                                        1. обеспечивать данными,
                                        2. оттаскивать данные
                                        3. охлаждать
                                        4. обслуживать и заменять в случае выхода из строя.
                                        Получится ли у вас мипсов на кубометр больше?
                                        • 0
                                          Ну, на точность не претендую, конечно, но:
                                          — «enabling 2Teraflops of double precision performance in a 1U of space» (http://www.nvidia.com/object/product-tesla-S2050-us.html)
                                          — там, как я понял, по 2 процессора на ноду, по две ноды на 1U, по 10GFlops каждый (http://www.top500.org/system/details/10042, h20195.www2.hp.com/V2/GetPDF.aspx/4AA1-6160ENW.pdf). Получается 40GFlops на 1U.

                                          Т.е. GPU по FLOPs-ам в 100 раз выгоднее. В реале, конечно, будет меньше, но даже если будет разница не на два порядка, а на один, имхо оно того стоит.

                                          Понятно что не весь рендеринг на них переписывать. Но можно же какие-то простые, но ресурсоемкие операции выделить и считать на GPU.

                                          У меня вон брат по науке считает на GPU. Один комп, набитый топовыми видюхами, обставляет небольшой кластер на xeon-ах больше, чем на порядок.
                                      • 0
                                        На такой системе известное видео от Pantural отрендерилось бы вмиг :)
                                        • 0
                                          Наутро, после того, как мы ночью установили и запустили FlexCache, «старший пастух» пришел к нам с отчетом, что все задания выполнены.

                                          Выходит, что до этого ядра простаивали.
                                          • 0
                                            Именно так. «Молотилки» не обеспечивались «сырьем» — теми самыми текстурами.
                                          • –4
                                            Перевод «hack» как «сломать» — позорище переводчику.
                                            • +4
                                              Как бы вы это перевели, сохранив контекстный смысл?
                                              • +3
                                                А по мне в данном случае самый адекватный перевод.
                                              • +2
                                                Пост — прям «кино как мы делали кино». Спасибо автору и переводчику!
                                                А можно как-то вычислить скорость рендеринга 1 кадра (или плана?) на некоем сферическом стандартном компьютере в вакууме? или на сервере определенной модели?

                                                Например, 150 000 лет… или что-то в этом роде? Потому что 100 часов — это даже для 5го по мощьности мирового вычислительного центра — как-то не мало ;)
                                                • +1
                                                  Я бы попросил уточнить, что подразумевается под кадром-сценой-планом в Аватаре. Все предлагают считать от 30 кадров в секунду, но в Аватаре же ТРИДЭ! 3д!.. Это значит, что вместо одного кадра в один момент времени показывается сразу два. 1 на левый глаз и 1 на правый. Стало быть считаем 60 кадров в секунду. Это верно?
                                                  • 0
                                                    Думаю, считается как раз именно по 2 кадра сразу.
                                                  • 0
                                                    Особо понравилось, что проблем не произошло из-за сплоченной работы командой.
                                                    А 10 000 + 10 000 + 5 000 ядер — впечатляет!

                                                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                    Самое читаемое