| Age | Commit message (Collapse) | Author |
|---|
|
When resizing a viewport all engine instance data was cleared.
This wasn't the intended design and lead to performance regressions
in the image engine.
This patch makes sure that the instance data isn't cleared when
the viewport size changes. When using instance data, draw engines
are responsible to update the textures accordingly.
This could also reduce flickering/stalling when resizing the viewport
in eevee-next.
Fixes T95428.
Reviewed By: fclem
Maniphest Tasks: T95428
Differential Revision: https://developer.blender.org/D14874
|
|
Each time the user clicks the viewport 2 sets of engine views are
created. Each set is currently composed of 8 view objects, each of size
592 bytes.
Because space is not reserved in the vector that holds them, several
unnecessary re-allocation/copy cycles occur as the vector resizes and
the total allocation load is 8880 bytes. This happens twice.
Reduce to just the allocations necessary and with exactly 4736 bytes
allocated for each set
- Before: 8 allocations and 8 deallocations totaling 17760 bytes
- After: 2 allocations and 2 deallocations totaling 9472 bytes
Reviewed By: fclem, jbakker
Differential Revision: https://developer.blender.org/D13782
|
|
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
|
|
Ref T92709
|
|
In the original design draw engines had to copy with a limitation that
they were not allowed to reuse complex data structures between drawing
calls. Data that could be reused were limited to:
- GPUFramebuffers
- GPUTextures
- Memory that could be removed calling MEM_freeN (storage list)
- DRWPass
This is fine when the storage list contains arrays or structs but when
more complex data types (vectors, maps) etc wasn't possible.
This patch adds instance_data that can be reused between drawing calls.
The instance_data is controlled by the draw engine and doesn't need to
be limited as described above.
When an engines stores instance_data it must implement the
`DrawEngineType.instance_free` callback to free the data.
The patch originates from eevee rewrite. But was added to master as the
image engine rewrite also has a need for it.
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D13425
|
|
This is a necessary step for EEVEE's new arch. This moves more data
to the draw manager. This makes it easier to have the render or draw
engines manage their own data.
This makes more sense and cleans-up what the GPUViewport holds
Also rewrites the Texture pool manager to be in C++.
This also move the DefaultFramebuffer/TextureList and the engine related
data to a new `DRWViewData` struct. This struct manages the per view
(as in stereo view) engine data.
There is a bit of cleanup in the way the draw manager is setup.
We now use a temporary DRWData instead of creating a dummy viewport.
Development: fclem, jbakker
Differential Revision: https://developer.blender.org/D11966
|
