We now do certain image layout transitions in the render pass instead of a barrier in EndRenderPass.
There is also an additional barrier on buffer uploads to prevent write-after-write hazard. It's a kludge on the fact that we're only tracking the most recent resource access.
Reviewed-on: #49
continuous-integration/drone/push Build is passingDetails
This should fix an issue where draw calls could flicker if a defrag was in progress and a uniform buffer was being used.
Uniform buffer "pools" are now just a single dedicated VulkanBuffer, and the uniform buffer objects are offsets into that buffer.
Reviewed-on: #48
continuous-integration/drone/push Build is passingDetails
Some minor stuff that's cropped up from the D3D11 work so far. This PR updates the Driver_Template with the latest API, and also fixes a crash in the Vulkan driver -- if you acquired a swapchain texture from a window that had been destroyed, there was no null check before de-referencing the WindowData.
Co-authored-by: Caleb Cornett <caleb.cornett@outlook.com>
Reviewed-on: #46
Co-authored-by: TheSpydog <thespydog@noreply.example.org>
Co-committed-by: TheSpydog <thespydog@noreply.example.org>
continuous-integration/drone/push Build is passingDetails
continuous-integration/drone/tag Build is passingDetails
continuous-integration/drone Build is passingDetails
Various changes to reduce and optimize memory usage.
- Defragmenter
- Allocate 4 16MB transfer buffers for pool
- If transfer is larger than 16MB, create temporary transfer buffer
- Fixed some issues with CopyTextureToTexture
Reviewed-on: #41
continuous-integration/drone/push Build is passingDetails
Depth textures handle MSAA differently than color textures do, because there's no need for a resolve texture. This means the root VulkanTexture can have the sample count instead of needing an additional `msaaTex`.
This changeset also fixes a bug where the depth buffer wasn't getting cleared if there were MSAA color attachments.
Co-authored-by: Caleb Cornett <caleb.cornett@outlook.com>
Reviewed-on: #38
Co-authored-by: TheSpydog <thespydog@noreply.example.org>
Co-committed-by: TheSpydog <thespydog@noreply.example.org>
continuous-integration/drone/push Build is passingDetails
This change makes Refresh behave more like FNA and other rendering APIs, where user-side textures have a sample count instead of generating MSAA RTs on the fly.
This should theoretically reduce memory consumption since subresource views no longer generate their own MSAA textures. Instead, each texture with a sample count > 1 now has a reference to an MSAA texture baked into the root texture itself, so views can just reference that.
This also simplifies VulkanRenderTarget significantly, to the point where it's just a wrapper around VkImageView. We could probably remove the abstraction entirely at this point.
Since VkRenderPass objects still require knowing the sample count, we can use the first bound texture's sample count. This means users only have to specify sample count in two places -- the graphics pipeline, and the texture. Easy enough.
I also noticed and fixed a bug with clear values with MSAA levels > 1.
Co-authored-by: Caleb Cornett <caleb.cornett@outlook.com>
Reviewed-on: #37
Co-authored-by: TheSpydog <thespydog@noreply.example.org>
Co-committed-by: TheSpydog <thespydog@noreply.example.org>
continuous-integration/drone/push Build is passingDetails
Before this change, framebuffers were created based on the attachments' full dimensions, instead of the dimensions of the requested mip level. This fixes validation errors in the RenderTextureMipmaps test program.
Co-authored-by: Caleb Cornett <caleb.cornett@outlook.com>
Reviewed-on: #36
Co-authored-by: TheSpydog <thespydog@noreply.example.org>
Co-committed-by: TheSpydog <thespydog@noreply.example.org>
continuous-integration/drone/push Build is passingDetails
The image type getting passed to imageCreateInfo was always VK_IMAGE_TYPE_2D, even for 3D textures. This fixes that bug, allowing Vulkan to successfully create 3D textures.
Co-authored-by: Caleb Cornett <caleb.cornett@outlook.com>
Reviewed-on: #35
Co-authored-by: TheSpydog <thespydog@noreply.example.org>
Co-committed-by: TheSpydog <thespydog@noreply.example.org>
continuous-integration/drone/push Build is passingDetails
This PR adds a shader cross-compiler program (written in C#) that uses glslc and spirv-cross to compile GLSL source files to a custom, Refresh-specific shader blob format that contains shader code for various backends.
The goal is that whenever you want to compile your shaders, you just run this program (either via `refreshc` or `dotnet run`), passing in the path to the GLSL source file. You can specify which backends you want to support via flags (`--vulkan`, for instance), and it will generate a .refresh blob file for Refresh to consume.
This can also be extended via C# defines and the `partial class` system. An example is the PS5 shader implementation, whose logic is squirreled away in the NDA'd repository but can be called in sequence with the rest of the shader cross-compile logic. This way, we don't have to run two separate programs to compile our shaders to all supported platforms.
Refresh handles all the parsing of the file format in Refresh_CreateShaderModule, so individual backends do not need to concern themselves with the particulars.
Co-authored-by: Caleb Cornett <caleb.cornett@outlook.com>
Reviewed-on: #34
Co-authored-by: TheSpydog <thespydog@noreply.example.org>
Co-committed-by: TheSpydog <thespydog@noreply.example.org>
continuous-integration/drone/push Build is passingDetails
Removes the `fixed` parameter from AcquireCommandBuffer, and removes a couple other unused bools from the VulkanCommandBuffer struct.
Co-authored-by: Caleb Cornett <caleb.cornett@outlook.com>
Reviewed-on: #33
Co-authored-by: TheSpydog <thespydog@noreply.example.org>
Co-committed-by: TheSpydog <thespydog@noreply.example.org>
continuous-integration/drone/push Build is passingDetails
The validator layer was complaining about us updating bound descriptor sets, this is technically a bug in the validator layer but resetting the command buffer in Cleanup makes more sense anyway. Also changed the wait for timeout call to a fence status query to make it easier to understand.
Reviewed-on: #32
continuous-integration/drone/push Build is passingDetails
Fixes a validation error when attempting to draw multiple primitives via an indirect draw call. Adds some documentation for how indirect draw buffers should be set up.
Co-authored-by: Caleb Cornett <caleb.cornett@outlook.com>
Reviewed-on: #30
Co-authored-by: TheSpydog <thespydog@noreply.example.org>
Co-committed-by: TheSpydog <thespydog@noreply.example.org>
continuous-integration/drone/push Build is passingDetails
This makes the order of VULKAN_Submit consistent with VULKAN_Wait.
Co-authored-by: Caleb Cornett <caleb.cornett@outlook.com>
Reviewed-on: #28
Co-authored-by: TheSpydog <thespydog@noreply.example.org>
Co-committed-by: TheSpydog <thespydog@noreply.example.org>
continuous-integration/drone/push Build is passingDetails
**Breaking API Changes**
* Removed `REFRESH_SAMPLECOUNT_16/32/64`, since hardware support for these sample counts is generally poor (and completely non-existent with MoltenVK and certain consoles).
* Removed unused `sampleCount` parameter from `Refresh_TextureCreateInfo`.
* Removed `sampleCount` parameter from `Refresh_ColorAttachmentDescription`. The existence of this parameter meant you had to sync up three different sample count values (render pass, pipeline, and color attachment description) whenever you wanted to use multisampling. However, Vulkan requires that all color attachments in a given pipeline _must_ match the pipeline's sample count anyway, so we can assume all color attachments will use the pipeline's sample count.
* Removed the `renderArea` parameter from `Refresh_BeginRenderPass()` since it didn't serve much practical purpose and slightly complicated things on the MoonWorks managed side.
**Behavior Changes**
* When creating a render pass or graphics pipeline, the requested multisample count will be converted into a sample count that's actually supported by the GPU. For example, if you request 8x MSAA on a device that only supports up to 4x MSAA, it will silently fall back to 4x MSAA.
* All color attachments are now forced to have an internal store op of `STORE`, even if `REFRESH_STORE_OP_DONTCARE` is specified. The one exception is internal multisample textures -- if `DONTCARE` is used, those textures will be discarded to save on bandwidth. (Their resolve textures will still be stored.)
* The RenderPass hashing logic was updated so that it would still work correctly with the removal of `Refresh_ColorAttachmentDescription.sampleCount`.
**Bug Fixes**
* Fixed bugs where multisampling logic wasn't kicking in for certain sample counts due to incorrect enum comparisons.
Co-authored-by: Caleb Cornett <caleb.cornett@outlook.com>
Reviewed-on: #26
Co-authored-by: TheSpydog <thespydog@noreply.example.org>
Co-committed-by: TheSpydog <thespydog@noreply.example.org>
continuous-integration/drone/push Build is passingDetails
- Fixed bug where multisample enum values were not being translated into their equivalent Vulkan enums
- Fixed bug where MSAA attachments in transient render pass creation were using a sample count of 1
- Fixed bug where the clearValues array in BeginRenderPass was not being populated with clear values for multisample attachments. (Modeled the fix after https://github.com/FNA-XNA/FNA3D/blob/master/src/FNA3D_Driver_Vulkan.c#L8723)
- Fixed bug where the multisample texture was not being transitioned when beginning a render pass
Reviewed-on: #25
Co-authored-by: TheSpydog <thespydog@noreply.example.org>
Co-committed-by: TheSpydog <thespydog@noreply.example.org>
cosmonaut
TheSpydog