| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
This is important for good texture paint performance.
|
|
|
|
|
|
This is part of the work needed to refactor the material parameters update.
Now the gpupass cache is polled before adding the gpumaterial to the
deferred compilation queue.
We store gpupasses in a single linked list grouped based on their hashes.
This is not the most efficient way but it can be improved upon later.
|
|
|
|
|
|
This commit restores support for Motion Path drawing in 2.8 (as it wasn't ported over
to the new draw engines earlier, and the existing space_view3d/drawanimviz.c code was
removed during the Blender Internal removal).
Notes:
* Motion Paths are now implemented as an overlay (enabled by default).
Therefore, you can turn all of them on/off from the "Overlays" popover
* By and large, we have kept the same draw style as was used in 2.7
Further changes can happen later following further design work.
* One change from 2.7 is that thicker lines are used by default (2px vs 1px)
Todo's:
* There are some bad-level calls introduced here (i.e. the actgroup_to_keylist() stuff).
These were introduced to optimise drawing performance (by avoiding full keyframes -> keylist
conversion step on each drawcall). Instead, this has been moved to the calculation step
(in blenkernel). Soon, there will be some cleanups/improvements with those functions,
so until then, we'll keep the bad level calls.
Credits:
* Clément Foucault (fclem) - Draw Engine magic + Shader Conversion/Optimisation
* Joshua Leung (Aligorith) - COW fixes, UI integration, etc.
Revision History:
See "tmp-b28-motionpath_drawing" branch (rBa12ab5b2ef49ccacae091ccb54d72de0d63f990d)
|
|
|
|
Also use 'uint'.
|
|
This is motivated by the refactor of DRWInstanceData to be actual non
contiguous mempools.
|
|
This new system use transform feedback to compute subdivided hair points
position. For now no smoothing is done between input points.
This new system decouple the strands data (uv, mcol) with the points
position, requiring less update work if only simulation is running.
In the future, we can have compute shader do the work of the feedback
transform pass since it's really what it's meant to. Also we could generate
the child particles during this pass, releasing some CPU time.
draw_hair.c has been created to handle all of the Shading group creations
as well as subdivision shaders.
We store one final batch per settings combination because multiple viewport
or render could use the same particle system with a different subdivision
count or hair shape type.
|
|
|
|
This mimics the behaviour of DRW_shgroup_empty_tri_batch_create and will
replace it eventually.
The advantage is that it's compatible with transform feedback.
|
|
|
|
|
|
This is a usefull feature that can be used to do a lot of precomputation on
the GPU instead of the CPU.
Implementation is simple and only covers the most usefull case.
How to use:
- Create shader with transform feedback.
- Create a pass with DRW_STATE_TRANS_FEEDBACK.
- Create a target Gwn_VertBuf (make sure it's big enough).
- Create a shading group with DRW_shgroup_transform_feedback_create().
- Add your draw calls to the shading group.
- Render your pass normaly.
Current limitation:
- Only one output buffer.
- Cannot pause/resume tfb rendering to interleave with normal drawcalls.
- Cannot get the number of verts drawn.
|
|
And also use a union instead of forcing the cast to void*.
|
|
|
|
|
|
This add a callback function that runs after frustum culling test.
This callback returns the final visibility for this object.
Be aware that it's called for EVERY drawcalls that use this callback even
if their visibility has been cached.
|
|
Same thing for mat3.
|
|
This allow to use int uniforms that are not references. Convenient for ids.
|
|
This uniforms can be used to have a unique id for each drawcall of a shgrp.
This only works for standard shgroups and is an exception for the outline
drawing.
|
|
|
|
|
|
usage.
The problem was that textures were assigned to different slots on different draw
calls, which caused shader specialization/patching by the driver. So the shader
would be compiled over and over until all possible assignments were used.
|
|
This is in order to not mix it with the incomming buffer textures.
|
|
Theses are no longer relevant. Better talk about shgroup directly.
|
|
Previous approach was not clear enough and caused problems.
UBOs were taking slots and not release them after a shading group even
if this UBO was only for this Shading Group (notably the nodetree ubo,
since we now share the same GPUShader for identical trees).
So I choose to have a better defined approach:
- Standard texture and ubo calls are assured to be valid for the shgrp
they are called from.
- (new) Persistent texture and ubo calls are assured to be valid accross
shgrps unless the shader changes.
The standards calls are still valids for the next shgrp but are not assured
to be so if this new shgrp binds a new texture.
This enables some optimisations by not adding redundant texture and ubo
binds.
|
|
This is mostly to avoid re-compilation when using undo/redo operators.
This also has the benefit to reuse the same GPUShader for multiple materials using the same nodetree configuration.
The cache stores GPUPasses that already contains the shader code and a hash to test for matches.
We use refcounts to know when a GPUPass is not used anymore.
I had to move the GPUInput list from GPUPass to GPUMaterial because it's containing references to the material nodetree and cannot be reused.
A garbage collection is hardcoded to run every 60 seconds to free every unused GPUPass.
|
|
|
|
This leads to less lookups to the GWNShaderInterface and less uniform upload.
We still keep a legacy path so that Builtin uniforms can still work. We might restrict this path to Builtin shader only in the future.
|
|
|
|
Instead of creating a new instancing shading group without attrib, we now have instancing calls. The benefits is that they can be culled.
They can be used in conjuction with the standard and generate calls but shader must support it (which is generally not the case).
We store a pointer to the actual count so that the number can be tweaked between redraw.
This will makes multi layer rendering more efficient.
|
|
This is very efficient and add a pretty low overhead (0.1ms of drawing time for 10K objects passing through all tests, on my i3-4100M).
The like the rest of the DRWCallState, test is "cached" until the view matrices changes.
|
|
|
|
|
|
This enables caching the matrices and reducing redraw time of the same object which is particulary important for eevee.
|
|
|
|
|
|
|
|
Refactor include:
- Removal of DRWInterface. (was useless)
- Split DRWCallHeader into a new struct DRWCallState that will be reused in the future.
- Use BLI_link_utils for APPEND/PREPEND.
- Creation of the new DRWManager struct type. This will enable us to create more than one manager in the future.
- Removal of some dead code.
|
