Multiple generations of Intel GPU have the same issue where multi
texture binding results in invalid operations where the driver
reports that the internal texture format isn't supported.
Previously this was only enabled for UHD devices, but this PR
enables it for any Intel GPU. It was detected to be faulty on
UHD600 and Iris.
Pull Request: https://projects.blender.org/blender/blender/pulls/121479
Advanced ID copying code can now take a `new_owner_id` ID pointer parameter,
and use it to set the relevant 'loopback' pointer to its owner ID by the
copy code itself.
Besides avoiding the need for all code copying embedded IDs to set the
loopback pointer themselves, this also means that `lib_id` copying code
itself does not need to use `IDWALK_IGNORE_MISSING_OWNER_ID` anymore.
This change is not expected to have any effect in current codebase.
This is an implementation of thin film iridescence in the Principled BSDF based on "A Practical Extension to Microfacet Theory for the Modeling of Varying Iridescence".
There are still several open topics that are left for future work:
- Currently, the thin film only affects dielectric Fresnel, not metallic. Properly specifying thin films on metals requires a proper conductive Fresnel term with complex IOR inputs, any attempt of trying to hack it into the F82 model we currently use for the Principled BSDF is fundamentally flawed. In the future, we'll add a node for proper conductive Fresnel, including thin films.
- The F0/F90 control is not very elegantly implemented right now. It fundamentally works, but enabling thin film while using a Specular Tint causes a jump in appearance since the models integrate it differently. Then again, thin film interference is a physical effect, so of course a non-physical tweak doesn't play nicely with it.
- The white point handling is currently quite crude. In short: The code computes XYZ values of the reflectance spectrum, but we'd need the XYZ values of the product of the reflectance spectrum and the neutral illuminant of the working color space. Currently, this is addressed by just dividing by the XYZ values of the illuminant, but it would be better to do a proper chromatic adaptation transform or to use the proper reference curves for the working space instead of the XYZ curves from the paper.
Pull Request: https://projects.blender.org/blender/blender/pulls/118477
This was caused by the 2 transmission event approximation we
do for object with non-null thickness. This follows cycles
by using the square root of the color.
Resolves offset error when building index buffers on device for
cuves/hair strips using Triangles instead of TriangleStrips.
Authored by Apple: Michael Parkin-White
Pull Request: https://projects.blender.org/blender/blender/pulls/121218
On windows the OpenGL backend of the UHD630 driver (but could also be other
GPUs that use the same driver) reports of supporting `GL_ARB_multi_bind`.
But when enabling it can result in incorrect bindings and report errors
about unsupported internal texture formats. These are internal driver issues.
Might also fix#107642 as it shows the same error message. EEVEE-Next
relies more on using the same binding slot for the same texture in order
to reduce actual bindings which makes this more prominent.
Pull Request: https://projects.blender.org/blender/blender/pulls/121062
Transport rays that enter to another location in the scene, with
specified ray position and normal. This may be used to render portals
for visual effects, and other production rendering tricks.
This acts much like a Transparent BSDF. Render passes are passed
through, and this is affected by light path max transparent bounces.
Pull Request: https://projects.blender.org/blender/blender/pulls/114386
Clamp some of the inputs of the Glossy BSDF, Glass BSDF, Sheen BSDF,
and Subsurface Scattering nodes to improve consistency between render
engines and to avoid unexpected results.
* Clamp roughness to 0..1
* Clamp subsurface radius to 0..inf
* Clamp colors to 0..inf
Pull Request: https://projects.blender.org/blender/blender/pulls/120390
This adds a new `Transform` type similar to cycles that reduces
the amount of data passed for a typical affine 3D transform.
This then applies this type to the light data and cleanup
all usage of the former `object_mat`. This also changes the axes
macros into utility accessor functions.
Pull Request: https://projects.blender.org/blender/blender/pulls/121089
Add dispatch indirect node. Also refactored the dispatch (direct) node
so more logic could be reused. The context only stores a `VKResourceAccessInfo`
struct which is reused by both the dispatch and dispatch indirect node.
Pull Request: https://projects.blender.org/blender/blender/pulls/120993
This PR adds support for compute shaders to render graph. Only direct dispatch
is supported. indirect dispatch will be added in a future PR.
This change enables the next test cases to be supported when using render graphs
- `GPUVulkanTest.push_constants*`
- `GPUVulkanTest.shader_compute_*`
- `GPUVulkanTest.buffer_texture`
- `GPUVulkanTest.specialization_constants_compute`
- `GPUVulkanTest.compute_direct`
```
[==========] 95 tests from 2 test suites ran. (24059 ms total)
[ PASSED ] 95 tests.
```
Specialization constants are supported when using the render graph. This should conclude
the conversion the prototype of the render graph.
Pull Request: https://projects.blender.org/blender/blender/pulls/120963
VKPipeline class is deprecated and will be phased out in the near future.
This PR moves the push constants to VKShader as it was wrongly placed in the
pipeline.
Pull Request: https://projects.blender.org/blender/blender/pulls/120980
Blender expects that only the filename is provided which is true
for internal shader sources.
Metal shaders can error and return a full path to a system shader.
This doesn't fit inside the reserved memory that Blender reserved
for logging filename and line number.
This out of bound write can be triggered when using `min`
where the parameters aren't of the same kind.
`uint min(uint, int)` for example.
This PR reserves more space to store the filename.
Pull Request: https://projects.blender.org/blender/blender/pulls/120967
In Vulkan, a Blender shader is organized in multiple
objects. A VkPipeline is the highest level concept and represents
somewhat we call a shader. A pipeline is an device/platform optimized
version of the shader that is uploaded and executed in the GPU device.
A key difference with shaders is that its usage is also compiled
in. When using the same shader with a different blending, a new pipeline
needs to be created.
In the current implementation of the Vulkan backend the pipeline is
re-created when any pipeline parameter changes. This triggers many
pipeline compilations. Especially when common shaders are used in
different parts of the drawing code.
A requirement of our render graph implementation is that changes
of the pipeline can be detected based on the VkPipeline handle.
We only want to rebind the pipeline handle when the handle actually
changes. This improves performance (especially on NVIDIA) devices
where pipeline binds are known to be costly.
The solution of this PR is to add a pipeline pool. This holds all
pipelines and can find an already created pipeline based on pipeline
infos. Only compute pipelines support has been added.
# Future enhancements
- Recent drivers replace `VkShaderModule` with pipeline libraries.
It improves sharing pipeline stages and reduce pipeline creation times.
- GPUMaterials should be removed from the pipeline pool when they are
destroyed. Details on this will be more clear when EEVEE support is
added.
Pull Request: https://projects.blender.org/blender/blender/pulls/120899
Due to an error in the hash function the specialization constants hash
wasn't optimal. This PR fixes the hash function implementation by replacing
the addition with an xor.
Pull Request: https://projects.blender.org/blender/blender/pulls/120964
Resource access info contains lists in a future setup the resource access info
will be kept in the VKContext and reused. This requires a reset function to
cleanup the instance for reuse.
Pull Request: https://projects.blender.org/blender/blender/pulls/120962
When building the resource access used when adding dispatch/draw commands
to the render graph, the access mask is required. This PR stores the
access mask in the shader interface. When binding the resources referenced
by the state manager, the resource access info struct is populated with
the access flags.
In the near future the resource access info will be passed when adding
a dispatch/draw node to the render graph to generate the links.
Pull Request: https://projects.blender.org/blender/blender/pulls/120908
Compute shaders are required since 4.0. There was one occasion where
an older AMD driver failed and support was turned off. This driver
is now marked unsupported.
This PR includes:
- removing the check in viewport compositing
- remove properties from system info
- always construct draw manager.
- remove unused pass logic in draw hair/curves
- add deprecation warning when accessed from python
Pull Request: https://projects.blender.org/blender/blender/pulls/120909
Test cases that uses compute shaders were exited when run on platforms
not supporting compute shaders. Since 4.0 Blender requires a platform
that supports compute shaders.
We should eventually phase out `GPU_compute_shader_support` as it
would always return true. Note that in OpenGL a platform is mentioned
that doesn't support compute shaders, but that is from an old driver
and should be save to remove as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/120907
There was a memory leak in the render graph where nodes where freed,
but not the data it could keep. Detected during adding support for
compute shaders and running the draw tests.
Pull Request: https://projects.blender.org/blender/blender/pulls/120906
The specialization constant default hash was implemented in gl_shader.hh
But the same implementation is needed for vulkan. This PR moves the
default hash to a common place where both backends can use it.
Pull Request: https://projects.blender.org/blender/blender/pulls/120889
This PR implements render graph for VKTexture. During the
implementation some tweaks to the render graph was done
to support depth and stencil textures.
The render graph will record the image aspect being used
for each node. This will then be used to generate barriers
for the correct aspect.
Also fixes an issue that uploading of array textures didn't
allocate a large enough staging buffer.
Pull Request: https://projects.blender.org/blender/blender/pulls/120821
A developer can switch `vk_common.hh#use_render_graph` to enable render graph.
When enabled the buffers and images are tracked by the device resource state
tracker. The storage buffer commands are recorded to the context render graph.
The next unit tests will pass:
- GPUVulkanTest.storage_buffer_create_update_read
- GPUVulkanTest.storage_buffer_clear_zero
- GPUVulkanTest.storage_buffer_clear
- GPUVulkanTest.storage_buffer_copy_from_vertex_buffer
The pattern to migrate to render graph is:
- always construct CreateInfo for class.
- based on `use_render_graph` call `context.command_buffers.something`
or `context.render_graph.add_node`.
- Hide calls to `context.flush` when `use_render_graph` is true.
Pull Request: https://projects.blender.org/blender/blender/pulls/120812
f2ae04db10 introduces missing binding
tracking for SSBO and UBOs. Vulkan relies on validation layers to
report on missing bindings, but the binding information should still
be cleared in the context state manager.
Pull Request: https://projects.blender.org/blender/blender/pulls/120814
**Design Task**: blender/blender#118330
This PR adds the core of the render graph. The render graph isn't used.
Current implementation of the Vulkan Backend is slow by design. We
focused on stability, before performance. With the new introduced render
graph the focus will shift to performance and keep the stability at where
it is.
Some highlights:
- Every context will get its own render graph. (`VKRenderGraph`).
- Resources (and resource state tracking) is device specific (`VKResourceStateTracker`).
- No node reordering / sub graph execution has been implemented. Currently
All nodes in the graph is executed in the order they were added. (`VKScheduler`).
- The links inside the graph describe the resources the nodes read from (input links)
or writes to (output links)
- When resources are written to a resource stamp is incremented allowing keeping
track of which nodes needs which stamp of a resource.
- At each link the access information (how does the node accesses the resource)
and image layout (for image resources) are stored. This allows the render graph
to find out how a resource was used in the past and will be used in the future.
That is important to construct pipeline barriers that don't stall the whole GPU.
# Defined nodes
This implementation has nodes for:
- Blit image
- Clear color image
- Copy buffers to buffers
- Copy buffers to images
- Copy images to images
- Copy images to buffers
- Dispatch compute shader
- Fill buffers
- Synchronization
Each node has a node info, create info and data struct. The create info
contains all data to construct the node, including the links of the graph.
The data struct only contains the data stored inside the node. The node info
contains the node specific implementation.
> NOTE: Other nodes will be added after this PR lands to main.
# Resources
Before a render graph can be used, the resources should be registered
to `VKResourceStateTracker`. In the final implementation this will be owned by
the `VKDevice`. Registration of resources can be done by calling
`VKResources.add_buffer` or `VKResources.add_image`.
# Render graph
Nodes can be added to the render graph. When adding a node its read/
write dependencies are extracted and converted into links (`VKNodeInfo.
build_links`).
When the caller wants to have a resource up to date the functions
`VKRenderGraph.submit_for_read` or `VKRenderGraph.submit_for_present`
can be called.
These functions will select and order the nodes that are needed
and convert them to `vkCmd*` commands. These commands include pipeline
barrier and image layout transitions.
The `vkCmd` are recorded into a command buffer which is sent to the
device queue.
## Walking the graph
Walking the render graph isn't implemented yet. The idea is to have a
`Map<ResourceWithStamp, Vector<NodeHandle>> consumers` and
`Map<ResourceWithStamp, NodeHandle> producers`. These attributes can
be stored in the render graph and created when building the links, or
can be created inside the VKScheduler as a variable. The exact detail
which one would be better is unclear as there aren't any users yet. At
the moment the scheduler would need them we need to figure out the best
way to store and retrieve the consumers/producers.
# Unit tests
The render graph can be tested by enabling `WITH_GTEST` and use
`vk_render_graph` as a filter.
```
bin/tests/blender_test --gtest_filter="vk_render_graph*"
```
Pull Request: https://projects.blender.org/blender/blender/pulls/120427
Trying to narrow down why some tests are failing on windows, but not on
linux/mac. These tests use a string compare. This PR adds two modifications
to the current vk_to_string.
- use `std::endl` although not required, it is important to portability
- print vulkan handles in a uniform way.
Pull Request: https://projects.blender.org/blender/blender/pulls/120780
When reviewing the render graph core PR, we discussed where specific
backend tests should be located. The code style is clear that it
needs to be located in a tests folder next to the code it tests.
This PR moved the tests folder from next to the files they test to
a tests folder.
Pull Request: https://projects.blender.org/blender/blender/pulls/120777
This happened when the buffer was bound as a SSBO as the
slot was not marked as used.
We do not tag the unbind as we never call `unbind` for
SSBOs. Also we don't track what target type the UBO is
bound to. This could be improved later.
- Removed ignored message ids as this is also part of vkconfig which should be used
This is also adviced by the Vulkan Tools WG.
- Also initialize logging when platform doesn't have debugging extensions.
Pull Request: https://projects.blender.org/blender/blender/pulls/120776
This PR adds a context function to consider all
buffer bindings obsolete. This is in order to
track missing binds and invalid lingering states
accross `draw::Pass`es.
The functions `GPU_storagebuf_debug_unbind_all`
and `GPU_uniformbuf_debug_unbind_all` do nothing
more than resetting the internal debug slot bits
to zero. This is what OpenGL backend does as it
doesn't track the bindings themselves.
Other backends might have other way to detect
missing bindings. If not they should be
implemented separately anyway.
I renamed the function to `debug_unbind_all` to
denote that it actually does something related to
debugging.
This also add SSBO binding check for OpenGL as it
was also missing.
#### Future
This error checking logic is pretty much backend
agnostic. While it would be nice to move it at
`gpu::Context` level, we don't have the resources
for that now.
Pull Request: https://projects.blender.org/blender/blender/pulls/120716
