Думаю, да, опрелённое ускорение можно получить за счёт raw-сокетов. Но тут нужно было обрабатывать именно UDP-пакеты из пользовательского приложения, т.е. у нас не было цели оптимизировать само приложение.
На хосте — обычный арч, на плате — тюнили заказчики, подробностей не знаю.
Я думаю, interrupt coalescing для сетевой карточки может помочь, если приходит много пакетов «разом» (а тут отправляющий хост шлёт их по одному и ждёт ответа), в других случаях это не должно значительно помогать. Или всё-таки помогает за счёт чего-то?
В Mesa действительно есть хорошая поддержка аппаратного ускорения, но она не работает с аппаратурой напрямую, для её использования нужен слой DRM, который и взаимодействует с GPU (и которого у нас пока что нет). Если сконфигурить Mesa с драйвером swrast, она будет, грубо говоря, рисовать картинку в оперативной памяти, без задействования DRM, этот вариант и используется на данный момент.
Реализовать аналог DRM из Linux достаточно сложно, работаем над этим. В данный момент делается драйвер для Vivante GPU на i.MX6. Получить простую анимацию уже получилось, а вот "подружить" драйвер с Mesa не выходит. Там достаточно много подводных камней, когда закончим м.б. накатаю статью по этой теме.
Можно, это видно на скринах в статье. Графика отрисовывается с помощью Mesa, Mesa реализует OpenGL API.
так сложно использовать
Так же, как и обычно — пишете программу, используя OpenGL API, и компилируете.
Станет понятнее, если прочитать статью чуть дальше первого предложения. Непосредственному использованию самого OpenGL тут посвящено несколько предложений и два листинга кода по 20 строк.
Странно, но KVM тут не помогает. Ещё страннее, что в исходниках qemu сама инструкция (stmxcsr) упоминается и кажется, что и программно всё должно работать. Но что-то идёт не так. Проверил только что — на хосте инструкция исполняется без проблем.
Чтобы избегать ситуаций, подобных следующей: min(foo++, bar)
С дополнительными переменными foo будет инкрементирована один раз, а без них — дважды.
Ещё есть более экзотический пример (возможно, надуманный, но всё же возможный), когда может нарушиться согласованность. Если передавать в качестве аргумента разыменованный указатель, после сравнения аргументов может произойти переключение контекста, изменяющее содержимое соответствующего участка памяти. В таком случае макрос может вернуть значение, которого ему не передавали.
Спасибо за замечание!
В исходниках используется именно безопасный вариант, но в статье тоже не помешает исправить. Ссылка на коммит
Да, тут перепутаны знаки «больше» и «меньше», но позже это было исправлено :)
Я думаю, interrupt coalescing для сетевой карточки может помочь, если приходит много пакетов «разом» (а тут отправляющий хост шлёт их по одному и ждёт ответа), в других случаях это не должно значительно помогать. Или всё-таки помогает за счёт чего-то?
В QEMU, как я понял, можно подсунуть ATF, но мы этого не делаем :)
На ARM для NEON у нас такое есть, а на x86 — нет.
В Mesa действительно есть хорошая поддержка аппаратного ускорения, но она не работает с аппаратурой напрямую, для её использования нужен слой DRM, который и взаимодействует с GPU (и которого у нас пока что нет). Если сконфигурить Mesa с драйвером
swrast
, она будет, грубо говоря, рисовать картинку в оперативной памяти, без задействования DRM, этот вариант и используется на данный момент.Реализовать аналог DRM из Linux достаточно сложно, работаем над этим. В данный момент делается драйвер для Vivante GPU на i.MX6. Получить простую анимацию уже получилось, а вот "подружить" драйвер с Mesa не выходит. Там достаточно много подводных камней, когда закончим м.б. накатаю статью по этой теме.
Можно, это видно на скринах в статье. Графика отрисовывается с помощью Mesa, Mesa реализует OpenGL API.
Так же, как и обычно — пишете программу, используя OpenGL API, и компилируете.
Станет понятнее, если прочитать статью чуть дальше первого предложения. Непосредственному использованию самого OpenGL тут посвящено несколько предложений и два листинга кода по 20 строк.
Странно, но KVM тут не помогает. Ещё страннее, что в исходниках qemu сама инструкция (
stmxcsr
) упоминается и кажется, что и программно всё должно работать. Но что-то идёт не так. Проверил только что — на хосте инструкция исполняется без проблем.Затрудняюсь сказать, что именно идёт не так.
Дело не в третьей переменной, а именно в
-O0
. С-O1
будет как в примере в статье.Если посмотреть дизассемблер, с оптимизацией
p == q
предподсчитывается как 0.Без оптимизации делается честный cmp.
Без оптимизации результат другой.
> gcc main.c
> ./a.out
0x7ffd9dad19fc 0x7ffd9dad19fc 1
> gcc main.c -O1
> ./a.out
0x7ffe4b876ebc 0x7ffe4b876ebc 0
gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)
min(foo++, bar)
С дополнительными переменными
foo
будет инкрементирована один раз, а без них — дважды.Ещё есть более экзотический пример (возможно, надуманный, но всё же возможный), когда может нарушиться согласованность. Если передавать в качестве аргумента разыменованный указатель, после сравнения аргументов может произойти переключение контекста, изменяющее содержимое соответствующего участка памяти. В таком случае макрос может вернуть значение, которого ему не передавали.
В исходниках используется именно безопасный вариант, но в статье тоже не помешает исправить.
Ссылка на коммит
Да, тут перепутаны знаки «больше» и «меньше», но позже это было исправлено :)