-
Notifications
You must be signed in to change notification settings - Fork 1.4k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
It's all led up to this! This adds the vulkan rendererer that implments the renderer interface previously implemented by OpenGL. It introduces a few tweaks to that interface as well. Additional entry points for the beginning and end of the frame are added and calls to finalize rendering and destroy the renderer state. The prototypes of a few existing calls have had information added because it's needed by vulkan. The cmake file now has a VULKANIZE flag that links appropriate libraries as well as the appropriate *renderer object and sets defines that change a few lines of code in source files. It would be extremely difficult to give much detail about the vkrenderer added here. As for broader design principles, there are a number of cases where flexibility is consciously limited based on the requirements of the application. This includes formats and layouts being explicitly specified and also the limitations of what extensions and features can be enabled. In general, the interface is still based on GL and so there is some sense of a minor GL on vulkan vibe. The preceding changes to the renderer interface were made to allow for this kind of abstraction. In general, the established practice of naming creation functions gen_* and destruction functions del_* is maintained. Internally, create_* is used to create internal representations and anything that is not an API function is made static and thrown inline. I considered hiving off a lot of the internal code to another module and making vkrenderer a translation layer, but I didn't feel like designing another API. To a large degree, the renderer centers around the usual standard objects that any vulkan app might have, instance, device, queue, render pass, swapchain, and various per-frame objects that amount to framebuffers and command buffers along with sync objects to keep it all in line. The user-controlled objects are exactly as they were for GL, Images (textures), Buffers, Uniforms, and Pipelines. The one with the greatest difference is of course the pipeline, which contains a lot more than GL programs do. I expect that's pretty standard though. Image is a bit broader than just textures, but externally, that's its only use. Buffers have the most gotchas. The app previously created and deleted them a lot and that's a problem if you don't have OpenGL around to keep track of when its safe to actually delete them. Uniforms are just per-frame descriptor sets and UBOs.
- Loading branch information
Showing
5 changed files
with
1,818 additions
and
35 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.