MAX
Подпишись
стань автором. присоединяйся к сообществу!
31 декабря 171
86

Тест обновлённой графической подсистемы и аппаратного 3D ускорения на процессоре Эльбрус-4С

Перед новым годом сотрудники МЦСТ решили протестировать работу обновлённой графической подсистемы платформы Эльбрус, поддерживающей аппаратное 3D-ускорение. Для этого решили немного поиграть.

[читать статью полностью...]

Кстати, а вы знали, что на «Сделано у нас» статьи публикуют посетители, такие же как и вы? И никакой премодерации, согласований и разрешений! Любой может добавить новость. А лучшие попадут в наш Телеграм @sdelanounas_ru. Подробнее о том как работает наш сайт здесь👈

Источник: mcst.ru

Поделись позитивом в своих соцсетях

Комментарии 0

Для комментирования необходимо войти на сайт

  • 2
    AndreyKruz AndreyKruz31.12.14 10:22:12

    Очень неплохо! Видно, что в низком фреймрейте виновен процессор, но зная его необычную архитектуру и частоту — это прогресс. Значит для большинства не игровых задач, а тем-более параллельных он хорошо сгодится. А уж 8с…       

    • 3
      Нет аватара t-garet31.12.14 12:33:37

      в низком фреймрейте виновен процессор

      Хех, не только и даже не столько. Например в ролике говорится, что драйвера OpenGL версии 3.3 (2010 год), а видюха уже поддерживает 4.4 (2013 год), PCI-E на плате версии 1.0×8, а карточка поддерживает 2.1×16 (т.е. в 4 раза быстрее), ну и память на самой плате тоже не новая, максимум DDR3−1600 (из спецификации Эльбрус-4С).

      Короче, для более объективного «игрового» тестирования нужна платформа «посвежее», поновее — расшить узкие места и потом уже смотреть, что будет. Есть подозрения, что будет заметный прирост производительности (даже без повышения частоты процесора).

      Отредактировано: t-garet~13:50 31.12.14
      • 1
        Нет аватара guest31.12.14 12:54:57

        Шина PCI-E почти никогда не узкое место, 1.0×8 вполне хватит для DOOM3, быстрой она нужна для очень специфичных задач, в играх её влияние очень мало, как правило, шина нужна что бы гонять данные, такими данными могут быть текстуры, точнее в основном текстуры, но он заливаются в видеокарту как правило при загрузке уровня, или там стоит какой-нить хитрый менеджер который стремится свести к минимуму такие операции, шина может быть узким местом когда используются фичи современных стандартов типа виртуальной памяти, вот там загрузка данных идет на лету. А что касается самого дума то там текстуры были не очень большие. DDR3 это очень быстрая память, почти тем более 1600, мало какие процессоры могут упереться в её пропускную способность. Она то же не узкое место, у меня в компе такая и фпс в думе3 будет наверно за две сотни.

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

        В думе3 по-моему вся нагрузка была в один поток, потому что на момент его выхода двухядерных систем не было. Так что можно сделать вывод что производительность каждого ядра на уровне Athlon 2000XP судя по фпс, то есть вот этот проц примерно как современные intel atom, только у atom есть поддержка таких модных штук как SSE, это специально заточенные штуки которые дают существенное ускорение в определенных задачах. Поэтому надо очень тщательно сразвнивать, например если тест будет написан с использованием SSE и без, то разница может быть кратная(в разы). Эльбрус sse использовать не может, потому что его там как бы и быть не может, но он может иметь свои фичи, будет ли тест написанный их использовать вот вопрос.

        • 2
          Нет аватара guest31.12.14 15:16:02

          Я так понимаю Вы как-то связаны с МЦСТ, это типа хорошо если фирма имет человека который о ней расскажет и всё такое.

          Вы наверное и так это делаете, но на всякий случай, советую: читайте побольше tomshardware.com/ там очень хорошо и доходчиво поясняют (языком для продвинутых пользователей) всякие детали архитектур, производительности, и так далее. Хорошо там разжёвана память, действительно DDR3 это с головой хватит, у меня комп современный (практически) а всё ещё DDR3 1333, меньше чем на вашем Эльбрусе (зато 32гб).

          Про игры: некоторые больше завязаны на видеокарты, а некоторые — на процессор. Захотите испытать процессор серьёзно — ставьте GTA4. Мне в своё время пришлось менять Core 2 Duo на Core 2 Quad чтобы она нормально работала. Тут вам и неслабые требования, и распараллеливание. Как GTA4 нормально заработает на Эльбрусе, можете считать процессор готов для людей (хотя и сейчас наверное уже хватит для офиса).

          Удачи вам!

          • 4
            sepheronx sepheronx31.12.14 22:03:50

            If one wants to test cpu in games, they need to lower the resolution to something like 1024×768 which will be more cpu intensive than graphic. Or test it on a game that is cpu intensive like Civilization 5.

            Sometimes games take advantage of instruction sets so since Elbrus lacks those (all vliw cpus would), then therr can be a good reason too.

            • 0
              Нет аватара guest31.12.14 22:14:32

              А я бы вам посоветовал побольше узнать сначала, перед тем как писать. 1024 это игра будет работать практически на «software rendering» практически без использования графической карты. Речь не об этом. Разные игры работающие в 1920×1080 имеют разные требования к процессору. Какие-то на любом процессаре дают 300 кадров в секунды, если видеокарта топовая. Другие на карту реагируют плохо, но сильно реагируют на процессор, даже про 1920×1080 (как GTA4).

              • 2
                sepheronx sepheronx31.12.14 22:28:41

                I used to do hardware tests. If you ever read any site regarding tests, you will notice how they compare processors at lower resolutions to see how it fairs in gaming. Higher res to see how well each will do with a graphics card.

                I am talking about comparing cpu vs cpu in performance tests in cpu demanding enviornments. Can give a better indication to CPU performance to a game, not how it may or may not bottleneck the gpu.

                Отредактировано: sepheronx~23:30 31.12.14
                • 2
                  shigorin shigorin01.01.15 13:41:49

                  You’re correct and Roman reminds me some ubuntu fan -- looking friendly but being helpless while trying to be helpful. Hope he does his own homework to get some solid understanding instead of a gamer’s «gut feeling».

                  Happy New Year!

                  --

                  Michael Shigorin

              • 3
                shigorin shigorin01.01.15 13:39:56

                1024 это игра будет работать практически на «software rendering» практически без использования графической карты.

                Глупости не говорите -- стыдно же отправлять учить матчасть, не зная оной вообще.

                Человек явно грамотный и как раз пишет о том, как создать условия, когда тестируемый процесс упрётся скорее в CPU, чем в GPU (будет CPU bound, иными словами).

                --

                Michael Shigorin

          • 3
            Нет аватара guest01.01.15 11:58:04

            Нет я никак не связан с МЦСТ. У меня просто лет 15 стажа программиста, поэтому читать сайты где рассказывают о том какая игра лучше работает на каком процессоре мягко говоря смешно. Очень редко когда ширина шины становится узким местом, чаще всего узкое место это минимальное время получение данных, вроде как латентностью называется. GTA4 нельзя поставить на Эльбрус, ввиду того что нет его исходников, этот дума был собран именно под архитектуру Эльбрус в его родном окружение, их же компиляторм.

            • -1
              Нет аватара guest01.01.15 16:02:34

              У меня стаж 10 лет, и ничего смешного в том что я сказал, нет. Если имея 15 лет вы не знаете что некоторые игры остаются очень требовательны к процессору (фпс сильно зависит от процессора, даже если стоит GTX 980), то вам должно быть стыдно, надо молча покраснеть и идти читать интернет в надежде поумнеть и немного сбить спесь.

              Пишите что хотите, отвечать больше я не буду (как и читать ваши ответы).

    • 2
      Нет аватара guest31.12.14 21:55:20

      Скорее даже не процессор, а сама архитектура движка, которые принципиально не рассчитан на параллельность (Кармак его точил на РIII, ЕМНИМС) и обладает парой узких мест при работе с памятью — например, подкачивает геометрию и текстуры при любом обращении игрокак к той же двери — а вдруг он её откроет. Видно, что фреймрейт проседает именно в эти моменты — как он, собственно, делал и в оригинале. Издержки БСП-технологии, однако.

      • 0
        Нет аватара guest01.01.15 12:00:56

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

        Отредактировано: Денис Демидович~13:01 01.01.15
        • 2
          Нет аватара guest01.01.15 12:08:12

          Ну, виртуальные машины — это не так плохо, скажем, тот же Эрик Шаи из говна (то есть Амиги 500) ухитрился сделать конфетку (Another World) как раз за счёт виртуальной машины, но вот то, что Кармак — большой любитель оверинжниринга, это медицинский факт. Ему бы немецкие танки делать. ;)

          • 0
            Нет аватара guest01.01.15 12:13:05

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

            • 0
              Нет аватара guest01.01.15 14:29:27

              Ну, во-первых, есть. ;) А во-вторых, виртуальная машина, — это очень удобный способ изоляции движка от контента.

              • 0
                Нет аватара guest01.01.15 14:41:09

                Вы ломаете мне мозг, или речь идет о пользовательских скриптах типа lua которые условно можно считать контентом? Крутые папки так давно не делают, крутые папки все описывают декларативно, в виде схемок, блоков и прочего тягания мышки, например UE3, у декларативного описания есть ряд существенных плюсов, в отличие от скриптов, например можно делать аналитические проверки достижимости всех ветвей условий, что существенно уменьшает количество ошибок в игре. А при программирование поведения уровня на lua (js, pyton и прочем) почти все время возникают такого рода ошибки что программист налажал в очередном if и при открывание двери в очередном уровне при некоторых редких условиях не спавнится ключевой квестовый объект, миссия становится непроходимой, тонны говна от пользователей в обзорах. Плюс это реально делает дороже процесс разработки, если тягать блоки может любая обезьянка после 15 минут объяснения назначение блока, то вот писать скрипты так уже не выйдет, плюс на тестировщиков вдвое большая нагрузка, плюс невозможно аналитически проверить все условия и обойти весь граф логики и выявить невыполнимые линии. Короче скрипты в пользовательских данных мастдай, сакс и вообще не круто.

                Вы я так понимаю каким-то образом связаны с разработкой игр?

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

                Отредактировано: Денис Демидович~15:44 01.01.15
                • 1
                  Нет аватара guest01.01.15 14:49:16

                  А теперь, внимание, вопрос: и что же мы имеем на выходе описанного вами построителя миров? Набор данных (модели, текстуры и т. п.) и всё те же скрипты программной логики (просто не написанные человеком, а автоматически сгенерированные машиной), которые ни один нормальный человек не будет пихать в движок игры, который в 90% случаев вообще разрабатывается сторонней фирмой и содержать hardcoded-игровую логику не может и не должен. Движок — это вообще в первую очередь высокоуровневый API, на основе которого уже строится игра. А между контентом и движком как раз и стоит некий middleware, который интерпретирует эти данные и вызывает функции движка, допустим, для отрисовки персонажа. В некоторых коммерческих движках этот код включается в поставку, но это не значит, что его нет.

                  Нет, не связан, но имею в тех областях знакомых. ;)

                  Отредактировано: Andrey Tupkalo~15:50 01.01.15
                  • 1
                    Нет аватара guest01.01.15 15:00:12

                    Набор данных (модели, текстуры и т. п.) и всё те же скрипты программной логики (просто не написанные человеком, а автоматически сгенерированные машиной)

                    Вы ошибаетесь, может у кого так и есть, но вообще необходимости в этом нет, у нас как минимум происходит настройка прямо с такого описания.

                    Процесс выглядит примерно так: есть описание, оно загружается как ресурс, после чего запускается прослойка которая настраивает нашу квестовую систему, а сама квестовая система это нетривиальный конечный автомат. В принципе конечный автомат можно назвать виртуальной машиной, вроде как машина Тьюринга это и есть конечный автомат, если честно в такой теории не силен, но все же под интерпритатором сейчас понимается вполне простая определенная вещь у которой есть так сказать компилятор, команды, промежуточное представление и прочие стадии. А настройка конечного автомата по описанию ввиде блоков это несколько иное. И уж точно там нет стадии генерации исходников на каком бы то ни было языке.

                    Движок — это вообще в первую очередь высокоуровневый API, на основе которого уже строится игра.

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

                    Отредактировано: Денис Демидович~16:04 01.01.15
                    • 1
                      Нет аватара guest01.01.15 15:07:29

                      И оказывается, ВНЕЗАПНО, что это именно то, о чём я сейчас вам говорил. ;) И, да, интерпретаторы логики — это далеко не только конечные автоматы, более того, более-менее сложный модуль игровой логики одних только конечных автоматов может содержать до десятка.

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

                      • 0
                        Нет аватара guest01.01.15 15:15:11

                        То, о чём вы сейчас написали — это очень нишевый подход, сильно ограничивающий варианты разработчика.

                        Я говорил сейчас про UE3, думаю не составит труда найти список игр на нем.

                        интерпретаторы логики

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

                        • 1
                          Нет аватара guest01.01.15 15:22:02

                          В UE3, насколько я им интересовался, всё много сложнее и шире. Можно так, а можно и эдак, и за влезание под капот там по рукам тоже не бьют. Движок Дума 3 лично не ковырял, полагаюсь на слова знакомого, который копается в id’овских движках вот уже лет двадцать, ещё со студенческих времён. Надо будет уточнить у него на сей счёт.

          • 2
            shigorin shigorin01.01.15 14:08:13

            Ого, так они это ещё и в четыре руки сделали?! Крепко, крепко.

            --

            Michael Shigorin

            • 2
              Нет аватара guest01.01.15 14:26:52

              В две. Шаи-младший в основном работал моделью для ротоскопинга, как и в случае с Prince of Persia. ;)