What is gpu rendering on android

Profiling GPU Rendering Walkthrough

In this document

You should also read

This walkthrough shows how to use Profile GPU Rendering on your mobile device.

Profile GPU Rendering gives you a quick visual representation of how much time it takes to render the frames of a UI window relative to the 16-ms-per-frame benchmark.

What it’s good for:

• Quickly seeing how a UI window performs against the 16-ms-per-frame target.
• Identifying whether any part of the rendering pipeline stands out in using processing time.
• Looking for spikes in frame rendering time associated with user or program actions.

Prerequisites

• A mobile device running at least Android 4.1 with Developer Options enabled.

Working with Profile GPU Rendering

Figure 1. Turning on Profile GPU Rendering.

Figure 2. Screen when Profile GPU Rendering is on.

What you see:

• For each visible application, the tool displays a graph.
• The horizontal axis shows time elapsing, and the vertical axis time per frame in milliseconds.
• As you interact with your application, vertical bars show up on your screen, appearing from left to right, graphing frame performance over time.
• Each vertical bar represents one frame of rendering. The taller the bar, the longer it took to render.
• The green line marks the 16 millisecond target. Every time a frame crosses the green line, your app is missing a frame, and your users may see this as stuttering images.

The Profile GPU Rendering Graph

Figure 3. Enlarged Annotated Profile GPU Rendering graph.

In this enlarged image of the Profile GPU Rending graph you can see the colored sections of the graph, and what phase of the rendering pipeline each color represents.

• The green line represents 16 milliseconds. To achieve 60 frames per second, the vertical bar for each frame needs to stay below this 16 ms mark. Any time a bar pushes above this line, there may be pauses in the animations.
• Each bar has a blue, purple (only for Android version 4.0 and higher), red, and orange component.

The blue section of the bar represents the time used to create and update the View’s display lists. If this part of the bar is tall, there may be a lot of custom view drawing, or a lot of work in onDraw methods.

Android 4.0 and higher: The purple section of the bar represents the time spent transferring resources to the render thread.

The red section of the bar represents the time spent by Android’s 2D renderer issuing commands to OpenGL to draw and redraw display lists. The height of this bar is directly proportional to the sum of the time it takes each display list to execute—more display lists equals a taller red bar.

The orange section of the bar represents the time the CPU is waiting for the GPU to finish its work. If this bar gets tall, it means the app is doing too much work on the GPU.

Note: While this tool is named Profile GPU Rendering, all monitored processes actually occur in the CPU. Rendering happens by submitting commands to the GPU, and the GPU renders the screen asynchronously. In certain situations, the GPU can have too much work to do, and your CPU will have to wait before it can submit new commands. When this happens, you’ll see spikes in the Process (orange bar) and Execute (red bar) stages, and the sommand submission will block until more room is made on the GPU command queue.

Источник

Как заставить рендеринг GPU на Android —

когда Рендеринг с помощью графического процессора добрался до Android, это было ненадежно, если не сказать больше. Официальная цель — повысить производительность приложений, но тогда многие графические пользовательские интерфейсы не знали, как работать с рендерингом на GPU. В некоторых случаях это было даже медленнее, чем программный рендеринг.

Со временем, особенно после появления Android 4.0, графический процессор стал более надежным и постепенно стал стандартным для большинства приложений. В настоящее время большинство обновленных приложений имеют встроенный графический рендеринг.

Но прежде чем мы перейдем к тому, как и когда включить эту опцию, давайте разберемся, как она работает.

Что такое рендеринг на GPU?

GPU является Графический процессор. По своей сути он очень похож на ЦП, но вместо выполнения вычислений и выполнения задач, связанных с операционной системой и оборудованием, графический процессор обрабатывает графическую информацию. Другими словами, это помещает материал на экран, чтобы ваши глаза могли видеть.

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

Это где Графический процессор приходит — он отнимает часть графической обработки от процессора, освобождая его для более важных дел. Поскольку графический процессор намного лучше с графическими данными, конечный результат — лучшая производительность как для процессора, так и для графического процессора.

Когда форсировать рендеринг на GPU

Включение этого параметра приведет к разгрузке таких компонентов окна, как текст, кнопки и расчеты 2D-графики, в графический процессор. Это позволит вашему устройству лучше отображать анимацию пользовательского интерфейса и чувствовать себя менее запаздывающим. Хотя вы, безусловно, достигнете более плавного восприятия и лучшей частоты кадров в 2-мерных приложениях, ваше устройство может в итоге использовать больше батареи. Известно, что графические процессоры потребляют больше энергии, чем процессоры, поэтому ожидайте, что время автономной работы уменьшится на 10-15%, если оставить его включенным постоянно.

Принудительное рендеринг с помощью графического процессора определенно имеет смысл на устройствах с более слабым процессором. Если ваше устройство является чем-то меньшим, чем четырехъядерный процессор, я бы рекомендовал вам всегда оставлять его включенным.

Но имейте в виду, что рендеринг с помощью графического процессора эффективен только для двумерных приложений. Большие игры с использованием 3D-графики могут иметь худшую частоту кадров при Force GPU Rendering включен. Хорошо то, что большинство версий Android не будут мешать 3D-приложениям и будут вызывать рендеринг с помощью графического процессора только в тех приложениях, которые не используют его по умолчанию.

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

Суть в том, что вам решать, хотите ли вы обменять срок службы батареи на повышенную текучесть и некоторые дополнительные частоты кадров. Имея это в виду, вот как включить Force GPU Rendering.

Источник

GPU-ускорение на Android — что это и нужно ли включать?

Смартфоны на Android с каждым годом работают быстрее: производители устанавливают новые процессоры и GPU, увеличивают объем оперативной памяти. Сегодня мобильное устройство может заменить ноутбук — мощности гаджета хватит, чтобы полноценно пользоваться интернетом и даже обрабатывать видео.

В операционной системе Android есть дополнительные функции, которые помогут увеличить скорость работы смартфона. Один из таких инструментов — GPU-ускорение.

Нужно ли включать GPU-ускорение на телефоне?

GPU — встроенный графический процессор. Задача GPU-ускорения — принудительный перенос процесса рендеринга изображения с процессора смартфона на GPU. Таким образом повышается общая производительность мобильного устройства — после активации этого режима увеличивается скорость обработки информации в производительных играх и приложениях (утилиты для обработки и рендеринга видеороликов, фотографий, графические приложения).

Если в некоторых играх или программах снижается производительность, активируйте GPU-ускорение. Это не навредит смартфону, единственное, что может произойти — некоторые утилиты перестанут запускаться.

Для включения GPU-ускорения откройте настройки гаджета. После этого перейдите в раздел «Для разработчиков» — вот подробная инструкция по его открытию.

В меню разработчиков находится подраздел «Аппаратное ускорение визуализации». Активируйте функцию «GPU-ускорение». Теперь гаджет будет использовать максимальное количество системных ресурсов, чтобы обеспечить высокую производительность в приложениях.

Источник

What is GPU rendering in Android and how to enable it?

If you are using an ageing Android device you probably won’t get the same experience compared to when it was new. Phones can get slower over time and to get rid of this lag and make your Android experience exceptional again, you can turn to GPU rendering.

Any computing device has two processing units — GPU (Graphical Processing Unit) and the CPU (Central Processing unit). Both of these units perform different operations. The CPU is used for logical operations and is great at doing the same but isn’t as great at parallel processing. GPU, on the other hand, is exceptional at parallel processing — performs the same tasks at faster speeds.

The main job of the GPU is to render images on the mobile phone. When you are playing a 3D game on your phone, the GPU is responsible for showing a 3D image on a 2D screen by performing various matrix calculations. If the CPU has to perform this rendering, it slows down the device because in such a case the CPU is burdened with a lot of tasks. By enabling the following settings on your Android device, it will become snappier.

Should you enable GPU rendering?

GPU rendering basically means that you’re tasking your GPU to do certain tasks like generate screen elements, which usually the CPU does, among other things. Needless to say, the CPU on any device is the busiest hardware as it has a lot of things to take care of and the entire functioning of the device actually rests on its shoulders.

Enabling GPU rendering can a take off a considerable amount of load from the CPU, which could effectively make your system run smoother and faster. However, it’s important that you have a high-performing graphics card for GPU rendering, otherwise, the whole process might turn out to be counterproductive as a low-performance GPU could slow down the screen loads and the entire experience.

In case of Android devices, if you’re working on a low or mid-segment smartphone with a not-so-efficient SoC, it’s not recommended to use GPU rendering as that can put stress on your device and might make it slower. However, you can give it a try if you wish as the process is reversible.

How to enable GPU rendering on Android?

To enable GPU rendering, you need to enable developer settings. Follow the steps below to do that and then enable GPU rendering on your Android device.

• Go to Settings >About phone> Build number. It’s mostly under About phone but can vary depending on the manufacturer. Once there, click repeatedly (about seven times) on the Build number. Doing this will enable developer options on your device.
• Once you have developer options enabled on your device. Go to Systems > Developer options and turn on Force GPU rendering and Force4x MSAA.

Enabling these two options will make your Android experience smoother as it takes the load of the CPU by using GPU for rendering images on the screen. MSAA makes the display look crispier by performing anti-aliasing.

If for some reason, your device starts to lag or stutter, follow the same steps above and switch off the toggle button besides Force 4x MSAA and Force GPU rendering.

A tech enthusiast, driven by curiosity. A bibliophile who loves to travel. An Engineering graduate who loves to code and write about new technologies. Can’t sustain without coffee.

You can contact Nischay via email: [email protected]

Источник

Оптимизация рендера под Mobile, часть 2. Основные семейства современных мобильных GPU

Приветствую, дорогие любители и профессионалы, программисты графики! Приступаем ко второй части нашего цикла статей про оптимизацию рендера под Mobile. В этой части мы будем рассматривать основные семейства GPU, представленные у игроков на Mobile.

Унифицированные или специализированные шейдерные ядра

В эпоху ранних мобильных видеокарт, до распространения комплексных эффектов, существовала точка зрения, что для фрагментных шейдеров достаточно поддержки вычислений на пониженной точности. Ведь в типичном режиме дисплея применяется 8, а то и меньше бит на каждый канал цвета. Такая точка зрения привела к использованию специализированных шейдерных ядер. Для вершин использовались ядра, оптимизированные для матричных преобразований на повышенной точности FP24/FP32(highp). Для пикселей — ядра, более эффективно работающие с пониженной точностью FP16 (mediump). При этом highp на них не поддерживался. На первый взгляд, такая специализация позволяет добится более рационального распределения транзисторов на чипе. Однако, на практике это приводит к трудностям при разработке комплексных эффектов, а также при использовании текстур большого разрешения. Кроме того, специализация ядер может приводить к vertex/fragment bottleneck. Таким термином называют ситуацию, когда из-за несимметричной нагрузки на вершинные и пиксельные ядра часть ядер «простаивала».

Поэтому в современных архитектурах применяются унифицированные ядра. Такие ядра могут брать на себя вершинные, пиксельные и другие вычислительные задачи в зависимости от нагрузки.

Векторный (SIMD) или скалярный набор инструкций

В духе описанного выше стремления экономить на транзисторах, специализируя ядра, происходил и дизайн набора шейдерных инструкций. Большинство типичных преобразований для трехмерной графики оперируют 4-х компонентными векторами. Поэтому ранние GPU работали именно с такими операндами. Если же в коде шейдера содержались разнородные скалярные операции, которые не удавалось упаковать в векторные операции оптимизатором, часть вычислительных мощностей не задействовалась. Это явление можно проиллюстрировать так:

Имеется шейдер, осуществляющий распространенную операцию Multiply Add: умножить 2 операнда, а затем добавить третий. При компиляции на условной векторной архитектуре (Vector ISA = Vector Instruction Set Architecture) мы получаем одну векторную инструкцию vMADD, выполняющуюся 1 такт. На условной скалярной архитектуре мы получаем 4 скалярные инструкции, которые благодаря усовершенствованному конвейеру также выполняются за 1 такт. Теперь рассмотрим усложненный шейдер, выполняющий 2 операции, но над 2-х компонентными операндами.

В случае векторной архитектуры получаем уже 2 инструкции, требующие 2 такта на выполнение. При этом над компонентами .zw действия не производятся, и вычислительные мощности простаивают. В случае скалярной архитектуры эти же операции можно упаковать в 4 скалярных sMADD, выполняющихся за тот же 1 такт. Таким образом на скалярной архитектуре за счет усовершенствования конвейера достигается большая плотность вычислений. Тем не менее, как будет показано ниже, векторная ISA по-прежнему актуальна. А значит, есть смысл применять техники векторизации шейдерного кода. Они позволяют добиться повышенной производительности на видеокартах с векторными ISA. В то же время, как правило, это не вредит быстродействию на более современных скалярных ISA.

Опираясь на приведенные характеристики, рассмотрим распространенные в наше время семейства мобильных GPU. Начнем с наиболее часто встречающегося семейства. Многие знают, что речь идет о видеокартах Mali от британской компании ARM. Непосредственно производством чипов ARM не занимается, предлагая вместо этого интеллектуальную собственность. Как и другие мобильные видеокарты, Mali является составной частью System on Chip(SoC), т.е. работает с общей для CPU и GPU памятью и шиной.

Mali Utgard

В 2008 году на свет появились первые представители архитектуры Mali Utgard, актуальной вплоть до сегодняшнего дня. Эти видеокарты именуются по схеме Mali-4xx MPn, где xx — номер модельного ряда, а n — количество фрагментных ядер. В Mali Utgard шейдерные ядра специализированные, и во всех моделях устанавливалось только 1 вершинное ядро.

Другие особенности архитектуры Mali Utgard:

• OpenGL ES 2.0
• Отсутствие поддержки highp во фрагментных ядрах
• Векторный набор инструкций (есть смысл векторизировать вычисления)

Невзирая на спецификацию OpenGL ES, драйвера видеокарт Mali Utgard успешно компилируют фрагментные шейдеры, где используется точность highp (например, точность задана по умолчанию при помощи precision highp float). Но фактически используется точность mediump. Поэтому, все шейдеры для мобильных игр желательно дополнительно тестировать на таких видеокартах. По данным, собираемым Unity, на конец 2019 года Mali Utgard работала на девайсах у около 10% игроков. А если выставить соответствующие фильтры на market.yandex.ru, то можно увидеть, что в 2019 году было анонсировано более 10 новых телефонов с видеокартами этой архитектуры.

Если имеется готовность отказаться от этой аудитории, достаточно установить требование поддержки OpenGL ES 3.0 в AndroidManifest.xml:

Кроме Mali Utgard, распространенных мобильных GPU без поддержки OpenGL ES 3.0 на данный момент нету.

Отдельного внимания заслуживает использование текстур большого разрешения на Mali Utgard. Десять бит мантиссы при точности mediump не хватает для качественного текстурирования с разрешением текстур более 1024 на одну из сторон. Однако, несмотря на поддержку только mediump точности вычислений во фрагментных ядрах Mali Utgard, можно получить fp24 точность текстурных координат при использовании varying напрямую.

В качестве бонуса на некоторых архитектурах такой подход позволяет осуществлять prefetch текстурного содержимого до выполнения fragment shader, что минимизирует stalls при ожидании результатов текстурных выборок.

Mali Midgard

На смену Mali Utgard пришла архитектура Mali Midgard. Существует несколько поколений этой архитектуры с названиями вида Mali-6xx, Mali-7xx и Mali-8xx. Несмотря на 8-летний возраст, Mali Midgard можно назвать современной архитектурой, обеспечивающей поддержку большинства новых фич:

• унифицированные шейдерные ядра
• OpenGL ES 3.2 (compute & geometry shaders, tesselation. )

Однако в Mali Midgard сохранена векторная ISA. Учитывая широкое распространение Mali Midgard (около 25% нашей аудитории), становится целесообразной векторизация вычислений.

Еще одной особенностью Mali Midgard является технология Forward Pixel Kill. Расчет каждого пикселя производится в отдельном потоке фрагментного ядра. Если во время выполнения потока становится известно, что результирующий пиксель будет перекрыт непрозрачным пикселем другого примитива, поток завершается преждевременно и освободившиеся ресурсы используются для других вычислений.

Mali Bifrost

Следующая за Midgard архитектура Bifrost выделяется переходом к скалярной ISA. По сравнению с предыдущей архитектурой увеличено максимальное количество ядер (с 16 до 32), а также поддерживается улучшенный интерфейс с CPU, позволяющий осуществлять когерентный доступ к общей памяти: изменения содержимого памяти CPU/GPU сразу становятся «видны» друг другу несмотря на кэши, что позволяет упростить синхронизацию.

Из неофициального

Предпринято немало попыток обратного инжиниринга видеокарт Mali с целью создания Open Source драйверов под Linux. Труды самоотверженных ребят, пытающихся это осуществить, позволяют взглянуть на недокументированные особенности видеокарт Mali. Так, в проекте PanFrost есть disassembler для Mali Midgard/Bifrost, при помощи которого можно познакомится с набором шейдерных инструкций (открытой официальной информации на эту тему нет).

Adreno

Вторым по распространенности семейством мобильных GPU является Adreno. Эта видеокарта устанавливается на SoC, известный под брендом Snapdragon, от американской компании Qualcomm. Snapdragon устанавливается в топовых смартфонах современности от Samsung, Sony и др.

Актуальными видеокартами Adreno являются семейства cерий 3xx — 6xx. Все эти серии объединяют следующие особенности:

• унифицированные шейдерные ядра
• Pseudo TBR (большие размеры тайлов, размещающиеся в традиционной dedicated GPU memory)
• Автоматическое переключение в Immediate Mode Rendering в зависимости от характера сцены (FlexRender)
• Скалярный набор инструкций

Начиная с Adreno 4xx появляется поддержка OpenGL ES 3.1, а с Adreno 5xx — Vulkan и OpenGL ES 3.2.

Adreno Tile Based Rendering

На видеокарты Adreno установлена «традиционная» GPU память, называемая GMEM. Применяются объемы от 128kb до 1536kb. Это позволяет использовать больший размер тайлов по сравнению с архитектурами других разработчиков мобильных GPU. На Adreno размер тайлов динамический и зависит от используемого формата цвета, буфера глубины и трафарета. При работе в режиме Immediate Mode рендер происходит в системную память.Существует GL ES расширение, позволяющее указать предпочтительный режим: QCOM_binning_control. Однако, последние рекомендации от Qualcomm предлагают полностью полагаться на драйвера GPU, которые сами определяют наиболее предпочтительный режим для сформированного приложением командного буфера.

При работе в режиме TBR Adreno делает 2 вершинных прохода:

1. Binning pass — распределение примитивов по бинам (bins, синоним тайлов)
2. Полноценный vertex pass для отрисовки только тех примитивов, которые попадают в текущий Bin

Во время Binning pass Adreno рассчитывает только позиции вершин. Другие атрибуты не вычисляются, а ненужный код удаляется оптимизатором. В официальной документации (9.2 Optimize vertex processing) существует рекомендация хранить вершинную информацию, необходимую для вычисления позиций, отдельно от остальных данных. Это делает кеширование вершинных данных более эффективным.

Freedreno

В отличие от ARM и Imagination Technologies, Qualcomm неохотно делится подробностями внутреннего устройства своих GPU. Однако, благодаря усилиям «обратного инженера» Роба Кларка, многое можно узнать из проекта Freedreno, open source драйвера Adreno для Linux.

Rob Clark, автор Freedreno

PowerVR от Imagination Technologies

Imagination Technologies — британская fabless компания, знаменитая разработкой GPU для продукции Apple. Эту роль компания выполняла вплоть до появления iPhone 8/X, в которых используются внутренние разработки Apple. Хотя по оставшимся без изменений рекомендациям по оптимизациям для этих чипов, а также по наличию патентных исков к Apple от Imagination можно предполагать, что Apple продолжила развивать архитектуру PowerVR — оригинальную разработку от Imagination. В начале 2020 года Apple вернулась к практике лицензирования у Imagination Technologies. Кроме устройств с iOS/iPadOS, видеокарты PowerVR устанавливаются в большое количество смартфонов и планшетов на базе Android.

Рассмотрим семейства видеокарт PowerVR, которые до сих пор можно встретить у пользователей.

PowerVR SGX

Первые видеокарты PowerVR SGX появились в далеком 2009-м году. Существует несколько поколений этой архитектуры: Series5, Series5XT и Series5XE. Apple использовала эти GPU вплоть до iPAD 4/iPhone 5/iPOD Touch 5. Можно привести такие особенности SGX:

• унифицированные шейдерные ядра
• OpenGL ES 2.0
• векторный набор инструкций
• поддержка 10-битной точности lowp в шейдерах
• низкая производительность зависимых текстурных выборок (dependent texture reads)

Остановимся на некоторых из них подробнее.

Lowp точность

PowerVR SGX — единственные актуальные мобильные GPU с аппаратной поддержкой
lowp. Более новые модели PowerVR, а также все современные GPU других вендоров фактически используют точность mediump. Использование
lowp на PowerVR SXG позволяет добиться более высокой плотности вычислений (больше операций за такт). При этом операция swizzle (перестановка компонент вектора) для lowp, в отличие от других точностей, не является бесплатной. Эта особенность, а также узкий диапазон значений, который предоставляет lowp ([-2,2]) ограничивает сферу ее применения. При этом неудачно поставленный lowp, приводящий к артефактам на семействе SGX, не будет замечен на всех остальных видеокартах, где фактически будет использоваться точность mediump. По этой причине стоит рассмотреть отказ от использования lowp в шейдерах.

Зависимые текстурные выборки (dependent texture reads)

Как известно, операции сэмплирования текстур являются наиболее медленными из-за необходимости ожидания результатов чтения памяти. В случае мобильных SoС речь идет об общей системной памяти с CPU. Для уменьшения количества обращений к медленной памяти используются текстурные кеши. Чтобы не было простоя в начале растеризации с использованием текстуры, есть смысл закешировать используемые участки заранее. Если фрагментный шейдер использует текстурную координату, передаваемую из вершинного шейдера без изменений, то необходимый для кэширования участок текстуры можно определить до выполнения фрагментного шейдера. Если же фрагментный шейдер меняет текстурную координату либо вычисляет ее, используя данные из другой текстуры, то сделать это не всегда возможно. В результате выполнение фрагментного шейдера может замедлиться. Видеокарты PowerVR SGX особенно «болезненно» реагируют на такой сценарий. При этом даже использование перестановки компонент текстурной координаты (swizzle) приводит к dependent texture read. Приведем пример shader program без dependent texture read.

vertex program

fragment program

fragment program

PowerVR Rogue

Дальнейшее развитие видеокарты PowerVR получили в архитектуре Rogue.Существует несколько поколений этой архитектуры: от Series6 до Series9. У всех PowerVR Rogue есть такие особенности:

• унифицированные шейдерные ядра
• скалярная архитектура инструкций
• поддержка OpenGL ES 3.0+ (вплоть до 3.2, а также Vulkan API у свежих линеек)

PowerVR TBDR

Как и во всех распространенных мобильных GPU, в PowerVR используется тайловый конвейер. Но в отличие от конкурентов, Imagination пошла дальше и реализовала отложенную растеризацию примитивов, позволяющую пропускать шейдинг невидимых пикселей независимо от порядка отрисовки. Такой подход получил название Tile Based Deferred Rendering,а процесс устранения невидимых пикселей — Hidden Surface Removal (HSR).

Hidden Surface Removal

Рекомендуется рисовать непрозрачную геометрию до прозрачной и не использовать Z Prepass, который в случае видеокарт PowerVR в большинстве сценариев приведет к лишней работе. Однако несколько подряд идущих прозрачных пикселей, перекрывающих друг друга, полностью шейдятся для получения корректного цвета с учетом смешивания. Последний же прозрачный пиксель может быть отброшен, если за ним следует непрозрачный пиксель.

Открытость Imagination Technologies

Создатели PowerVR предоставили в открытый доступ больше документации по сравнению с другими разработчиками GPU. Детально описана архитектура графического конвейера, а также набор инструкций для архитектуры Rogue. Существует удобный инструмент PVRShaderEditor, позволяющий на лету получать профилировочную информацию по шейдеру, а также его дизассемблерный листинг для Rogue.

Несмотря на ограниченное присутствие видеокарт PowerVR в среде устройств на базе Android, есть смысл изучать их архитектуры для грамотного программирования графики под iOS.

Immediate mode mobile GPUs

Мы рассмотрели наиболее распространенные семейства мобильных видеокарт. Во всех этих семействах применялась тайловая архитектура рендера. Однако существуют мобильные видеокарты, в которых используется и традиционный immediate mode подход. Приведем некоторые из них:

• nVIdia (Tegra SoC)
• Все семейство Intel, кроме последних Gen 11
• Vivante GCxxxx (+Arcturus GC8000)

Особенностью мобильных видеокарт, работающих в immediate mode, является дорогая операция очистки FBO. Напомним, что на тайловой архитектуре полноэкранная очистка ускоряет рендер, позволяя драйверу не добавлять Load операцию старого содержимого в тайловую память. На мобильных immediate mode GPU полноэкранная очистка — ощутимая по времени операция, позволяющая, кроме прочего, такие GPU «вычислить». Если добавление очистки не ускоряет, а замедляет рендер, то, скорее всего, мы работаем с immediate mode GPU. Ну и, конечно, не забудем упомянуть о том, что на immediate mode GPUs смена таргета — «условно бесплатная» процедура.

Распределение различных семейств мобильных GPU у наших игроков

Приведем статистику по мобильным GPU, собранную у наших игроков на конец 2019 года:

Ниже раскроем сегмент «Others»

Исходя из этих данных, посмотрим на распределение GPU с точки зрения их основных особенностей.

Векторные ALU (arithmetic logic unit) устаревают и заменяются скалярными. На сегодня основная масса мобильных GPU с векторным набором инструкций — это Mali Midgard, который можно считать средним по производительности. Т.к. векторизация, как правило, не замедляет выполнение на скалярных ALU, стоит рассматривать векторизацию как актуальный прием оптимизации шейдеров под mobile.

Специализированные шейдерные ядра устарели и заменяются унифицированными. Vertex Bottleneck на скелетном меше более не страшен. Специализированные ядра используются только на семействе Mali-4xx (Utgard). Напомним, что эти GPU поддерживают только OpenGL ES 2.0. У нашей аудитории их около 3.5%.

И наконец, подавляющее количество мобильных GPU используют тайловый подход. Immediate Mode стал маргинальным и быстро вытесняется вместе с видеокартами, его применяющими. Доля immediate mode GPUs у наших игроков составляет около 0.7%.

Источник