nilsonragee
commented
4 months ago Выкатил первую рабочую версию, НО - проверял только в растере, в RT рендере скорее всего не работает. Возможно оно будет работать, если происходит запуск сразу на RT, но переключение между рендерами точно работать не должно из-за логики работы связанных с RT модулями - подробнее в комментариях ревью.
Пока что все сообщения инитов / деинитов пишутся в консоль, но скорее всего нужно будет добавить что-то, что будет это контролировать, т.к. спамит достаточно. Хотя сразу видно какой модуль когда включен, когда выключен. Как это реализовать пока что не знаю - сделать ручную проверку аргумента типа -vkdbgmod или как-то через vk_logs реализовать, я пока что не разобрался и у меня уже просто мозг кипит от этого, потому что работал над этим целую неделю практически без перерыва.
Если честно мне уже тошно от этого и пишу все это через силу, но я понимаю, что никто за меня ход моих мыслей и идей объяснять не будет, поэтому приходится. По сути большая часть работы сделана, осталось довести до конца, отполировать к финальному, готовому виду.
К сожалению коммиты читать очень тяжело, потому что они в спаме изменений из-за того, что я все функции инитов и деинитов перенес в конец файлов, т.к. они в разных файлах были в разных местах, плюс если они в конце файла, то никакие лишние форвард-декларации плодить не придется. Во всяком случае постарался писать комментарии в ревью под значимыми кусками кода, чтобы не потеряться в спаме.
На этом, наверно, пока все - буду ждать разбора на стриме. А до этого, я наверно немного развеюсь, потому что реально уже голова кипит мало того, что от комплексности самой проблемы и методов реализаций, так еще и от того, что это нужно все объяснять... В общем, надеюсь меня поняли.
w23
Как мы знаем, все наши
Vulkan-овские модули внутриref/vkтак или иначе имеют концепцию инициализации и деинициализации посредством вызова функций:xxx_Init()- для инициализации модуля перед тем, как его использовать.xxx_Shutdown()- для деинициализации модуля после того, как им закончили пользоваться.Данная концепция подразумевает, что перед тем, как использовать что-то из нужного нам модуля, мы сначала должны этот модуль инициализировать, а когда он нам не нужен, то мы вызываем деинициализацию, чтобы этот модуль сделал все необходимые действия для плавного возвращения всех ресурсов, которые он занял, обратно в систему.
Реализовано это у нас очень просто, но эта простота упускает реализацию достаточно важных деталей:
Состояние инициализации
Мы его просто напросто не знаем. То есть каждый раз перед тем, как использовать функционал модуля, мы должны либо инициализировать его, даже если он уже инициализирован, так как мы не знаем об этом, либо надеяться на то, что кто-то уже сделал это до нас.
Зависимости
Все они задаются вручную и никак не отслеживаются самим модулем. Нет какого-то определенного списка зависимостей, который мы просто можем взять и посмотреть, а также, чтобы это сделал сам модуль и проинициализировал их, если это еще не было сделано. "Списки" этих зависимостей нигде не хранятся, кроме как в самом коде в виде вызовов их функций инициализации, которые обычно идут списком внутри функции
xxx_Init().Этот PR является попыткой все это реорганизовать и вынести в отдельный, доведенный до ума API. Намеки на надобность такого рода API уже есть комментариях самого кода:
https://github.com/w23/xash3d-fwgs/blob/a0b36a4301fbd718a4c3ae85bbe06d9efa50d6df/ref/vk/vk_core.c#L680-L707
Осталось лишь понять как именно этот API реализовать и что конкретно мы от него хотим. Я выделил следующие критерии (за исключением всяких "простота в использовании", "понятность" и т.д. - берем это, как базовые критерии):
Init-ы внутри другихInit-ов.Initи были уверены в том, что все зависимости будут прогружены и модуль будет готов к работе.Это был небольшой
Specification, надеюсь мои мысли и идеи совпадают с первоначальными. Вот как примерно выглядит код инициализации и деинициализации модулей сейчас:https://github.com/w23/xash3d-fwgs/blob/a0b36a4301fbd718a4c3ae85bbe06d9efa50d6df/ref/vk/vk_core.c#L765-L783
https://github.com/w23/xash3d-fwgs/blob/a0b36a4301fbd718a4c3ae85bbe06d9efa50d6df/ref/vk/vk_core.c#L838-L853
Первоначально хотел показать реализацию непосредственно внедрив ее сразу, но столкнулся с тем, что не все модули имеют простой
Initбез аргументов - некоторые ожидают параметры, которые создаются на этапе других модулей, которые зависят от других и так далее...Такая проблема есть в
vk_swapchain, где инициализация ожидает внешние параметры: https://github.com/w23/xash3d-fwgs/blob/a0b36a4301fbd718a4c3ae85bbe06d9efa50d6df/ref/vk/vk_swapchain.c#L184Эти параметры потом сохраняются в глобальное состояние: https://github.com/w23/xash3d-fwgs/blob/a0b36a4301fbd718a4c3ae85bbe06d9efa50d6df/ref/vk/vk_swapchain.c#L196-L197
Если посмотреть саму структуру где они хранятся, то видим комментарий, что они тут быть и не должны: https://github.com/w23/xash3d-fwgs/blob/a0b36a4301fbd718a4c3ae85bbe06d9efa50d6df/ref/vk/vk_swapchain.c#L9-L12
Сам модуль
vk_swapchainинициализируется в модулеvk_framectl(кстати не знаю что заframectl, понятно лишь то, чтоframe- значит связано с кадрами, #709): https://github.com/w23/xash3d-fwgs/blob/a0b36a4301fbd718a4c3ae85bbe06d9efa50d6df/ref/vk/vk_framectl.c#L420-L432Идем в заголовок и видим, что и здесь это не должно быть: https://github.com/w23/xash3d-fwgs/blob/a0b36a4301fbd718a4c3ae85bbe06d9efa50d6df/ref/vk/vk_framectl.h#L13-L22
Если посмотреть чуть выше, то видим комментарий, что тут вообще всех этих глобальных переменных не должно быть: https://github.com/w23/xash3d-fwgs/blob/a0b36a4301fbd718a4c3ae85bbe06d9efa50d6df/ref/vk/vk_framectl.h#L8C1-L8C1
Такой вложенности мне хватило, чтобы понять, что сам я тут точно не разберусь... Наверно это надо в отдельную ишью вынести, ну ладно, написал значит написал, может потом создам, где сразу для всех модулей выпишу эти зависимости.
Жду отзывов на данное творение и возможные предложения/исправления.