Pull to refresh

Comments 21

Хмммм, Эльбрус, интересно. А почему вас именно Fly привлёк? И можно ли найти «Эльбрус 801-РС» дешевле 325К? А так статья мне очень понравилась.
По Fly чистый субъективизм.
По цене — насколько я знаю МЦСТ также продает материнки с процами отдельно. Можно купить и дособрать у себя. Помимо материнской платы с их чипсетом и проца все остальное стандартное. Насколько это будет выгоднее не знаю, -50-100 тысяч наверное
Я думал будет рентген плат Эльбруса, а тут всякие NDA…
Когда выдаёте таблички с «производительностью» пишите размерность или «больше/меньше — лучше», применительно к обработке графики это могут быть как секунды, так и кадры/пиксели/тексели и т.п.
Отлично! Сравнения это хорошо, сравнения это магнит, на котором всегда залипает колёсико мышки, так что ждём с нетерпением данные по Эльбрус 16C, инженерные образцы — уже в ходу. ;-)

То есть МЦСТ продолжает нарушать GPL отдавая GPL-софт только под NDA?

https://www.gnu.org/licenses/gpl-faq.en.html#DoesTheGPLAllowNDA


Does the GPL allow me to distribute copies under a nondisclosure agreement? (#DoesTheGPLAllowNDA)

No. The GPL says that anyone who receives a copy from you has the right to redistribute copies, modified or not. You are not allowed to distribute the work on any more restrictive basis.

If someone asks you to sign an NDA for receiving GPL-covered software copyrighted by the FSF, please inform us immediately by writing to license-violation@fsf.org.

If the violation involves GPL-covered code that has some other copyright holder, please inform that copyright holder, just as you would for any other kind of violation of the GPL.

так что ждем, пока кто-нибудь из авторов gpl-софта из дистрибутива их засудит

Каким образом получилось вычислять гистограмму на OpenGL 3.1 без Compute shaders/Storage buffer?
Мы тоже долго ломали голову, как это сделать. На Vulkan, CUDA, OpenCL – просто. На OpenGL мы пришли к тому, что передаем изображение в вертексный шейдер как входные VertexAttibutes. И далее, в зависимости от яркости рендерим в нужную точку одномерной текстуры с соответствующим блендингом. В принципе, работает хорошо. Но количество ядер, выделенных на вертексный шейдер сильно меньше, чем на фрагментный. Поэтому еще и mipmap заранее используем.

Там достаточно много тонкостей было, непросто получилось.
Ну я в принципе так и подумал, что наверное как то через рендер в одномерную текстуру :) Понятно, спасибо.
>Бэкап раздела Астры работал только из-под лайв образа Альта.
Расскажите чуть подробнее, пожалуста, что именно не работло и с какими ошибками. С Астрой не сталкивался, поэтому вопрос скорее для общего развития.
У на скрипт бэкапа выполняет dd копирование нужного раздела и автоматическое развертывание в случае необходимости. Соответственно нужно запустится с лайв образа, но с лайв образами ОС для Эльбруса проблемка. Пока они были только у Альта
A dd на работающей системе не работает? Или dump/restore, в случае ext4 — возможно, даже быстрее, вполне промышленный метод для копирования файловой системы. Сервисы, изменяющие данные должны быть остановлены, а в остальном dump/restore/fsck.

а почему вы не соберёте Qt сами? Вы планируете свой софт поставлять как пакет для Альта\Астры\Эльбрус ОС? Будете несколько пакетов разных собирать под каждую версию?


Тот же вопрос про OpenCV — почему версию 4.4 не собрали, с которой на Винде сравнивали? Зависимость от EML понятна, но ведь и сама либа развивается. Или в хранилище ОС поставляется модифицированная версия OpenCV?

ещё раз посмотрел на таблицу сравнений. На Астре Ленинград всё совсем плохо, а версия OpenCV аналогичная ОС Эльбрус. С чем это может быть связано?

Там отличия в версиях пакетов. Пакет OpenCV от ОС Эльбрус не равно пакет OpenCV в Астре. Какждый производитель ОС их собирает сам, МЦСТ заморочились с оптимизацией, Астра нет
Причины сугубо рациональные.

Другую версию OpenCV мы не собирали по причине того, что нас интересовала именно EML. Новые фичи OpenCV, наверное, хороши, но для нас пока не представляют интереса. Быстродействие EML представляют намного большую ценность даже при ограниченности функционала версии 3.2 (с которым мы пока не столкнулись).

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

"Вследствие особенностей архитектуры на Эльбрус не рекомендуется использовать исключения. " — а в чём там соль, поясните пожалуйста, если можно (NDA всё таки). Это особенность VLIW архитектуры? Особенность конвейеров? И ещё вопрос, а решения на архитектуре sparc рассматривали?

В принципе, использование исключений не ускоряет работу программы на любой архитектуре. Поэтому использовать их в критических местах не лучшая идея. А особенности конкретно Эльбрус делают этот факт еще более значимым. Более детально можно посмотреть в открытых источниках, например здесь:
www.youtube.com/watch?v=8rYfUO1x_MQ

Перед нами, как разработчиками софта, не ставилось задачи выбора платформы. Напротив, необходимо было реализовать качественный и быстрый кросплатформенный код по обработке изображений, одинаково хорошо работающий как на Эльбрус, так и на Intel (Linux + Windows). Мы эту задачу успешно решили.
Only those users with full accounts are able to leave comments. Log in, please.