Сетевой рендеринг на гибридном кластере


    Однажды в DEPO Computers поступил запрос рассчитать решение для 10 дизайнеров-проектировщиков, работающих в 3ds Max. Подобрать требовалось не только рабочие станции, но и рендер-сервер для визуализации полученных результатов. С графическими станциями проблем не возникло, но вот рендер-сервер никак не хотел вписываться в бюджет. Объем работ по рендерингу предполагался не большой, но скорость выполнения расчета требовалась высокая. Я порекомендовал заказчику использовать распределенные вычисления на всех рабочих станциях средствами сетевого рендеринга, но заказчика не устроил этот вариант. Он сообщил, что при запуске расчета, все сетевые машины загружаются на 100%, и возможность локальной работы практически исключается. При этом доступные средства, позволяющие отрегулировать нагрузку на сетевые машины участвующие в расчете, довольно сложны и не всегда могут решить поставленную задачу.

    Нам пришлось разработать новый способ реализации решения, который позволил бы обеспечить необходимый функционал в рамках заданного бюджета.

    Основой решения стала изоляция ресурсов предназначенных для локальной работы и ресурсов выделяемых для сетевых расчетов. Эта задача решилась переносом вычислительных ресурсов в виртуальную среду и объединением в вычислительный кластер. Виртуальная среда была построена на базе гипервизора Parallels Workstation 6.

    Пример реализации

    На все графические станции устанавливается операционная система и гипервизор Parallels Workstation. С помощью гипервизора создается виртуальная машина, на которую устанавливается операционная система – в нашем случае это Windows 7, но возможна установка различных операционных систем. В нашей конфигурации хост-машина имеет 12 вычислительных потоков, для виртуальной машины выделяется 10 из 12. Оставшиеся 2 потока обеспечат стабильную работу хост-машины.



    Также в распоряжение виртуального вычислительного сервера выделяется физический сетевой адаптер для обеспечения высокоскоростного доступа в локальную сеть. Виртуальная машина получает необходимый для работы объем оперативной памяти и дискового пространства.



    На хост-машины устанавливается специализированное программное обеспечение, позволяющее производить сетевые расчеты. На виртуальные машины устанавливаются программные модули (решатели), которые позволят идентифицировать машину в сети в качестве звена вычислительного кластера.
    В нашем случае используется программа Autodesk 3Ds MAX для трехмерного моделирования и система визуализации Mental Ray с поддержкой сетевого рендеринга. Для того чтобы при расчете рендера использовать вычислительные мощности сетевых машин, прописываем IP-адреса каждой машины в настройках системы визуализации. В нашем примере задействованы 5 графических станций, одна из которых является инициатором расчета.



    В процессе рендеринга система визуализации задействует 90-100% вычислительных мощностей всех машин, участвующих в расчете. Так как в гибридном решении для виртуальной машины выделяются не все ресурсы станции, во время сетевого расчета хост-машина сохранят способность к локальной работе. На изображении приведен пример загрузки вычислительных ресурсов виртуальной машины и хоста при следующей нагрузке: виртуальная машина участвует в сетевом расчете, а на графической станции локально проигрывается Full HD видеоролик и производится обработка 3D-объекта.



    Монитор ресурсов показывает 100% загрузку виртуальной машины и 93% загрузку графической станции. Если для локальной работы графической станции требуется больше вычислительных мощностей, то в настройках гипервизора можно перераспределить ресурсы в пользу хоста.
    В момент, когда работа на графической станции не велась и активной была только виртуальная машина, загрузка хост-машины снижалась до 50-60%. Это означает, что существует запас вычислительных ресурсов для локальной работы графической станции.



    Прирост производительности в этом решении пропорционален количеству ядер, участвующих в расчете процессоров (при условии, если они одинаковые)

    Таким образом, гибридное графическое решение для кластерных вычислений позволяет эффективно использовать вычислительные ресурсы каждой графической станции без ущерба локальной работе и производить несложные расчеты без использования выделенных серверов. Это решение можно применять для повышения производительности системы в программных продуктах ANSYS, MSC, Mental ray, V-Ray и других программах, использующих распределенные вычисления.

    Надеюсь, что это простое решение поможет кому-нибудь c оптимизацией работы группы пользователей в расчетно-графических приложениях.
    DEPO Computers
    86.47
    Company
    Share post

    Comments 46

      +5
      А не проще было бы приоритет ниже среднего установить для процесса «специализированного программного обеспечения, позволяющего производить сетевые расчеты» или там же, в менеджере задач, указать конкретные ядра, которые оно может использовать?
        +1
        В некоторых случаях проблему можно решить и приоритетом. Но это требует от пользователя определенных навыков, он случайно может остановить какой-нибудь важный процесс или выставить максимальный приоритет для процесса расчета, что повесит машину. Тем более, что решатели могут быть не только под Windows, и настройки делаются всего один раз. Пользователь и знать не будет, что его машина участвует в расчете.
          +10
          Ребята, не обижайтесь, но ваше решение создано по принципу «умею пользоваться плоскогубцами — значит и гвозди буду ими же забивать»…

          Городить виртуалку ради банального ограничения приоритета фоновой задачи — это сурово. Вы КПД по CPU такого решения хоть посмотрели по тестам?

          Увы, не знаю, как под виндой, но под юниксами ваша «задача» решается банальным nice -n 20 (ну и возможно ionice для ограничения приоритета дисковой активности) при запуске демона расчета. Под виндой думаю тоже можно найти решение, хоть бы и на visualbasic-е.
          Такая настройка тоже делается один раз и пользователь тоже знать не будет, что на его машине фоновый процесс что-то считает с минимальным приоритетом ))
            0
            Вот тут разобраны win cmd команд для понижения приоритета — stackoverflow.com/questions/4208/windows-equivalent-of-nice

            Но в реальности все сложно, по многим причинам мне это решение чемто импонирует :)

            Вот причины почему сложно ограничить бак граунд процессы, что под win, что под линуксом:
            1. Жестко ограничить выделеной группе процесов сумарыный расход процентов CPU и что самое главное «оперативку» не получиться не под линукс и не под вин… Или расскажите мне как это сделать — честно интересно!!!
            2. Даже если демон рендера запускает процесс рендер с низким приоритете, то он в свою очередь запускает дочернии процессы и на сколько я помню, они не наследуют этот приоритет. А некорые процессы/программы рендера сами сбрасывают/повышают приоритет!
            3. В системе рендер манаджемента которую использовали в статье (скорей всего встроеный BackBurner) не получиться внедрить кастомную командуну строчку для попыток понижения приоритета
              0
              1. Зачем жестко? Ведь задача стоит — чтобы не мешало никому. Что толку оставлять свободное ядро-два, если за их счет можно соотв уменьшить время рендера? Опять же, а если свободных ядер окажется недостаточно для текущих локальных задач? В случае с понижением приоритета ОС сама отберет ядра у фонового рендера.
              С оперативкой да, ограничить не получится, но опять же — а что такого? Если в виртуалке рендер уйдет в своп — кому от этого легче станет. И опять же — если виртуалка не будет зря занимать оперативку (а почем ОС знает, страницы памяти виртуалки уже освободились или ещё понадобятся ?), то для локальных задач её ещё больше получится.

              2. В юнихах поднять приоритет себе или другим может только рут. Остальные могут только понизить, и только своему uid-у (что логично). За винду не скажу — не спец.

              3. Неужели и cmd-файл из которого будет запускаться эта вся система с пониженым приоритетом нельзя составить?
                0
                1. Ответ ну вы попробуйте так сделать и посмотрити смогу ли люди дальше работать… Я лично пробывал (правда давно) не получаеться :) Метод описаный в статье дает шанс что смогут…

                2. Я не про поднятие, я про наследование приоритета от материнского к дочернему… Это есть в линуксе? В винде нет на сколько я понимаю…

                3. Нужно менять систему рендер менаджемента, на другую отличную от встроеной
                  0
                  2. Есть-есть
                    –1
                    1. Ну я порты свои на фряхе например апгрейжу под найсом, а то иначе браузер подтормаживает. И по работе некоторые вещи сразу под найсом программирую запускать, подсчет контрольной суммы например. Не вижу проблем с этим, удобная штука, прямое решение по ограничению аппетитов cpu-емких задач.

                    2. Забыл упомянуть, разумеется есть, иначе какой смысл в ограничении на подъем приоритета, если банальный fork/exit может его сбросить, без наследования то…

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

                    4. Также напомню про оверхед от виртуалки, который может выражаться в десятках процентов. И про проблемы с пробросом PCI(e) устройств в виртуалку для акселерации рендера.
                    0
                    2. В винде приоритеты процессов тоже наследуются. И тоже могут быть ограничены от ручного повышения.
                    0
                    В линуксе очень многое можно выставить для пользователя через limits.conf
                    man limits.conf

                    Можно ограничить CPU, RAM, приоритеты и т.д и т.п
                    Этот пользователь будет запускать «рендер вычисления» и позволит реализовать задуманное.
                      0
                      память можно зарезать под линуксом гораздо более легковесными способами — через LXC или linux-vserver, контейнерной виртуализацией, в общем.

                      в винде: stackoverflow.com/questions/192876/set-windows-process-or-user-memory-limit
                –1
                а вариант уйти в облака не рассматривали, например на том же амазоне?
                  0
                  Вариантов много, в статье лишь частный случай. К тому же подходит для уже сформированного парка рабочих станций.
                    +4
                    а артефактов не было из-за разного софта, разного железа или машины все одинаковые? у себя делали сетевой рендер в ночное время на 40 машинах, было замечено что на разном железе очень сильно отличается картинка, получались разной тональность бакеты
                      0
                      Софт одинаковый, ОС и железо безразличны. В Mental Ray артефактов не было. Разница в тональности бывает в Vray из-за того, что некоторые машины не находят путь к картам или материалам. Об этих проблемах есть много статей.
                        –2
                        Не соглашусь. v-ray на nvidia и на ati-шных видеокартах ведут себя по разному, ментал тоже чувствителен к железу. Скорее всего у вас одинаковое железо было.

                        Не силен в технике, но попрошу админов, может поделятся информацией как на амазоне настроили нам ферму. Кстати Автодеск стал предлагать облачный рендер в последних версиях Ревита, может он и для Макса такое сделает. Работает пока еще с глюками, но идея нравится — щелкнул кнопку и работай дальше, картинка сама отрендерится и вернётся на машину.
                          0
                          Vray считает процессором — он не ведет себя на видеокартах никак вообще.
                          А железо было частично без видюх вовсе, а процессоры от i5 до E5
                            –2
                            Vray не только процом считает, он на nvidia считает на gpu если поддерживается cuda, а вот ati gpu не поддерживает(либо я об этом не знаю еще :)
                              0
                              Обычный Vray работает с CPU, а вот Vray RT имеет расширение с обработкой на GPU.
                              "… а вот ati gpu не поддерживает..." Вы наверное хотели сказать ATI не поддерживает GPGPU. Но это не так, Open CL работает и на AMD-шных видюхах.
                  +5
                  А если бы хоть один человек в студии знал бы что такое 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. Это стоимость одной хорошей рендер ноды, которую могла купить себе студия.
                    +2
                    Частично не согласен — habrahabr.ru/company/depocomputers/blog/163829/#comment_5635697
                    Но согласен что точно нужны нормальные системы Render Манаджмента! :)
                      +1
                      Во многом согласен с вами (в частности на счет людей, далеких от систем распределенного рендеринга), но при чем здесь VMware? Речь шла о Parallels, который дешевле более чем в 25 раз.
                        0
                        Я могу оставлять комментарий только раз в сутки, поэтому объединю тут два комментария в одном

                        >>> 1. Жестко ограничить выделеной группе процесов сумарыный расход процентов CPU и что самое главное «оперативку» не получиться не под линукс и не под вин… Или расскажите мне как это сделать — честно интересно!!!

                        Жестко ограничить запускаемому приложению CPU просто: start /affinity x, где binary x — выделяемые процессоры например первый и третий cpu: 101 bin = 5

                        >>> Во многом согласен с вами (в частности на счет людей, далеких от систем распределенного рендеринга), но при чем здесь VMware? Речь шла о Parallels, который дешевле более чем в 25 раз.

                        Прошу прощения за свою невнимательность. Вообще то я хотел отредактировать свое сообщение но из за низкой кармы это не получается.
                          +1
                          >Жестко ограничить запускаемому приложению 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
                        Какой-то пипец, что за студия такая, жлобская. В процессе работы желательно видеть, то что ты делаешь, хотя бы приблизительно. Про ультра бук выше правильно подмечено, это не работа а слайд шоу какое-то!

                        Второй момент, ПАМЯТЬ, которой нужно много, для того что-бы как-то переварвать множество текстур высокого разрешения. У вас может быть дофига, офигительно быстрых ядер, но при нехватке памяти они большую часть времени курят в ожидании готовности того или иного хранилища…

                        Бюджетное решение для финального рендеринга, это как раз-таки одна машина (возможно даже бытовая ибо её падения не критичны) с огромным количество оперативной памяти, и шустрыми дисками. Ибо сетевое решение, даже на база таких-же машин, будет требовать использования профессиональных сетевых компонентов и человека с очень специфическим опытом.
                          +2
                          «Огромное количество оперативной памяти» на определенном этапе становится избыточным, а вот «дофига, офигительно быстрых ядер» всегда будут давать рост производительности при их наращивании, т.к. рендеринг — почти идеальная многопотоковая задача. И тем более кто сказал, что в описанном решении нехватка оперативки? Она сейчас стоит очень не дорого, и средние рабочие станции с 16-32Гб — это норма.
                          И к тому же, коллеги, я не претендую на признание этого метода лучшим. Я технический специалист по графическим станциям и с распределенным рендерингом столкнулся впервые. Метод стабилен, эффективен, не привязан к ОС, не требует ни от по пользователя ни от админа навыков описанных выше. Но, в любом случае, я много полезного узнал из всех комментариев.
                            –1
                            Правильно, норма, а у вас на рабочую станцию по 6 гигов приходится, из них два прибирает виртуалка :-)

                            3D графика бывает разная, если речь о архитектурной визуализации, то действительно, и памяти не надо, и вообще GPU решают, так что эффективность так и прёт.
                            Если же речь заходит о кинематографе, то в иной сцене одних текстур на десяток гиг может набираться, а ещё всякая процедурщина, ага вот и разрослась сценка до невиданных размеров…
                            рендеринг — почти идеальная многопотоковая задача только на первый взгляд, есть чисто технические проблемы, ведь исходные данные должны быть доступны каждому вычислительному потоку, это задаёт требования к объёму физической памяти кластеров…

                            PS. Был у меня, случай, когда пришлось городить велосипед подобный вашему, но задача была запустить старое приложение с недоступными исходниками. Вот тут да, виртуалки, и самописный софт, что бы программами запущенными на них дирижировать… Это всё выглядело круто и эпично, но это был костыль педальный. Так же и ваше решение, по своей оригинальности сравнимо с секретаршами, которые распечатывают документ на бумаге, сканируют его в pdf :-)
                          –1
                          Мне просто жалко людей, которые до сих пор не используют фермы на GPU.
                            0
                            Это бесконечно спорно. На сколько я понимаю GPU обрабатывает только трассировку лучей, а все сложные алгоритмы по-прежнему рассчитываются на CPU.
                              –1
                              Вот вам пища для размышлений:
                              1. render.otoy.com/videos.php
                              2. www.cubixgpu.com/

                              И Вы могли бы привести пример этих Ваших «сложных» алгоритмов в рендеринге, которые жрали бы больше вычислительных ресурсов чем трассировка лучей (к которой относятся преломления, отражения, рассеивания, каустика, глобальное освещение и т.д.)?
                                0
                                Я в этом не специалист, но много тестировал систему визуализации iray, которая как раз основана на принципе трассировки лучей и использует GPU при расчете.

                                Хочу обратить внимание, что CPU при подобном рендеринге также нагружался на 100%.

                                <img src="image
                                Из диаграммы следует, что младшие Quadro (и тем более GeForce) абсолютно не приспособлены для расчетных задач. При чем производительность 600 модели даже была отрицательной, т.е. CPU справился с задачей в одиночку быстрее, чем в паре с Quadro 600. Топовые видеокарты конечно превосходят по производительности 6-ядерный CPU, но разница не настолько велика, чтобы делать из этого сенсацию. Алгоритмы сложны и CPU по-прежнему справляется с ними эффективно, не смотря на меньшее количество потоков.
                                  +1
                                  Из Вашей же диаграммы следует, что GTX 580 имеет двукратное преимущество по сравнению с i7, следовательно, при вполне сопоставимых ценах, мы имеем в два раза более высокую скорость. Плюс — конфигурация по железу в случае с GPU может быть гораздо (в разы) эффективнее. В 2 раза быстрее — это конечно не сенсация, но разница между сутками и двумя тоже, по Вашему, пренебрежительно мала? К тому же мой личный опыт показывает куда больший прирост производительности. Хотя конечно многое зависит от решаемых задач и мы ничего не знаем о том, при просчете какой именно сцены Вы получили свои данные (количество полигонов, шейдеры, прокси и т.д.).
                                    0
                                    Далеко не все рендеры написаны под GPU. Я не говорю, что GPGPU плохо, просто я убежден, что это не панацея.
                                      –2
                                      Это не панацея а просто самое эффективное (по соотношению стоимости и производительности, по удобству и т.д.) на сегодняшний момент решение. Те рендеры, которые не поддерживают GPU — вымирающие динозавры в большинстве своем.
                                        0
                                        Это все конечно оффтопик но всеже :)
                                        Все большие рендер фермы во всех больших студих VFX за рубежом, гдя я был сам или про которые мне рассказвали, НЕ содержат значительного количества GPU. То есть 1000 нод на CPU и типа 40 нод с GPU для спец задач.
                                          0
                                          Это конечно аргумент. А во всех крупных бухгалтериях все используют IE, на основании этого мы делаем вывод, что это лучший браузер, так?
                                          И еще: одна «нода» на GPU, это сколько GPU? Что там у нас с вычислительной плотностью? И какие именно «спец» задачи имеются в виду? Для CPU в VFX действительно куча дел, и далеко не все они относятся к рендеру, скорее к просчету сцены.
                                            0
                                            Все что описано ниже это ТОЛЬКО для vfx и манимации.
                                            >И еще: одна «нода» на GPU, это сколько GPU?
                                            По разному
                                            — как правлило просто WS тауэры но запихнутые в стойку и в нем 2-4 хороших видео карты
                                            — наверное кто то стал покупать спец шаси с вычислителями но это редкая экзотика и переплата
                                            — в русских компания по vfx/aнимации рендер стойки GPU вообше отсутвуют

                                            >Что там у нас с вычислительной плотностью?
                                            Смысл в том что вся это история с CPU и GPU именно в VFX/анимации и имено в рендер ферме сейчас экономический НЕ выгодна и иностранные студии НЕ покупают. Это не холи вар, я его продолжать НЕ буду продолжать, это факт!

                                            >И какие именно «спец» задачи имеются в виду?
                                            Для расчета: различной динамики газов / воды / твердых тела+ оптический поток + частицы
                                            Для ренринга — инхаус рендера для превью сцены.
                                            Но все эти задачи занимаю не более 10% машиного времения, по сравнению конечным рендрингом.
                                              0
                                              > это факт
                                              — это станет фактом, когда Вы приведете примеры конфигураций, их стоимости и вычислительной мощности. В противном случае это безапелляционное голословное утверждение. Еще, хочу обратить Ваше внимание на то, что я говорю именно о рендере, а не о просчете геометрии, физики и частиц, и о том, чем занимаются другие приложения. И топик не о хай-энд-решениях для ведущих студий по производству видео-эффектов, а о бюджетном решении для скромной 3d-студии. Я сам уже насмотрелся на холивары по этой теме и не хочу никому ничего доказывать, я просто вижу вот прямо у себя в офисе, на конкретном примере, дикую разницу в скоростях. Удачи.
                                                0
                                                Окей не будем спорить про большие студии и не будем разводить холиварды.
                                                Тогда мне интересно уже узнать про вашу знакомую студию?
                                                Правильно ли я вас понял, что вы рендрите финального качества (а не статичное превью для света/материалов) сиквенсы файлов используя ваши WS компы использую в том числе их GPU? Если да, то какой (или какие) движки рендринга вы используете?
                                    0
                                    И Вы не ответили на вопрос о «сложных алгоритмах», я просто не совсем понимаю о чем таком идет речь.
                                      0
                                      Вот статья, которая первой попала на глаза habrahabr.ru/post/125398/
                                      К тому же: CPU в Iray может обойтись без GPU, а вот наоборот — нет. Я не программист, но предполагаю, что часть алгоритмов предназначена для расчета только на CPU, как раз из-за соображений сложности ветвлений.
                                        –1
                                        Статья не в тему, мы говорим о конкретной специфической области. И совершенно не важно что без чего может обойтись, важна только эффективность решения конкретной задачи. Вся проблема в том, что Вы не 3D-специалист и видимо никогда не ждали просчета сложной сцены в режиме жестких сроков от клиента, когда дорога каждая минута, а рендер гонит артефакты например, а времени на перерендер просто нет… Вот я и говорю, что мне жалко тех, кто до сих пор так мучается.
                                          0
                                          Ну мне в совою очередь жалко тех, кто мучается в попытках получить идеальную сцену в 3D редакторе, и от монтажа возвращается к моделированию и рендерингу ради сущей фигни, которая легко лечится мановением стилуса композера :-) Для мелких проектов рендер слоёв под композинг кажется слишком толстым, но это сильно бережет время, деньги, нервы…
                                            0
                                            Давайте вместе пожалеем всех, кто мучается. И вообще, какая разница сложно или просто исправить картинку постобработкой, если сначала её все-равно нужно получить, хоть в каком-то виде? Мне вот еще жалко тех, кто с пеной у рта будет спорить, отстаивая свое владение привычными инструментами, лишь бы не разбираться в чем-то новом. Я ведь не на пустом месте заговорил о GPU, мое мнение — следствие собственного профессионального опыта, я работал с очень разными рендерами, и долго слежу за их эволюцией.
                                          +1
                                          Совершенно правильное предположение. Кроме того, у GPU большие проблемы с точностью, что сильно ограничивает их проф пригодность, это лечится но, взрослому CPU проще самостоятельно выполнить весь просчёт, чем танцевать вокруг GPU с бубном.
                                          0
                                          … ну и конечно закон Амдала. Для попытки его обойти необходимо усложнять параллельные алгоритмы и упрощать последовательные. И тут снова упираемся в ограничения GPGPU.

                                Only users with full accounts can post comments. Log in, please.