| Age | Commit message (Collapse) | Author |
|---|
|
|
|
* Mark either all or no class methods with override
* Don't use zero sized array since it has a different size in C and C++.
Using a little more memory here is not significant.
* Don't use deprecated mechanism to mark private GSet members in clang
just like we don't for MSVC, it warns even for simple zero initialization.
|
|
|
|
Currently the emboss is only fading on left side of the widget,
resulting in the emboss extending vertically on the right side
and ending abruptly. This patch fixes this by also fading the
emboss on the right side and making it symmetric.
Differential Revision: https://developer.blender.org/D10810
|
|
|
|
These were limited to obvious cases. Some less obvious cases
were kept as refactoring might make them necessary in future.
|
|
One drawback to trying to predict the number of threads that will be
used in the `task_graph` is that we are only sure of the number when the
threads are running.
Using `BLI_task_parallel_range` allows the driver to
choose the best thread distribution through `parallel_reduce`.
The benefit is most evident on hardware with fewer cores.
This is the result on an 4-core laptop:
||before:|after:
|---|---|---|
|large_mesh_editing:|Average: 5.203638 FPS|Average: 5.398925 FPS
||rdata 15ms iter 43ms (frame 193ms)|rdata 14ms iter 36ms (frame 187ms)
Differential Revision: https://developer.blender.org/D11558
|
|
This is an adaptation of {D11488}.
A disadvantage of manually setting the iter ranges per thread is that
we don't know how many threads are running in the background and so we
don't know how to best distribute the ranges.
To solve this limitation we can use `parallel_reduce` and thus let the
driver choose the best distribution of ranges among the threads.
This proved to be especially beneficial for computers with few cores.
**Benchmarking:**
Here's the result on an 4-core laptop:
||master:|PATCH:
|---|---|---|
|large_mesh_editing:|Average: 5.203638 FPS|Average: 5.398925 FPS
||rdata 15ms iter 43ms (frame 193ms)|rdata 14ms iter 36ms (frame 187ms)
Here's the result on an 8-core PC:
||master:|PATCH:
|---|---|---|
|large_mesh_editing:|Average: 15.267482 FPS|Average: 15.906881 FPS
||rdata 9ms iter 28ms (frame 65ms)|rdata 9ms iter 25ms (frame 63ms)
|large_mesh_editing_ledge: |Average: 15.145966 FPS|Average: 15.520474 FPS
||rdata 9ms iter 29ms (frame 65ms)|rdata 9ms iter 25ms (frame 64ms)
|looptris_test:|Average: 4.001917 FPS|Average: 4.061105 FPS
||rdata 12ms iter 90ms (frame 236ms)|rdata 12ms iter 87ms (frame 230ms)
|subdiv_mesh_cage_and_final:|Average: 1.917769 FPS|Average: 1.971790 FPS
||rdata 7ms iter 37ms (frame 261ms)|rdata 7ms iter 31ms (frame 258ms)
||rdata 7ms iter 38ms (frame 252ms)|rdata 7ms iter 33ms (frame 249ms)
|subdiv_mesh_final_only:|Average: 6.387240 FPS|Average: 6.591251 FPS
||rdata 3ms iter 25ms (frame 151ms)|rdata 3ms iter 16ms (frame 145ms)
|subdiv_mesh_final_only_ledge:|Average: 6.247393 FPS|Average: 6.596024 FPS
||rdata 3ms iter 26ms (frame 158ms)|rdata 3ms iter 16ms (frame 148ms)
**Notes:**
- The improvement can only be noticed if all extracts are multithreaded.
- This patch touches different areas of the code, so it can be split into another patch if the idea is accepted.
These screenshots show how threads behave in a quadcore:
Master:
{F10164664}
Patch:
{F10164666}
Differential Revision: https://developer.blender.org/D11558
|
|
Current index builder is designed to be used in a single thread.
This makes all index buffer extractions single threaded.
This patch adds a thread safe solution enabling multithreaded
building of index buffers.
To reduce locking the solution would provide a task/thread local
index buffer builder (called sub builder).
When a thread is finished this thread local index buffer builder
can be joined with the initial index buffer builder.
`GPU_indexbuf_subbuilder_init`: Initialized a sub builder. The
index list is shared between the parent and sub buffer, but the
counters are localized. Ensuring that updating counters would
not need any locking.
`GPU_indexbuf_subbuilder_finish`: merge the information of the
sub builder back to the parent builder. Needs to be invoked outside
the worker thread, or when sure that all worker threads have been
finished. Internal the function is not thread safe.
For testing purposes the extract_points extractor has been migrated to
the new API. Herefore changes to the mesh extractor were needed.
* When creating tasks, the task number of current task is stored in
ExtractTaskData including the total number of tasks.
* Adding two functions in `MeshExtract`.
** `task_init` will initialize the task specific userdata.
** `task_finish` should merge back the task specific userdata back.
* adding task_id parameter to the iteration functions so they can
access the correct task data without any need for locking.
There is no noticeable change in end user performance.
Reviewed By: mano-wii
Differential Revision: https://developer.blender.org/D11499
|
|
This reverts commit 43464c94f4def8689dd99a9e459f5ff77420d27b.
|
|
|
|
Apparently `textureSize` doesn't work with
`sampler1DArray` on this OS.
Thanks to @dave1853 for finding the source of the
problem.
|
|
Moving the bounds code to the builder can be useful
for future optimizations like building multithreaded.
Reviewed By: fclem, jbakker
Differential Revision: https://developer.blender.org/D11455
|
|
Cycles, Eevee, OSL, Geo, Attribute
This operator provides consistency with the standard math node. Allows users to use a single node instead of two nodes for this common operation.
Reviewed By: HooglyBoogly, brecht
Differential Revision: https://developer.blender.org/D10808
|
|
When projecting into screen space Z value isn't always needed.
Add 2D projection functions, renaming them to avoid accidents
happening again.
- Add GPU_matrix_project_2fv
- Add ED_view3d_project_v2
- Rename ED_view3d_project to ED_view3d_project_v3
- Use the 2D versions of these functions when the Z value isn't used.
|
|
This patch will use compute shaders to create the VBO for hair.
The previous implementation uses transform feedback.
Timings before: between 0.000069s and 0.000362s.
Timings after: between 0.000032s and 0.000092s.
Speedup isn't noticeable by end-users. The patch is used to test
the new compute shader pipeline and integrate it with the draw
manager. Allowing EEVEE, Workbench and other draw engines to
use compute shaders with the introduction of `DRW_shgroup_call_compute`
and `DRW_shgroup_vertex_buffer`.
Future improvements are possible by generating the index buffer
of hair directly on the GPU.
NOTE: that compute shaders aren't supported by Apple and still use
the transform feedback workaround.
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D11057
|
|
|
|
This reverts commit 8f9599d17e80254928d2d72081a4c7e0dee64038.
Mac seems to have an error with this change.
```
ERROR: /Users/blender/git/blender-vdev/blender.git/source/blender/draw/intern/draw_hair.c:115:44: error: use of undeclared identifier 'shader_src'
ERROR: /Users/blender/git/blender-vdev/blender.git/source/blender/draw/intern/draw_hair.c:123:13: error: use of undeclared identifier 'shader_src'
ERROR: make[2]: *** [source/blender/draw/CMakeFiles/bf_draw.dir/intern/draw_hair.c.o] Error 1
ERROR: make[1]: *** [source/blender/draw/CMakeFiles/bf_draw.dir/all] Error 2
ERROR: make: *** [all] Error 2
```
|
|
This patch will use compute shaders to create the VBO for hair.
The previous implementation uses tranform feedback.
Timings master (transform feedback with GPU_USAGE_STATIC between 0.000069s and 0.000362s
Timings transform feedback with GPU_USAGE_DEVICE_ONLY. between 0.000057s and 0.000122s
Timings compute shader between 0.000032 and 0.000092s
Future improvements:
* Generate hair Index buffer using compute shaders: currently done single threaded on CPU, easy to add as compute shader.
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D11057
|
|
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
|
|
Includes fixes to misspelled function names.
Ref D11280
|
|
Enabled HQ normals workaround for this specific configuration.
|
|
This patch adds wavelength node support to Eevee, similar to how
Eevee Blackbody node works, thus it is a little off from Cycles.
Reviewed By: #eevee_viewport, fclem, brecht
Differential Revision: https://developer.blender.org/D11326
|
|
|
|
Fixes T86097 EEVEE Subsurface Node give blurry edges
|
|
|
|
Changes output for geometry info node in Eevee to be consistent with Cycles (w/o osl)
Before this patch Eevee outputs Z-tangent even for hair. This patch changes it to output hair tangent (growth direction). Hair tangent is impossible to derive otherwise from normal or view direction.
Reviewed By: fclem, brecht
Differential Revision: https://developer.blender.org/D10841
|
|
|
|
This module exposes the platform utils defined in the GPU module in C.
This will be useful for porting existing code with `bgl` to `gpu`.
Reviewed By: fclem, brecht, campbellbarton
Maniphest Tasks: T80730
Part of D11147
|
|
This module exposes the capabilities defined in the GPU module in C.
This will be useful for porting existing code in `bgl` to `gpu`.
Reviewed By: fclem, brecht, campbellbarton
Maniphest Tasks: T80730
Part of D11147
|
|
|
|
This needs to be backported to 2.83.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Resolves occasional glitch/flicker drawing dark buttons in the UI.
Regression in 405a5d3bd7ada5dd5af605b59ba07c7144f144a2
which removed shader unbinding when the batch is drawn.
GPU_shader_bind could run with the sRGB uniform in an unexpected state.
Reviewed By: fclem
Ref D11124
|
|
GPU_NO_USE_PY_REFERENCES`
This is safer for incremental build.
And there was already a macro `GPU_USE_PY_REFERENCES` used elsewhere.
|
|
This commit adds a new API tha allow to replace the bgl API in the exemples on:
https://docs.blender.org/api/current/gpu.html
**Overview (New API):**
```
gpu.state: active_framebuffer_get
GPUFramebuffer: read_color
GPUOffscreen: texture_color
```
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D11031
|
|
Instead of creating different python wrappers for the same GPU object,
return the same `PyObject` created earlier.
This also allows for more secure access to existing GPU objects.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D11044
|
|
|
|
GLDrawList::init() used MDI_INDEXED which checks base_index_.
|
|
Added in rB7cef01b090c4c2d2703274edb91886ae37d3ce82
and rB87bfa2b207b90b5e34ebd835a23c2a82afbed878
Reviewed by: jbakker, #platform_macos
Differential Revision: https://developer.blender.org/D11012
|
|
The SB back-end optimizer for the mesa R600g driver corrupts the vertex
shader for widget drawing. This will not be fixed upstream because SB is
getting replaced as part of the new NIR path. This was thought to be an
issue with instancing and an attempted fix was submitted in D8374, but
it did not fix the issue.
This patch reimplements the array look-up part of the code using switch
case as a workaround and removes the old workaround implemented as part
of D8374.
Reviewed By: Clement Foucault
Differential Revision: https://developer.blender.org/D10967
|
|
|
|
|
|
|
|
Negative speculars are evil.
|
