Comments 46
А не проще было бы приоритет ниже среднего установить для процесса «специализированного программного обеспечения, позволяющего производить сетевые расчеты» или там же, в менеджере задач, указать конкретные ядра, которые оно может использовать?
В некоторых случаях проблему можно решить и приоритетом. Но это требует от пользователя определенных навыков, он случайно может остановить какой-нибудь важный процесс или выставить максимальный приоритет для процесса расчета, что повесит машину. Тем более, что решатели могут быть не только под Windows, и настройки делаются всего один раз. Пользователь и знать не будет, что его машина участвует в расчете.
Ребята, не обижайтесь, но ваше решение создано по принципу «умею пользоваться плоскогубцами — значит и гвозди буду ими же забивать»…
Городить виртуалку ради банального ограничения приоритета фоновой задачи — это сурово. Вы КПД по CPU такого решения хоть посмотрели по тестам?
Увы, не знаю, как под виндой, но под юниксами ваша «задача» решается банальным nice -n 20 (ну и возможно ionice для ограничения приоритета дисковой активности) при запуске демона расчета. Под виндой думаю тоже можно найти решение, хоть бы и на visualbasic-е.
Такая настройка тоже делается один раз и пользователь тоже знать не будет, что на его машине фоновый процесс что-то считает с минимальным приоритетом ))
Городить виртуалку ради банального ограничения приоритета фоновой задачи — это сурово. Вы КПД по CPU такого решения хоть посмотрели по тестам?
Увы, не знаю, как под виндой, но под юниксами ваша «задача» решается банальным nice -n 20 (ну и возможно ionice для ограничения приоритета дисковой активности) при запуске демона расчета. Под виндой думаю тоже можно найти решение, хоть бы и на visualbasic-е.
Такая настройка тоже делается один раз и пользователь тоже знать не будет, что на его машине фоновый процесс что-то считает с минимальным приоритетом ))
Вот тут разобраны win cmd команд для понижения приоритета — stackoverflow.com/questions/4208/windows-equivalent-of-nice
Но в реальности все сложно, по многим причинам мне это решение чемто импонирует :)
Вот причины почему сложно ограничить бак граунд процессы, что под win, что под линуксом:
1. Жестко ограничить выделеной группе процесов сумарыный расход процентов CPU и что самое главное «оперативку» не получиться не под линукс и не под вин… Или расскажите мне как это сделать — честно интересно!!!
2. Даже если демон рендера запускает процесс рендер с низким приоритете, то он в свою очередь запускает дочернии процессы и на сколько я помню, они не наследуют этот приоритет. А некорые процессы/программы рендера сами сбрасывают/повышают приоритет!
3. В системе рендер манаджемента которую использовали в статье (скорей всего встроеный BackBurner) не получиться внедрить кастомную командуну строчку для попыток понижения приоритета
Но в реальности все сложно, по многим причинам мне это решение чемто импонирует :)
Вот причины почему сложно ограничить бак граунд процессы, что под win, что под линуксом:
1. Жестко ограничить выделеной группе процесов сумарыный расход процентов CPU и что самое главное «оперативку» не получиться не под линукс и не под вин… Или расскажите мне как это сделать — честно интересно!!!
2. Даже если демон рендера запускает процесс рендер с низким приоритете, то он в свою очередь запускает дочернии процессы и на сколько я помню, они не наследуют этот приоритет. А некорые процессы/программы рендера сами сбрасывают/повышают приоритет!
3. В системе рендер манаджемента которую использовали в статье (скорей всего встроеный BackBurner) не получиться внедрить кастомную командуну строчку для попыток понижения приоритета
1. Зачем жестко? Ведь задача стоит — чтобы не мешало никому. Что толку оставлять свободное ядро-два, если за их счет можно соотв уменьшить время рендера? Опять же, а если свободных ядер окажется недостаточно для текущих локальных задач? В случае с понижением приоритета ОС сама отберет ядра у фонового рендера.
С оперативкой да, ограничить не получится, но опять же — а что такого? Если в виртуалке рендер уйдет в своп — кому от этого легче станет. И опять же — если виртуалка не будет зря занимать оперативку (а почем ОС знает, страницы памяти виртуалки уже освободились или ещё понадобятся ?), то для локальных задач её ещё больше получится.
2. В юнихах поднять приоритет себе или другим может только рут. Остальные могут только понизить, и только своему uid-у (что логично). За винду не скажу — не спец.
3. Неужели и cmd-файл из которого будет запускаться эта вся система с пониженым приоритетом нельзя составить?
С оперативкой да, ограничить не получится, но опять же — а что такого? Если в виртуалке рендер уйдет в своп — кому от этого легче станет. И опять же — если виртуалка не будет зря занимать оперативку (а почем ОС знает, страницы памяти виртуалки уже освободились или ещё понадобятся ?), то для локальных задач её ещё больше получится.
2. В юнихах поднять приоритет себе или другим может только рут. Остальные могут только понизить, и только своему uid-у (что логично). За винду не скажу — не спец.
3. Неужели и cmd-файл из которого будет запускаться эта вся система с пониженым приоритетом нельзя составить?
1. Ответ ну вы попробуйте так сделать и посмотрити смогу ли люди дальше работать… Я лично пробывал (правда давно) не получаеться :) Метод описаный в статье дает шанс что смогут…
2. Я не про поднятие, я про наследование приоритета от материнского к дочернему… Это есть в линуксе? В винде нет на сколько я понимаю…
3. Нужно менять систему рендер менаджемента, на другую отличную от встроеной
2. Я не про поднятие, я про наследование приоритета от материнского к дочернему… Это есть в линуксе? В винде нет на сколько я понимаю…
3. Нужно менять систему рендер менаджемента, на другую отличную от встроеной
2. Есть-есть
1. Ну я порты свои на фряхе например апгрейжу под найсом, а то иначе браузер подтормаживает. И по работе некоторые вещи сразу под найсом программирую запускать, подсчет контрольной суммы например. Не вижу проблем с этим, удобная штука, прямое решение по ограничению аппетитов cpu-емких задач.
2. Забыл упомянуть, разумеется есть, иначе какой смысл в ограничении на подъем приоритета, если банальный fork/exit может его сбросить, без наследования то…
3. Опять же, не спец по виндам, но в юниксе если любую навороченную систему рендер менеджмента запустить из под скрипта, который себе понизил приоритет (перед запуском оной системы), то выше этого приоритета она не прыгнет (без рутовых прав, конечно).
4. Также напомню про оверхед от виртуалки, который может выражаться в десятках процентов. И про проблемы с пробросом PCI(e) устройств в виртуалку для акселерации рендера.
2. Забыл упомянуть, разумеется есть, иначе какой смысл в ограничении на подъем приоритета, если банальный fork/exit может его сбросить, без наследования то…
3. Опять же, не спец по виндам, но в юниксе если любую навороченную систему рендер менеджмента запустить из под скрипта, который себе понизил приоритет (перед запуском оной системы), то выше этого приоритета она не прыгнет (без рутовых прав, конечно).
4. Также напомню про оверхед от виртуалки, который может выражаться в десятках процентов. И про проблемы с пробросом PCI(e) устройств в виртуалку для акселерации рендера.
2. В винде приоритеты процессов тоже наследуются. И тоже могут быть ограничены от ручного повышения.
В линуксе очень многое можно выставить для пользователя через limits.conf
Можно ограничить CPU, RAM, приоритеты и т.д и т.п
Этот пользователь будет запускать «рендер вычисления» и позволит реализовать задуманное.
man limits.confМожно ограничить CPU, RAM, приоритеты и т.д и т.п
Этот пользователь будет запускать «рендер вычисления» и позволит реализовать задуманное.
память можно зарезать под линуксом гораздо более легковесными способами — через LXC или linux-vserver, контейнерной виртуализацией, в общем.
в винде: stackoverflow.com/questions/192876/set-windows-process-or-user-memory-limit
в винде: stackoverflow.com/questions/192876/set-windows-process-or-user-memory-limit
а вариант уйти в облака не рассматривали, например на том же амазоне?
Вариантов много, в статье лишь частный случай. К тому же подходит для уже сформированного парка рабочих станций.
а артефактов не было из-за разного софта, разного железа или машины все одинаковые? у себя делали сетевой рендер в ночное время на 40 машинах, было замечено что на разном железе очень сильно отличается картинка, получались разной тональность бакеты
Софт одинаковый, ОС и железо безразличны. В Mental Ray артефактов не было. Разница в тональности бывает в Vray из-за того, что некоторые машины не находят путь к картам или материалам. Об этих проблемах есть много статей.
Не соглашусь. v-ray на nvidia и на ati-шных видеокартах ведут себя по разному, ментал тоже чувствителен к железу. Скорее всего у вас одинаковое железо было.
Не силен в технике, но попрошу админов, может поделятся информацией как на амазоне настроили нам ферму. Кстати Автодеск стал предлагать облачный рендер в последних версиях Ревита, может он и для Макса такое сделает. Работает пока еще с глюками, но идея нравится — щелкнул кнопку и работай дальше, картинка сама отрендерится и вернётся на машину.
Не силен в технике, но попрошу админов, может поделятся информацией как на амазоне настроили нам ферму. Кстати Автодеск стал предлагать облачный рендер в последних версиях Ревита, может он и для Макса такое сделает. Работает пока еще с глюками, но идея нравится — щелкнул кнопку и работай дальше, картинка сама отрендерится и вернётся на машину.
А если бы хоть один человек в студии знал бы что такое Render Farm Manager, не пришлось бы просить людей, далеких от систем распределенного рендеринга, заново изобретать велосипед. Да к тому же настолько криво.
Тяжело представить чем занимаются artist-ы в студии если им для работы (а не для воспроизведения Full HD видео, и не для «обработки 3D-объекта» включенного в состав еще Discreet 3ds max 5) хватает двух тредов. Последный раз когда я работал артистом (это было 4 года назад) мне не хватало 8. Я серьезно, они не смогут хорошо делать свою работу на ультрабуке.
1) Насколько я понял, вы используете mental ray Satellite, что автоматически ислючает любую очередь заданий, исключает и scheduling заданий. Каждый человек в студии может отправить только одну задачу на рендер, ему придется ждать завершения задачи, вместо того чтобы продолжить работать. Если рендерить захотят несколько человек, то им придется договариваться как делить компьютеры, и каждый раз редактировать список машин для рендера. Это даже описывать долго, сложно представить что будет с артистами.
2) Большинство Render Farm Manager-ов способны ограничить количество тредов для текущей задачи. Гипервизор — это неоправдано. И все опять же придется делать вручную. Если в данный момент времени машина не выполняет никакой задачи, зачем ограничивать артиста двумя тредами? И если артист, видя что его машина не задействована в рендеринге.
Очень сложно, работа в студии это постоянные дедлайны, постоянная спешка. Из за вас артистам придется задерживаться допоздна на работе. Но зато вы использовали никому не нужный гипервизор, браво. К слову, стоимость лицензии VMware vSphere Standard — USD 1,940.25. Это стоимость одной хорошей рендер ноды, которую могла купить себе студия.
Тяжело представить чем занимаются artist-ы в студии если им для работы (а не для воспроизведения Full HD видео, и не для «обработки 3D-объекта» включенного в состав еще Discreet 3ds max 5) хватает двух тредов. Последный раз когда я работал артистом (это было 4 года назад) мне не хватало 8. Я серьезно, они не смогут хорошо делать свою работу на ультрабуке.
1) Насколько я понял, вы используете mental ray Satellite, что автоматически ислючает любую очередь заданий, исключает и scheduling заданий. Каждый человек в студии может отправить только одну задачу на рендер, ему придется ждать завершения задачи, вместо того чтобы продолжить работать. Если рендерить захотят несколько человек, то им придется договариваться как делить компьютеры, и каждый раз редактировать список машин для рендера. Это даже описывать долго, сложно представить что будет с артистами.
2) Большинство Render Farm Manager-ов способны ограничить количество тредов для текущей задачи. Гипервизор — это неоправдано. И все опять же придется делать вручную. Если в данный момент времени машина не выполняет никакой задачи, зачем ограничивать артиста двумя тредами? И если артист, видя что его машина не задействована в рендеринге.
Очень сложно, работа в студии это постоянные дедлайны, постоянная спешка. Из за вас артистам придется задерживаться допоздна на работе. Но зато вы использовали никому не нужный гипервизор, браво. К слову, стоимость лицензии VMware vSphere Standard — USD 1,940.25. Это стоимость одной хорошей рендер ноды, которую могла купить себе студия.
Частично не согласен — habrahabr.ru/company/depocomputers/blog/163829/#comment_5635697
Но согласен что точно нужны нормальные системы Render Манаджмента! :)
Но согласен что точно нужны нормальные системы Render Манаджмента! :)
Во многом согласен с вами (в частности на счет людей, далеких от систем распределенного рендеринга), но при чем здесь VMware? Речь шла о Parallels, который дешевле более чем в 25 раз.
Я могу оставлять комментарий только раз в сутки, поэтому объединю тут два комментария в одном
>>> 1. Жестко ограничить выделеной группе процесов сумарыный расход процентов CPU и что самое главное «оперативку» не получиться не под линукс и не под вин… Или расскажите мне как это сделать — честно интересно!!!
Жестко ограничить запускаемому приложению CPU просто: start /affinity x, где binary x — выделяемые процессоры например первый и третий cpu: 101 bin = 5
>>> Во многом согласен с вами (в частности на счет людей, далеких от систем распределенного рендеринга), но при чем здесь VMware? Речь шла о Parallels, который дешевле более чем в 25 раз.
Прошу прощения за свою невнимательность. Вообще то я хотел отредактировать свое сообщение но из за низкой кармы это не получается.
>>> 1. Жестко ограничить выделеной группе процесов сумарыный расход процентов CPU и что самое главное «оперативку» не получиться не под линукс и не под вин… Или расскажите мне как это сделать — честно интересно!!!
Жестко ограничить запускаемому приложению CPU просто: start /affinity x, где binary x — выделяемые процессоры например первый и третий cpu: 101 bin = 5
>>> Во многом согласен с вами (в частности на счет людей, далеких от систем распределенного рендеринга), но при чем здесь VMware? Речь шла о Parallels, который дешевле более чем в 25 раз.
Прошу прощения за свою невнимательность. Вообще то я хотел отредактировать свое сообщение но из за низкой кармы это не получается.
>Жестко ограничить запускаемому приложению CPU просто: start /affinity x, где binary x — выделяемые процессоры например >первый и третий cpu: 101 bin = 5
1. Да cpu маску и CPU приортет можно задать через командную строчку (start /low)… Но как это сделать в бакбернере или vrayspawn ответ никак :( Нужно меять систему рендринга, что было можно исgользовать кастомные cmd.
2. Ограничить память (mam) как выяснилось можно через хитрый JOBS (про win см коментарии рядом) хотя даже мы в Duma мы это не сделали может быть как раз сделаем… Я незнаю ПО для рендер манаджеров под win кто это умеет делает. Сейчас через JOB в Duma под Win мы убиваем все дочернии процесы.
1. Да cpu маску и CPU приортет можно задать через командную строчку (start /low)… Но как это сделать в бакбернере или vrayspawn ответ никак :( Нужно меять систему рендринга, что было можно исgользовать кастомные cmd.
2. Ограничить память (mam) как выяснилось можно через хитрый JOBS (про win см коментарии рядом) хотя даже мы в Duma мы это не сделали может быть как раз сделаем… Я незнаю ПО для рендер манаджеров под win кто это умеет делает. Сейчас через JOB в Duma под Win мы убиваем все дочернии процесы.
Какой-то пипец, что за студия такая, жлобская. В процессе работы желательно видеть, то что ты делаешь, хотя бы приблизительно. Про ультра бук выше правильно подмечено, это не работа а слайд шоу какое-то!
Второй момент, ПАМЯТЬ, которой нужно много, для того что-бы как-то переварвать множество текстур высокого разрешения. У вас может быть дофига, офигительно быстрых ядер, но при нехватке памяти они большую часть времени курят в ожидании готовности того или иного хранилища…
Бюджетное решение для финального рендеринга, это как раз-таки одна машина (возможно даже бытовая ибо её падения не критичны) с огромным количество оперативной памяти, и шустрыми дисками. Ибо сетевое решение, даже на база таких-же машин, будет требовать использования профессиональных сетевых компонентов и человека с очень специфическим опытом.
Второй момент, ПАМЯТЬ, которой нужно много, для того что-бы как-то переварвать множество текстур высокого разрешения. У вас может быть дофига, офигительно быстрых ядер, но при нехватке памяти они большую часть времени курят в ожидании готовности того или иного хранилища…
Бюджетное решение для финального рендеринга, это как раз-таки одна машина (возможно даже бытовая ибо её падения не критичны) с огромным количество оперативной памяти, и шустрыми дисками. Ибо сетевое решение, даже на база таких-же машин, будет требовать использования профессиональных сетевых компонентов и человека с очень специфическим опытом.
«Огромное количество оперативной памяти» на определенном этапе становится избыточным, а вот «дофига, офигительно быстрых ядер» всегда будут давать рост производительности при их наращивании, т.к. рендеринг — почти идеальная многопотоковая задача. И тем более кто сказал, что в описанном решении нехватка оперативки? Она сейчас стоит очень не дорого, и средние рабочие станции с 16-32Гб — это норма.
И к тому же, коллеги, я не претендую на признание этого метода лучшим. Я технический специалист по графическим станциям и с распределенным рендерингом столкнулся впервые. Метод стабилен, эффективен, не привязан к ОС, не требует ни от по пользователя ни от админа навыков описанных выше. Но, в любом случае, я много полезного узнал из всех комментариев.
И к тому же, коллеги, я не претендую на признание этого метода лучшим. Я технический специалист по графическим станциям и с распределенным рендерингом столкнулся впервые. Метод стабилен, эффективен, не привязан к ОС, не требует ни от по пользователя ни от админа навыков описанных выше. Но, в любом случае, я много полезного узнал из всех комментариев.
Правильно, норма, а у вас на рабочую станцию по 6 гигов приходится, из них два прибирает виртуалка :-)
3D графика бывает разная, если речь о архитектурной визуализации, то действительно, и памяти не надо, и вообще GPU решают, так что эффективность так и прёт.
Если же речь заходит о кинематографе, то в иной сцене одних текстур на десяток гиг может набираться, а ещё всякая процедурщина, ага вот и разрослась сценка до невиданных размеров…
рендеринг — почти идеальная многопотоковая задача только на первый взгляд, есть чисто технические проблемы, ведь исходные данные должны быть доступны каждому вычислительному потоку, это задаёт требования к объёму физической памяти кластеров…
PS. Был у меня, случай, когда пришлось городить велосипед подобный вашему, но задача была запустить старое приложение с недоступными исходниками. Вот тут да, виртуалки, и самописный софт, что бы программами запущенными на них дирижировать… Это всё выглядело круто и эпично, но это был костыль педальный. Так же и ваше решение, по своей оригинальности сравнимо с секретаршами, которые распечатывают документ на бумаге, сканируют его в pdf :-)
3D графика бывает разная, если речь о архитектурной визуализации, то действительно, и памяти не надо, и вообще GPU решают, так что эффективность так и прёт.
Если же речь заходит о кинематографе, то в иной сцене одних текстур на десяток гиг может набираться, а ещё всякая процедурщина, ага вот и разрослась сценка до невиданных размеров…
рендеринг — почти идеальная многопотоковая задача только на первый взгляд, есть чисто технические проблемы, ведь исходные данные должны быть доступны каждому вычислительному потоку, это задаёт требования к объёму физической памяти кластеров…
PS. Был у меня, случай, когда пришлось городить велосипед подобный вашему, но задача была запустить старое приложение с недоступными исходниками. Вот тут да, виртуалки, и самописный софт, что бы программами запущенными на них дирижировать… Это всё выглядело круто и эпично, но это был костыль педальный. Так же и ваше решение, по своей оригинальности сравнимо с секретаршами, которые распечатывают документ на бумаге, сканируют его в pdf :-)
Мне просто жалко людей, которые до сих пор не используют фермы на GPU.
Это бесконечно спорно. На сколько я понимаю GPU обрабатывает только трассировку лучей, а все сложные алгоритмы по-прежнему рассчитываются на CPU.
Вот вам пища для размышлений:
1. render.otoy.com/videos.php
2. www.cubixgpu.com/
И Вы могли бы привести пример этих Ваших «сложных» алгоритмов в рендеринге, которые жрали бы больше вычислительных ресурсов чем трассировка лучей (к которой относятся преломления, отражения, рассеивания, каустика, глобальное освещение и т.д.)?
1. render.otoy.com/videos.php
2. www.cubixgpu.com/
И Вы могли бы привести пример этих Ваших «сложных» алгоритмов в рендеринге, которые жрали бы больше вычислительных ресурсов чем трассировка лучей (к которой относятся преломления, отражения, рассеивания, каустика, глобальное освещение и т.д.)?
Я в этом не специалист, но много тестировал систему визуализации iray, которая как раз основана на принципе трассировки лучей и использует GPU при расчете.
Хочу обратить внимание, что CPU при подобном рендеринге также нагружался на 100%.
<img src="
Из диаграммы следует, что младшие Quadro (и тем более GeForce) абсолютно не приспособлены для расчетных задач. При чем производительность 600 модели даже была отрицательной, т.е. CPU справился с задачей в одиночку быстрее, чем в паре с Quadro 600. Топовые видеокарты конечно превосходят по производительности 6-ядерный CPU, но разница не настолько велика, чтобы делать из этого сенсацию. Алгоритмы сложны и CPU по-прежнему справляется с ними эффективно, не смотря на меньшее количество потоков.
Хочу обратить внимание, что CPU при подобном рендеринге также нагружался на 100%.
<img src="
Из диаграммы следует, что младшие Quadro (и тем более GeForce) абсолютно не приспособлены для расчетных задач. При чем производительность 600 модели даже была отрицательной, т.е. CPU справился с задачей в одиночку быстрее, чем в паре с Quadro 600. Топовые видеокарты конечно превосходят по производительности 6-ядерный CPU, но разница не настолько велика, чтобы делать из этого сенсацию. Алгоритмы сложны и CPU по-прежнему справляется с ними эффективно, не смотря на меньшее количество потоков.
Из Вашей же диаграммы следует, что GTX 580 имеет двукратное преимущество по сравнению с i7, следовательно, при вполне сопоставимых ценах, мы имеем в два раза более высокую скорость. Плюс — конфигурация по железу в случае с GPU может быть гораздо (в разы) эффективнее. В 2 раза быстрее — это конечно не сенсация, но разница между сутками и двумя тоже, по Вашему, пренебрежительно мала? К тому же мой личный опыт показывает куда больший прирост производительности. Хотя конечно многое зависит от решаемых задач и мы ничего не знаем о том, при просчете какой именно сцены Вы получили свои данные (количество полигонов, шейдеры, прокси и т.д.).
Далеко не все рендеры написаны под GPU. Я не говорю, что GPGPU плохо, просто я убежден, что это не панацея.
Это не панацея а просто самое эффективное (по соотношению стоимости и производительности, по удобству и т.д.) на сегодняшний момент решение. Те рендеры, которые не поддерживают GPU — вымирающие динозавры в большинстве своем.
Это все конечно оффтопик но всеже :)
Все большие рендер фермы во всех больших студих VFX за рубежом, гдя я был сам или про которые мне рассказвали, НЕ содержат значительного количества GPU. То есть 1000 нод на CPU и типа 40 нод с GPU для спец задач.
Все большие рендер фермы во всех больших студих VFX за рубежом, гдя я был сам или про которые мне рассказвали, НЕ содержат значительного количества GPU. То есть 1000 нод на CPU и типа 40 нод с GPU для спец задач.
Это конечно аргумент. А во всех крупных бухгалтериях все используют IE, на основании этого мы делаем вывод, что это лучший браузер, так?
И еще: одна «нода» на GPU, это сколько GPU? Что там у нас с вычислительной плотностью? И какие именно «спец» задачи имеются в виду? Для CPU в VFX действительно куча дел, и далеко не все они относятся к рендеру, скорее к просчету сцены.
И еще: одна «нода» на GPU, это сколько GPU? Что там у нас с вычислительной плотностью? И какие именно «спец» задачи имеются в виду? Для CPU в VFX действительно куча дел, и далеко не все они относятся к рендеру, скорее к просчету сцены.
Все что описано ниже это ТОЛЬКО для vfx и манимации.
>И еще: одна «нода» на GPU, это сколько GPU?
По разному
— как правлило просто WS тауэры но запихнутые в стойку и в нем 2-4 хороших видео карты
— наверное кто то стал покупать спец шаси с вычислителями но это редкая экзотика и переплата
— в русских компания по vfx/aнимации рендер стойки GPU вообше отсутвуют
>Что там у нас с вычислительной плотностью?
Смысл в том что вся это история с CPU и GPU именно в VFX/анимации и имено в рендер ферме сейчас экономический НЕ выгодна и иностранные студии НЕ покупают. Это не холи вар, я его продолжать НЕ буду продолжать, это факт!
>И какие именно «спец» задачи имеются в виду?
Для расчета: различной динамики газов / воды / твердых тела+ оптический поток + частицы
Для ренринга — инхаус рендера для превью сцены.
Но все эти задачи занимаю не более 10% машиного времения, по сравнению конечным рендрингом.
>И еще: одна «нода» на GPU, это сколько GPU?
По разному
— как правлило просто WS тауэры но запихнутые в стойку и в нем 2-4 хороших видео карты
— наверное кто то стал покупать спец шаси с вычислителями но это редкая экзотика и переплата
— в русских компания по vfx/aнимации рендер стойки GPU вообше отсутвуют
>Что там у нас с вычислительной плотностью?
Смысл в том что вся это история с CPU и GPU именно в VFX/анимации и имено в рендер ферме сейчас экономический НЕ выгодна и иностранные студии НЕ покупают. Это не холи вар, я его продолжать НЕ буду продолжать, это факт!
>И какие именно «спец» задачи имеются в виду?
Для расчета: различной динамики газов / воды / твердых тела+ оптический поток + частицы
Для ренринга — инхаус рендера для превью сцены.
Но все эти задачи занимаю не более 10% машиного времения, по сравнению конечным рендрингом.
> это факт
— это станет фактом, когда Вы приведете примеры конфигураций, их стоимости и вычислительной мощности. В противном случае это безапелляционное голословное утверждение. Еще, хочу обратить Ваше внимание на то, что я говорю именно о рендере, а не о просчете геометрии, физики и частиц, и о том, чем занимаются другие приложения. И топик не о хай-энд-решениях для ведущих студий по производству видео-эффектов, а о бюджетном решении для скромной 3d-студии. Я сам уже насмотрелся на холивары по этой теме и не хочу никому ничего доказывать, я просто вижу вот прямо у себя в офисе, на конкретном примере, дикую разницу в скоростях. Удачи.
— это станет фактом, когда Вы приведете примеры конфигураций, их стоимости и вычислительной мощности. В противном случае это безапелляционное голословное утверждение. Еще, хочу обратить Ваше внимание на то, что я говорю именно о рендере, а не о просчете геометрии, физики и частиц, и о том, чем занимаются другие приложения. И топик не о хай-энд-решениях для ведущих студий по производству видео-эффектов, а о бюджетном решении для скромной 3d-студии. Я сам уже насмотрелся на холивары по этой теме и не хочу никому ничего доказывать, я просто вижу вот прямо у себя в офисе, на конкретном примере, дикую разницу в скоростях. Удачи.
Окей не будем спорить про большие студии и не будем разводить холиварды.
Тогда мне интересно уже узнать про вашу знакомую студию?
Правильно ли я вас понял, что вы рендрите финального качества (а не статичное превью для света/материалов) сиквенсы файлов используя ваши WS компы использую в том числе их GPU? Если да, то какой (или какие) движки рендринга вы используете?
Тогда мне интересно уже узнать про вашу знакомую студию?
Правильно ли я вас понял, что вы рендрите финального качества (а не статичное превью для света/материалов) сиквенсы файлов используя ваши WS компы использую в том числе их GPU? Если да, то какой (или какие) движки рендринга вы используете?
И Вы не ответили на вопрос о «сложных алгоритмах», я просто не совсем понимаю о чем таком идет речь.
Вот статья, которая первой попала на глаза habrahabr.ru/post/125398/
К тому же: CPU в Iray может обойтись без GPU, а вот наоборот — нет. Я не программист, но предполагаю, что часть алгоритмов предназначена для расчета только на CPU, как раз из-за соображений сложности ветвлений.
К тому же: CPU в Iray может обойтись без GPU, а вот наоборот — нет. Я не программист, но предполагаю, что часть алгоритмов предназначена для расчета только на CPU, как раз из-за соображений сложности ветвлений.
Статья не в тему, мы говорим о конкретной специфической области. И совершенно не важно что без чего может обойтись, важна только эффективность решения конкретной задачи. Вся проблема в том, что Вы не 3D-специалист и видимо никогда не ждали просчета сложной сцены в режиме жестких сроков от клиента, когда дорога каждая минута, а рендер гонит артефакты например, а времени на перерендер просто нет… Вот я и говорю, что мне жалко тех, кто до сих пор так мучается.
Ну мне в совою очередь жалко тех, кто мучается в попытках получить идеальную сцену в 3D редакторе, и от монтажа возвращается к моделированию и рендерингу ради сущей фигни, которая легко лечится мановением стилуса композера :-) Для мелких проектов рендер слоёв под композинг кажется слишком толстым, но это сильно бережет время, деньги, нервы…
Давайте вместе пожалеем всех, кто мучается. И вообще, какая разница сложно или просто исправить картинку постобработкой, если сначала её все-равно нужно получить, хоть в каком-то виде? Мне вот еще жалко тех, кто с пеной у рта будет спорить, отстаивая свое владение привычными инструментами, лишь бы не разбираться в чем-то новом. Я ведь не на пустом месте заговорил о GPU, мое мнение — следствие собственного профессионального опыта, я работал с очень разными рендерами, и долго слежу за их эволюцией.
Совершенно правильное предположение. Кроме того, у GPU большие проблемы с точностью, что сильно ограничивает их проф пригодность, это лечится но, взрослому CPU проще самостоятельно выполнить весь просчёт, чем танцевать вокруг GPU с бубном.
… ну и конечно закон Амдала. Для попытки его обойти необходимо усложнять параллельные алгоритмы и упрощать последовательные. И тут снова упираемся в ограничения GPGPU.
Sign up to leave a comment.
Сетевой рендеринг на гибридном кластере