Компания Collabora объявила о реализации в Vulkan-драйвере PanVK поддержки графического API Vulkan 1.4 для устройств с GPU ARM на базе архитектуры V10, таких как Mali-G610 и Mali-G310. Изменения включены в кодовую базу Mesa и будут предложены пользователям в выпуске Mesa 25.2, находящемся на стадии кандидата в релизы. В текущем стабильном выпуске Mesa 25.1 в PanVK поддерживается лишь версия Vulkan 1.2...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=63643
Интересно, на сколько реально увидеть десктопы с CPU ARM и главное GPU Mali? Почему не делают дешевые видеокарточки, на mali для десктопа?
Почему Mali, а не Adreno?
>AdrenoВ ноутах на Snapdragon X
https://www.techpowerup.com/cpu-specs/?f=mfgr_Qualcomm
Ну вот, пока только процессоры от Qualcomm.
А от кого же ещё ?
Adreno это разработка Qualcomm:
https://en.wikipedia.org/wiki/Adreno
Ну вот, пока хороших альтернатив Qualcomm не видел. Только ARM от Mac и Qualcomm имеются. Да и процессоры Qualcomm производительней.
> Ну вот, пока хороших альтернатив Qualcomm не видел. Только ARM от Mac
> и Qualcomm имеются. Да и процессоры Qualcomm производительней.Qualcomm - весьма мерзкая и проприетарная корпа, насквозь маздайная, и патентный тролль к тому же. И то что там драйвер какой-то открытый - не отменит общего ужасного экспериенса с этой штукой в контексте опенсорса.
Одноплатников море, покупай, смотри.
Он хочет нормальный процессор на 100+ ватт TDP, что непонятно?
Видеоускорение там в .... плачевном состоянии. Там где смартфоны выдают сотни тысяч попугаев эти твои платники только нагревают атмосферу.
Железо одноплатников отстаёт на 10 лет от смартфонов. Зато драйвера есть.
Одноплатники есть и на Intel и AMD, которые не отстают не десятилетия.Сейчас скажут, что у тормозных ARM есть gpio. Так он не для всяких задач нужен, но есть и одноплатники на intel с gpio сопроцессором.
Запрос был посмотреть десктоп на арм с мали, дешёвые одноплатники для этого отлично подходят. Есть железо от apple, которое не так отстаёт, но и стоит хорошо.
Ну одноплатники это хорошо, но я имел ввиду почему не делать те же Mali но для разъёма PCIe.
Рынок видеокарт-«затычек» мёртв. На новых ПК везде встройка, для старых проще что-нибудь на вторичке взять. Ну и в магазинах всяких GT730 на 50 лет запасено.
> Ну одноплатники это хорошо, но я имел ввиду почему не делать те
> же Mali но для разъёма PCIe.Зачем они там? Слишком дохлые чтобы рубаться с дискретками, они сугубо накристальный блок в ARMовских чипах. Их достоинство - это лицензируемый IP-блок для встройки в тот или иной SoC. Под дискретное применение оно никогда не делалось тупо.
> дешёвые одноплатники для этого отлично подходятдешевый одноплатник - это miniPC на n5095.
На минималках он дешевле или сопоставим по цене с одноплатниками на MALI, но при этом быстрее, больше ОЗУ, и не надо докупать SSD и корпус.У меня есть почти полная коллекция одноплатников на Raspberry и Orange, и несколько других.
Некоторые можно использовать как ТВ приставку или как эрцац-десктоп, но при наличии miniPC смысла в этом нет.Дешевые и малопотребляющие ARM-одноплатники одноплатники хороши поделок. А уже Raspberry5 ни рыба ни мясо, например для недодесктопа дорог и слаб, для многих поделок избыточен и дорог.
Кстати, о MALI. У него же кривые перекривые драйвера под Linux, что врагу не пожелаешь.
В общем оно только под Андроидом вменяемо работает.
> дешевый одноплатник - это miniPC на n5095.
> На минималках он дешевле или сопоставим по цене с одноплатниками на MALI,Если мы возьмем одноплатник на минималках с MALI - он будет стоить 10 баксов. Как десктоп его врядли захочется конечно, но...
> Дешевые и малопотребляющие ARM-одноплатники одноплатники хороши поделок. А уже Raspberry5
> ни рыба ни мясо,Их покусала гигантомания. Впрочем ARM можно найти и довольно мощные - и с PCIe слотом. В который воткнуть какой-нибудь AMDGPU и вот там уже вулкан можно побенчмаркать :)
> Кстати, о MALI. У него же кривые перекривые драйвера под Linux, что
> врагу не пожелаешь.Оно на основе реверса блин. Но вулкан - таки простой и сильно глючить там нечему. А фирма ARM с энных пор внезапно присоединилась к банкету - и шлет улучшения. Это довольно неожиданно, но...
Но например в Raspberry Pi там VideoCore:
https://en.wikipedia.org/wiki/VideoCore
>> Почему не делают дешевые видеокарточки, на mali для десктопа?Потому что даже древняя HD4000, по функциям лучше чем MALI. Да и по производительности они почти на равных. А уж более свежие Intel встройки UHD ещё лучше и дешевые.
А если встройки Райзенов рассматривать, типа 760М, то на них и поиграть можно.
В общем, MALI - не нужен.
Рабочий стол же отрисовывает? Многим больше и ненадо. За 500 р. купил бы.
Для рабочего стола встройки-затычки хватит.
Рабочий стол же отрисовывает? Многим больше и ненадо. За 500 р. купил бы.
> Почему не делают дешевые видеокарточки, на mali для десктопа?А дрова к ним кто напишет?
Смотрите, завидуйте... :)
https://itinti.ru/catalog/rossiyskie_kompyutery/es607_monobl...
Так там только смотреть и можно.
> Интересно, на сколько реально увидеть десктопы с CPU ARM и главное GPU Mali?Возьми какой-нибудь одноплатник пожирнее. Можно даже с PCIe найти. Правда, тогда в него захочется воткнуть GPU пожирнее - типа AMDGPU какого.
> Почему не делают дешевые видеокарточки, на mali для десктопа?
Малохольные слишком, кому они там нужны.
...а для Mali T720 делать поддержку OpenGL 3.0 так никто не собирается.
А зачем инвестировать в драйвер для умирающего API?
какое отношение биологических особей к абстракциям интерфейсов IT?
> ...а для Mali T720 делать поддержку OpenGL 3.0 так никто не собирается.Zink юзай если там вулкан есть.
Я недавно обнаружил, что некоторые люди, которым мы доверяем производительность операций с GPU на стороне процессора,.. не умеют или не всегда хотят верно бенчмаркить.Вот их бенчмарк: https://github.com/vkmark/vkmark (анализ для коммита 2c5f020005a597fb4b7d9ed1eaa1bf40e466bf01, все лицензии на код находятся в соответствующих репозиториях)
>vkmark offers a suite of scenes that can be used to measure various aspects of Vulkan performance.
https://www.collabora.com/news-and-blog/blog/2017/07/18/vkma.../
>A few years ago we were pleasantly surprised to learn that developers were using glmark2 as a testing tool for driver development, especially in free (as in freedom) software projects. This is a goal that we want to actively pursue for vkmark, too.
Давайте посмотрим, как эти понтовые заявления соотносятся с реальностью.
```c++
// With a lot of contractions
class Scene
{
public:
...
virtual bool is_valid() const;
...
virtual VulkanImage draw(VulkanImage const&);
...
virtual void update();
...
unsigned int average_fps() const;
...
};
```1. Виртуальные функции, Карл!
2. `unsigned int average_fps() const;` - СРЕДНЕЕ. FPS.
3. Функции не являются inline. И не force-inlined.```c++
scene.start();while (scene.is_running() &&
!(should_quit = ws.should_quit()) &&
!should_stop)
{
ws.present_vulkan_image(
scene.draw(ws.next_vulkan_image()));
scene.update();
}auto const scene_fps = scene.average_fps();
log_scene_fps(scene_fps);
```Где находятся функции (в отдельном translation unit):
```c++
void Scene::start()
{
current_frame = 0;
running = true;
start_time = Util::get_timestamp_us();
last_update_time = start_time;
}unsigned int Scene::average_fps() const
{
return last_update_time > start_time ?
current_frame * 1000000 / (last_update_time - start_time) : 0;
}bool Scene::is_running() const
{
return running;
}
VulkanImage Scene::draw(VulkanImage const& image)
{
return image.copy_with_semaphore({});
}
void Scene::update()
{
auto const current_time = Util::get_timestamp_us();
auto const elapsed_time = current_time - start_time;++current_frame;
last_update_time = current_time;
if (elapsed_time >= duration)
running = false;
}void log_scene_fps(unsigned int fps)
{
auto const fmt = Log::continuation_prefix + " FPS: %u FrameTime: %.3f ms\n";
Log::info(fmt.c_str(), fps, 1000.0 / fps);
Log::flush();
}uint64_t Util::get_timestamp_us()
{
struct timespec ts;
clock_gettime(CLOCK_MONOTONIC, &ts);
uint64_t const now = static_cast<uint64_t>(ts.tv_sec) * 1000000 +
static_cast<uint64_t>(ts.tv_nsec) / 1000;
return now;
}```
ОК, предположим, что компилятор и линковщик достаточно умны, чтобы их заинлайнить, поэтому давайте заинлайним их вручную, и глянем, что получается...
```c++
current_frame = 0;
running = true;
start_time = Util::get_timestamp_us();
last_update_time = start_time;while (running &&
!(should_quit = ws.should_quit()) &&
!should_stop)
{
auto image = ws.next_vulkan_image();
VulkanImage draw_result = image.copy_with_semaphore({});
ws.present_vulkan_image(draw_result);struct timespec ts;
clock_gettime(CLOCK_MONOTONIC, &ts);
uint64_t const current_time = static_cast<uint64_t>(ts.tv_sec) * 1000000 + static_cast<uint64_t>(ts.tv_nsec) / 1000;
uint64_t const elapsed_time = current_time - start_time;++current_frame;
last_update_time = current_time;
if (elapsed_time >= duration){
running = false;
}
}unsigned int const scene_fps = last_update_time > start_time ? current_frame * 1000000 / (last_update_time - start_time) : 0;
auto const fmt = Log::continuation_prefix + " FPS: %u FrameTime: %.3f ms\n";
Log::info(fmt.c_str(), scene_fps, 1000.0 / scene_fps);
Log::flush();
```1. Мы измеряем не FPS, а время. Но... они сначала вычисляют FPS из времени, усекают его до целого числа, затем время из FPS, и также усекают его. Это была проблема, которую я заметил первой, что заставило меня покопаться в этом.
2. Они используют `clock_gettime` вместо `__rdtsc` + `_mm_lfence` для получения точных тиков ЦП. Ни один разумный микро-бенчмарк не полагается на время, предоставляемое через системные вызовы.
3. В коде измерения времени - ненужные операции.
4. Мы видим ненужные операции между точками, где мы получаем время. В идеале `ws.present_vulkan_image(scene.draw(ws.next_vulkan_image()));` должно быть сендвичем между двумя гаджетами```c++
_mm_lfence();
const uint64_t current_time = __rdtsc();
_mm_lfence();
```
.6. Вместо измерения времени отдельных операций, они проводят бенчмаркинг в течение заранее заданного периода времени. Это противоположно тому, как обычно делают бенчмаркинг.
7. Они вычисляют средний FPS, используя `last_update_time - start_time` в качестве времени, а не сумму точных интервалов.
8. Никакой коррекции систематической погрешности, вносимой самими инструкциями измерения времени.Мы просто предположили инлайнинг, но разумеется, компиляторы не настолько умны для этого. Для правильного бенчмаркинга им понадобится `MainLoop` в качестве шаблона и предоставление реализаций сцен в качестве аргументов шаблона, тогда компилятор заинлайнит реализацию прямо в горячий цикл.
Так что утверждение о том, что этот бенчмарк можно использовать каким-либо образом для чего-либо полезного, не выдерживает никакой критики.
Вот небольшой патч https://0x0.st/8kvd.patch , просто запихивающий `__rdtsc` туда, без каких-либо других необходимых изменений этого. И график гистограммы (нормализованной до плотности вероятности) времен (оставлен только первый пик, и на самом деле измерения расположены с 8 тиками, так что 8 тиков с количеством 0, затем тик с количеством, а затем снова 8 тиков с количеством 0 и тик с количеством) и соответствующая kernel density estimation. 2 изображения, одно в крупном масштабе, другое увеличено возле моды распределения, обратите внимание, что счетчики гистограммы очень шумные, более чем в два раза больше моды на ее пике. Команда была `./src/vkmark -D <device uuid> -p immediate -b effect2d:kernel=none:duration=4200000 --run-forever > results.txt`, после чего парсинг скриптом.
Вот что вам нужно знать об инженере из Collabora, который это разработал.
О, может быть, другие бенчмарки дадут лучшие результаты? Я нашел `https://github.com/RippeR37/GL_vs_VK` (коммит 735d153f7d85b7ce8d7097e89e877304ee23180b) , понтовую часть Phoronics Test Suite.
>This project is part of my master-thesis and aims to compare OpenGL and Vulkan API in terms of API-related overhead.
Если вы думаете, что этот бенчмарк отличается... нет, он в основном повторяет те же ошибки (за исключением виртуальных функций): неиспользование `rdtsc` напрямую (вместо этого он использует `glfwGetTime` из динамической библиотеки, определенной как
```c++GLFWAPI double glfwGetTime(void)
{
_GLFW_REQUIRE_INIT_OR_RETURN(0.0);
return (double) (_glfwPlatformGetTimerValue() - _glfw.timer.offset) / _glfwPlatformGetTimerFrequency();
}
```где
```c++
uint64_t _glfwPlatformGetTimerValue(void)
{
struct timespec ts;
clock_gettime(_glfw.timer.posix.clock, &ts);
return (uint64_t) ts.tv_sec * _glfw.timer.posix.frequency + (uint64_t) ts.tv_nsec;
}
```
- да, те же яйца, только в профиль), фактический вызов получения времени находится в отдельной функции в отдельном translation unit, а не заинлайнен в нужное место.
Чувак, да ты ваще бешеный! (с)Было весьма познавательно, да еще и с кодом.
Интересно примут ли изменения 🤔.
> Я недавно обнаружил, что некоторые люди, которым мы доверяем производительность операций
> с GPU на стороне процессора,.. не умеют или не всегда хотят
> верно бенчмаркить.Во всем этом километровом спаме вы забыли главное.
1) Запрофайлить код и обосновать с инструментированными данными что этот код вообще существенно влиял на результаты бенчей.
2) Оценить уровень ошибки от всех этих упущений. Если бенч выдает цифирь с точностью 5% допустим - то и хрен со всем этим, во.И да, если что - плавучка на ARM вовсе не обязана быть столь же производительной как на x86 так что усечь до целого - может быть вполне себе выигрышно до перфоманса, если вы там не знали.
>Запрофайлить код и обосновать с инструментированными данными что этот код вообще существенно влиял на результаты бенчей.Вы на профайлинг и анализ его результатов больше времени потратите, чем просто на выпил идиотизма и замену обращений к RTC на обращения к счётчику тактов.
> 2. Они используют `clock_gettime` вместо `__rdtsc` + `_mm_lfence`Это просто фэйспалм эксперта. Кому надо бенч с такими допущениями? Это не кроссплатформенно от слова вообще. А мы тут бенчмаркаем Vulkan на вон том ARM. А завтра и на RISCV придем бенчмаркать. Поразвелось тут экспертов, уверенных что rdtsc везде есть...
Слушай, для каждой нормальной архитектуры есть счётчик тиков. Для арма это например CNTPCT_EL0. А кроссплатформенность можно обеспечить хедером, где в зависимости от архитектуры выбирается нужная инлайн-функция с нужными интринсиками ил inline assembly. Микробенчмаркить любым способом, кроме счётчика тиков - неверно, вы измеряете не пойми что.И бенчмаркить вулкан вообще-то надо и на хосте, и на GPU, то есть использовать вулкан-расширения запроса таймеров с GPU. Так как меня интересовал только хост в данном исследовании, а в GPU-таймерах и GPU-кодинге я пока что нихрена не понимаю (я просто хотел узнать, стоит ли собирать месу шлангом с -flto, потому что она у меня более 5 часов непрерывного тарахтения хардом только ликовалась с прибитыми всеми остальными процессами, просто трешинг, это ни в какие ворота не лезет), то про GPU-таймеры писать не стал - эти бенчмарки время на GPU вообще не измеряют (хотя должны были).
> вызов получения времени находится в отдельной функции в отдельном translation unit,
> а не заинлайнен в нужное место.Нормальные бенчмарки - делают дофига итераций, и усредняют. Дабы как раз избежать заморочек с тем какая там точность системных часов, инлайн оно или нет и проч. Но эксперту опеннета про это забыли рассказать. Как и о том что разрешение источников времени на разных платформах - не константа.
Все что надо знать о квалификации критика с опеннета.
Нормальные бенчмарки ничего не усредняют. Они промеряют распределение, причём на разных размерностях, после чего отрезают все моды, кроме первой, потому что вторая и последующая моды - это результат работы планировщика ОС, далее распределение фитится аналитическим параметрическим распределением, и параметры этого распределения идут в регрессию. Там можно отделить фиксированный оверхед, не зависящий от размерности, от стоимости непосредственно обработки данных.
Забыл картинки:
и только для малины все никак и никак не напишут нормальный драйвер Вулкан
