Ну и предлагаю вам почитать превод последней части главы "Render Pass" спецификации, в которой рассказывается об еще одном фундаментальном понятии Вулкана - Framebuffers, они же буферы кадра или фреймбуферы.
Разработка движка прекращена, исходные коды проекта доступны тут: http://code.google.com/p/glsnewton/
среда, 23 марта 2016 г.
понедельник, 21 марта 2016 г.
Vulkan API, Render Pass
Render Pass
Вот я и добрался до следующего болшого куска спецификации, так же имеющего важное значение для понимания фундаментальных основ Вулкана, к Render Pass и Subpass. В предыдущей статье я уже затрагивал тему Render Pass, теперь пришло время изучить спецификацию.
Ярлыки:
Render Pass,
Specification,
subpass,
Vulkan API
четверг, 17 марта 2016 г.
Vulkan, еще раз о синхронизации...
Наконец-то я закончил перевод этого здоровенного и не менее важного куска спецификации. О том, что я думаю об авторе этого раздела спецификации я уже писал много, потому я просто счастлив что это осталось позади (хотя кто знает что еще меня ждет впереди))
Написано там было очень много, о параметрах, и случаях использования, о вариантах, о тонкостях и прочем, но это тот случай, когда за деревьями леса не видно, потому я и решил собрать воедино всю эту информацию в одной короткой статье, так сказать для закрепления материала.
Ярлыки:
Barriers,
Events,
Fences,
Semaphores,
Vulkan API
Vulkan API. Memory Barriers and Implicit Ordering Guarantees.
Вот я и добрался до последней главы раздела "Synchronization and Cache Control", перевод этого раздела оказался достаточно "стремным", как вообщем-то и текст оригинала. После этой статьи я приведу еще одну итоговую, где постараюсь в сжатом виде пересказать содержание последних серий, ну а пока - Memory Barriers и Implicit Ordering Guarantees.
Ярлыки:
Barriers,
Buffer Memory Barriers,
Global Memory Barriers,
Image Memory Barriers,
Implicit Ordering Guarantees,
Specification,
Vulkan API
понедельник, 14 марта 2016 г.
Vulkan API, Barriers, Execution And Memory Dependencies.
Перевод этой части спецификации очень затянулся. Причин здесь несколько, во-первых - большой объем информации, во-вторых - высокая сложность материала (много терминов, много новых понятий и концепций, отсутствующих в других API и прочее), ну и ко-всему - неудачный порядок изложения материала, что приемлемо для спецификации, но неудобно для систематизированного изучения. Так же у меня есть претензии к автору этой главы, так как написано все очень коряво и без понимания сути материала очень сложно передать мысль “своими словами”, а перевод оказывается набором слов.
Потому, чтоб упростить понимание этой главы, я немного изменил порядок следования глав и разбавил их фрагментами статей от AMD (можно ж ведь и сложные вещи простым языком описать, снимаю перед этими ребятами шляпу).
Ну и прежде чем приступить к переводу следующего куска спецификации я решил забежать немного вперед и дать определение некоторым из используемых в этой главе спецификации терминов.
суббота, 12 марта 2016 г.
Vulkan Renderpasses
Переводя следующую главу спецификации я столкнулся с несколькими проблемами.
По всей видимости, начиная с главы "6.4 Execution And Memory Dependencies", у спецификации поменялся автор - два слова связать не может, постоянно пережовывает одно и тоже, сплош и рядом тафтология, предложения закручивает так, что и 100-грамм не помогает, вообщем текст ужасный, местами я при перечитывании переведенного просто удалял целые абзацы, заменяя их одной фразой.
Но это пол-беды, не знаю кто виноват, этот же автор или еще кто, но в этой главе явно нарушен порядок изложения материала (да, я понимаю что это спецификация, но все же), вначале разжовываются сценарии, а только через пару глав рассказывается что же такое эти dependency, renderpass, subpass, pipeline stages и многое другое. В результате теряется суть написанного и весь перевод главы становится абсолютно бессмысленным.
Можно было бы оставить "как есть", и в конце приписать что-то типа "не виноватая-я, оно так и было" и предложить вернуться к этой главе спустя сотню страничек спеки, но я все же постараюсь сделать это повествование логичным, хоть и придется отойти от порядка изложения определенного в спецификации, в том числе и используя "сторонние" материалы.
По всей видимости, начиная с главы "6.4 Execution And Memory Dependencies", у спецификации поменялся автор - два слова связать не может, постоянно пережовывает одно и тоже, сплош и рядом тафтология, предложения закручивает так, что и 100-грамм не помогает, вообщем текст ужасный, местами я при перечитывании переведенного просто удалял целые абзацы, заменяя их одной фразой.
Но это пол-беды, не знаю кто виноват, этот же автор или еще кто, но в этой главе явно нарушен порядок изложения материала (да, я понимаю что это спецификация, но все же), вначале разжовываются сценарии, а только через пару глав рассказывается что же такое эти dependency, renderpass, subpass, pipeline stages и многое другое. В результате теряется суть написанного и весь перевод главы становится абсолютно бессмысленным.
Можно было бы оставить "как есть", и в конце приписать что-то типа "не виноватая-я, оно так и было" и предложить вернуться к этой главе спустя сотню страничек спеки, но я все же постараюсь сделать это повествование логичным, хоть и придется отойти от порядка изложения определенного в спецификации, в том числе и используя "сторонние" материалы.
Стоило мне принять это решение как тут же попалась статья от AMD по этим самым renderpass-ам, с которых и начнется повествование.
воскресенье, 6 марта 2016 г.
Vulkan API, Synchronization primitives, Events.
Продолжение перевода 6 главы - Synchronization and Cache Control, в этот раз рассмотрим третий тип синхронизации - события(Events).
Предыдущие части можно посмотреть здесь:
Vulkan API, Synchronization primitives, Semaphores
Подписаться на:
Комментарии (Atom)