Listing the "Blender Foundation" as copyright holder implied the Blender
Foundation holds copyright to files which may include work from many
developers.
While keeping copyright on headers makes sense for isolated libraries,
Blender's own code may be refactored or moved between files in a way
that makes the per file copyright holders less meaningful.
Copyright references to the "Blender Foundation" have been replaced with
"Blender Authors", with the exception of `./extern/` since these this
contains libraries which are more isolated, any changed to license
headers there can be handled on a case-by-case basis.
Some directories in `./intern/` have also been excluded:
- `./intern/cycles/` it's own `AUTHORS` file is planned.
- `./intern/opensubdiv/`.
An "AUTHORS" file has been added, using the chromium projects authors
file as a template.
Design task: #110784
Ref !110783.
A lot of files were missing copyright field in the header and
the Blender Foundation contributed to them in a sense of bug
fixing and general maintenance.
This change makes it explicit that those files are at least
partially copyrighted by the Blender Foundation.
Note that this does not make it so the Blender Foundation is
the only holder of the copyright in those files, and developers
who do not have a signed contract with the foundation still
hold the copyright as well.
Another aspect of this change is using SPDX format for the
header. We already used it for the license specification,
and now we state it for the copyright as well, following the
FAQ:
https://reuse.software/faq/
Extract vendor, driver and device information from the physical device
properties.
Note that driver version is implementation dependent and might fail as
it is unclear which driver is being used. An open source driver could
store the driver version in a different way than a closed source driver.
But as it is not clear which driver version is being used it might
extract the incorrect version.
To solve this issue we check if the extracted version makes sense
depending on the version schema of the driver and if they don't match we
use another approach.
Pull Request: https://projects.blender.org/blender/blender/pulls/107872
ShaderInput lookup used to be explicit as in we know for sure that the
shader input exists. This was guarded by a assert. During development
of the graphics pipeline we came to the conclusion that this isn't
always the case due to its late bindings of resources.
This PR Makes the shader input lookup return an optional result.
This result can then be checked depending on the area where it is used
to validate the existence.
Pull Request: https://projects.blender.org/blender/blender/pulls/107735
Previous GHOST_ContextVK would create a logical device for each
context. Blender uses multiple contexts at the same time and wasn't able
to share resources between them as the logical device where different.
This patch will create a single logical device and share them between
multiple contexts. This allows sharing memory/shaders between contexts
and make sure that all memory allocations are freed from the device it
was allocated from.
Some allocations in Blender are freed when there isn't a context, this
was failing in the previous implementation. We didn't noticed it before
as we didn't test multiple contexts.
This patch also moves device specific data structures from VKContext to
VKDevice like the descriptor pools, debug layers etc.
Pull Request: https://projects.blender.org/blender/blender/pulls/107606
The goal is to solve confusion of the "All rights reserved" for licensing
code under an open-source license.
The phrase "All rights reserved" comes from a historical convention that
required this phrase for the copyright protection to apply. This convention
is no longer relevant.
However, even though the phrase has no meaning in establishing the copyright
it has not lost meaning in terms of licensing.
This change makes it so code under the Blender Foundation copyright does
not use "all rights reserved". This is also how the GPL license itself
states how to apply it to the source code:
<one line to give the program's name and a brief idea of what it does.>
Copyright (C) <year> <name of author>
This program is free software ...
This change does not change copyright notice in cases when the copyright
is dual (BF and an author), or just an author of the code. It also does
mot change copyright which is inherited from NaN Holding BV as it needs
some further investigation about what is the proper way to handle it.
**What are push constants?**
Push constants is a way to quickly provide a small amount of uniform data to shaders.
It should be much quicker than UBOs but a huge limitation is the size of data - spec
requires 128 bytes to be available for a push constant range.
**What are the challenges with push constants?**
The challenge with push constants is that the limited available size. According to
the Vulkan spec each platform should at least have 128 bytes reserved for push
constants. Current Mesa/AMD drivers supports 256 bytes, but Mesa/Intel is only 128
bytes.
**What is our solution?**
Some shaders of Blender uses more than these boundaries. When more data is needed
push constants will not be used, but the shader will be patched to use an uniform
buffer instead. This mechanism will be part of the Vulkan backend and shader
developers should not see any difference on API level.
**Known limitations**
Current state of the vulkan backend does not track resources that are in the
command queue. This patch includes some test cases that identified this issue as
well. See #104771.
Pull Request #104880
Resolving builtin uniforms and uniform blocks when creating
shader interface. This maps builtin uniforms to uniforms
defined by the shader. Works the same as the OpenGL
builtin uniforms.
Pull Request #105128
Descriptor set locations are now determined in the
VKShaderInterface. Issues with the previous solution:
- Due to legacy code in GPU module the locations/bindings
must be the same. Using one for something else might
result in undesired lookups, incorrect resource
bindings.
- Images/Textures reuses the same namespace, that didn't
work as expected when looking up the resources via
its binding.
This refactoring is required for adding support for
push constants.
Pull Request #105073
This patch adds initial support for compute shaders to
the vulkan backend. As the development is oriented to the test-
cases we have the implementation is limited to what is used there.
It has been validated that with this patch that the following test
cases are running as expected
- `GPUVulkanTest.gpu_shader_compute_vbo`
- `GPUVulkanTest.gpu_shader_compute_ibo`
- `GPUVulkanTest.gpu_shader_compute_ssbo`
- `GPUVulkanTest.gpu_storage_buffer_create_update_read`
- `GPUVulkanTest.gpu_shader_compute_2d`
This patch includes:
- Allocating VkBuffer on device.
- Uploading data from CPU to VkBuffer.
- Binding VkBuffer as SSBO to a compute shader.
- Execute compute shader and altering VkBuffer.
- Download the VkBuffer to CPU ram.
- Validate that it worked.
- Use device only vertex buffer as SSBO
- Use device only index buffer as SSBO
- Use device only image buffers
GHOST API has been changed as the original design was created before
we even had support for compute shaders in blender. The function
`GHOST_getVulkanBackbuffer` has been separated to retrieve the command
buffer without a backbuffer (`GHOST_getVulkanCommandBuffer`). In order
to do correct command buffer processing we needed access to the queue
owned by GHOST. This is returned as part of the `GHOST_getVulkanHandles`
function.
Open topics (not considered part of this patch)
- Memory barriers & command buffer encoding
- Indirect compute dispatching
- Rest of the test cases
- Data conversions when requested data format is different than on device.
- GPUVulkanTest.gpu_shader_compute_1d is supported on AMD devices.
NVIDIA doesn't seem to support 1d textures.
Pull-request: #104518
