Vulkan API, Framebuffers

Ну и предлагаю вам почитать превод последней части главы "Render Pass" спецификации, в которой рассказывается об еще одном фундаментальном понятии Вулкана - Framebuffers, они же буферы кадра или фреймбуферы. 

Vulkan API, Render Pass

Render Pass

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

Vulkan, еще раз о синхронизации...

Наконец-то я закончил перевод этого здоровенного и не менее важного куска спецификации. О том, что я думаю об авторе этого раздела спецификации я уже писал много, потому я просто счастлив что это осталось позади (хотя кто знает что еще меня ждет впереди))

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

Vulkan API. Memory Barriers and Implicit Ordering Guarantees.

Вот я и добрался до последней главы раздела "Synchronization and Cache Control", перевод этого раздела оказался достаточно "стремным", как вообщем-то и текст оригинала. После этой статьи я приведу еще одну итоговую, где постараюсь в сжатом виде пересказать содержание последних серий, ну а пока - Memory Barriers и Implicit Ordering Guarantees.

Vulkan API, Barriers, Execution And Memory Dependencies.

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

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

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

Vulkan Renderpasses

Переводя следующую главу спецификации я столкнулся с несколькими проблемами.

По всей видимости, начиная с главы "6.4 Execution And Memory Dependencies", у спецификации поменялся автор - два слова связать не может, постоянно пережовывает одно и тоже, сплош и рядом тафтология, предложения закручивает так, что и 100-грамм не помогает, вообщем текст ужасный, местами я при перечитывании переведенного просто удалял целые абзацы, заменяя их одной фразой.

Но это пол-беды, не знаю кто виноват, этот же автор или еще кто, но в этой главе явно нарушен порядок изложения материала (да, я понимаю что это спецификация, но все же), вначале разжовываются сценарии, а только через пару глав рассказывается что же такое эти dependency, renderpass, subpass, pipeline stages и многое другое. В результате теряется суть написанного и весь перевод главы становится абсолютно бессмысленным.

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

Стоило мне принять это решение как тут же попалась статья от AMD по этим самым renderpass-ам, с которых и начнется повествование.

Vulkan API, Synchronization primitives, Events.

Продолжение перевода 6 главы - Synchronization and Cache Control, в этот раз рассмотрим третий тип синхронизации - события(Events).

Предыдущие части можно посмотреть здесь:

Vulkan API, Synchronization primitives, Fences.

Vulkan API, Synchronization primitives, Semaphores

Vulkan API, Synchronization primitives, Semaphores

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

Vulkan API, Synchronization primitives, Fences.

Одним из ключевых изменений, произошедших в Вулкане, стало ручное управление потоками команд, что с одной стороны - позволило существенно снизить нагрузку на CPU, с другой - требует понимания принципов многопоточного программирования. Важнейшим инструментов многопоточного програмирования являются примитивы синхронизации. Вулкан предоставляет 4 типа таких примитивов, в этой части мы рассмотрим первый из них - Fences.

Vulkan API, Command Buffers

Признаться, начинал я переводить эту главу нехотя, во-првых - она очень большая :)

Во-вторых - на этом месте все туториалы делают большой прыжок и минуя эту главу начинают создавать поверхность рендеринга, фреймбуфер и прочее. Был и у меня такой соблазн, темболе что предыдущие главы были достаточно простыми. Однако я себя пересилил и думал правильно сделал. Тут как никогда подходит выражение - "чем дальше в лес тем больше дров", количество понятий, новых терминов, нюансов использования и связей с другими объектами здесь просто зашкаливает. Боюсь к этой статье придется возвращаться еще не раз, так как на этом этапе нужно начинать планировать всю архитектуру вашего приложения, причем в таких деталях, что аж мурашки по коже :) Без этого ваше приложение будет работать, но эффективность его будет на уровне вызовов glBegin/glEnd на фоне дисплейных списков. Вообщем скоро вы сами все поймете :)

Vulkan API, Queues.

Queues. Queue Family Properties

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