Commit Graph

45 Commits

Author SHA1 Message Date
Jason Fielder
2e61c446ac GPU: Explicit Texture Usage Flags for enabling GPU Backend optimizations.
Texture usage flags can now be provided during texture creation specifying
the ways in which a texture can be used. This allows the GPU backends to
perform contextual optimizations which were not previously possible. This
includes enablement of hardware lossless compression which can result in
a 15%+ performance uplift for bandwidth-limited scenes on hardware such
as Apple-Silicon using Metal.

GPU_TEXTURE_USAGE_GENERAL can be used by default if usage is not known
ahead of time. Patch will also be relevant for the Vulkan backend.

Authored by Apple: Michael Parkin-White

Ref T96261

Reviewed By: fclem
Differential Revision: https://developer.blender.org/D15967
2022-12-08 23:31:05 +01:00
2a41cd46ba Cleanup: format 2022-11-15 16:43:18 +11:00
187bce103b DRW: Fix compilation issues in inline functions 2022-11-14 14:01:23 +01:00
f1466ce9a8 DRW: Wrappers: Allow taking reference of the framebuffer object
This is in order to make it work with the new `framebuffer_set` command
which requires a `GPUFrameBuffer **`.
2022-11-13 16:02:57 +01:00
0e4bdd428c DRW: Wrappers: Allow trivial types inside draw::SwapChain
This allows to use pointers and such other trivial types which cannot
implement the `swap` mehod.
2022-11-13 16:00:58 +01:00
67dfb61700 DRW: Wrappers: Avoid default vector length of 0 if sizeof(T) is large
This increases the default size to some reasonable value (>512bytes) and
allocate at least 1 element.
2022-11-13 15:59:23 +01:00
7a9a83f4a0 DRW: Wrappers: Add TextureRef to wrap around GPUTexture pointers
This adds the possibility to use the C++ API for other GPUTexture.
2022-10-12 17:39:23 +02:00
4baa6e57bd Cleanup: prefer 'arg' over 'params' for sphinx documentation
While both are supported, 'arg' is in more common use so prefer it.
2022-09-19 14:24:31 +10:00
a1aafddcbe DRW: GPU wrapper: Add new StorageVectorBuffer
Same as `StorageArrayBuffer` but has a length counter and act like a
`blender::Vector` you can clear and append to.
2022-09-17 12:27:00 +02:00
44619eaa32 Cleanup: make format 2022-09-05 17:25:05 +02:00
Clément Foucault
65ad36f5fd DRWManager: New implementation.
This is a new implementation of the draw manager using modern
rendering practices and GPU driven culling.

This only ports features that are not considered deprecated or to be
removed.

The old DRW API is kept working along side this new one, and does not
interfeer with it. However this needed some more hacking inside the
draw_view_lib.glsl. At least the create info are well separated.

The reviewer might start by looking at `draw_pass_test.cc` to see the
API in usage.

Important files are `draw_pass.hh`, `draw_command.hh`,
`draw_command_shared.hh`.

In a nutshell (for a developper used to old DRW API):
- `DRWShadingGroups` are replaced by `Pass<T>::Sub`.
- Contrary to DRWShadingGroups, all commands recorded inside a pass or
   sub-pass (even binds / push_constant / uniforms) will be executed in order.
- All memory is managed per object (except for Sub-Pass which are managed
   by their parent pass) and not from draw manager pools. So passes "can"
   potentially be recorded once and submitted multiple time (but this is
   not really encouraged for now). The only implicit link is between resource
   lifetime and `ResourceHandles`
- Sub passes can be any level deep.
- IMPORTANT: All state propagate from sub pass to subpass. There is no
   state stack concept anymore. Ensure the correct render state is set before
   drawing anything using `Pass::state_set()`.
- The drawcalls now needs a `ResourceHandle` instead of an `Object *`.
   This is to remove any implicit dependency between `Pass` and `Manager`.
   This was a huge problem in old implementation since the manager did not
   know what to pull from the object. Now it is explicitly requested by the
   engine.
- The pases need to be submitted to a `draw::Manager` instance which can
   be retrieved using `DRW_manager_get()` (for now).

Internally:
- All object data are stored in contiguous storage buffers. Removing a lot
   of complexity in the pass submission.
- Draw calls are sorted and visibility tested on GPU. Making more modern
   culling and better instancing usage possible in the future.
- Unit Tests have been added for regression testing and avoid most API
   breakage.
- `draw::View` now contains culling data for all objects in the scene
   allowing caching for multiple views.
- Bounding box and sphere final setup is moved to GPU.
- Some global resources locations have been hardcoded to reduce complexity.

What is missing:
- ~~Workaround for lack of gl_BaseInstanceARB.~~ Done
- ~~Object Uniform Attributes.~~ Done (Not in this patch)
- Workaround for hardware supporting a maximum of 8 SSBO.

Reviewed By: jbakker

Differential Revision: https://developer.blender.org/D15817
2022-09-02 18:45:14 +02:00
78e0c936c1 Merge branch 'blender-v3.3-release' 2022-08-19 17:32:55 +02:00
0c8749788c Fix build error on mips64el architecture
Same as D12194, name "mips" conflicts on such systems.
2022-08-19 17:28:51 +02:00
1f2a5fea87 Cleanup: strip blank lines around comment blocks 2022-08-17 12:51:07 +10:00
b43b62191c EEVEE-Next: HiZ Buffer: New implementation
This new implementation does all downsampling in a single compute shader
dispatch, removing a lot of complexity from the previous recursive
downsampling.

This is heavilly inspired by the Single-Pass-Downsampler from GPUOpen:
https://github.com/GPUOpen-Effects/FidelityFX-SPD
However I do not implement all the optimization bits as they require
vulkan (GL_KHR_shader_subgroup) and is not as versatile (it is only
for HiZ).

Timers inside renderdoc report ~0.4ms of saving on a 2048*1024 render for
the whole downsampling. Note that the previous implementation only
processed 6 mips where the new one processes 8 mips.
```
EEVEE ~1.0ms
EEVEE-Next ~0.6ms
```

Padding has been bumped to be of 128px for processing 8 mips.

A new debug option has been added (debug value 2) to validate the HiZ.
2022-08-15 18:36:19 +02:00
c5526dc6f4 DRW: GPU Wrapper: add possibility to swap Texture and TextureFromPool
Ownership is transfered from the pool to the `Texture` and vice versa.
This allows to have history buffers with only 1 persistent texture.
2022-08-05 14:45:09 +02:00
1ae767be9f Cleanup: DRW: Remove void function argument 2022-08-05 14:45:09 +02:00
710609a2e0 DRW: GPU Wrapper: Fix invalid cached texture view when ensure() reallocs 2022-08-02 21:53:17 +02:00
22143b351f DRW: GPU wrapper: Make SwapChain renference work
This make using texture reference easier. But now, it makes it mandatory
for the wrapped type to implement the `swap()` static method.
2022-08-02 21:53:17 +02:00
04160ffd12 DRW: GPU wrappers: Expose more ease of use functions and cleanup style 2022-08-02 21:53:17 +02:00
82327ce01d DRW: TextureFromPool: Change API to use acquire / release
This removes the quirk of having to call the sync function for each new
render loop.

# Conflicts:
#	source/blender/draw/engines/eevee_next/eevee_view.cc
2022-07-28 17:00:46 +02:00
fde7d39051 Cleanup: DRW: Fix misnamed argument and add more info in a function doc 2022-06-28 18:48:38 +02:00
ae2d2c9361 DRW: GPU wrappers: Fix resize routines for StorageArrayBuffer
Resizing was not resizing the `data_` buffer. Also use `power_of_2_max_u`.
2022-05-19 00:35:36 +02:00
683570c7fe DRW: Wrappers: Use runtime length of the buffer instead of the initial len
This could have produce errors especially in the iterators.
2022-05-18 23:01:08 +02:00
80811c5638 DRW: Replace StorageFlexibleBuffer with explicit get_or_resize()
This is to avoid hiding resize inside the `[]` operator.
2022-05-18 23:01:08 +02:00
c7033bdf26 DRWWrapper: Add StorageFlexibleBuffer
This buffer resizes on access.
2022-05-17 12:34:35 +02:00
65fa34f63f DRW: Add SwapChain container to allow easier usage of double buffering
The template also takes the length of the chain to allow triple buffering.
2022-05-17 12:34:35 +02:00
fa3bd17ae8 GPU: Replace GPUMaterialVolumeGrid by GPUMaterialAttribute
This is to make the codegen and shading nodes object type agnostic. This
is essential for flexibility of the engine to use the nodetree as it see
fits.

The essential volume attributes struct properties are moved to the
`GPUMaterialAttribute` which see its final input name set on creation.

The binding process is centralized into `draw_volume.cc` to avoid
duplicating the code between multiple engines. It mimics the hair attributes
process.

Volume object grid transforms and other per object uniforms are packed into
one UBO per object. The grid transform is now based on object which simplify
the matrix preparations.

This also gets rid of the double transforms and use object info orco factors
for volume objects.

Tagging @brecht because he did the initial implementation of Volume Grids.
2022-04-19 12:09:18 +02:00
4822153b85 Cleanup: spelling in comments 2022-03-23 12:15:50 +11:00
dbf1e7c07f DRW: GPU wrappers: Some quality of life improvements
- Add name support to storage buffers
- Delete view functions for TextureFromPool
- Add support for different size acquire and assert on mulitple acquire
- Allow multiple release
2022-03-19 22:05:34 +01:00
2297db5c49 DRW: gpu wrappers: Fix compilation in release mode 2022-03-18 20:59:48 +01:00
16dd382f06 GPUTexture: Add Cube view as 2D array
This is useful to read/write to the textures directly using compute
shaders and imageLoad/Store.
2022-03-18 20:59:44 +01:00
c509a12fd8 DRW: Expose stencil view in gpu_wrapper 2022-03-18 20:59:40 +01:00
daa26ac0f5 Cleanup: DRW: Fix comments in DRW_gpu_wrapper 2022-03-18 20:59:37 +01:00
0f08453ea9 DRW: Add simple texture view wrappers to draw::Texture 2022-03-18 20:53:41 +01:00
2580869901 DRW: Add support for GPUStorageBuf in wrappers
# Conflicts:
#	source/blender/draw/engines/eevee/eevee_light.cc
#	source/blender/draw/engines/eevee/eevee_shadow.cc
2022-03-18 20:50:25 +01:00
e59f754c16 GPUTexture: Use immutable storage
This means textures need to have the number of mipmap levels specified
upfront. It does not mean the data is immutable.

There is fallback code for OpenGL < 4.2.

Immutable storage will enables texture views in the future.
2022-02-24 22:51:19 +01:00
c434782e3a File headers: SPDX License migration
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
2022-02-11 09:14:36 +11:00
cbd23a7304 DRW: Fix memory leak in UniformArrayBuffer 2022-02-05 13:59:46 +01:00
665997f1cd DRW: Fix bug in cubemap creation in draw::Texture
The order of if clause made impossible to create a cubemap.
2022-02-04 18:54:32 +01:00
012e41fc8b Cleanup: use our own conventions for tags in comments 2022-01-31 10:49:59 +11:00
a21f1e81e0 DRW: Fix some issues with DRW_gpu_wrapper.hh
- Fix assert on size.
- Fix void * casting.
- Pass extent by values.
- Add swap function to avoid letting the types copyable.
- Add back the GPUTexture * operator on TextureFromPool.
2022-01-27 18:46:01 +01:00
658ae5d63f DRW: Fix DRW_gpu_wrapper.hh
The UBYTE datatype is not supported by the clear fallback. Also fix vector
types headers.
2022-01-27 17:05:02 +01:00
cea588b9ef Cleanup: spelling in comments, C++ style comments for disabled code
Also ensure space at end of comment.
2022-01-14 11:23:46 +11:00
ec5560db73 DRW: Add DRW_gpu_wrapper.hh
This adds wrapper classes that make it easier to use GPU objects in C++.

####Motivations:####

 - Easier handling of GPU objects.
 - EEVEE rewrite already makes use of similar wrappers.
 - There is the ongoing effort to use more C++ in the codebase
 and lans to port more engines to it.
 - The shader code refactor will make use of many UBOs with shared
 struct declaration. This helps managing them.
 - Safer handling of `TextureFromPool` which can't be bound as normal
 texture (only texture ref) and can be better tracked in the future.

####Considerations:####

 - I chose the `blender::draw` namespace because `blender::gpu` already has private classes (i.e: `gpu::Texture`).
 - Theses are wrappers that manage a GPU object internally. They might be confused with actual `Texture`. However, the name `TextureWrapper` is a bit too much verbose in my opinion. I'm open to suggestion about better name.

Reviewed By: jbakker

Differential Revision: http://developer.blender.org/D13805
2022-01-12 13:05:18 +01:00