Android для работаы
Подключить bluetooth клавиатуру не проблема. Мышь и тачпад работают, курсор отображается.
Бывает проблема с переключением языка, решается возвращением стандартной гугловской клавиатуры.
Подключение монитора. Самый простой вариант - по проводу через USB-C 3.1, для него есть альтернативные режимы с поддержкой DisplayPort.
Пропорции экрана не меняются, так что монитор надо подбирать с близким соотношением сторон. Сенсорный экран на мониторе тоже работает.
Другой вариант - через MiraCast модуль, из минусов: ограничение в 1080p, цена модуля и задержка сигнала.
IDE. Вариантов не много, часть из них платные, поддержку cmake проектов не нашел.
Должен быть способ доработать десктопную IDE, так с большим монитором и мышью UI переделывать не придется.
Компилятор. Так как Android это почти Linux, то для него есть терминал, а через него ставится cmake, git, clang и далее собрается любой проект.
В фоне компиляция сильно замедляется или останавливается, возможно это связано с переходом на энергоэффективные ядра.
Apk-tools не поддерживаются, поэтому для запуска нужно на ПК собрать apk, который копирует .so в локальное хранилище и загружает динамически.
Батарея. На некоторых устройствах есть режим питания от сети в обход аккумулятора, что меньше изнашивает батарею.
Перегерев. С этим сложнее, но для игровых смартфонов предусмотрено дополнительное охлаждение. А например макбуки до М1 начинали тротлить намного раньше.
Кроме смартфона есть вариант использовать Androd TV Box или одноплатник типа OrangePi, где уже есть HDMI выход, USB для клавиатуры и мыши, и цена намного меньше.
В целом из среднего смартфона получается слабенький ультрабук, только монитор и клавиатура занимают больше места.
Подключить bluetooth клавиатуру не проблема. Мышь и тачпад работают, курсор отображается.
Бывает проблема с переключением языка, решается возвращением стандартной гугловской клавиатуры.
Подключение монитора. Самый простой вариант - по проводу через USB-C 3.1, для него есть альтернативные режимы с поддержкой DisplayPort.
Пропорции экрана не меняются, так что монитор надо подбирать с близким соотношением сторон. Сенсорный экран на мониторе тоже работает.
Другой вариант - через MiraCast модуль, из минусов: ограничение в 1080p, цена модуля и задержка сигнала.
IDE. Вариантов не много, часть из них платные, поддержку cmake проектов не нашел.
Должен быть способ доработать десктопную IDE, так с большим монитором и мышью UI переделывать не придется.
Компилятор. Так как Android это почти Linux, то для него есть терминал, а через него ставится cmake, git, clang и далее собрается любой проект.
В фоне компиляция сильно замедляется или останавливается, возможно это связано с переходом на энергоэффективные ядра.
Apk-tools не поддерживаются, поэтому для запуска нужно на ПК собрать apk, который копирует .so в локальное хранилище и загружает динамически.
Батарея. На некоторых устройствах есть режим питания от сети в обход аккумулятора, что меньше изнашивает батарею.
Перегерев. С этим сложнее, но для игровых смартфонов предусмотрено дополнительное охлаждение. А например макбуки до М1 начинали тротлить намного раньше.
Кроме смартфона есть вариант использовать Androd TV Box или одноплатник типа OrangePi, где уже есть HDMI выход, USB для клавиатуры и мыши, и цена намного меньше.
В целом из среднего смартфона получается слабенький ультрабук, только монитор и клавиатура занимают больше места.
Deferred Vertex Shading. Как это может быть реализовано.
На этапе нарезания на тайлы вызывается часть вершинного шейдера, отвечающая за позицию, если треугольник маленький, то он помечается для использования DVS, для этого нужно сохранить вершинный и индексный буферы и смещения в них. Скорее всего оптимизация работает только для групп из мелких треугольников, тогда сохранение диапазона индексов займет меньше места, чем хорошо упакованные экранные координаты.
Если треугольник не маленький, то он проецируется в экранные координаты и нарезается на тайлы, эти данные впоследствии сжимаются и выгружаются из кэша, затем загружаются частями на этапе потайловой растеризации.
На этапе растеризации для DVS треугольников заново вызывается вершинный шейдер и затем фрагментный. Для остальных треугольников берутся уже расчитанные экранные координаты и вызывается другая часть вершинного шейдера, чтобы получить аттрибуты, затем все интерполируется и передается во фрагментный шейдер.
Получается расчет позиции для DVS треугольников происходит дважды, что может быть затратно если есть вершинная анимация.
#mali
На этапе нарезания на тайлы вызывается часть вершинного шейдера, отвечающая за позицию, если треугольник маленький, то он помечается для использования DVS, для этого нужно сохранить вершинный и индексный буферы и смещения в них. Скорее всего оптимизация работает только для групп из мелких треугольников, тогда сохранение диапазона индексов займет меньше места, чем хорошо упакованные экранные координаты.
Если треугольник не маленький, то он проецируется в экранные координаты и нарезается на тайлы, эти данные впоследствии сжимаются и выгружаются из кэша, затем загружаются частями на этапе потайловой растеризации.
На этапе растеризации для DVS треугольников заново вызывается вершинный шейдер и затем фрагментный. Для остальных треугольников берутся уже расчитанные экранные координаты и вызывается другая часть вершинного шейдера, чтобы получить аттрибуты, затем все интерполируется и передается во фрагментный шейдер.
Получается расчет позиции для DVS треугольников происходит дважды, что может быть затратно если есть вершинная анимация.
#mali
Hidden Surface Removal in Immortalis-G925: The Fragment Prepass
(webarchive)
На этапе потайловой растеризации добавили еще один проход, который ищет единственный видимый пиксель, а остальные исключает.
Поиск прерывается, если встречается несовместимое состояние или шейдер, например прозрачность или discard.
В чем-то это повторяет идею Visibility Buffer, где для непрозрачной геометрии вызывается только один фрагментный шейдер на пиксель.
Как было до этого.
Early ZS. После растеризации треугольника он делится на квадраты 2х2 пикселя и Z-координата каждого квадрата сравнивается с буфером глубины.
Forward Pixel Kill. Параллельно с выполнением фрагментного шейдера идет растеризация новых треугольников, если новый треугольник перекрывает текущий, то выполнение фрагментного шейдера прерывается. Не работает для слишком маленьких треугольников.
Late ZS. В случае, если фрагментный шейдер меняет Z или stencil значения, то тест происходит после выполнения шейдера.
#mali
(webarchive)
На этапе потайловой растеризации добавили еще один проход, который ищет единственный видимый пиксель, а остальные исключает.
Поиск прерывается, если встречается несовместимое состояние или шейдер, например прозрачность или discard.
В чем-то это повторяет идею Visibility Buffer, где для непрозрачной геометрии вызывается только один фрагментный шейдер на пиксель.
Как было до этого.
Early ZS. После растеризации треугольника он делится на квадраты 2х2 пикселя и Z-координата каждого квадрата сравнивается с буфером глубины.
Forward Pixel Kill. Параллельно с выполнением фрагментного шейдера идет растеризация новых треугольников, если новый треугольник перекрывает текущий, то выполнение фрагментного шейдера прерывается. Не работает для слишком маленьких треугольников.
Late ZS. В случае, если фрагментный шейдер меняет Z или stencil значения, то тест происходит после выполнения шейдера.
#mali
Насколько быстрее fp16
Термины:
2xfp16 - вектор из двух fp16, операции над ним происходят за один цикл, что дает вдвое больший FLOPS чем fp32.
FMA - пайплайн отвечающий за сложение и умножение.
SFU - пайплайн отвечающий за тригонометрию, степени, логарифмы и деление. Обычно поддерживает только fp32.
Apple M1. Производительность fp16 равна fp32 FMA.
Apple M3. Производительность fp16 равна fp32 FMA, но это 2 разных пайплайна, которые работают параллельно, поэтому суммарная производительность удваивается.
Adreno 6xx. Использует 2xfp16 FMA и SFU.
ARM Mali Valhall. Использует 2xfp16 FMA, при вызове SFU тратится один цикл на конвертацию в fp32.
AMD GCN 3-4. Производительность fp16 равна fp32 FMA. Не всегда есть поддержка в драйверах.
AMD GCN 5. Использует 2xfp16 FMA.
AMD RDNA 1. Использует 2xfp16 FMA. Позволяет комбинировать fp32 и fp16.
AMD RDNA 2+. Добавили
NV Pascal. В 64 раза медленее fp32.
NV Turing. Использует 2xfp16 FMA. Некоторые операции (min,step) на fp16 медленее fp32, остальные равны fp32. По тестам 2 сложения 2xfp16 выполняются за один цикл.
NV Ampere+. Убрали 2xfp16, но ускорили fp32.
PowerVR BXM. Должен поддерживать 2xfp16 FMA, но по тестам совпадает с fp32, а некоторые функции работают медленее из-за конвертации.
Intel 9Gen+. Использует 2xfp16 FMA. Выполняет 2 сложения 2xfp16 за цикл.
ARM Neon. Опционально доступен float16x8_t тип с вдвое большим FLOPS, поддерживает FMA и SFU инструкции.
x64 SSE. С расширением f16c поддерживает конвертацию между fp32 и fp16.
x64 AVX512_FP16. Поддерживает все инструкции fp32 (FMA и SFU), но с вдвое большим FLOPS.
Термины:
2xfp16 - вектор из двух fp16, операции над ним происходят за один цикл, что дает вдвое больший FLOPS чем fp32.
FMA - пайплайн отвечающий за сложение и умножение.
SFU - пайплайн отвечающий за тригонометрию, степени, логарифмы и деление. Обычно поддерживает только fp32.
Apple M1. Производительность fp16 равна fp32 FMA.
Apple M3. Производительность fp16 равна fp32 FMA, но это 2 разных пайплайна, которые работают параллельно, поэтому суммарная производительность удваивается.
Adreno 6xx. Использует 2xfp16 FMA и SFU.
ARM Mali Valhall. Использует 2xfp16 FMA, при вызове SFU тратится один цикл на конвертацию в fp32.
AMD GCN 3-4. Производительность fp16 равна fp32 FMA. Не всегда есть поддержка в драйверах.
AMD GCN 5. Использует 2xfp16 FMA.
AMD RDNA 1. Использует 2xfp16 FMA. Позволяет комбинировать fp32 и fp16.
AMD RDNA 2+. Добавили
fp32 Dot(2xfp16). NV Pascal. В 64 раза медленее fp32.
NV Turing. Использует 2xfp16 FMA. Некоторые операции (min,step) на fp16 медленее fp32, остальные равны fp32. По тестам 2 сложения 2xfp16 выполняются за один цикл.
NV Ampere+. Убрали 2xfp16, но ускорили fp32.
PowerVR BXM. Должен поддерживать 2xfp16 FMA, но по тестам совпадает с fp32, а некоторые функции работают медленее из-за конвертации.
Intel 9Gen+. Использует 2xfp16 FMA. Выполняет 2 сложения 2xfp16 за цикл.
ARM Neon. Опционально доступен float16x8_t тип с вдвое большим FLOPS, поддерживает FMA и SFU инструкции.
x64 SSE. С расширением f16c поддерживает конвертацию между fp32 и fp16.
x64 AVX512_FP16. Поддерживает все инструкции fp32 (FMA и SFU), но с вдвое большим FLOPS.
Обзор NVIDIA RTX Kit
RTX Texture Filtering
Основано на публикации: Filtering After Shading With Stochastic Texture Filtering
При линейной фильтрации карт нормалей возникает проблема - резкие перепады сглаживаются и освещение становится более плоским. Решается все выборкой нужных текселей, освещением и затем только фильтрацией, но тут в разы увеличиваются вычисления.
Для оптимизации каждый кадр читается только один тексель со случайным смещением. Если соседние пиксели в варпе читают ту же текстуру, то результат усредняется между ними. (код)
Затем результат фильтруется через темпоральные техники: TAA или DLSS.
Neural Shading
В примере весь расчет BRDF заменили нейронным шейдером.
Сам шейдер состоит из 4х вызовов
В целом выглядит интересно, сложно предсказать какие артефакты выдаст нейронка, но входных данных не так много, можно перебором все валидировать.
#nv
RTX Texture Filtering
Основано на публикации: Filtering After Shading With Stochastic Texture Filtering
При линейной фильтрации карт нормалей возникает проблема - резкие перепады сглаживаются и освещение становится более плоским. Решается все выборкой нужных текселей, освещением и затем только фильтрацией, но тут в разы увеличиваются вычисления.
Для оптимизации каждый кадр читается только один тексель со случайным смещением. Если соседние пиксели в варпе читают ту же текстуру, то результат усредняется между ними. (код)
Затем результат фильтруется через темпоральные техники: TAA или DLSS.
Neural Shading
В примере весь расчет BRDF заменили нейронным шейдером.
Сам шейдер состоит из 4х вызовов
rtxns::LinearOp(), где внутри вызывается coopVecMatMulAdd().В целом выглядит интересно, сложно предсказать какие артефакты выдаст нейронка, но входных данных не так много, можно перебором все валидировать.
#nv
продолжение:
Neural Texture Compression
Позволяет сжимать набор текстур до 16 каналов в сумме, что хорошо подходит для PBR текстур.
Предлагается 2 варианта использования:
* Загружать максимально сжатую текстуру в VRAM, затем распаковывать в BC формат, тем самым экономится место на диске и траффик PCIe.
* Хранить в максимально сжатом формате и распаковывать один тексель при чтении. Так уменьшается нагрузка на VRAM, но требуются тяжелые вычисления, зато в комбинации с RTX Texture Filtering распаковывается меньше текселей и производительность приходит в норму.
Проблемы:
* Детали из одного канала текстуры могут протекать в другие каналы.
* Хуже справляется с HDR форматами.
* Поддерживается только один альфа-канал, для него применяются специальные правила чтобы лучше сохранить значения 0 и 1.
* Альфа канал может использоваться отдельно для depth pre-pass, тогда распаковывать текстуру слишком затратно и лучше использовать другой формат.
RTX Mega Geometry
Новые расширения для ускоряющих структур.
В NV отказались от отдельного хэндла для AS, теперь везде DeviceAddress, то есть ссылка на GPU-память.
Добавили только Indirect команды, это полезно, но на начальном этапе отлаживать стало слишком сложно, остается ждать обновление VK_NV_ray_tracing_validation, так как обычные слои валидации не проверяют содержимое DeviceAddress.
VK_NV_partitioned_tlas
Теперь TLAS нарезается на тайлы и каждый тайл обновляется отдельно.
Ранее я планировал реализовать такое же через AABB и второй TLAS внутри, но с таким расширением явно будет быстрее работать.
VK_NV_cluster_acceleration_structure
Ранее BLAS хранил треугольники для одной модели, теперь добавили CLAS для хранения мешлетов (до 256 треугольников), это нужно для унификации с меш шейдерами.
CLAS нужны для переключения уровней детализации, как в Nanite, а для статики обычный BLAS работает быстрее.
#nv
Neural Texture Compression
Позволяет сжимать набор текстур до 16 каналов в сумме, что хорошо подходит для PBR текстур.
Предлагается 2 варианта использования:
* Загружать максимально сжатую текстуру в VRAM, затем распаковывать в BC формат, тем самым экономится место на диске и траффик PCIe.
* Хранить в максимально сжатом формате и распаковывать один тексель при чтении. Так уменьшается нагрузка на VRAM, но требуются тяжелые вычисления, зато в комбинации с RTX Texture Filtering распаковывается меньше текселей и производительность приходит в норму.
Проблемы:
* Детали из одного канала текстуры могут протекать в другие каналы.
* Хуже справляется с HDR форматами.
* Поддерживается только один альфа-канал, для него применяются специальные правила чтобы лучше сохранить значения 0 и 1.
* Альфа канал может использоваться отдельно для depth pre-pass, тогда распаковывать текстуру слишком затратно и лучше использовать другой формат.
RTX Mega Geometry
Новые расширения для ускоряющих структур.
В NV отказались от отдельного хэндла для AS, теперь везде DeviceAddress, то есть ссылка на GPU-память.
Добавили только Indirect команды, это полезно, но на начальном этапе отлаживать стало слишком сложно, остается ждать обновление VK_NV_ray_tracing_validation, так как обычные слои валидации не проверяют содержимое DeviceAddress.
VK_NV_partitioned_tlas
Теперь TLAS нарезается на тайлы и каждый тайл обновляется отдельно.
Ранее я планировал реализовать такое же через AABB и второй TLAS внутри, но с таким расширением явно будет быстрее работать.
VK_NV_cluster_acceleration_structure
Ранее BLAS хранил треугольники для одной модели, теперь добавили CLAS для хранения мешлетов (до 256 треугольников), это нужно для унификации с меш шейдерами.
CLAS нужны для переключения уровней детализации, как в Nanite, а для статики обычный BLAS работает быстрее.
#nv
Моя статься про проекцию на сферу.
Рассматривается:
* как построить сферу с одинаковыми треугольниками
* как равномерно распределить точки на сфере
* как равномерно наложить кубическую карту на сферу
* процедурная сфера без геометрии (как импостер)
* рендеринг в кубическую карту с корректировкой искажений
* генерация планет (кратеры, каньены)
Рассматривается:
* как построить сферу с одинаковыми треугольниками
* как равномерно распределить точки на сфере
* как равномерно наложить кубическую карту на сферу
* процедурная сфера без геометрии (как импостер)
* рендеринг в кубическую карту с корректировкой искажений
* генерация планет (кратеры, каньены)
C++ Data Structures That Make Video Games Go Round
Простенько, но наглядно.
Рассматривается:
* оптимизация хэш мапы
* массив из чанков вместо std::vector
* квадродерево для проверки видимости
* направленный граф для рендер графа
#cpp
Простенько, но наглядно.
Рассматривается:
* оптимизация хэш мапы
* массив из чанков вместо std::vector
* квадродерево для проверки видимости
* направленный граф для рендер графа
#cpp
Unlocking Modern CPU Power - Next-Gen C++ Optimization Techniques
17:00 - про кэш и префетч, цена случайного доступа к памяти.
24:42 - операции могут выполняться параллельно на уровне инструкций, но все портит ветвление.
32:19 - branchless, когда выполняются обе ветви.
45:45 - дальше про оптимизации на NUMA (много ЦП с локальной и общей памятью).
#cpp #cpu_opt
17:00 - про кэш и префетч, цена случайного доступа к памяти.
24:42 - операции могут выполняться параллельно на уровне инструкций, но все портит ветвление.
32:19 - branchless, когда выполняются обе ветви.
45:45 - дальше про оптимизации на NUMA (много ЦП с локальной и общей памятью).
#cpp #cpu_opt
Vulkanised 2025 (playlist)
Using Ycbcr Samples with Bindless Vulkan
Предлагает использовать specialization constant для Ycbcr immutable sampler, так как динамические индексы не работают.
ARM ASR: Platform Agnostic Efficient Temporal Upscaling on Mobile
Оптимизировали FSR2 под свое железо. В разы уменьшили нагрузку на шину памяти, что важно для мобилок.
Integrating Bindless Vulkan with Ray Tracing on Mobile Devices
Рассказывают про трассировку лучей с самого начала. Демка с AO и тенями.
Blender Transition Towards Vulkan
Немного про рендер граф, компиляцию шейдеров, слои и отладку. Сделали тулзы для симуляции разных ГП (так многие делают).
A New Open Source Profiler & Debugger for Android + Vulkan
Рассказывают про Android GPU Inspector.
Implementing Foveated Rendering with OpenXR and Vulkan
Рассказывают про VRS в обоих вариантах: fragment shading rate и fragment density map.
Inspecting Shader Value Using GPU-Driven Rendering
Сделали рисование линий из шейдера, нужно для визуализации значений переменных, также линиями можно выводить числа.
Crash Diagnostic Layer
Слой валидации который упрощает поиск места падения драйвера. Не работает на уровне шейдеров.
Debugging Your GPU Workflow
Про GPU Assisted Validation - валидация на уровне ГП, включает шейдеры, indirect параметры, индексы вершин.
#vk
Using Ycbcr Samples with Bindless Vulkan
Предлагает использовать specialization constant для Ycbcr immutable sampler, так как динамические индексы не работают.
ARM ASR: Platform Agnostic Efficient Temporal Upscaling on Mobile
Оптимизировали FSR2 под свое железо. В разы уменьшили нагрузку на шину памяти, что важно для мобилок.
Integrating Bindless Vulkan with Ray Tracing on Mobile Devices
Рассказывают про трассировку лучей с самого начала. Демка с AO и тенями.
Blender Transition Towards Vulkan
Немного про рендер граф, компиляцию шейдеров, слои и отладку. Сделали тулзы для симуляции разных ГП (так многие делают).
A New Open Source Profiler & Debugger for Android + Vulkan
Рассказывают про Android GPU Inspector.
Implementing Foveated Rendering with OpenXR and Vulkan
Рассказывают про VRS в обоих вариантах: fragment shading rate и fragment density map.
Inspecting Shader Value Using GPU-Driven Rendering
Сделали рисование линий из шейдера, нужно для визуализации значений переменных, также линиями можно выводить числа.
Crash Diagnostic Layer
Слой валидации который упрощает поиск места падения драйвера. Не работает на уровне шейдеров.
Debugging Your GPU Workflow
Про GPU Assisted Validation - валидация на уровне ГП, включает шейдеры, indirect параметры, индексы вершин.
#vk
Vulkanised 2025, продолжение
libGPULayers: Diagnostic Vulkan Layers for Android
В ARM разработали слой libGPULayers, чтобы помогать другим разработчикам: находить ошибки при работе с Vulkan, анализировать производительность.
Это сложнее чем исправить код в приложении или подправить шейдер.
Vulkan Best Practices for Mobile Development
С новым поколением потребление энергии (и тепловыделение) памятью уменьшается незначительно, тогда как энергоэффективность процессоров растет, поэтому для мобильных платформ важно уменьшить нагрузку на память. Рекомендации по синхронизации. Рассматриваются техники пропуска невидимых пикселей (HSV, DVS, FPP).
What is Maximal Reconvergence and Why it Matters
Рассказывает как работает SIMT, вырожденные потоки (divergence). Ветвление создает вырожденные потоки, после ветвления все потоки снова выполняют одинаковые инструкции, но в зависимости от реализации они могут остаться вырожденными, что приводит к неопределенным результатам при операциях с subgroup. Maximal reconvergence исправляет эту ситуацию.
Color Volume Transformations in Vulkan Shaders
Как появились цветовые пространства. Чем отличаются цветовые пространства, тонемапинг.
Swapchains Explained: How to Manage Them Effectively
Кроме пересказа документации еще расказывают о деталях вывода на экран Android. Разбираются проблемы синхронизации.
#vk
libGPULayers: Diagnostic Vulkan Layers for Android
В ARM разработали слой libGPULayers, чтобы помогать другим разработчикам: находить ошибки при работе с Vulkan, анализировать производительность.
Это сложнее чем исправить код в приложении или подправить шейдер.
Vulkan Best Practices for Mobile Development
С новым поколением потребление энергии (и тепловыделение) памятью уменьшается незначительно, тогда как энергоэффективность процессоров растет, поэтому для мобильных платформ важно уменьшить нагрузку на память. Рекомендации по синхронизации. Рассматриваются техники пропуска невидимых пикселей (HSV, DVS, FPP).
What is Maximal Reconvergence and Why it Matters
Рассказывает как работает SIMT, вырожденные потоки (divergence). Ветвление создает вырожденные потоки, после ветвления все потоки снова выполняют одинаковые инструкции, но в зависимости от реализации они могут остаться вырожденными, что приводит к неопределенным результатам при операциях с subgroup. Maximal reconvergence исправляет эту ситуацию.
Color Volume Transformations in Vulkan Shaders
Как появились цветовые пространства. Чем отличаются цветовые пространства, тонемапинг.
Swapchains Explained: How to Manage Them Effectively
Кроме пересказа документации еще расказывают о деталях вывода на экран Android. Разбираются проблемы синхронизации.
#vk
Vulkanised 2025, нейронки
Practical Neural Texture Compression
Тоже самое что в документации по NV NTC, только в виде презентации.
Slang is for Neural Graphics
Добавили в язык поддержку градиентного спуска:
Подробнее по авто-генерацию производных в статье: SLANG.D: Fast, Modular and Differentiable Shader Programming
Using Neural Networks in Shaders
В железе нейронные шейдеры сделаны как умножение матрицы на матрицу, то есть аналогично cooperative matrix, это может уменьшить производительность при неоднородном выполнении (nonuniform).
Ссылаются на статью Real-Time Neural Appearance Models, где нейронка с BRDF работает в 10 раз быстрее и точнее, чем аналитический BRDF с многослойным материалом.
#vk
Practical Neural Texture Compression
Тоже самое что в документации по NV NTC, только в виде презентации.
Slang is for Neural Graphics
Добавили в язык поддержку градиентного спуска:
[Differentiable] аттрибут помечает функции для которых генерируется производная, далее производная используется в градиентном спуске для поиска наилучших коэфициентов.Подробнее по авто-генерацию производных в статье: SLANG.D: Fast, Modular and Differentiable Shader Programming
Using Neural Networks in Shaders
В железе нейронные шейдеры сделаны как умножение матрицы на матрицу, то есть аналогично cooperative matrix, это может уменьшить производительность при неоднородном выполнении (nonuniform).
Ссылаются на статью Real-Time Neural Appearance Models, где нейронка с BRDF работает в 10 раз быстрее и точнее, чем аналитический BRDF с многослойным материалом.
#vk
Lavapipe
Это софтварная реализация Vulkan, поддерживает 1.4 и популярные расширения, включая трассировку, меш шейдеры и ворк-графы.
Нужен для запуска тестов на CI, также можно использовать чтобы пощупать новые расширения на старом железе.
Мои тесты:
* Трассировка лучей в спонзе - 2.6с на кадр, построение ускоряющей структуры - 25с.
* RT-Shadow тест - 6 FPS, 4.7 млн лучей.
* fp32 FMA - 56 GFLOPS на ядро, 46% от теоретических.
Баги:
* Меш шейдеры не всегда работают.
* dFdxCoarse работает как dFdxFine.
Установка на Windows:
* скомпилировать или скачать бинарники с github
* если vulkan не установлен - скачать vulkan runtime там же где SDK и использовать vulkan-1.dll
* в переменных окружения добавить VK_DRIVER_FILES = '<path>/lvp_icd.x86_64.json'
Установка на Linux:
Презентация на Vulkanised 2025: Current State of Lavapipe
Это софтварная реализация Vulkan, поддерживает 1.4 и популярные расширения, включая трассировку, меш шейдеры и ворк-графы.
Нужен для запуска тестов на CI, также можно использовать чтобы пощупать новые расширения на старом железе.
Мои тесты:
* Трассировка лучей в спонзе - 2.6с на кадр, построение ускоряющей структуры - 25с.
* RT-Shadow тест - 6 FPS, 4.7 млн лучей.
* fp32 FMA - 56 GFLOPS на ядро, 46% от теоретических.
Баги:
* Меш шейдеры не всегда работают.
* dFdxCoarse работает как dFdxFine.
Установка на Windows:
* скомпилировать или скачать бинарники с github
* если vulkan не установлен - скачать vulkan runtime там же где SDK и использовать vulkan-1.dll
* в переменных окружения добавить VK_DRIVER_FILES = '<path>/lvp_icd.x86_64.json'
Установка на Linux:
apt install mesa-vulkan-drivers libvulkan1Презентация на Vulkanised 2025: Current State of Lavapipe
В видео Unlocking Modern CPU Power (30:19) есть код:
Как ЦП его выполнит?
Задолго до реального выполнения происходит спекулятивное выполнение - ЦП смотри вперед, если значение condition уже содержится в L1, то выполнение идет дальше и загружает данные в кэш.
Если значение неизвестно, то спекулятивное выполнение не останавливается и включается предсказатель ветвлений, который направлет выполнение по одному из путей.
Если предсказатель ошибся, то спекулятивное выполнение откатывается назад, но запрошенные данные остаются в кэше.
Глубина выполнения зависит от размера reorder buffer, например 192 микроопераций на Haswell архитектуре, а задержка на чтение из L3 около 36 циклов, из ОЗУ - более 200 циклов. Это позволяет почти скрыть потери на все кэш-промахи.
Какая память загружается в кэш?
Оказалось, что пытается загрузить любой адрес, работает аналогично
Особенности спекулятивного выполнения хорошо разобрали в статьях по Spectre. Так исследования безопасности ЦП дают интересные подробности работы различных систем, тогда как в рекомендациях по оптимизации это не так наглядно.
#cpu_opt
x += condition ? a[i] : b[i];Как ЦП его выполнит?
Задолго до реального выполнения происходит спекулятивное выполнение - ЦП смотри вперед, если значение condition уже содержится в L1, то выполнение идет дальше и загружает данные в кэш.
Если значение неизвестно, то спекулятивное выполнение не останавливается и включается предсказатель ветвлений, который направлет выполнение по одному из путей.
Если предсказатель ошибся, то спекулятивное выполнение откатывается назад, но запрошенные данные остаются в кэше.
Глубина выполнения зависит от размера reorder buffer, например 192 микроопераций на Haswell архитектуре, а задержка на чтение из L3 около 36 циклов, из ОЗУ - более 200 циклов. Это позволяет почти скрыть потери на все кэш-промахи.
Какая память загружается в кэш?
Оказалось, что пытается загрузить любой адрес, работает аналогично
_mm_prefetch. Если виртуальный адрес не существует, то выполнение может пойти по другому пути, предполагая, что несуществующий адрес не будет использован.Особенности спекулятивного выполнения хорошо разобрали в статьях по Spectre. Так исследования безопасности ЦП дают интересные подробности работы различных систем, тогда как в рекомендациях по оптимизации это не так наглядно.
#cpu_opt
Лекции GAMES104 - Modern Game Engine: Theory and Practice
Хороший обзор всего, что применяется в геймдеве, без углубления в детали реализации.
Видео на китайском, исходники движка, архив с pdf.
1. Overview of Game Engine
2. Layered Architecture of Game Engine
3. How to Build a Game World
Rendering on Game Engine:
4. Basics of Game Rendering
5. Lighting, Materials and Shaders (только видео)
6. The Challenges & Fun of Rendering the Beautiful Mother Nature
7. Render Pipeline, Post-process and Everything
Animation System:
8. Basics of Animation Technology
9. Advanced Animation Technology
Physics System:
10. Basic Concepts
11. Applications
12. Effects
13. Tool Chains
14. Tool Chains - Applications & Advanced Topic
Gameplay Systems:
15. Complexity and Building Blocks
16. Basic Artificial Intelligence
17. Advanced Artificial Intelligence
Online Gaming Architecture:
18. Fundamentals
19. Advanced Topics
20. Data-Oriented Programming and Job System
21. Dynamic Global Illumination and Lumen
22. GPU-Driven GeometryPipeline - Nanite
Хороший обзор всего, что применяется в геймдеве, без углубления в детали реализации.
Видео на китайском, исходники движка, архив с pdf.
1. Overview of Game Engine
2. Layered Architecture of Game Engine
3. How to Build a Game World
Rendering on Game Engine:
4. Basics of Game Rendering
5. Lighting, Materials and Shaders (только видео)
6. The Challenges & Fun of Rendering the Beautiful Mother Nature
7. Render Pipeline, Post-process and Everything
Animation System:
8. Basics of Animation Technology
9. Advanced Animation Technology
Physics System:
10. Basic Concepts
11. Applications
12. Effects
13. Tool Chains
14. Tool Chains - Applications & Advanced Topic
Gameplay Systems:
15. Complexity and Building Blocks
16. Basic Artificial Intelligence
17. Advanced Artificial Intelligence
Online Gaming Architecture:
18. Fundamentals
19. Advanced Topics
20. Data-Oriented Programming and Job System
21. Dynamic Global Illumination and Lumen
22. GPU-Driven GeometryPipeline - Nanite
Моя статья по Geometry Culling
Обзор различных техник отсечения невидимой геометрии на ПК и мобилках.
На ПК хороший результат показал Visibility Buffer.
Среди мобилок Adreno Low Resolution Z лучше других справляется с неотсортированной геометрией.
#gpu_opt
Обзор различных техник отсечения невидимой геометрии на ПК и мобилках.
На ПК хороший результат показал Visibility Buffer.
Среди мобилок Adreno Low Resolution Z лучше других справляется с неотсортированной геометрией.
#gpu_opt
'Delta Force': Performant High-Quality Terrain and Biome Technology for PC and Mobile
Оптимизация большого открытого мира под ПК и мобилки.
* Фейковый АО для травы и деревьев
* Оптимизация импостеров деревьев
* Процедурная генерация мира. При наложении деревьев проверяют пересечение через воксели.
* Детально разбирают виртуальные текстуры. Для мобилок сжимают в шейдере в ASTC. Проблема на склонах.
* Софтварная тесселяция оказалась в 6 раз быстрее.
#gpu_opt
Оптимизация большого открытого мира под ПК и мобилки.
* Фейковый АО для травы и деревьев
* Оптимизация импостеров деревьев
* Процедурная генерация мира. При наложении деревьев проверяют пересечение через воксели.
* Детально разбирают виртуальные текстуры. Для мобилок сжимают в шейдере в ASTC. Проблема на склонах.
* Софтварная тесселяция оказалась в 6 раз быстрее.
#gpu_opt
Библиотеки для эмуляции GAPI
Zink: OpenGL поверх Vulkan
Часть Mesa драйверов, полезен для отладки и профилирования OpenGL приложений.
Сейчас RenderDoc имеет ограниченный функционал под GL, который к тому же часто некорректно работает.
В NSight также забросили поддержку GL и весь новый функционал только под Vulkan/DX12.
Как использовать: качаем бинарники под windows, копируем opengl32.dll и libgallium_wgl.dll в папку с exe, в переменных окружения ставим GALLIUM_DRIVER=zink и запускаем.
DXVK: DX8/9/10/11 поверх Vulkan
Позволяет запускать старые игры на более свежих драйверах.
Также позволяет их захватывать RenderDoc'ом.
Как использовать: качаем бинарники, копируем d3dX.dll и dxgi.dll в папку с exe, запускаем.
vkd3d-proton: DX12 поверх Vulkan
Используется для запуска современных игр на линуксе, но также совместим с windows.
Производительность лучше не станет, разве что позволит обойти баги в дх драйвере для каких-то редких ГП.
Как использовать: качаем бинарники, берем dxgi.dll из DXVK, копируем все в папку с exe и запускаем.
Zink: OpenGL поверх Vulkan
Часть Mesa драйверов, полезен для отладки и профилирования OpenGL приложений.
Сейчас RenderDoc имеет ограниченный функционал под GL, который к тому же часто некорректно работает.
В NSight также забросили поддержку GL и весь новый функционал только под Vulkan/DX12.
Как использовать: качаем бинарники под windows, копируем opengl32.dll и libgallium_wgl.dll в папку с exe, в переменных окружения ставим GALLIUM_DRIVER=zink и запускаем.
DXVK: DX8/9/10/11 поверх Vulkan
Позволяет запускать старые игры на более свежих драйверах.
Также позволяет их захватывать RenderDoc'ом.
Как использовать: качаем бинарники, копируем d3dX.dll и dxgi.dll в папку с exe, запускаем.
vkd3d-proton: DX12 поверх Vulkan
Используется для запуска современных игр на линуксе, но также совместим с windows.
Производительность лучше не станет, разве что позволит обойти баги в дх драйвере для каких-то редких ГП.
Как использовать: качаем бинарники, берем dxgi.dll из DXVK, копируем все в папку с exe и запускаем.
Предкомпилированные заголовки в C++
При компиляции каждого cpp файла происходит перекомпиляция всех подключаемых заголовков, что занимает много времени.
Предкомпилированные заголовки (pch) позволяют скомпилировать их один раз и переиспользовать, что значительно ускорит компиляцию.
Остается только правильно их использовать.
Первый вариант - для каждой либы проекта сделать pch с входными .h, это обычно std и другие либы.
Минус - для каждой либы придется создавать свой pch с повторной компиляцией, что в итоге раздувает размер проекта.
У меня такой способ ускорил компиляцию в 2 раза и увеличил размер проекта до 100Гб.
Второй вариант - сложить все заголовки проекта в pch, тогда каждый .cpp файл будет обращаться к предкомпилированным заголовкам.
Скорость компиляции выросла еще в 2 раза, на старом ЦП даже в 5 раз. Размер проекта также уменьшился, ведь больше нет десятков pch.
Недостатки тоже есть - все зависимости и макросы придется вынести в один проект, чтобы pch компилировался со всем необходимыми макросами. Из-за этого не получится изолировать макросы в пределах одной либы. Изменение одного заголовка приводит к перекомпиляции всего проекта, что лучше подходит для CI, чем для разработки.
Третий вариант - сложить все заголовки отдельной либы в pch. Это решит проблему с макросами и чуть ускорит сборку, но останется слишком большой размер проекта.
Последний вариант - перейти на модули, но это требует рефакторинга всего кода.
#cpp
При компиляции каждого cpp файла происходит перекомпиляция всех подключаемых заголовков, что занимает много времени.
Предкомпилированные заголовки (pch) позволяют скомпилировать их один раз и переиспользовать, что значительно ускорит компиляцию.
Остается только правильно их использовать.
Первый вариант - для каждой либы проекта сделать pch с входными .h, это обычно std и другие либы.
Минус - для каждой либы придется создавать свой pch с повторной компиляцией, что в итоге раздувает размер проекта.
У меня такой способ ускорил компиляцию в 2 раза и увеличил размер проекта до 100Гб.
Второй вариант - сложить все заголовки проекта в pch, тогда каждый .cpp файл будет обращаться к предкомпилированным заголовкам.
Скорость компиляции выросла еще в 2 раза, на старом ЦП даже в 5 раз. Размер проекта также уменьшился, ведь больше нет десятков pch.
Недостатки тоже есть - все зависимости и макросы придется вынести в один проект, чтобы pch компилировался со всем необходимыми макросами. Из-за этого не получится изолировать макросы в пределах одной либы. Изменение одного заголовка приводит к перекомпиляции всего проекта, что лучше подходит для CI, чем для разработки.
Третий вариант - сложить все заголовки отдельной либы в pch. Это решит проблему с макросами и чуть ускорит сборку, но останется слишком большой размер проекта.
Последний вариант - перейти на модули, но это требует рефакторинга всего кода.
#cpp
Новые GPU от Intel
С дискретными картами все просто - уже не новый Alchemist (Xe-HP) поддерживает все модные расширения типа рейтреса, меш шейдеров, асинхронные очереди. Но больше не поддерживает ASTC формат.
В Battlemage (Xe2-HP) добавили новые тензорные ядра, они же XMX engine.
Со встройками намного интереснее.
Xe-LP поддерживает fragment shading rate, fragment interlock, sampler feedback (только в dx), video decode, но лимиты для bindless остались в пределах 200 текстур. Для эмуляции мобилок оставили поддержку ASTC формата.
Дальше появился Xe+LP, например Arc 140T, где добавили все из Xe-HP, только урезали тензорные ядра и получилось так:
Arrow Lake-H: XeSS super resolution, frame generation, low latency
Arrow Lake-S, Meteor Lake: XeSS super resolution, low latency
Затем выпустили Xe2-LP и назвали его Arc 140V, но только на Ultra 200V серии, а остальная 200 серия осталась на Xe+.
Из новых расширений: fragment shader barycentric.
Подробнее в моих заметках: Xe1, Xe2
С дискретными картами все просто - уже не новый Alchemist (Xe-HP) поддерживает все модные расширения типа рейтреса, меш шейдеров, асинхронные очереди. Но больше не поддерживает ASTC формат.
В Battlemage (Xe2-HP) добавили новые тензорные ядра, они же XMX engine.
Со встройками намного интереснее.
Xe-LP поддерживает fragment shading rate, fragment interlock, sampler feedback (только в dx), video decode, но лимиты для bindless остались в пределах 200 текстур. Для эмуляции мобилок оставили поддержку ASTC формата.
Дальше появился Xe+LP, например Arc 140T, где добавили все из Xe-HP, только урезали тензорные ядра и получилось так:
Arrow Lake-H: XeSS super resolution, frame generation, low latency
Arrow Lake-S, Meteor Lake: XeSS super resolution, low latency
Затем выпустили Xe2-LP и назвали его Arc 140V, но только на Ultra 200V серии, а остальная 200 серия осталась на Xe+.
Из новых расширений: fragment shader barycentric.
Подробнее в моих заметках: Xe1, Xe2