Каковы перспективы у «Эльбруса» в качестве игровой платформы, учитывая, что в современных играх почти вся нагрузка ложится на видеокарту, и мощный процессор зачастую не нужен?
Постановка вопроса некорректна. На центральный вычислитель ложится колосальная работа по подготовке данных, посылке команд в очередь GPU (у 3D команд размер может быть вполне ощутимым) и предварительным расчетам. В этом смысле критичным является стык пропускных способностей КЭШа/памяти/процессора при доступе к памяти (в частности в контексте КПИ). Из всего многообразия исполнительных устройств центральных процессоров Эльбрусов, лишь ограниченное число способно адресоваться к памяти. Иными словами, при решении задач взаимодействия с периферией роль центрального процессора остается одной из решающих.
Отсюда решение увеличить перечень исполнительных устройств, выполняющих роль FPU, конечно же прекрасен, но вопрос о "сферичности в вакууме" подобных вычислений при ограничении потенциала подкачки данных остается открытым.
Имел дело с документацией коллег из МЦСТ. Написана она вообще не для людей. Порой складывалось ощущение, что преследовалась цель не снабдить инженернов информацией, а выдать это за некий академический труд. Полагаю, что анонсированное открытие доков может сопровождаться их перекраиванием.
Приложение имеет возможность прибрать за собой как в случае видеопамяти, так и в случае оперативной. Для первого варианта как справедливо отметил iSage, достаточно одной команды, с оперативной памятью чуть сложнее и несколько более затратно, но тем не менее осуществимо.
Вообще, мне не ясна природу утверждения о необходимости ОС передавать зануленные страницы. Есть возможность запрашивать при выделении памяти зануление (тривиальная функция calloc()/mmap() ), для обратных операций подобного требования к ОС и системной библиотеке нет — хотите занулить, зануляйте сами. Оно появляется только в процессе сертификации по определенному классу защищенности и в этом смысле идет речь о спец. средствах и спец. ОС. Работает оно обычно по принципу — сдох процесс, прикопаем с трупом его пожитки.
Не совсем. Условие отсутствия более приоритетных потоков ставит крест на гарантиях обеспечения безопасности. На бытовом уровне это не спасет незадачливого любителя порнографии. Кроме того, есть такая штука, как РД АС НСД, которая для ряда видов АС не допускает подобных вольностей.
Тестировали и Эльбрус 2С и 4С. 8С еще не видели, имеются определенные надежды на контроллер периферии 2й версии. Результаты не однозначные, поскольку исполнительные устройства ядер не однородны по функционалу (например, к памяти могут обращаться далеко не все), есть сомнения по производительности КЭШей ядер.
В нативном режиме работают только Эльбрус ОС (дебиан) и QNX (многократно видели на выставках, по заверениям разработчика уже поставляют заказчикам). Скажем так, свою сферу применения устройство имеет, но это не лекарство от всех болезней. В режиме бинарной трансляции вроде windows и шевелится, но дальше демонстраций никто эксплуатировать не решается.
Многие приложения используют двойную буферизацию. Пока одна поверхность готовится/рендерится в не отображаемой области видеопамяти, на экран выводится другая. При этом, если приложение отдельно не озаботится очисткой дефолтной поверхности ее содержимое в начальный момент времени может содержать результаты работы предшественника. Поскольку первоначальная подготовка кадра может быть достаточно длительной, не очищенная поверхность может быть заметна глазу до переключения.
Драйвер и ОС в данном случае не брали на себя дополнительной ответственности за гарантирование очищения чужих кадров. Как оказалось, пользователям хром также этого не гарантировал, хотя это исключительно в его компетенции. Все остальные вариации решения проблемы не могут претендовать на универсальность и кросс-платформенность. Также это замечание справедливо для зануления оперативной памяти операционной системой.
Постановка вопроса некорректна. На центральный вычислитель ложится колосальная работа по подготовке данных, посылке команд в очередь GPU (у 3D команд размер может быть вполне ощутимым) и предварительным расчетам. В этом смысле критичным является стык пропускных способностей КЭШа/памяти/процессора при доступе к памяти (в частности в контексте КПИ). Из всего многообразия исполнительных устройств центральных процессоров Эльбрусов, лишь ограниченное число способно адресоваться к памяти. Иными словами, при решении задач взаимодействия с периферией роль центрального процессора остается одной из решающих.
Отсюда решение увеличить перечень исполнительных устройств, выполняющих роль FPU, конечно же прекрасен, но вопрос о "сферичности в вакууме" подобных вычислений при ограничении потенциала подкачки данных остается открытым.
Вообще, мне не ясна природу утверждения о необходимости ОС передавать зануленные страницы. Есть возможность запрашивать при выделении памяти зануление (тривиальная функция calloc()/mmap() ), для обратных операций подобного требования к ОС и системной библиотеке нет — хотите занулить, зануляйте сами. Оно появляется только в процессе сертификации по определенному классу защищенности и в этом смысле идет речь о спец. средствах и спец. ОС. Работает оно обычно по принципу — сдох процесс, прикопаем с трупом его пожитки.
В нативном режиме работают только Эльбрус ОС (дебиан) и QNX (многократно видели на выставках, по заверениям разработчика уже поставляют заказчикам). Скажем так, свою сферу применения устройство имеет, но это не лекарство от всех болезней. В режиме бинарной трансляции вроде windows и шевелится, но дальше демонстраций никто эксплуатировать не решается.
Драйвер и ОС в данном случае не брали на себя дополнительной ответственности за гарантирование очищения чужих кадров. Как оказалось, пользователям хром также этого не гарантировал, хотя это исключительно в его компетенции. Все остальные вариации решения проблемы не могут претендовать на универсальность и кросс-платформенность. Также это замечание справедливо для зануления оперативной памяти операционной системой.