There is little to no performance gain, with a lot of burden
to maintenance of the extra path. It's better to unify the code
with the other render pass logic.
Before this patch some common patterns would lead to very suboptimal
render passes.
Consider the following code:
```lua
local canvas = love.graphics.newCanvas(...)
function love.draw()
love.graphics.setCanvas(canvas)
love.graphics.clear(...)
love.graphics.draw(...)
love.graphics.setCanvas()
love.graphics.draw(canvas)
end
```
This would lead to the following rendering:
1) render pass on main window with loadOp=load, followed by an immediate
call to vkCmdClearAttachments
2) render pass on canvas with loadOp=load, followed by an immediate call
to vkCmdClearAttachments
3) render pass on main window with loadOp=load
This patch changes the behaviour to the more performant
(and equivalent) version:
1) render pass on canvas with loadOp=clear
2) render pass on main window with loadOp=clear
This is especially helpful on mobile devices, where creating render
passes is an expensive operation.
Resolves#1879.
- Add an 'indirectdraw' boolean field to the graphics feature support table returned by love.graphics.getSupported. This is almost always supported when compute shaders are supported, except on a few older phones.
- Add an 'indirectarguments' boolean field to the settings table in love.graphics.newBuffer.
- Add love.graphics.dispatchIndirect(shader, argumentsbuffer [, argumentsindex = 1]).
The compute dispatch's threadgroup width, height, and depth values are fetched from the buffer (as 3 uints) instead of coming from function parameters.
- Add love.graphics.drawIndirect(mesh, argumentsbuffer, argumentsindex, x, y, ....).
Vertex or index count, instance count, and other related parameters for drawing the mesh are fetched from the buffer (as 4 or 5 uints depending on whether the mesh has an index buffer) instead of coming from function parameters. It's usually a good idea to keep parameters other than the instance count in sync with what the mesh should be using.
- Add love.graphics.drawFromShaderIndirect(drawmode, argumentsbuffer [, argumentsindex = 1] [, maintexture = nil]) and drawFromShaderIndirect(indexbuffer, argumentsbuffer [, argumentsindex] [, maintexture = nil]).
Vertex or index count, instance count, and other related parameters are fetched from the buffer as 4 or 5 uints, as above.
For the dispatch indirect arguments buffer, it has to have 3 uint32 elements: { uint threadgroupsX, uint threadgroupsY, uint threadgroupsZ }.
For non-indexed draws, the arguments buffer has to have 4 uint32 elements: { uint vertexCount, uint instanceCount, uint baseVertex, uint baseInstance }. Note that baseInstance should always be set to 0 as many drivers don't support non-zero values.
For draws which use an index buffer, the arguments buffer has to have 5 uint32 elements: { uint indexCount, uint instanceCount, uint firstIndex, uint baseVertex, uint baseInstance }. As above, the baseInstance value should always be 0.
A buffer can be created to have an array of those structures, which can be used with the argumentsindex parameter of the Indirect dispatch/draw functions.
When creating a texture with user-specified mipmaps, it no longer errors if all mipmaps down to 1x1 aren't present.
Added a 'mipmapcount' field to the settings table in newImage and friends (only used when mipmaps are enabled for the texture.) If it's set, only mipmap levels up to the specified count will be created instead of always creating the full range.
Old OpenGL ES 2 devices don't support loading a mipmapped texture without the full mipmap range, so there's a new 'mipmaprange' boolean field in the table returned by love.graphics.getSupported.
Vulkan does not differentiate between between bindings for textures
and buffers, as opposed to opengl. This can lead to situations, where
different uniforms get assigned the same binding leading to a crash,
when trying to update a descriptor set with the wrong type.
This patch solves this problem, by remapping the bindings when needed.
Right now we have to recreate the swapchain everytime vsync
/ present mode changes.
VK_EXT_swapchain_maintenance1 might remove the need for this.
However, right now there are not any drivers yet that support it.
In the future, this might be the better way to handle this situation.
This is not actually needed. The api version specified when creating
the vulkan instance should be the highest api version that might
be used by the application, which can be higher than the supported
instance version. VMA can make use of vulkan 1.3 features so this
can be hardcoded to VK_API_VERSION_1_3.
niki
nikeinikei
Sasha Szpakowski