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: MoonsideGames/Refresh#37
Co-authored-by: TheSpydog <thespydog@noreply.example.org>
Co-committed-by: TheSpydog <thespydog@noreply.example.org>
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: MoonsideGames/Refresh#33
Co-authored-by: TheSpydog <thespydog@noreply.example.org>
Co-committed-by: TheSpydog <thespydog@noreply.example.org>
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: MoonsideGames/Refresh#30
Co-authored-by: TheSpydog <thespydog@noreply.example.org>
Co-committed-by: TheSpydog <thespydog@noreply.example.org>
**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: MoonsideGames/Refresh#26
Co-authored-by: TheSpydog <thespydog@noreply.example.org>
Co-committed-by: TheSpydog <thespydog@noreply.example.org>
- The application must now call `Refresh_SetBackend` before creating the device
- `Refresh_SetBackend` can set a preferred backend, but will fall back if it is not available
- Device creation no longer takes presentation parameters
- Windows must now be explicitly claimed by the device
- Windows can be unclaimed by the device
- Windows can have their swapchain present mode changed after creation
Reviewed-on: MoonsideGames/Refresh#23
Fixes various errors related to the swapchain being recreated.
Additionally, `BeginRenderPass` now allows a NULL `renderArea` parameter. If NULL, Refresh will select a sensible default render area.
Co-authored-by: cosmonaut <evan@moonside.games>
Co-committed-by: cosmonaut <evan@moonside.games>
Removes `Refresh_RenderTarget`, `Refresh_CreateRenderTarget` and `Refresh_QueueDestroyRenderTarget`. Render targets are now managed by the implementation.
Adds `REFRESH_TEXTUREFORMAT_B8G8R8A8`.
Adds `Refresh_AcquireSwapchainTexture`. Returns a swapchain texture for the requested window.
Removes `Refresh_QueuePresent`. It is now assumed that the texture returned by `Refresh_AcquireSwapchainTexture` will be presented. This texture can be manipulated like any other texture.
Adds `Refresh_GetSwapchainFormat`. Returns the swapchain format for the requested window.
Reviewed-on: MoonsideGames/Refresh#15
Co-authored-by: cosmonaut <evan@moonside.games>
Co-committed-by: cosmonaut <evan@moonside.games>
Removes `Refresh_RenderPass` and `Refresh_Framebuffer` objects.
`Refresh_BeginRenderPass` now takes a set of `Refresh_ColorAttachmentInfo` structs and an optional `Refresh_DepthStencilAttachmentInfo` struct that describe the render pass. The render pass and framebuffer objects are now managed by the implementation instead of the application.
Accordingly, `Refresh_GraphicsPipelineCreateInfo` now takes a `Refresh_GraphicsPipelineAttachmentInfo` struct that describes render passes that may be used with the pipeline. It is an error to bind a pipeline during an incompatible render pass.
Reviewed-on: MoonsideGames/Refresh#14
Co-authored-by: cosmonaut <evan@moonside.games>
Co-committed-by: cosmonaut <evan@moonside.games>
cosmonaut
TheSpydog