Графический api что это
Предисловие и условия
реклама
Данная статья отпочковалась от другой статьи, ссылка на статью:
Я сомневаюсь что данный материал будет интересен большинству обычных пользователей, здесь не будет фотографий видеокарт, как логотипы подсвечиваются, графики с FPS в играх и т.п., здесь будет очень много текста, но очень мало слов.
Если вам интересно посмотреть «изнутри» как обстоят дела с графическими (и не очень) API, то добро пожаловать.
реклама
Я не стану в пределах данной статьи разбирать каждое расширение до последнего бита, но поверхностно я постараюсь наглядно выделить разницу.
Условия:
Результаты
Результаты были собраны утилитой GPU Caps Viewer версии 1.50.0.0, сбор информации был проведен в текстовый файл, именно из этого файла я и буду брать данные, по сути там повторяется всё, что отображается в окне самой программы.
OpenGL
Общая информация:
реклама
Расширенная информация:
SPIR-V расширения:
реклама
OpenGL расширения:
Расширения присутствующие в обоих драйверах (272 расширения):
Расширения присутствующие только в драйвере AMD (55 расширений):
Расширения присутствующие только в драйвере nVidia (149 расширений):
OpenGL core capabilities:
OpenGL extension capabilities:
OpenCL
Vulkan
Я не придумал ничего умнее чем некоторую информацию представить скриншотом:
Vulkan Instance extensions:
Vulkan extensions:
Vulkan device features:
Vulkan device limits:
Выводы
Кто-то скажет — безумие, и возможно будет прав, но как иначе сравнивать если даже не видел то, что собираешься сравнить?
Я старался в минимальный объем всё поместить, но даже так, количество текста оказалось на десятки тысяч символов, разбивать на несколько частей не вижу целесообразным, статья имеет конкретную тематику.
Мне пришлось перенести основную массу информации в изображения, просто чтобы хоть как-то сделать размер статьи адекватнее.
Возможности:
Можно заметить, что в разных API некоторые возможности совпадают, например «CL_DEVICE_MAX_WORK_ITEM_SIZES» из OpenCL и «Threads Per Block» из CUDA имеют одинаковые ограничения.
Еще можно заметить «maxImageDimensionXX» из Vulkan и «GL_MAX_TEXTURE_SIZE » из OpenGL, а так же ряд других аналогичных параметров имеют одинаковые ограничения, и они судя по всему обусловлены архитектурой видеокарт.
Я думаю многие люди как минимум слышали про такую игру как Minecraft, а некоторые еще и с одной интересной проблемой вероятно сталкивались, когда применяешь текстурпак (ресурспак) и он крашит игру с видеокартой от AMD, но в паре с видеокартой от nVidia все работает, как так?
Возможно некоторые уже заметили такие ограничения как «GL_MAX_TEXTURE_SIZE», просто создатели ресурспака порой не учитывают (а может специально. ) разные ограничения у nVidia и AMD, и в итоге рождаются листы текстур размером 1024х20480 (и другие вариации), для анимации лавы или воды в игре, естественно такие текстуры не входят в лимит 16384 и Minecraft благополучно падает с видеокартой от AMD, когда с видеокартой от nVidia все нормально т.к. лимит 32768.
Надеюсь достаточно понятно объяснил как могут влиять ограничения, это был конечно лишь один пример, но в целом сложно сказать у кого лучше обстоят дела с ограничениями.
Очень многое зависит от конкретных случаев и разработчиков, одной лишь манипуляцией с размером текстур можно заставить работать игру только на видеокартах от nVidia, даже если эту текстуру никогда никто не увидит, и она будет размером всего 2х20480.
Расширения:
Очевидно количество расширений на стороне nVidia, хотя у AMD я заметил несколько расширений «GOOGLE_», что показалось мне довольно забавным.
Единственное, где большинство расширений оказалось на стороне AMD это OpenCL, причем у nVidia выделяются расширения «NV_», некоторые имеют одинаковые имена с расширениями «KHR_».
Хотя ради справедливости nVidia наштамповала 89 «GL_NV_» расширений, когда за AMD числится лишь 29 «GL_AMD_» расширений и 5 «GL_ATI_», естественно без учета расширений которые поддерживаются как AMD, так и nVidia.
А еще отмечу что в OpenCL у AMD есть «cl_khr_fp16» расширение (вычисления с половинной точностью), но отсутствует у nVidia, хотя в Vulkan расширение «VK_KHR_shader_float16_int8» есть у AMD и nVidia.
Версии API:
Несмотря на меньшее количество расширений у AMD, версии таких API как Vulkan, OpenCL и OpenGL выше чем у nVidia, и больше добавить нечего.
Заключение:
Я не знаю что еще добавить интересного для людей которые видят во всей массе статьи лишь набор символов и цифр.
Люди которым нужна будет данная информация вполне вероятно обойдутся и без выводов, что я написал.
Видеодрайверы взаимодействуют непосредственно с API (ликбез).
Видеодрайверы взаимодействуют непосредственно с API (ликбез).
Правильная и полнофункциональная работа современного графического адаптера обеспечивается с помощью видеодрайвера — специального программного обеспечения, поставляемого производителем видеокарты и загружаемого в процессе запуска операционной системы. Видеодрайвер выполняет функции интерфейса между системой с запущенными в ней приложениями и видеоадаптером. Так же как и видео-BIOS, видеодрайвер организует и программно контролирует работу всех частей видеоадаптера через специальные регистры управления, доступ к которым происходит через соответствующую шину. Программный драйвер является одним из важнейших элементов видеосистемы, с помощью которого осуществляется связь программного обеспечения с видеокартой. Видеокарта может быть оснащена самым быстрым процессором и наиболее эффективной памятью, но плохой драйвер способен свести на нет все эти преимущества. Видеодрайверы используются для поддержки процессора видеоадаптера. Несмотря на то, что видеокарты поставляются изготовителем вместе с драйверами, иногда используются драйверы, поставляемые вместе с набором микросхем системной логики.
Хотя производители видеоадаптеров поддерживают стандарт OpenGL, компания Microsoft предоставляет поддержку Direct3D для более комплексного API, называемого DirectX.
С DirectX 9 и выше, и последними версиями программного интерфейса, значительно расширина поддержка трехмерной графики обеспечившей улучшенные игровые возможности. Для получения дополнительной информации относительно DirectX или загрузки его последней версии можно обратиться на Web-узел DirectX компании Microsoft.
Видеодрайверы используются для поддержки процессора видеоадаптера. Несмотря на то, что видеокарты поставляются изготовителем вместе с драйверами, иногда используются драйверы, поставляемые вместе с набором микросхем системной логики. Желательно использовать драйверы, поставляемые производителем адаптера.
IM состоит из тонкого уровня, который взаимодействует с аппаратурой и обеспечивает самое высокое быстродействие.
Отношения между аппаратным, программным обеспечением и DirectX можно продемонстрировать следующей схемой:
Обновление DirectX можно выполнять независимо от операционной системы. DirectX состоит из «основного» слоя, который обеспечивает доступ к звуковым устройствам, устройствам двухмерной и трехмерной графики, устройствам ввода и процедурам установки.
Сейчас поколения ускорителей в видеокартах можно считать по версии DirectX, которую они поддерживают. Различают следующие поколения:
— DirectX 7 — карта не поддерживает шейдеры, все картинки рисуются наложением текстур;
— DirectX 8 — поддержка пиксельных шейдеров версий 1.0, 1.1 и 1.2, в DX 8.1 ещё и версию 1.4, поддержка вершинных шейдеров версии 1.0;
— DirectX 9 — поддержка пиксельных шейдеров версий 2.0, 2.0a и 2.0b, 3.0;
— DirectX 10 — поддержка унифицированных шейдеров версии 4.0;
— DirectX 10.1 — поддержка унифицированных шейдеров версии 4.1;
— DirectX 11 — поддержка унифицированных шейдеров версии 5.0;
— DirectX 12 — поддержка унифицированных шейдеров версии 6.0.
С выходом DirectX 11 и появлением модели поддержки API Feature Level (FLxx), видеокарты в большинстве своем перестали быть привязаны к конкретной версии DirectX.
Версия OpenGL обозначает то, какие операции графического ускорения поддерживает данная графическая карта:
— OpenGL 1.1 — Объекты текстур;
— OpenGL 1.2 — 3D-текстуры, форматы BGRA и упакованных пикселей;
— OpenGL 1.3 — Мультитекстурирование, multisampling, сжатие текстур;
— OpenGL 1.4 — Текстуры глубины;
— OpenGL 1.5 — VBO, Occlusion Querys;
— OpenGL 2.0 — GLSL 1.1, MRT, текстуры с размерами, не являющимися степенью двойки, Point Sprites, Two-sided stencil;
— OpenGL 2.1 — GLSL 1.2, Pixel Buffer Object (PBO), текстуры sRGB;
— OpenGL 3.1 — GLSL 1.4, Instancing, Texture Buffer Object, Uniform Buffer Object, Primitive restart;
— OpenGL 3.2 — GLSL 1.5, Geometry Shader, Multi-sampled textures Buffer Object: FBO (Frame), VBO (Vertex), PBO (Pixel), Texture, Uniform;
— OpenGL 4.0 — GLSL 4.00, Тесселяция на GPU, шейдеры с 64-битной точностью.
Графические API высокого и низкого уровня: различия и принцип работы
Следует учитывать, что графические процессоры не выполняют программы, а выполняют список инструкций. Но откуда взялся этот список и как он попадает в GPU?
Что такое графический API?
Упомянутый список экранов считывается программным обеспечением, которое является не чем иным, как драйвером видеокарты, это преобразует список в микрокод, который может понять графический процессор, и копирует его в часть Оперативная память память, к которой всегда обращается графический процессор. Чтобы прочитать список экранов, скопируйте список во внутреннюю память командных процессоров и начните рендеринг сцены или ее части с помощью инструкций из списка экранов.
Этот процесс выполняется непрерывно в каждом кадре, который графический процессор обрабатывает и отправляет на экран, независимо от того, используете ли вы игровой ПК, смартфон или игровую приставку.
Какие графические API существуют сегодня?
Вычисления против графики
В настоящее время приложения отправляют не один список, а несколько списков, один из которых является графикой, а остальные вычисления, где графический процессор используется для решения конкретных проблем, которые не имеют ничего общего с визуализацией графики, причем последние работают полностью асинхронно. и, следовательно, не зависит от списка экранов.
Например, может случиться так, что приложение графического дизайна использует мощность графического процессора для создания специального эффекта на фотографии только потому, что графический процессор лучше оборудован для решения этой проблемы, чем графический процессор. ЦП. Благодаря спискам вычислений вы можете сделать это, используя бесплатные ресурсы графического процессора для решения этих небольших проблем.
Графические API высокого и низкого уровня: чем они отличаются?
На самом деле неверно, что низкоуровневым API-интерфейсам не хватает драйвера, поскольку его можно читать и прослушивать в некоторых местах, но это намного проще и усложняет работу при выполнении некоторых важных задач в приложении, это позволит разработчикам максимально оптимизируйте синхронизацию каждого кадра, контролируя процесс создания списка экранов.
Однако во многих случаях для разработчиков может быть намного удобнее использовать высокоуровневый API из-за того, что дополнительное время разработки не окупается с финансовой точки зрения или просто потому, что выгода, которую можно получить за счет адаптации игры к API низкий уровень незаметен.
Миф о консоли и ПК
Существует миф о том, что, поскольку консоль имеет уникальное оборудование, это означает, что API-интерфейсы гораздо более оптимизированы, чем на ПК, где существует множество различных конфигураций, но на самом деле это драйвер, который мы установили, создает список экранов. Разница в том, что в консолях этот драйвер статичен и не получает обновлений производительности или изменений в течение всего коммерческого срока службы консоли.
Vulkan. Руководство разработчика. Краткий обзор
Я работаю техническим переводчиком ижевской IT-компании CG Tribe, которая предложила мне внести свой вклад в сообщество и начать публиковать переводы интересных статей и руководств.
Здесь я буду публиковать перевод руководства к Vulkan API. Ссылка на источник — vulkan-tutorial.com. Поскольку переводом этого же руководства занимается еще один пользователь Хабра — kiwhy, мы договорились разделить уроки между собой. В своих публикациях я буду давать ссылки на главы, переведенные kiwhy.
9. Загрузка моделей
10. Создание мип-карт
FAQ
Политика конфиденциальности
1. Вступление
2. Краткий обзор
Предпосылки возникновения Vulkan
Как и предыдущие графические API, Vulkan задуман как кроссплатформенная абстракция над GPU. Основная проблема большинства таких API заключается в том, что в период их разработки использовалось графическое оборудование, ограниченное фиксированным функционалом. Разработчики должны были предоставить данные о вершинах в стандартном формате и в плане освещения и теней полностью зависели от производителей графических процессоров.
По мере развития архитектуры видеокарт в ней стало появляться все больше программируемых функций. Все новые функции необходимо было каким-то образом объединить с существующими API. Это привело к неидеальным абстракциям и множеству гипотез со стороны графического драйвера о том, как воплотить замысел программиста в современных графических архитектурах. Поэтому для повышения производительности в играх выпускается большое количество обновлений драйверов. Из-за сложности таких драйверов среди поставщиков часто возникают расхождения, например, в синтаксисе, принятом для шейдеров. Помимо этого, в последнее десятилетие также наблюдался приток мобильных устройств с мощным графическим оборудованием. Архитектуры этих мобильных GPU могут сильно отличаться в зависимости от требований по размерам и энергопотреблению. Одним из таких примеров является тайловый рендеринг, который может дать большую производительность за счет лучшего контроля над функционалом. Еще одним ограничением, связанным с возрастом API, является ограниченная поддержка многопоточности, что может привести к появлению узкого места со стороны ЦП.
Vulkan помогает решить эти проблемы, поскольку изначально создан для современных графических архитектур. Это снижает потери на стороне драйвера за счет того, что разработчики могут четко описать свои цели с помощью подробного API. Vulkan позволяет параллельно создавать и отсылать команды в нескольких потоках. Также снижаются расхождения компиляции шейдеров за счет перехода на стандартизованный формат байтового кода и использования одного компилятора. И наконец, Vulkan реализует главную возможность современных видеокарт, объединяя графические и вычислительные возможности в едином API.
Как нарисовать треугольник?
Мы кратко рассмотрим шаги, необходимые для отрисовки треугольника. Это позволит вам получить общее представление о процессе. Подробное описание каждой концепции будет дано в следующих главах.
Шаг 1 — Экземпляр (instance) и физические устройства
Работа с Vulkan начинается с настройки Vulkan API через VkInstance (экземпляр). Экземпляр создается с помощью описания вашей программы и всех расширений, которые вы хотите использовать. После создания экземпляра вы можете запросить, какое оборудование поддерживает Vulkan, и выбрать один или несколько VkPhysicalDevices для выполнения операций. Вы можете сделать запрос по таким параметрам, как размер VRAM и возможности устройств, чтобы выбрать желаемые устройства, если вы предпочитаете использовать специализированные видеокарты.
Шаг 2 — Логическое устройство и семейства очередей
После того, как вы выберете подходящее hardware устройство для использования, вам необходимо создать VkDevice (логическое устройство), где вы более подробно опишете, какие возможности (VkPhysicalDeviceFeatures) будете использовать, например, рендеринг в несколько viewport-ов (multi viewport rendering) и 64-битные числа с плавающей точкой. Вам также необходимо установить, какие семейства очередей вы бы хотели использовать. Многие операции, совершаемые с помощью Vulkan, например, команды рисования и операции в памяти, выполняются асинхронно после отправки в VkQueue. Очереди выделяются из семейства очередей, где каждое семейство поддерживает определенный набор операций. Например, для операций с графикой, вычислительных операций и передачи данных памяти могут существовать отдельные семейства очередей. Кроме того их доступность может использоваться в качестве ключевого параметра при выборе физического устройства. Некоторые устройства с поддержкой Vulkan не предлагают никаких графических возможностей, однако, все современные видеокарты с поддержкой Vulkan, как правило, поддерживают все необходимые нам операции с очередями.
Шаг 3 — Window surface и цепочки показа (swap chain)
Если вас интересует не только внеэкранный рендеринг, вам необходимо создать окно для отображения отрендеренных изображений. Окна можно создать с помощью API исходной платформы или библиотек, таких как GLFW и SDL. В руководстве мы будем использовать GLFW, подробнее о которой мы расскажем в следующей главе.
Цепочка показа — это набор целей рендеринга. Ее задача — обеспечивать, чтобы изображение, которое рендерится в текущий момент, отличалось от отображаемого на экране. Это позволяет отслеживать, чтобы отображались только готовые изображения. Каждый раз, когда нам нужно создать кадр, мы должны сделать запрос, чтобы цепочка показа предоставила нам изображение для рендеринга. После того, как кадр создан, изображение возвращается в цепочку показа, чтобы в какой-то момент отобразиться на экране. Количество целей рендеринга и условий для отображения готовых изображений на экране зависит от текущего режима. Среди таких режимов можно выделить двойную буферизацию (vsync) и тройную буферизацию. Мы рассмотрим их в главе, посвященной созданию цепочки показа.
Некоторые платформы позволяют рендерить непосредственно на экран через расширения VK_KHR_display и VK_KHR_display_swapchain без взаимодействия с каким-либо менеджером окон. Это позволяет создать surface, которая представляет собой весь экран и может использоваться, например, для реализации вашего собственного менеджера окон.
Шаг 4 — Image views и фреймбуферы
Чтобы рисовать в изображение (image), полученное из цепочки показа, мы должны обернуть его в VkImageView и VkFramebuffer. Image view ссылается на определенную часть используемого изображения, а фреймбуфер ссылается на image views, которые используются как буферы цвета, глубины и шаблонов (stencil). Поскольку в цепочке показа может быть множество разных изображений, мы заранее создадим image view и фреймбуфер для каждого из них и выберем необходимое изображение во время рисования.
Шаг 5 — Проходы рендера
Проходы рендера в Vulkan описывают тип изображений, используемых во время операций рендеринга, то, как они используются, и то, как необходимо обрабатывать их содержимое. Перед отрисовкой треугольника мы сообщим Vulkan, что мы хотим использовать одиночное изображение в качестве буфера цвета и что нам нужно очистить его перед рисованием. Если проход рендера описывает только тип изображений, используемых в качестве буферов, то VkFramebuffer фактически связывает определенные изображения с этими слотами.
Шаг 6 — Графический конвейер (pipeline)
Графический конвейер в Vulkan настраивается с помощью создания объекта VkPipeline. Он описывает конфигурируемое состояние видеокарты, например, размер viewport или операцию буфера глубины, а также программируемое состояние, используя объекты VkShaderModule. Объекты VkShaderModule создаются из байтового кода шейдера. Драйверу также необходимо указать, какие цели рендеринга будут использоваться в конвейере. Мы задаем их, ссылаясь на проход рендера.
Одна из наиболее отличительных особенностей Vulkan по сравнению с существующими API-интерфейсами заключается в том, что почти все системные настройки графического конвейера должны задаваться заранее. Это значит, что если вы хотите переключиться на другой шейдер или немного изменить vertex layout, вам необходимо полностью пересоздать графический конвейер. Поэтому вам придется заранее создать множество объектов VkPipeline для всех комбинаций, необходимых для операций рендеринга. Только некоторые базовые настройки, такие как размер viewport и цвет очистки, могут быть изменены динамически. Все состояния должны быть описаны явно. Так, например, не существует смешивания цветов (color blend state) по умолчанию.
К счастью, поскольку процесс больше напоминает опережающую компиляцию, вместо компиляции «на лету», у драйвера появляется больше возможностей для оптимизации, а производительность оказывается более предсказуемой, так как значительные изменения состояния, например, переключение на другой графический конвейер, указываются явно.
Шаг 7 — Пул команд и буферы команд
Как уже было сказано, многие операции в Vulkan, например операции рисования, должны быть отправлены в очередь. Прежде чем отправить операции, их необходимо записать в VkCommandBuffer. Буферы команд берутся из VkCommandPool, который связан с определенным семейством очередей. Чтобы нарисовать простой треугольник, нам нужно записать буфер команд со следующими операциями:
Шаг 8 — Основной цикл
Этот краткий обзор позволяет получить общее представление о предстоящей работе по рисованию вашего первого треугольника. В реальности же шагов гораздо больше. Среди них выделение буферов вершин, создание uniform-буферов и загрузка изображений текстур — все это мы рассмотрим в следующих главах, а пока начнем с простого. Чем дальше мы будем двигаться, тем сложнее будет материал. Обратите внимание, что мы решили пойти хитрым путем, изначально встраивая координаты вершины в вершинный шейдер вместо использования буфера вершин. Такое решение связано с тем, что для управления буферами вершин сначала требуется знакомство с буферами команд.
Подведем краткий итог. Для отрисовки первого треугольника нам необходимо:
Концепты API
В заключение к текущей главе будет приведен краткий обзор того, как структурируются Vulkan API на более низком уровне.
Стандарт оформления кода
Как уже было сказано, Vulkan был разработан для обеспечения высокой производительности при низких нагрузках на драйвер. Поэтому он включает в себя очень ограниченные возможности автоматического обнаружения и исправления ошибок. Если вы сделаете ошибку, драйвер даст сбой или еще хуже, продолжит работать на вашей видеокарте, но выйдет из строя на других видеокартах.
Поэтому Vulkan позволяет запускать расширенные проверки с помощью функции, известной как слои валидации. Слои валидации — это фрагменты кода, которые могут быть вставлены между API и графическим драйвером для выполнения дополнительных проверок параметров функций и отслеживания проблем по управлению памятью. Это удобно тем, что вы можете запустить их во время разработки, а затем полностью отключить при запуске программы без дополнительных затрат. Любой пользователь может написать свои собственные слои валидации, но Vulkan SDK от LunarG предоставляет стандартный набор, который мы будем использовать в руководстве. Вам также необходимо зарегистрировать функцию обратного вызова для получения сообщений отладки от слоев.
Поскольку операции в Vulkan расписываются очень подробно, и слои валидации достаточно обширные, вам будет намного проще установить причину черного экрана по сравнению с OpenGL и Direct3D.
Остался всего один шаг, прежде чем мы начнем писать код, и это — настройка рабочей среды.