Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add initial Vulkan support, master branch goes UNSTABLE #36098

merged 126 commits into from Feb 11, 2020

Add initial Vulkan support, master branch goes UNSTABLE #36098

merged 126 commits into from Feb 11, 2020


Copy link

akien-mga commented Feb 11, 2020

The vulkan branch has served us well, seeing parallel development to master for over 8 months while Godot 3.2 was in development.

To go full steam ahead towards Godot 4.0, it's now time to merge the WIP Vulkan port in the master branch, so that we can start doing the heavy refactoring work which is necessary for many 4.0 features (Vulkan, GDScript improvements, C++14 port, streamlined node naming, etc.).

IMPORTANT: The master branch is now unstable, and will be so for a few months until we reach the alpha stage. It is NOT meant for use in production, and if you want a stable branch to do custom development, you can use 3.2. Note however that, unless exception is given, we do not accept new features PR'ed directly to the 3.2 branch. Feature work needs to happen in master before it can be cherry-picked (or manually backported) to any stable branch.

We encourage contributors to refrain from doing extensive feature work during the transition period where @reduz will rework many of the engine's internals, and the rest of us will port the whole codebase to C++14. Trying to get features merged in this turmoil will likely result in rebase hell and frustration :)

After this merge and subsequent refactoring work, most unmerged PRs will also get merge conflicts which will not be trivial to solve. Once the initial refactoring pass has been done, we plan to address this by closing all older PRs (minus a few 3.2-focused exceptions), and asking their authors to re-do them if relevant, rebased on the current master branch. We apologize in advance for the extra work that we'll ask of everyone, but this is the sanest way forward to avoid being dragged down by 500 PRs worth of unmergeable conflicts. More about this in an upcoming blog post. Edit:

reduz and others added 30 commits Jun 7, 2019
-Added VulkanContext
-Added an X11 implementation
-Added a rendering device abstraction
-added a Vulkan rendering device abstraction
-Engine does not work, only shows Godot logo (run it from bin/)
* Implements a growing chunked allocator
* Removed redudant methods get and getptr, only getornull is supported now.
-Texture renamed to Texture2D
-TextureLayered as base now inherits 2Darray, cubemap and cubemap array
-Removed all references to flags in textures (they will go in the shader)
-Texture3D gone for now (will come back later done properly)
-Create base rasterizer for RenderDevice, RasterizerRD
This should make it easier to obtain the data directly from an Image

Removes antialiased flag for draw_* methods.
They should now allocate memory in blocks and reuse the same
memory every time the item is cleared and redrawn.

This should improve performance considerably.
Added support for Sprite, AnimatedSprite and Polygon2D (should add for tileset eventually).
Modified polygon management to make it more compatible with MoltenVK
Also, optimized shader compilation to happen on threads.
Initial Vulkan support for Windows.
Initial Vulkan support for macOS.
Initial Vulkan support for macOS (MoltenVK) and Windows
@akien-mga akien-mga added this to the 4.0 milestone Feb 11, 2020
@akien-mga akien-mga requested review from AndreaCatania, BastiaanOlij, hpvb, JFonS, reduz, vnen and godotengine/documentation as code owners Feb 11, 2020
- `vk_enum_string_helper.h` is a generated file taken from the SDK
- `vk_mem_alloc.h` is a library from GPUOpen:
@akien-mga akien-mga merged commit 1eb424e into master Feb 11, 2020
4 checks passed
4 checks passed
continuous-integration/appveyor/branch AppVeyor build succeeded
continuous-integration/appveyor/pr AppVeyor build succeeded
continuous-integration/travis-ci/pr The Travis CI build passed
continuous-integration/travis-ci/push The Travis CI build passed

This comment has been minimized.

Copy link

jasonswearingen commented Feb 12, 2020

@akien-mga Could you guys please make an announcement when the new vulkan features are stable enough for "preview" use? I would love to dogfood it, provided that the API's are not expected to be completely rewritten


This comment has been minimized.

Copy link
Member Author

akien-mga commented Feb 12, 2020

There will be an announcement on the blog when we release the first alpha build (and all subsequent builds).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

10 participants
You can’t perform that action at this time.