| Age | Commit message (Collapse) | Author |
|---|
|
The only difference between `GPU_SHADER_2D_LINE_DASHED_UNIFORM_COLOR`
and `GPU_SHADER_3D_LINE_DASHED_UNIFORM_COLOR` is that in the vertex
shader the 2D version uses `vec4(pos, 0.0, 1.0)` and the 3D version
uses `vec4(pos, 1.0)`.
But VBOs with 2D attributes work perfectly in shaders that use 3D
attributes. Components not specified are filled with components from
`vec4(0.0, 0.0, 0.0, 1.0)`.
So there is no real benefit to having two different shader versions.
|
|
`GPU_SHADER_3D_IMAGE_MODULATE_ALPHA` can be seamlessly replaced by
`GPU_SHADER_3D_IMAGE_COLOR` with no real harm done.
|
|
3D shaders work in both 2D and 3D viewports.
This shader is a good candidate to be exposed in Python.
|
|
The only real difference between `GPU_SHADER_2D_SMOOTH_COLOR` and
`GPU_SHADER_3D_SMOOTH_COLOR` is that in the vertex shader the 2D
version uses `vec4(pos, 0.0, 1.0)` and the 3D version uses
`vec4(pos, 1.0)`.
But VBOs with 2D attributes work perfectly in shaders that use 3D
attributes. Components not specified are filled with components from
`vec4(0.0, 0.0, 0.0, 1.0)`.
So there is no real benefit to having two different shader versions.
This will simplify porting shaders to python as it will not be
necessary to use a 3D and a 2D version of the shaders.
In python the new name for '2D_SMOOTH_COLOR' and '3D_SMOOTH_COLOR'
is 'SMOOTH_COLOR', but the old names still work for backward
compatibility.
|
|
The only real difference between `GPU_SHADER_2D_IMAGE` and
`GPU_SHADER_3D_IMAGE` is that in the vertex shader the 2D
version uses `vec4(pos, 0.0, 1.0)` and the 3D version uses
`vec4(pos, 1.0)`.
But VBOs with 2D attributes work perfectly in shaders that use 3D
attributes. Components not specified are filled with components from
`vec4(0.0, 0.0, 0.0, 1.0)`.
So there is no real benefit to having two different shader versions.
This will simplify porting shaders to python as it will not be
necessary to use a 3D and a 2D version of the shaders.
In python the new name for '2D_IMAGE' and '3D_IMAGE'
is 'IMAGE', but the old names still work for backward
compatibility.
|
|
The only real difference between `GPU_SHADER_2D_FLAT_COLOR` and
`GPU_SHADER_3D_FLAT_COLOR` is that in the vertex shader the 2D
version uses `vec4(pos, 0.0, 1.0)` and the 3D version uses
`vec4(pos, 1.0)`.
But VBOs with 2D attributes work perfectly in shaders that use 3D
attributes. Components not specified are filled with components from
`vec4(0.0, 0.0, 0.0, 1.0)`.
So there is no real benefit to having two different shader versions.
This will simplify porting shaders to python as it will not be
necessary to use a 3D and a 2D version of the shaders.
In python the new name for '2D_FLAT_COLOR'' and '3D_FLAT_COLOR'
is 'FLAT_COLOR', but the old names still work for backward
compatibility.
|
|
The only real difference between `GPU_SHADER_2D_UNIFORM_COLOR` and
`GPU_SHADER_3D_UNIFORM_COLOR` is that in the vertex shader the 2D
version uses `vec4(pos, 0.0, 1.0)` and the 3D version uses
`vec4(pos, 1.0)`.
But VBOs with 2D attributes work perfectly in shaders that use 3D
attributes. Components not specified are filled with components from
`vec4(0.0, 0.0, 0.0, 1.0)`.
So there is no real benefit to having two different shader versions.
This will simplify porting shaders to python as it will not be
necessary to use a 3D and a 2D version of the shaders.
In python the new name for '2D_UNIFORM_COLOR'' and '3D_UNIFORM_COLOR'
is 'UNIFORM_COLOR', but the old names still work for backward
compatibility.
Differential Revision: https://developer.blender.org/D15836
|
|
With the new `attrs_info_get` method, we can get information about
the attributes used in a `GPUShader` and thus have more freedom in the
automatic creation of `GPUVertFormat`s
Reviewed By: fclem, campbellbarton
Differential Revision: https://developer.blender.org/D15764
|
|
This is a complete rewrite of the draw debug drawing module in C++.
It uses `GPUStorageBuf` to store the data to be drawn and use indirect
drawing. This makes it easier to do a mirror API for GPU shaders.
The C++ API class is exposed through `draw_debug.hh` and should be used
when possible in new code.
However, the debug drawing will not work for platform not yet supporting
`GPUStorageBuf`. Also keep in mind that this module must only be used
in debug build for performance and compatibility reasons.
|
|
This patch implements the necessary changes to the GPU module that are
needed by the realtime compositor.
A new function GPU_material_from_callbacks was added to construct a GPU
material from a number of callbacks. A callback to construct the
material graph by adding and linking the necessary GPU material nodes.
And the existing code generator callback. This essentially allows the
construction of GPU materials independent of node trees and without the
need to do any node tree localization.
A new composite source output to the code generator was added. This
output contains the serialization of nodes that are tagged with
GPU_NODE_TAG_COMPOSITOR, which are the nodes linked to the newly added
composite output links.
Two new GPU uniform setters were added for int2 and matrix3 types.
Shader create info now supports generated compute sources.
Shaders starting with gpu_shader_compositor are now considered part of
the shader library.
Additionally, two fixes were implemented. First, GPU setter node
de-duplication now appropriately increments the reference count of the
references resources. Second, unlinked sockets now get their value from
their associated GPU node stack instead of the socket itself.
Differential Revision: https://developer.blender.org/D14690
Reviewed By: Clement
|
|
Revert change from [0] that assumed UNORM was a mis-spelling of UNIFORM.
[0]: 2c75857f9fc0dc5d524e4a0407e0a68856e5906e
|
|
python API
Adds an example python script to the documentation for the 3D_IMAGE shader.
The **use-case** is to draw textures with 3D vertex positions, in XR views as well as non-XR views (in a simpler manner).
**Testing**: I've tested that this compiles and works on my Macbook (with the example python script included in this change). I don't have access to a Windows or Linux machine right now, but this change doesn't look platform-specific and no new glsl shaders have been added or edited by this change. I'll try to get access to a Windows machine, but if someone does have one, I'd be really grateful if they could try this change. Thanks!
**Problem addressed**: The existing 2D_IMAGE shader (exposed in the python API) gets near-clipped when drawn in the
XR view, regardless of the near-clip settings. Additionally, the 2D_IMAGE shader only accepts 2D
positions for the image vertices, which means drawing textures in 3D requires providing
2D coordinates and then pushing a transform-rotate-scale matrix to the GPU, even for
non-XR (i.e. WINDOW) views. The 3D_IMAGE shader is simpler: it accepts 3D vertex positions, and doesn't require
any additional work by the scripter.
**Workaround**: The current workaround is to use custom shaders in the python script.
**Non-intrusive change**: No new glsl shaders were added. This change just bundles two existing shaders: the vertex shader used
by the 3D_IMAGE_MODULATE_ALPHA shader, and the fragment shader used by the 2D_IMAGE shader.
Reviewed By: #eevee_viewport, jbakker
Differential Revision: https://developer.blender.org/D14832
|
|
This had only one use and it was for debugging. Remove the shader for now.
This also simplifies the debug drawing even if slower.
|
|
Since shader sources are now parsed on demand via `GPUShaderCreateInfo`,
sources are not available to be read via
`GPU_shader_get_builtin_shader_code`.
Currently this results in a crash as the code tries to read `NULL`
pointers.
`GPU_shader_get_builtin_shader_code` was created with the intention of
informing the user how a builtin shader works, thus "replacing"
detailed documentation.
Therefore this function doesn't really have a practical use in an addon.
So, instead of updating the function (which would require several
changes to the gpu module), remove it and improve the documentation.
Release Notes: https://wiki.blender.org/wiki/Reference/Release_Notes/3.2/Python_API#Breaking_Changes
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D14678
|
|
In order to allow GLSL Cross Compilation across platforms, expose in
Python the `GPUShaderCreateInfo` strategy as detailed in
https://wiki.blender.org/wiki/EEVEE_%26_Viewport/GPU_Module/GLSL_Cross_Compilation
The new features can be listed as follows:
```
>>> gpu.types.GPUShaderCreateInfo.
define(
fragment_out(
fragment_source(
push_constant(
sampler(
typedef_source(
uniform_buf(
vertex_in(
vertex_out(
vertex_source(
>>> gpu.types.GPUStageInterfaceInfo.
flat(
name
no_perspective(
smooth(
>>> gpu.shader.create_from_info(
```
Reviewed By: fclem, campbellbarton
Differential Revision: https://developer.blender.org/D14497
|
|
Add blank lines after file references to avoid them being interpreted as
doc-strings the following declarations.
|
|
Use a shorter/simpler license convention, stops the header taking so
much space.
Follow the SPDX license specification: https://spdx.org/licenses
- C/C++/objc/objc++
- Python
- Shell Scripts
- CMake, GNUmakefile
While most of the source tree has been included
- `./extern/` was left out.
- `./intern/cycles` & `./intern/atomic` are also excluded because they
use different header conventions.
doc/license/SPDX-license-identifiers.txt has been added to list SPDX all
used identifiers.
See P2788 for the script that automated these edits.
Reviewed By: brecht, mont29, sergey
Ref D14069
|
|
This allows to check if a create_info extists based on its name.
|
|
Also adds a few things to GPUShader for easily create shaders.
Heavy usage of macros to compose the createInfo and avoid
duplications and copy paste bugs.
This makes the link between the shader request functions
(in workbench_shader.cc) and the actual createInfo a bit
obscure since the names are composed and not searchable.
Reviewed By: jbakker
Differential Revision: https://developer.blender.org/D13910
|
|
This function will be used as the way to build shaders from
create_infos. The previous used method was using a private function.
|
|
This reverts commit edee5a947b7ea3e1324aa334a22c7c9bbf47f5f7.
Fixes compilation error (Missing file BLI_float2.hh)
|
|
This reverts commit 8fb2ff458ba579dba08bfdf57d043ad158b5db07.
Missing some files.
|
|
This is a first part of the Shader Create Info system could be.
A shader create info provides a way to define shader structure, resources
and interfaces. This makes for a quick way to provide backend agnostic
binding informations while also making shader variations easy to declare.
- Clear source input (only one file). Cleans up the GPU api since we can create a
shader from one descriptor
- Resources and interfaces are generated by the backend (much simpler than parsing).
- Bindings are explicit from position in the array.
- GPUShaderInterface becomes a trivial translation of enums and string copy.
- No external dependency to third party lib.
- Cleaner code, less fragmentation of resources in several libs.
- Easy to modify / extend at runtime.
- no parser involve, very easy to code.
- Does not hold any data, can be static and kept on disc.
- Could hold precompiled bytecode for static shaders.
This also includes a new global dependency system.
GLSL shaders can include other sources by using #pragma BLENDER_REQUIRE(...).
This patch already migrated several builtin shaders. Other shaders should be migrated
one at a time, and could be done inside master.
There is a new compile directive `WITH_GPU_SHADER_BUILDER` this is an optional
directive for linting shaders to increase turn around time.
What is remaining:
- pyGPU API {T94975}
- Migration of other shaders. This could be a community effort.
Reviewed By: jbakker
Maniphest Tasks: T94975
Differential Revision: https://developer.blender.org/D13360
|
|
Shader isn't used and not accessible via py-api.
|
|
Shader isn't used and not accessible via py-api.
|
|
Shader isn't used and not accessible via py-api.
|
|
Shader isn't used and not accessible via py-api.
|
|
Shader isn't used and not accessible via the py-api.
|
|
Shader isn't used and isn't accessible via py-api.
|
|
|
|
The UV shaders have been migrated to the overlay engine and aren't
accessible via the python API.
|
|
MSVC used to warn about const mismatch for arguments passed by value.
Remove these as newer versions of MSVC no longer show this warning.
|
|
Ref T92709
|
|
Issue introduced in {7e66616b7e15} where the shader was replaced with a
2d image shader. This patch reverts several commits that removed the 3d
image shader.
|
|
No functional change.
The shader is complicated by itself, having hardcoded values makes it
even more cryptic.
I also renamed the shader because the shader is not for the keyfarme diamond only,
but for all the keyframe shapes.
Differential Revision: https://developer.blender.org/D12615
|
|
Added optional `name` argument to `GPUShader` constructor
(defaults to `pyGPUShader`), and added `name` getter to `GPUShader`.
Ref D12393
Reviewed By: campbellbarton, jbakker
|
|
Shader doesn't have any shader code. Requesting the shader
would crash blender. Solved by removing the enum_value.
|
|
With the compute pipeline calculation can be offloaded to the GPU.
This patch only adds the framework for compute. So no changes for users at
this moment.
NOTE: As this is an OpenGL4.3 feature it must always have a fallback.
Use `GPU_compute_shader_support` to check if compute pipeline can be used.
Check `gpu_shader_compute*` test cases for usage.
This patch also adds support for shader storage buffer objects and device only
vertex/index buffers.
An alternative that had been discussed was adding this to the `GPUBatch`, this
was eventually not chosen as it would lead to more code when used as part of a
shading group. The idea is that we add an `eDRWCommandType` in the near
future.
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D10913
|
|
|
|
|
|
This patch allows the user to type a property name into the
Attribute node, which will then output the value of the property
for each individual object, allowing to e.g. customize shaders
by object without duplicating the shader.
In order to make supporting this easier for Eevee, it is necessary
to explicitly choose whether the attribute is varying or uniform
via a dropdown option of the Attribute node. The dropdown also
allows choosing whether instancing should be taken into account.
The Cycles design treats all attributes as one common namespace,
so the Blender interface converts the enum to a name prefix that
can't be entered using keyboard.
In Eevee, the attributes are provided to the shader via a UBO indexed
with resource_id, similar to the existing Object Info data. Unlike it,
however, it is necessary to maintain a separate buffer for every
requested combination of attributes.
This is done using a hash table with the attribute set as the key,
as it is expected that technically different but similar materials
may use the same set of attributes. In addition, in order to minimize
wasted memory, a sparse UBO pool is implemented, so that chunks that
don't contain any data don't have to be allocated.
The back-end Cycles code is already refactored and committed by Brecht.
Differential Revision: https://developer.blender.org/D2057
|
|
This makes the debugging easier.
|
|
No functional changes
|
|
This avoids the misleading inheritance.
Also cleanup by setting the blender::gpu::Shader as active shader to
avoid some casting.
|
|
This follows the GPU module naming of other buffers.
We pass name to distinguish each GPUUniformBuf in debug mode.
Also remove DRW_uniform_buffer interface.
|
|
|
|
Use macro to get calling function name. Helps debugging shaders.
|
|
|
|
|
|
|
