archive/blender-archive
Archived
1
1
Fork 0
Code Pull Requests Packages Activity
This repository has been archived on 2023-10-09. You can view files and clone it, but cannot push or open issues or pull requests.
Files
91d320edc3cfb30443af4adbcb09bc3d7a609e1d
blender-archive/source/blender/draw/intern/draw_instance_data.c

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

411 lines
13 KiB
C
Raw Normal View History

DRW: Add instance data memory manager. This is a special memory manager that keeps memory blocks ready to send as vbo data. Since we loose which memory block was used each DRWShadingGroup we need to redistribute them in the same order/size to avoid to realloc each frame. This is why DRWInstanceDatas are sorted in a list for each different data size.
2018-01-09 14:09:14 +01:00
/*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version 2
* of the License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software Foundation,
* Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
*
Cleanup: add BEGIN/END to GPL headers
2019-01-23 11:29:18 +11:00
* Copyright 2016, Blender Foundation.
DRW: Add instance data memory manager. This is a special memory manager that keeps memory blocks ready to send as vbo data. Since we loose which memory block was used each DRWShadingGroup we need to redistribute them in the same order/size to avoid to realloc each frame. This is why DRWInstanceDatas are sorted in a list for each different data size.
2018-01-09 14:09:14 +01:00
*/
doxygen: add newline after \file While \file doesn't need an argument, it can't have another doxy command after it.
2019-02-18 08:08:12 +11:00
/** \file
* \ingroup draw
DRW: Add instance data memory manager. This is a special memory manager that keeps memory blocks ready to send as vbo data. Since we loose which memory block was used each DRWShadingGroup we need to redistribute them in the same order/size to avoid to realloc each frame. This is why DRWInstanceDatas are sorted in a list for each different data size.
2018-01-09 14:09:14 +01:00
*/
/**
* DRW Instance Data Manager
Cleanup: spelling Also correct wrapped lines of example code in threads.cc.
2020-09-07 15:57:12 +10:00
* This is a special memory manager that keeps memory blocks ready to send as VBO data in one
Cleanup: correct comments
2019-08-18 04:11:41 +10:00
* continuous allocation. This way we avoid feeding #GPUBatch each instance data one by one and
Spelling: Loose Versus Lose Corrects incorrect usages of the word 'loose' when 'lose' was required. Differential Revision: https://developer.blender.org/D9243 Reviewed by Campbell Barton
2020-10-19 09:15:34 -07:00
* unnecessary memcpy. Since we lose which memory block was used each #DRWShadingGroup we need to
Cleanup: comments (long lines) in draw
2019-05-01 10:35:46 +10:00
* redistribute them in the same order/size to avoid to realloc each frame. This is why
* #DRWInstanceDatas are sorted in a list for each different data size.
Cleanup: comment blocks
2019-03-19 15:17:46 +11:00
*/
DRW: Add instance data memory manager. This is a special memory manager that keeps memory blocks ready to send as vbo data. Since we loose which memory block was used each DRWShadingGroup we need to redistribute them in the same order/size to avoid to realloc each frame. This is why DRWInstanceDatas are sorted in a list for each different data size.
2018-01-09 14:09:14 +01:00
#include "draw_instance_data.h"
#include "DRW_engine.h"
DRW: Add instance buffer manager. This manager allows to distribute existing batches for instancing attributes. This reduce the number of batches creation. Querying a batch is done with a vertex format. This format should be static so that it's pointer never changes (because we are using this pointer as identifier [we don't want to check the full format that would be too slow]). This might make the original Instance Data manager useless but it's currently used by DRW_object_engine_data_ensure().
2018-02-14 18:16:52 +01:00
#include "DRW_render.h" /* For DRW_shgroup_get_instance_count() */
DRW: Add instance data memory manager. This is a special memory manager that keeps memory blocks ready to send as vbo data. Since we loose which memory block was used each DRWShadingGroup we need to redistribute them in the same order/size to avoid to realloc each frame. This is why DRWInstanceDatas are sorted in a list for each different data size.
2018-01-09 14:09:14 +01:00
DRW: Refactor: Use DRWCall to accumulate per instance attributes This is a big change that cleanup a lot of confusing code. - The instancing/batching data buffer distribution in draw_instance_data.c. - The selection & drawing code in draw_manager_exec.c - Prety much every non-meshes object drawing (object_mode.c). Most of the changes are just renaming but there still a chance a typo might have sneek through. The Batching/Instancing Shading groups are replace by DRWCallBuffers. This is cleaner and conceptually more in line with what a DRWShadingGroup should be. There is still some little confusion in draw_common.c where some function takes shgroup as input and some don't.
2019-05-13 17:56:20 +02:00
#include "BLI_memblock.h"
Cleanup: `make format` after SortedIncludes change
2020-03-19 09:33:03 +01:00
#include "BLI_mempool.h"
#include "BLI_utildefines.h"
#include "MEM_guardedalloc.h"
DRW: Add instance data memory manager. This is a special memory manager that keeps memory blocks ready to send as vbo data. Since we loose which memory block was used each DRWShadingGroup we need to redistribute them in the same order/size to avoid to realloc each frame. This is why DRWInstanceDatas are sorted in a list for each different data size.
2018-01-09 14:09:14 +01:00
struct DRWInstanceData {
struct DRWInstanceData *next;
bool used; /* If this data is used or not. */
size_t data_size; /* Size of one instance data. */
DRW: Instance Data: Replace with static allocation that can be referenced. This mean you can store data used for drawing inside the object engine data. Also fixes T55243 Crash in ASAN debug builds due to use-after-free memory in draw code - instances issue?
2018-05-30 12:19:20 +02:00
BLI_mempool *mempool;
DRW: Add instance data memory manager. This is a special memory manager that keeps memory blocks ready to send as vbo data. Since we loose which memory block was used each DRWShadingGroup we need to redistribute them in the same order/size to avoid to realloc each frame. This is why DRWInstanceDatas are sorted in a list for each different data size.
2018-01-09 14:09:14 +01:00
};
struct DRWInstanceDataList {
Gawain: Refactor: VAOs caching AND use new VAOs manager. A major bottleneck of current implementation is the call to create_bindings() for basically every drawcalls. This is due to the VAO being tagged dirty when assigning a new shader to the Batch, defeating the purpose of the Batch (reuse it for drawing). Since managing hundreds of batches in DrawManager and DrawCache seems not fun enough to me, I prefered rewritting the batches itself. --- Batch changes --- For this to happen I needed to change the Instancing to be part of the Batch rather than being another batch supplied at drawtime. The Gwn_VertBuffers are copied from the batch to be instanciated and a new Gwn_VertBuffer is supplied for instancing attribs. This mean a VAO can be generated and cached for this instancing case. A Batch can be rendered with instancing, without instancing attribs and without the need for a new VAO using the GWN_batch_draw_range_ex with the force_instance parameter set to true. --- Draw manager changes --- The downside with this approach is that we must track the validity of the instanced batch (the original one). For this the only way (I could think of) is to set a callback for when the batch is getting free. This means a bit of refactor in the DrawManager with the separation of batching and instancing Batches. --- VAO cache --- Each VAO is generated for a given ShaderInterface. This means we can keep it alive as long as the shader interface lives. If a ShaderInterface is discarded, it needs to destroy every VAO associated to it. Otherwise, a new ShaderInterface with the same adress could be generated and reuse the same VAO with incorrect bindings. The VAO cache itself is using a mix between a static array of VAO and a dynamic array if the is not enough space in the static. Using this hybrid approach is a bit more performant than the dynamic array alone. The array will not resize down but empty entries will be filled up again. It's unlikely we get a buffer overflow from this. Resizing could be done on next allocation if needed. --- Results --- Using Cached VAOs means that we are not querying each vertex attrib for each vbo for each drawcall, every redraw! In a CPU limited test scene (10000 cubes in Clay engine) I get a reduction of CPU drawing time from ~20ms to 13ms. The only area that is not caching VAOs is the instancing from particles (see comment DRW_shgroup_instance_batch).
2018-02-20 01:55:19 +01:00
struct DRWInstanceDataList *next, *prev;
DRW: Add instance data memory manager. This is a special memory manager that keeps memory blocks ready to send as vbo data. Since we loose which memory block was used each DRWShadingGroup we need to redistribute them in the same order/size to avoid to realloc each frame. This is why DRWInstanceDatas are sorted in a list for each different data size.
2018-01-09 14:09:14 +01:00
/* Linked lists for all possible data pool size */
DRWInstanceData *idata_head[MAX_INSTANCE_DATA_SIZE];
DRWInstanceData *idata_tail[MAX_INSTANCE_DATA_SIZE];
DRW: Add instance buffer manager. This manager allows to distribute existing batches for instancing attributes. This reduce the number of batches creation. Querying a batch is done with a vertex format. This format should be static so that it's pointer never changes (because we are using this pointer as identifier [we don't want to check the full format that would be too slow]). This might make the original Instance Data manager useless but it's currently used by DRW_object_engine_data_ensure().
2018-02-14 18:16:52 +01:00
DRW: Refactor: Use DRWCall to accumulate per instance attributes This is a big change that cleanup a lot of confusing code. - The instancing/batching data buffer distribution in draw_instance_data.c. - The selection & drawing code in draw_manager_exec.c - Prety much every non-meshes object drawing (object_mode.c). Most of the changes are just renaming but there still a chance a typo might have sneek through. The Batching/Instancing Shading groups are replace by DRWCallBuffers. This is cleaner and conceptually more in line with what a DRWShadingGroup should be. There is still some little confusion in draw_common.c where some function takes shgroup as input and some don't.
2019-05-13 17:56:20 +02:00
BLI_memblock *pool_instancing;
BLI_memblock *pool_batching;
BLI_memblock *pool_buffers;
DRW: Add instance data memory manager. This is a special memory manager that keeps memory blocks ready to send as vbo data. Since we loose which memory block was used each DRWShadingGroup we need to redistribute them in the same order/size to avoid to realloc each frame. This is why DRWInstanceDatas are sorted in a list for each different data size.
2018-01-09 14:09:14 +01:00
};
DRW: Refactor: Use DRWCall to accumulate per instance attributes This is a big change that cleanup a lot of confusing code. - The instancing/batching data buffer distribution in draw_instance_data.c. - The selection & drawing code in draw_manager_exec.c - Prety much every non-meshes object drawing (object_mode.c). Most of the changes are just renaming but there still a chance a typo might have sneek through. The Batching/Instancing Shading groups are replace by DRWCallBuffers. This is cleaner and conceptually more in line with what a DRWShadingGroup should be. There is still some little confusion in draw_common.c where some function takes shgroup as input and some don't.
2019-05-13 17:56:20 +02:00
typedef struct DRWTempBufferHandle {
DRW: InstanceData: Remove hacks of batch freeing callback We instead use a handle reference counter on the GPUVertBufs used by the instancing batches. This make sure that if an update happens on the GPUVertBuf used to contruct the batch, they will never have the same memory address than the previously allocated ones (since they are still pending deletion thanks to the refcounter). This avoid the linear search to update the GPUBatch in the case a batch is deleted (which was even a bad option since they could be only cleared)
2020-08-10 01:43:50 +02:00
GPUVertBuf *buf;
DRW: Refactor: Use DRWCall to accumulate per instance attributes This is a big change that cleanup a lot of confusing code. - The instancing/batching data buffer distribution in draw_instance_data.c. - The selection & drawing code in draw_manager_exec.c - Prety much every non-meshes object drawing (object_mode.c). Most of the changes are just renaming but there still a chance a typo might have sneek through. The Batching/Instancing Shading groups are replace by DRWCallBuffers. This is cleaner and conceptually more in line with what a DRWShadingGroup should be. There is still some little confusion in draw_common.c where some function takes shgroup as input and some don't.
2019-05-13 17:56:20 +02:00
/** Format pointer for reuse. */
GPUVertFormat *format;
/** Touched vertex length for resize. */
DRW: Refactor to support draw call batching Reviewers: brecht Differential Revision: D4997
2019-05-31 01:45:41 +02:00
int *vert_len;
DRW: Refactor: Use DRWCall to accumulate per instance attributes This is a big change that cleanup a lot of confusing code. - The instancing/batching data buffer distribution in draw_instance_data.c. - The selection & drawing code in draw_manager_exec.c - Prety much every non-meshes object drawing (object_mode.c). Most of the changes are just renaming but there still a chance a typo might have sneek through. The Batching/Instancing Shading groups are replace by DRWCallBuffers. This is cleaner and conceptually more in line with what a DRWShadingGroup should be. There is still some little confusion in draw_common.c where some function takes shgroup as input and some don't.
2019-05-13 17:56:20 +02:00
} DRWTempBufferHandle;
DRW: InstanceData: Remove hacks of batch freeing callback We instead use a handle reference counter on the GPUVertBufs used by the instancing batches. This make sure that if an update happens on the GPUVertBuf used to contruct the batch, they will never have the same memory address than the previously allocated ones (since they are still pending deletion thanks to the refcounter). This avoid the linear search to update the GPUBatch in the case a batch is deleted (which was even a bad option since they could be only cleared)
2020-08-10 01:43:50 +02:00
typedef struct DRWTempInstancingHandle {
/** Copy of geom but with the per-instance attributes. */
GPUBatch *batch;
/** Batch containing instancing attributes. */
GPUBatch *instancer;
/** Callbuffer to be used instead of instancer . */
GPUVertBuf *buf;
/** Original non-instanced batch pointer. */
GPUBatch *geom;
} DRWTempInstancingHandle;
Gawain: Refactor: VAOs caching AND use new VAOs manager. A major bottleneck of current implementation is the call to create_bindings() for basically every drawcalls. This is due to the VAO being tagged dirty when assigning a new shader to the Batch, defeating the purpose of the Batch (reuse it for drawing). Since managing hundreds of batches in DrawManager and DrawCache seems not fun enough to me, I prefered rewritting the batches itself. --- Batch changes --- For this to happen I needed to change the Instancing to be part of the Batch rather than being another batch supplied at drawtime. The Gwn_VertBuffers are copied from the batch to be instanciated and a new Gwn_VertBuffer is supplied for instancing attribs. This mean a VAO can be generated and cached for this instancing case. A Batch can be rendered with instancing, without instancing attribs and without the need for a new VAO using the GWN_batch_draw_range_ex with the force_instance parameter set to true. --- Draw manager changes --- The downside with this approach is that we must track the validity of the instanced batch (the original one). For this the only way (I could think of) is to set a callback for when the batch is getting free. This means a bit of refactor in the DrawManager with the separation of batching and instancing Batches. --- VAO cache --- Each VAO is generated for a given ShaderInterface. This means we can keep it alive as long as the shader interface lives. If a ShaderInterface is discarded, it needs to destroy every VAO associated to it. Otherwise, a new ShaderInterface with the same adress could be generated and reuse the same VAO with incorrect bindings. The VAO cache itself is using a mix between a static array of VAO and a dynamic array if the is not enough space in the static. Using this hybrid approach is a bit more performant than the dynamic array alone. The array will not resize down but empty entries will be filled up again. It's unlikely we get a buffer overflow from this. Resizing could be done on next allocation if needed. --- Results --- Using Cached VAOs means that we are not querying each vertex attrib for each vbo for each drawcall, every redraw! In a CPU limited test scene (10000 cubes in Clay engine) I get a reduction of CPU drawing time from ~20ms to 13ms. The only area that is not caching VAOs is the instancing from particles (see comment DRW_shgroup_instance_batch).
2018-02-20 01:55:19 +01:00
DRW: InstanceData: Remove hacks of batch freeing callback We instead use a handle reference counter on the GPUVertBufs used by the instancing batches. This make sure that if an update happens on the GPUVertBuf used to contruct the batch, they will never have the same memory address than the previously allocated ones (since they are still pending deletion thanks to the refcounter). This avoid the linear search to update the GPUBatch in the case a batch is deleted (which was even a bad option since they could be only cleared)
2020-08-10 01:43:50 +02:00
static ListBase g_idatalists = {NULL, NULL};
DRW: Add instance buffer manager. This manager allows to distribute existing batches for instancing attributes. This reduce the number of batches creation. Querying a batch is done with a vertex format. This format should be static so that it's pointer never changes (because we are using this pointer as identifier [we don't want to check the full format that would be too slow]). This might make the original Instance Data manager useless but it's currently used by DRW_object_engine_data_ensure().
2018-02-14 18:16:52 +01:00
DRW: InstanceData: Remove hacks of batch freeing callback We instead use a handle reference counter on the GPUVertBufs used by the instancing batches. This make sure that if an update happens on the GPUVertBuf used to contruct the batch, they will never have the same memory address than the previously allocated ones (since they are still pending deletion thanks to the refcounter). This avoid the linear search to update the GPUBatch in the case a batch is deleted (which was even a bad option since they could be only cleared)
2020-08-10 01:43:50 +02:00
static void instancing_batch_references_add(GPUBatch *batch)
DRW: Add instance buffer manager. This manager allows to distribute existing batches for instancing attributes. This reduce the number of batches creation. Querying a batch is done with a vertex format. This format should be static so that it's pointer never changes (because we are using this pointer as identifier [we don't want to check the full format that would be too slow]). This might make the original Instance Data manager useless but it's currently used by DRW_object_engine_data_ensure().
2018-02-14 18:16:52 +01:00
{
DRW: InstanceData: Remove hacks of batch freeing callback We instead use a handle reference counter on the GPUVertBufs used by the instancing batches. This make sure that if an update happens on the GPUVertBuf used to contruct the batch, they will never have the same memory address than the previously allocated ones (since they are still pending deletion thanks to the refcounter). This avoid the linear search to update the GPUBatch in the case a batch is deleted (which was even a bad option since they could be only cleared)
2020-08-10 01:43:50 +02:00
for (int i = 0; i < GPU_BATCH_VBO_MAX_LEN && batch->verts[i]; i++) {
GPU_vertbuf_handle_ref_add(batch->verts[i]);
}
for (int i = 0; i < GPU_BATCH_INST_VBO_MAX_LEN && batch->inst[i]; i++) {
GPU_vertbuf_handle_ref_add(batch->inst[i]);
DRW: Instance: Makes it possible to have instances of a non-init batch
2018-12-18 13:08:08 +01:00
}
DRW: InstanceData: Remove hacks of batch freeing callback We instead use a handle reference counter on the GPUVertBufs used by the instancing batches. This make sure that if an update happens on the GPUVertBuf used to contruct the batch, they will never have the same memory address than the previously allocated ones (since they are still pending deletion thanks to the refcounter). This avoid the linear search to update the GPUBatch in the case a batch is deleted (which was even a bad option since they could be only cleared)
2020-08-10 01:43:50 +02:00
}
DRW: Refactor: Use DRWCall to accumulate per instance attributes This is a big change that cleanup a lot of confusing code. - The instancing/batching data buffer distribution in draw_instance_data.c. - The selection & drawing code in draw_manager_exec.c - Prety much every non-meshes object drawing (object_mode.c). Most of the changes are just renaming but there still a chance a typo might have sneek through. The Batching/Instancing Shading groups are replace by DRWCallBuffers. This is cleaner and conceptually more in line with what a DRWShadingGroup should be. There is still some little confusion in draw_common.c where some function takes shgroup as input and some don't.
2019-05-13 17:56:20 +02:00
DRW: InstanceData: Remove hacks of batch freeing callback We instead use a handle reference counter on the GPUVertBufs used by the instancing batches. This make sure that if an update happens on the GPUVertBuf used to contruct the batch, they will never have the same memory address than the previously allocated ones (since they are still pending deletion thanks to the refcounter). This avoid the linear search to update the GPUBatch in the case a batch is deleted (which was even a bad option since they could be only cleared)
2020-08-10 01:43:50 +02:00
static void instancing_batch_references_remove(GPUBatch *batch)
{
for (int i = 0; i < GPU_BATCH_VBO_MAX_LEN && batch->verts[i]; i++) {
GPU_vertbuf_handle_ref_remove(batch->verts[i]);
}
for (int i = 0; i < GPU_BATCH_INST_VBO_MAX_LEN && batch->inst[i]; i++) {
GPU_vertbuf_handle_ref_remove(batch->inst[i]);
Gawain: Refactor: VAOs caching AND use new VAOs manager. A major bottleneck of current implementation is the call to create_bindings() for basically every drawcalls. This is due to the VAO being tagged dirty when assigning a new shader to the Batch, defeating the purpose of the Batch (reuse it for drawing). Since managing hundreds of batches in DrawManager and DrawCache seems not fun enough to me, I prefered rewritting the batches itself. --- Batch changes --- For this to happen I needed to change the Instancing to be part of the Batch rather than being another batch supplied at drawtime. The Gwn_VertBuffers are copied from the batch to be instanciated and a new Gwn_VertBuffer is supplied for instancing attribs. This mean a VAO can be generated and cached for this instancing case. A Batch can be rendered with instancing, without instancing attribs and without the need for a new VAO using the GWN_batch_draw_range_ex with the force_instance parameter set to true. --- Draw manager changes --- The downside with this approach is that we must track the validity of the instanced batch (the original one). For this the only way (I could think of) is to set a callback for when the batch is getting free. This means a bit of refactor in the DrawManager with the separation of batching and instancing Batches. --- VAO cache --- Each VAO is generated for a given ShaderInterface. This means we can keep it alive as long as the shader interface lives. If a ShaderInterface is discarded, it needs to destroy every VAO associated to it. Otherwise, a new ShaderInterface with the same adress could be generated and reuse the same VAO with incorrect bindings. The VAO cache itself is using a mix between a static array of VAO and a dynamic array if the is not enough space in the static. Using this hybrid approach is a bit more performant than the dynamic array alone. The array will not resize down but empty entries will be filled up again. It's unlikely we get a buffer overflow from this. Resizing could be done on next allocation if needed. --- Results --- Using Cached VAOs means that we are not querying each vertex attrib for each vbo for each drawcall, every redraw! In a CPU limited test scene (10000 cubes in Clay engine) I get a reduction of CPU drawing time from ~20ms to 13ms. The only area that is not caching VAOs is the instancing from particles (see comment DRW_shgroup_instance_batch).
2018-02-20 01:55:19 +01:00
}
}
DRW: Add instance buffer manager. This manager allows to distribute existing batches for instancing attributes. This reduce the number of batches creation. Querying a batch is done with a vertex format. This format should be static so that it's pointer never changes (because we are using this pointer as identifier [we don't want to check the full format that would be too slow]). This might make the original Instance Data manager useless but it's currently used by DRW_object_engine_data_ensure().
2018-02-14 18:16:52 +01:00
DRW: InstanceData: Remove hacks of batch freeing callback We instead use a handle reference counter on the GPUVertBufs used by the instancing batches. This make sure that if an update happens on the GPUVertBuf used to contruct the batch, they will never have the same memory address than the previously allocated ones (since they are still pending deletion thanks to the refcounter). This avoid the linear search to update the GPUBatch in the case a batch is deleted (which was even a bad option since they could be only cleared)
2020-08-10 01:43:50 +02:00
/* -------------------------------------------------------------------- */
/** \name Instance Buffer Management
* \{ */
DRW: Refactor: Use DRWCall to accumulate per instance attributes This is a big change that cleanup a lot of confusing code. - The instancing/batching data buffer distribution in draw_instance_data.c. - The selection & drawing code in draw_manager_exec.c - Prety much every non-meshes object drawing (object_mode.c). Most of the changes are just renaming but there still a chance a typo might have sneek through. The Batching/Instancing Shading groups are replace by DRWCallBuffers. This is cleaner and conceptually more in line with what a DRWShadingGroup should be. There is still some little confusion in draw_common.c where some function takes shgroup as input and some don't.
2019-05-13 17:56:20 +02:00
/**
* This manager allows to distribute existing batches for instancing
* attributes. This reduce the number of batches creation.
* Querying a batch is done with a vertex format. This format should
Spelling: It's Versus Its Corrects incorrect usage of contraction for 'it is', when possessive 'its' was required. Differential Revision: https://developer.blender.org/D9250 Reviewed by Campbell Barton
2020-10-19 08:12:33 -07:00
* be static so that its pointer never changes (because we are using
DRW: Refactor: Use DRWCall to accumulate per instance attributes This is a big change that cleanup a lot of confusing code. - The instancing/batching data buffer distribution in draw_instance_data.c. - The selection & drawing code in draw_manager_exec.c - Prety much every non-meshes object drawing (object_mode.c). Most of the changes are just renaming but there still a chance a typo might have sneek through. The Batching/Instancing Shading groups are replace by DRWCallBuffers. This is cleaner and conceptually more in line with what a DRWShadingGroup should be. There is still some little confusion in draw_common.c where some function takes shgroup as input and some don't.
2019-05-13 17:56:20 +02:00
* this pointer as identifier [we don't want to check the full format
* that would be too slow]).
*/
GPUVertBuf *DRW_temp_buffer_request(DRWInstanceDataList *idatalist,
GPUVertFormat *format,
DRW: Refactor to support draw call batching Reviewers: brecht Differential Revision: D4997
2019-05-31 01:45:41 +02:00
int *vert_len)
Gawain: Refactor: VAOs caching AND use new VAOs manager. A major bottleneck of current implementation is the call to create_bindings() for basically every drawcalls. This is due to the VAO being tagged dirty when assigning a new shader to the Batch, defeating the purpose of the Batch (reuse it for drawing). Since managing hundreds of batches in DrawManager and DrawCache seems not fun enough to me, I prefered rewritting the batches itself. --- Batch changes --- For this to happen I needed to change the Instancing to be part of the Batch rather than being another batch supplied at drawtime. The Gwn_VertBuffers are copied from the batch to be instanciated and a new Gwn_VertBuffer is supplied for instancing attribs. This mean a VAO can be generated and cached for this instancing case. A Batch can be rendered with instancing, without instancing attribs and without the need for a new VAO using the GWN_batch_draw_range_ex with the force_instance parameter set to true. --- Draw manager changes --- The downside with this approach is that we must track the validity of the instanced batch (the original one). For this the only way (I could think of) is to set a callback for when the batch is getting free. This means a bit of refactor in the DrawManager with the separation of batching and instancing Batches. --- VAO cache --- Each VAO is generated for a given ShaderInterface. This means we can keep it alive as long as the shader interface lives. If a ShaderInterface is discarded, it needs to destroy every VAO associated to it. Otherwise, a new ShaderInterface with the same adress could be generated and reuse the same VAO with incorrect bindings. The VAO cache itself is using a mix between a static array of VAO and a dynamic array if the is not enough space in the static. Using this hybrid approach is a bit more performant than the dynamic array alone. The array will not resize down but empty entries will be filled up again. It's unlikely we get a buffer overflow from this. Resizing could be done on next allocation if needed. --- Results --- Using Cached VAOs means that we are not querying each vertex attrib for each vbo for each drawcall, every redraw! In a CPU limited test scene (10000 cubes in Clay engine) I get a reduction of CPU drawing time from ~20ms to 13ms. The only area that is not caching VAOs is the instancing from particles (see comment DRW_shgroup_instance_batch).
2018-02-20 01:55:19 +01:00
{
DRW: Refactor: Use DRWCall to accumulate per instance attributes This is a big change that cleanup a lot of confusing code. - The instancing/batching data buffer distribution in draw_instance_data.c. - The selection & drawing code in draw_manager_exec.c - Prety much every non-meshes object drawing (object_mode.c). Most of the changes are just renaming but there still a chance a typo might have sneek through. The Batching/Instancing Shading groups are replace by DRWCallBuffers. This is cleaner and conceptually more in line with what a DRWShadingGroup should be. There is still some little confusion in draw_common.c where some function takes shgroup as input and some don't.
2019-05-13 17:56:20 +02:00
BLI_assert(format != NULL);
BLI_assert(vert_len != NULL);
DRWTempBufferHandle *handle = BLI_memblock_alloc(idatalist->pool_buffers);
if (handle->format != format) {
handle->format = format;
DRW: InstanceData: Remove hacks of batch freeing callback We instead use a handle reference counter on the GPUVertBufs used by the instancing batches. This make sure that if an update happens on the GPUVertBuf used to contruct the batch, they will never have the same memory address than the previously allocated ones (since they are still pending deletion thanks to the refcounter). This avoid the linear search to update the GPUBatch in the case a batch is deleted (which was even a bad option since they could be only cleared)
2020-08-10 01:43:50 +02:00
GPU_VERTBUF_DISCARD_SAFE(handle->buf);
Cleanup: GPUVertBuf: Replace GPU_vertbuf_create by GPU_vertbuf_calloc This is a simple cleanup to make naming consistent with the rest of the module.
2020-09-06 22:09:51 +02:00
GPUVertBuf *vert = GPU_vertbuf_calloc();
DRW: Refactor: Use DRWCall to accumulate per instance attributes This is a big change that cleanup a lot of confusing code. - The instancing/batching data buffer distribution in draw_instance_data.c. - The selection & drawing code in draw_manager_exec.c - Prety much every non-meshes object drawing (object_mode.c). Most of the changes are just renaming but there still a chance a typo might have sneek through. The Batching/Instancing Shading groups are replace by DRWCallBuffers. This is cleaner and conceptually more in line with what a DRWShadingGroup should be. There is still some little confusion in draw_common.c where some function takes shgroup as input and some don't.
2019-05-13 17:56:20 +02:00
GPU_vertbuf_init_with_format_ex(vert, format, GPU_USAGE_DYNAMIC);
GPU_vertbuf_data_alloc(vert, DRW_BUFFER_VERTS_CHUNK);
DRW: InstanceData: Remove hacks of batch freeing callback We instead use a handle reference counter on the GPUVertBufs used by the instancing batches. This make sure that if an update happens on the GPUVertBuf used to contruct the batch, they will never have the same memory address than the previously allocated ones (since they are still pending deletion thanks to the refcounter). This avoid the linear search to update the GPUBatch in the case a batch is deleted (which was even a bad option since they could be only cleared)
2020-08-10 01:43:50 +02:00
handle->buf = vert;
Gawain: Refactor: VAOs caching AND use new VAOs manager. A major bottleneck of current implementation is the call to create_bindings() for basically every drawcalls. This is due to the VAO being tagged dirty when assigning a new shader to the Batch, defeating the purpose of the Batch (reuse it for drawing). Since managing hundreds of batches in DrawManager and DrawCache seems not fun enough to me, I prefered rewritting the batches itself. --- Batch changes --- For this to happen I needed to change the Instancing to be part of the Batch rather than being another batch supplied at drawtime. The Gwn_VertBuffers are copied from the batch to be instanciated and a new Gwn_VertBuffer is supplied for instancing attribs. This mean a VAO can be generated and cached for this instancing case. A Batch can be rendered with instancing, without instancing attribs and without the need for a new VAO using the GWN_batch_draw_range_ex with the force_instance parameter set to true. --- Draw manager changes --- The downside with this approach is that we must track the validity of the instanced batch (the original one). For this the only way (I could think of) is to set a callback for when the batch is getting free. This means a bit of refactor in the DrawManager with the separation of batching and instancing Batches. --- VAO cache --- Each VAO is generated for a given ShaderInterface. This means we can keep it alive as long as the shader interface lives. If a ShaderInterface is discarded, it needs to destroy every VAO associated to it. Otherwise, a new ShaderInterface with the same adress could be generated and reuse the same VAO with incorrect bindings. The VAO cache itself is using a mix between a static array of VAO and a dynamic array if the is not enough space in the static. Using this hybrid approach is a bit more performant than the dynamic array alone. The array will not resize down but empty entries will be filled up again. It's unlikely we get a buffer overflow from this. Resizing could be done on next allocation if needed. --- Results --- Using Cached VAOs means that we are not querying each vertex attrib for each vbo for each drawcall, every redraw! In a CPU limited test scene (10000 cubes in Clay engine) I get a reduction of CPU drawing time from ~20ms to 13ms. The only area that is not caching VAOs is the instancing from particles (see comment DRW_shgroup_instance_batch).
2018-02-20 01:55:19 +01:00
}
DRW: InstanceData: Remove hacks of batch freeing callback We instead use a handle reference counter on the GPUVertBufs used by the instancing batches. This make sure that if an update happens on the GPUVertBuf used to contruct the batch, they will never have the same memory address than the previously allocated ones (since they are still pending deletion thanks to the refcounter). This avoid the linear search to update the GPUBatch in the case a batch is deleted (which was even a bad option since they could be only cleared)
2020-08-10 01:43:50 +02:00
handle->vert_len = vert_len;
return handle->buf;
Gawain: Refactor: VAOs caching AND use new VAOs manager. A major bottleneck of current implementation is the call to create_bindings() for basically every drawcalls. This is due to the VAO being tagged dirty when assigning a new shader to the Batch, defeating the purpose of the Batch (reuse it for drawing). Since managing hundreds of batches in DrawManager and DrawCache seems not fun enough to me, I prefered rewritting the batches itself. --- Batch changes --- For this to happen I needed to change the Instancing to be part of the Batch rather than being another batch supplied at drawtime. The Gwn_VertBuffers are copied from the batch to be instanciated and a new Gwn_VertBuffer is supplied for instancing attribs. This mean a VAO can be generated and cached for this instancing case. A Batch can be rendered with instancing, without instancing attribs and without the need for a new VAO using the GWN_batch_draw_range_ex with the force_instance parameter set to true. --- Draw manager changes --- The downside with this approach is that we must track the validity of the instanced batch (the original one). For this the only way (I could think of) is to set a callback for when the batch is getting free. This means a bit of refactor in the DrawManager with the separation of batching and instancing Batches. --- VAO cache --- Each VAO is generated for a given ShaderInterface. This means we can keep it alive as long as the shader interface lives. If a ShaderInterface is discarded, it needs to destroy every VAO associated to it. Otherwise, a new ShaderInterface with the same adress could be generated and reuse the same VAO with incorrect bindings. The VAO cache itself is using a mix between a static array of VAO and a dynamic array if the is not enough space in the static. Using this hybrid approach is a bit more performant than the dynamic array alone. The array will not resize down but empty entries will be filled up again. It's unlikely we get a buffer overflow from this. Resizing could be done on next allocation if needed. --- Results --- Using Cached VAOs means that we are not querying each vertex attrib for each vbo for each drawcall, every redraw! In a CPU limited test scene (10000 cubes in Clay engine) I get a reduction of CPU drawing time from ~20ms to 13ms. The only area that is not caching VAOs is the instancing from particles (see comment DRW_shgroup_instance_batch).
2018-02-20 01:55:19 +01:00
}
DRW: Add instance buffer manager. This manager allows to distribute existing batches for instancing attributes. This reduce the number of batches creation. Querying a batch is done with a vertex format. This format should be static so that it's pointer never changes (because we are using this pointer as identifier [we don't want to check the full format that would be too slow]). This might make the original Instance Data manager useless but it's currently used by DRW_object_engine_data_ensure().
2018-02-14 18:16:52 +01:00
DRW: InstanceData: Remove hacks of batch freeing callback We instead use a handle reference counter on the GPUVertBufs used by the instancing batches. This make sure that if an update happens on the GPUVertBuf used to contruct the batch, they will never have the same memory address than the previously allocated ones (since they are still pending deletion thanks to the refcounter). This avoid the linear search to update the GPUBatch in the case a batch is deleted (which was even a bad option since they could be only cleared)
2020-08-10 01:43:50 +02:00
/* NOTE: Does not return a valid drawable batch until DRW_instance_buffer_finish has run.
* Initialization is delayed because instancer or geom could still not be initialized. */
DRW: Refactor: Use DRWCall to accumulate per instance attributes This is a big change that cleanup a lot of confusing code. - The instancing/batching data buffer distribution in draw_instance_data.c. - The selection & drawing code in draw_manager_exec.c - Prety much every non-meshes object drawing (object_mode.c). Most of the changes are just renaming but there still a chance a typo might have sneek through. The Batching/Instancing Shading groups are replace by DRWCallBuffers. This is cleaner and conceptually more in line with what a DRWShadingGroup should be. There is still some little confusion in draw_common.c where some function takes shgroup as input and some don't.
2019-05-13 17:56:20 +02:00
GPUBatch *DRW_temp_batch_instance_request(DRWInstanceDataList *idatalist,
GPUVertBuf *buf,
Overlay Engine: Refactor & Cleanup This is the unification of all overlays into one overlay engine as described in T65347. I went over all the code making it more future proof with less hacks and removing old / not relevent parts. Goals / Acheivements: - Remove internal shader usage (only drw shaders) - Remove viewportSize and viewportSizeInv and put them in gloabl ubo - Fixed some drawing issues: Missing probe option and Missing Alt+B clipping of some shader - Remove old (legacy) shaders dependancy (not using view UBO). - Less shader variation (less compilation time at first load and less patching needed for vulkan) - removed some geom shaders when I could - Remove static e_data (except shaders storage where it is OK) - Clear the way to fix some anoying limitations (dithered transparency, background image compositing etc...) - Wireframe drawing now uses the same batching capabilities as workbench & eevee (indirect drawing). - Reduced complexity, removed ~3000 Lines of code in draw (also removed a lot of unused shader in GPU). - Post AA to avoid complexity and cost of MSAA. Remaining issues: - ~~Armature edits, overlay toggles, (... others?) are not refreshing viewport after AA is complete~~ - FXAA is not the best for wires, maybe investigate SMAA - Maybe do something more temporally stable for AA. - ~~Paint overlays are not working with AA.~~ - ~~infront objects are difficult to select.~~ - ~~the infront wires sometimes goes through they solid counterpart (missing clear maybe?) (toggle overlays on-off when using infront+wireframe overlay in solid shading)~~ Note: I made some decision to change slightly the appearance of some objects to simplify their drawing. Namely the empty arrows end (which is now hollow/wire) and distance points of the cameras/spots being done by lines. Reviewed By: jbakker Differential Revision: https://developer.blender.org/D6296
2019-12-02 01:40:58 +01:00
GPUBatch *instancer,
DRW: Refactor: Use DRWCall to accumulate per instance attributes This is a big change that cleanup a lot of confusing code. - The instancing/batching data buffer distribution in draw_instance_data.c. - The selection & drawing code in draw_manager_exec.c - Prety much every non-meshes object drawing (object_mode.c). Most of the changes are just renaming but there still a chance a typo might have sneek through. The Batching/Instancing Shading groups are replace by DRWCallBuffers. This is cleaner and conceptually more in line with what a DRWShadingGroup should be. There is still some little confusion in draw_common.c where some function takes shgroup as input and some don't.
2019-05-13 17:56:20 +02:00
GPUBatch *geom)
Gawain: Refactor: VAOs caching AND use new VAOs manager. A major bottleneck of current implementation is the call to create_bindings() for basically every drawcalls. This is due to the VAO being tagged dirty when assigning a new shader to the Batch, defeating the purpose of the Batch (reuse it for drawing). Since managing hundreds of batches in DrawManager and DrawCache seems not fun enough to me, I prefered rewritting the batches itself. --- Batch changes --- For this to happen I needed to change the Instancing to be part of the Batch rather than being another batch supplied at drawtime. The Gwn_VertBuffers are copied from the batch to be instanciated and a new Gwn_VertBuffer is supplied for instancing attribs. This mean a VAO can be generated and cached for this instancing case. A Batch can be rendered with instancing, without instancing attribs and without the need for a new VAO using the GWN_batch_draw_range_ex with the force_instance parameter set to true. --- Draw manager changes --- The downside with this approach is that we must track the validity of the instanced batch (the original one). For this the only way (I could think of) is to set a callback for when the batch is getting free. This means a bit of refactor in the DrawManager with the separation of batching and instancing Batches. --- VAO cache --- Each VAO is generated for a given ShaderInterface. This means we can keep it alive as long as the shader interface lives. If a ShaderInterface is discarded, it needs to destroy every VAO associated to it. Otherwise, a new ShaderInterface with the same adress could be generated and reuse the same VAO with incorrect bindings. The VAO cache itself is using a mix between a static array of VAO and a dynamic array if the is not enough space in the static. Using this hybrid approach is a bit more performant than the dynamic array alone. The array will not resize down but empty entries will be filled up again. It's unlikely we get a buffer overflow from this. Resizing could be done on next allocation if needed. --- Results --- Using Cached VAOs means that we are not querying each vertex attrib for each vbo for each drawcall, every redraw! In a CPU limited test scene (10000 cubes in Clay engine) I get a reduction of CPU drawing time from ~20ms to 13ms. The only area that is not caching VAOs is the instancing from particles (see comment DRW_shgroup_instance_batch).
2018-02-20 01:55:19 +01:00
{
DRW: Refactor: Use DRWCall to accumulate per instance attributes This is a big change that cleanup a lot of confusing code. - The instancing/batching data buffer distribution in draw_instance_data.c. - The selection & drawing code in draw_manager_exec.c - Prety much every non-meshes object drawing (object_mode.c). Most of the changes are just renaming but there still a chance a typo might have sneek through. The Batching/Instancing Shading groups are replace by DRWCallBuffers. This is cleaner and conceptually more in line with what a DRWShadingGroup should be. There is still some little confusion in draw_common.c where some function takes shgroup as input and some don't.
2019-05-13 17:56:20 +02:00
/* Do not call this with a batch that is already an instancing batch. */
Overlay Engine: Refactor & Cleanup This is the unification of all overlays into one overlay engine as described in T65347. I went over all the code making it more future proof with less hacks and removing old / not relevent parts. Goals / Acheivements: - Remove internal shader usage (only drw shaders) - Remove viewportSize and viewportSizeInv and put them in gloabl ubo - Fixed some drawing issues: Missing probe option and Missing Alt+B clipping of some shader - Remove old (legacy) shaders dependancy (not using view UBO). - Less shader variation (less compilation time at first load and less patching needed for vulkan) - removed some geom shaders when I could - Remove static e_data (except shaders storage where it is OK) - Clear the way to fix some anoying limitations (dithered transparency, background image compositing etc...) - Wireframe drawing now uses the same batching capabilities as workbench & eevee (indirect drawing). - Reduced complexity, removed ~3000 Lines of code in draw (also removed a lot of unused shader in GPU). - Post AA to avoid complexity and cost of MSAA. Remaining issues: - ~~Armature edits, overlay toggles, (... others?) are not refreshing viewport after AA is complete~~ - FXAA is not the best for wires, maybe investigate SMAA - Maybe do something more temporally stable for AA. - ~~Paint overlays are not working with AA.~~ - ~~infront objects are difficult to select.~~ - ~~the infront wires sometimes goes through they solid counterpart (missing clear maybe?) (toggle overlays on-off when using infront+wireframe overlay in solid shading)~~ Note: I made some decision to change slightly the appearance of some objects to simplify their drawing. Namely the empty arrows end (which is now hollow/wire) and distance points of the cameras/spots being done by lines. Reviewed By: jbakker Differential Revision: https://developer.blender.org/D6296
2019-12-02 01:40:58 +01:00
BLI_assert(geom->inst[0] == NULL);
/* Only call with one of them. */
BLI_assert((instancer != NULL) != (buf != NULL));
DRW: Refactor: Use DRWCall to accumulate per instance attributes This is a big change that cleanup a lot of confusing code. - The instancing/batching data buffer distribution in draw_instance_data.c. - The selection & drawing code in draw_manager_exec.c - Prety much every non-meshes object drawing (object_mode.c). Most of the changes are just renaming but there still a chance a typo might have sneek through. The Batching/Instancing Shading groups are replace by DRWCallBuffers. This is cleaner and conceptually more in line with what a DRWShadingGroup should be. There is still some little confusion in draw_common.c where some function takes shgroup as input and some don't.
2019-05-13 17:56:20 +02:00
DRW: InstanceData: Remove hacks of batch freeing callback We instead use a handle reference counter on the GPUVertBufs used by the instancing batches. This make sure that if an update happens on the GPUVertBuf used to contruct the batch, they will never have the same memory address than the previously allocated ones (since they are still pending deletion thanks to the refcounter). This avoid the linear search to update the GPUBatch in the case a batch is deleted (which was even a bad option since they could be only cleared)
2020-08-10 01:43:50 +02:00
DRWTempInstancingHandle *handle = BLI_memblock_alloc(idatalist->pool_instancing);
if (handle->batch == NULL) {
GPUBatch: Move allocator to backend
2020-08-10 11:41:22 +02:00
handle->batch = GPU_batch_calloc();
DRW: Instance Data: Replace GPUBatch bulk allocation by separate alloc This is suboptimal but needed for the new GPU abstraction. Maybe a better solution will be needed if performance is impacted.
2020-08-01 12:57:17 +02:00
}
DRW: InstanceData: Remove hacks of batch freeing callback We instead use a handle reference counter on the GPUVertBufs used by the instancing batches. This make sure that if an update happens on the GPUVertBuf used to contruct the batch, they will never have the same memory address than the previously allocated ones (since they are still pending deletion thanks to the refcounter). This avoid the linear search to update the GPUBatch in the case a batch is deleted (which was even a bad option since they could be only cleared)
2020-08-10 01:43:50 +02:00
GPUBatch *batch = handle->batch;
GPUVertBuf: Make GPUVertBuf private to the GPU module This is just a cleanup to isolate the internals of the vertbuf. This adds some getters to avoid refactor of existing code.
2020-09-06 16:40:07 +02:00
bool instancer_compat = buf ? ((batch->inst[0] == buf) &&
(GPU_vertbuf_get_status(buf) & GPU_VERTBUF_DATA_UPLOADED)) :
DRW: InstanceData: Remove hacks of batch freeing callback We instead use a handle reference counter on the GPUVertBufs used by the instancing batches. This make sure that if an update happens on the GPUVertBuf used to contruct the batch, they will never have the same memory address than the previously allocated ones (since they are still pending deletion thanks to the refcounter). This avoid the linear search to update the GPUBatch in the case a batch is deleted (which was even a bad option since they could be only cleared)
2020-08-10 01:43:50 +02:00
((batch->inst[0] == instancer->verts[0]) &&
(batch->inst[1] == instancer->verts[1]));
GPUBatch: Remove usage of gl_prim_type outside of GPU module
2020-08-08 23:37:43 +02:00
bool is_compatible = (batch->prim_type == geom->prim_type) && instancer_compat &&
GPUBatch: Merge phase and ownership flags and cleanup there usage Also add new flags to communicate specific behavior to future backend.
2020-08-10 03:17:35 +02:00
(batch->flag & GPU_BATCH_BUILDING) == 0 && (batch->elem == geom->elem);
DRW: Refactor: Use DRWCall to accumulate per instance attributes This is a big change that cleanup a lot of confusing code. - The instancing/batching data buffer distribution in draw_instance_data.c. - The selection & drawing code in draw_manager_exec.c - Prety much every non-meshes object drawing (object_mode.c). Most of the changes are just renaming but there still a chance a typo might have sneek through. The Batching/Instancing Shading groups are replace by DRWCallBuffers. This is cleaner and conceptually more in line with what a DRWShadingGroup should be. There is still some little confusion in draw_common.c where some function takes shgroup as input and some don't.
2019-05-13 17:56:20 +02:00
for (int i = 0; i < GPU_BATCH_VBO_MAX_LEN && is_compatible; i++) {
if (batch->verts[i] != geom->verts[i]) {
is_compatible = false;
DRW: Add instance buffer manager. This manager allows to distribute existing batches for instancing attributes. This reduce the number of batches creation. Querying a batch is done with a vertex format. This format should be static so that it's pointer never changes (because we are using this pointer as identifier [we don't want to check the full format that would be too slow]). This might make the original Instance Data manager useless but it's currently used by DRW_object_engine_data_ensure().
2018-02-14 18:16:52 +01:00
}
}
DRW: Refactor: Use DRWCall to accumulate per instance attributes This is a big change that cleanup a lot of confusing code. - The instancing/batching data buffer distribution in draw_instance_data.c. - The selection & drawing code in draw_manager_exec.c - Prety much every non-meshes object drawing (object_mode.c). Most of the changes are just renaming but there still a chance a typo might have sneek through. The Batching/Instancing Shading groups are replace by DRWCallBuffers. This is cleaner and conceptually more in line with what a DRWShadingGroup should be. There is still some little confusion in draw_common.c where some function takes shgroup as input and some don't.
2019-05-13 17:56:20 +02:00
if (!is_compatible) {
DRW: InstanceData: Remove hacks of batch freeing callback We instead use a handle reference counter on the GPUVertBufs used by the instancing batches. This make sure that if an update happens on the GPUVertBuf used to contruct the batch, they will never have the same memory address than the previously allocated ones (since they are still pending deletion thanks to the refcounter). This avoid the linear search to update the GPUBatch in the case a batch is deleted (which was even a bad option since they could be only cleared)
2020-08-10 01:43:50 +02:00
instancing_batch_references_remove(batch);
DRW: Refactor: Use DRWCall to accumulate per instance attributes This is a big change that cleanup a lot of confusing code. - The instancing/batching data buffer distribution in draw_instance_data.c. - The selection & drawing code in draw_manager_exec.c - Prety much every non-meshes object drawing (object_mode.c). Most of the changes are just renaming but there still a chance a typo might have sneek through. The Batching/Instancing Shading groups are replace by DRWCallBuffers. This is cleaner and conceptually more in line with what a DRWShadingGroup should be. There is still some little confusion in draw_common.c where some function takes shgroup as input and some don't.
2019-05-13 17:56:20 +02:00
GPU_batch_clear(batch);
DRW: InstanceData: Remove hacks of batch freeing callback We instead use a handle reference counter on the GPUVertBufs used by the instancing batches. This make sure that if an update happens on the GPUVertBuf used to contruct the batch, they will never have the same memory address than the previously allocated ones (since they are still pending deletion thanks to the refcounter). This avoid the linear search to update the GPUBatch in the case a batch is deleted (which was even a bad option since they could be only cleared)
2020-08-10 01:43:50 +02:00
/* Save args and init later. */
GPUBatch: Merge phase and ownership flags and cleanup there usage Also add new flags to communicate specific behavior to future backend.
2020-08-10 03:17:35 +02:00
batch->flag = GPU_BATCH_BUILDING;
DRW: InstanceData: Remove hacks of batch freeing callback We instead use a handle reference counter on the GPUVertBufs used by the instancing batches. This make sure that if an update happens on the GPUVertBuf used to contruct the batch, they will never have the same memory address than the previously allocated ones (since they are still pending deletion thanks to the refcounter). This avoid the linear search to update the GPUBatch in the case a batch is deleted (which was even a bad option since they could be only cleared)
2020-08-10 01:43:50 +02:00
handle->buf = buf;
handle->instancer = instancer;
handle->geom = geom;
Gawain: Refactor: VAOs caching AND use new VAOs manager. A major bottleneck of current implementation is the call to create_bindings() for basically every drawcalls. This is due to the VAO being tagged dirty when assigning a new shader to the Batch, defeating the purpose of the Batch (reuse it for drawing). Since managing hundreds of batches in DrawManager and DrawCache seems not fun enough to me, I prefered rewritting the batches itself. --- Batch changes --- For this to happen I needed to change the Instancing to be part of the Batch rather than being another batch supplied at drawtime. The Gwn_VertBuffers are copied from the batch to be instanciated and a new Gwn_VertBuffer is supplied for instancing attribs. This mean a VAO can be generated and cached for this instancing case. A Batch can be rendered with instancing, without instancing attribs and without the need for a new VAO using the GWN_batch_draw_range_ex with the force_instance parameter set to true. --- Draw manager changes --- The downside with this approach is that we must track the validity of the instanced batch (the original one). For this the only way (I could think of) is to set a callback for when the batch is getting free. This means a bit of refactor in the DrawManager with the separation of batching and instancing Batches. --- VAO cache --- Each VAO is generated for a given ShaderInterface. This means we can keep it alive as long as the shader interface lives. If a ShaderInterface is discarded, it needs to destroy every VAO associated to it. Otherwise, a new ShaderInterface with the same adress could be generated and reuse the same VAO with incorrect bindings. The VAO cache itself is using a mix between a static array of VAO and a dynamic array if the is not enough space in the static. Using this hybrid approach is a bit more performant than the dynamic array alone. The array will not resize down but empty entries will be filled up again. It's unlikely we get a buffer overflow from this. Resizing could be done on next allocation if needed. --- Results --- Using Cached VAOs means that we are not querying each vertex attrib for each vbo for each drawcall, every redraw! In a CPU limited test scene (10000 cubes in Clay engine) I get a reduction of CPU drawing time from ~20ms to 13ms. The only area that is not caching VAOs is the instancing from particles (see comment DRW_shgroup_instance_batch).
2018-02-20 01:55:19 +01:00
}
DRW: Refactor: Use DRWCall to accumulate per instance attributes This is a big change that cleanup a lot of confusing code. - The instancing/batching data buffer distribution in draw_instance_data.c. - The selection & drawing code in draw_manager_exec.c - Prety much every non-meshes object drawing (object_mode.c). Most of the changes are just renaming but there still a chance a typo might have sneek through. The Batching/Instancing Shading groups are replace by DRWCallBuffers. This is cleaner and conceptually more in line with what a DRWShadingGroup should be. There is still some little confusion in draw_common.c where some function takes shgroup as input and some don't.
2019-05-13 17:56:20 +02:00
return batch;
}
/* NOTE: Use only with buf allocated via DRW_temp_buffer_request. */
GPUBatch *DRW_temp_batch_request(DRWInstanceDataList *idatalist,
GPUVertBuf *buf,
GPUPrimType prim_type)
{
DRW: InstanceData: Remove hacks of batch freeing callback We instead use a handle reference counter on the GPUVertBufs used by the instancing batches. This make sure that if an update happens on the GPUVertBuf used to contruct the batch, they will never have the same memory address than the previously allocated ones (since they are still pending deletion thanks to the refcounter). This avoid the linear search to update the GPUBatch in the case a batch is deleted (which was even a bad option since they could be only cleared)
2020-08-10 01:43:50 +02:00
GPUBatch **batch_ptr = BLI_memblock_alloc(idatalist->pool_batching);
DRW: Instance Data: Replace GPUBatch bulk allocation by separate alloc This is suboptimal but needed for the new GPU abstraction. Maybe a better solution will be needed if performance is impacted.
2020-08-01 12:57:17 +02:00
if (*batch_ptr == NULL) {
GPUBatch: Move allocator to backend
2020-08-10 11:41:22 +02:00
*batch_ptr = GPU_batch_calloc();
DRW: Instance Data: Replace GPUBatch bulk allocation by separate alloc This is suboptimal but needed for the new GPU abstraction. Maybe a better solution will be needed if performance is impacted.
2020-08-01 12:57:17 +02:00
}
GPUBatch *batch = *batch_ptr;
GPUVertBuf: Make GPUVertBuf private to the GPU module This is just a cleanup to isolate the internals of the vertbuf. This adds some getters to avoid refactor of existing code.
2020-09-06 16:40:07 +02:00
bool is_compatible = (batch->verts[0] == buf) && (batch->prim_type == prim_type) &&
(GPU_vertbuf_get_status(buf) & GPU_VERTBUF_DATA_UPLOADED);
DRW: Refactor: Use DRWCall to accumulate per instance attributes This is a big change that cleanup a lot of confusing code. - The instancing/batching data buffer distribution in draw_instance_data.c. - The selection & drawing code in draw_manager_exec.c - Prety much every non-meshes object drawing (object_mode.c). Most of the changes are just renaming but there still a chance a typo might have sneek through. The Batching/Instancing Shading groups are replace by DRWCallBuffers. This is cleaner and conceptually more in line with what a DRWShadingGroup should be. There is still some little confusion in draw_common.c where some function takes shgroup as input and some don't.
2019-05-13 17:56:20 +02:00
if (!is_compatible) {
GPU_batch_clear(batch);
GPU_batch_init(batch, prim_type, buf, NULL);
DRW: Add instance buffer manager. This manager allows to distribute existing batches for instancing attributes. This reduce the number of batches creation. Querying a batch is done with a vertex format. This format should be static so that it's pointer never changes (because we are using this pointer as identifier [we don't want to check the full format that would be too slow]). This might make the original Instance Data manager useless but it's currently used by DRW_object_engine_data_ensure().
2018-02-14 18:16:52 +01:00
}
DRW: Refactor: Use DRWCall to accumulate per instance attributes This is a big change that cleanup a lot of confusing code. - The instancing/batching data buffer distribution in draw_instance_data.c. - The selection & drawing code in draw_manager_exec.c - Prety much every non-meshes object drawing (object_mode.c). Most of the changes are just renaming but there still a chance a typo might have sneek through. The Batching/Instancing Shading groups are replace by DRWCallBuffers. This is cleaner and conceptually more in line with what a DRWShadingGroup should be. There is still some little confusion in draw_common.c where some function takes shgroup as input and some don't.
2019-05-13 17:56:20 +02:00
return batch;
}
static void temp_buffer_handle_free(DRWTempBufferHandle *handle)
{
handle->format = NULL;
DRW: InstanceData: Remove hacks of batch freeing callback We instead use a handle reference counter on the GPUVertBufs used by the instancing batches. This make sure that if an update happens on the GPUVertBuf used to contruct the batch, they will never have the same memory address than the previously allocated ones (since they are still pending deletion thanks to the refcounter). This avoid the linear search to update the GPUBatch in the case a batch is deleted (which was even a bad option since they could be only cleared)
2020-08-10 01:43:50 +02:00
GPU_VERTBUF_DISCARD_SAFE(handle->buf);
}
static void temp_instancing_handle_free(DRWTempInstancingHandle *handle)
{
instancing_batch_references_remove(handle->batch);
GPU_BATCH_DISCARD_SAFE(handle->batch);
DRW: Add instance buffer manager. This manager allows to distribute existing batches for instancing attributes. This reduce the number of batches creation. Querying a batch is done with a vertex format. This format should be static so that it's pointer never changes (because we are using this pointer as identifier [we don't want to check the full format that would be too slow]). This might make the original Instance Data manager useless but it's currently used by DRW_object_engine_data_ensure().
2018-02-14 18:16:52 +01:00
}
DRW: Instance Data: Replace GPUBatch bulk allocation by separate alloc This is suboptimal but needed for the new GPU abstraction. Maybe a better solution will be needed if performance is impacted.
2020-08-01 12:57:17 +02:00
static void temp_batch_free(GPUBatch **batch)
{
GPU_BATCH_DISCARD_SAFE(*batch);
}
DRW: Add instance buffer manager. This manager allows to distribute existing batches for instancing attributes. This reduce the number of batches creation. Querying a batch is done with a vertex format. This format should be static so that it's pointer never changes (because we are using this pointer as identifier [we don't want to check the full format that would be too slow]). This might make the original Instance Data manager useless but it's currently used by DRW_object_engine_data_ensure().
2018-02-14 18:16:52 +01:00
void DRW_instance_buffer_finish(DRWInstanceDataList *idatalist)
{
DRW: Refactor: Use DRWCall to accumulate per instance attributes This is a big change that cleanup a lot of confusing code. - The instancing/batching data buffer distribution in draw_instance_data.c. - The selection & drawing code in draw_manager_exec.c - Prety much every non-meshes object drawing (object_mode.c). Most of the changes are just renaming but there still a chance a typo might have sneek through. The Batching/Instancing Shading groups are replace by DRWCallBuffers. This is cleaner and conceptually more in line with what a DRWShadingGroup should be. There is still some little confusion in draw_common.c where some function takes shgroup as input and some don't.
2019-05-13 17:56:20 +02:00
/* Resize down buffers in use and send data to GPU. */
BLI_memblock_iter iter;
DRWTempBufferHandle *handle;
BLI_memblock_iternew(idatalist->pool_buffers, &iter);
while ((handle = BLI_memblock_iterstep(&iter))) {
if (handle->vert_len != NULL) {
uint vert_len = *(handle->vert_len);
uint target_buf_size = ((vert_len / DRW_BUFFER_VERTS_CHUNK) + 1) * DRW_BUFFER_VERTS_CHUNK;
GPUVertBuf: Make GPUVertBuf private to the GPU module This is just a cleanup to isolate the internals of the vertbuf. This adds some getters to avoid refactor of existing code.
2020-09-06 16:40:07 +02:00
if (target_buf_size < GPU_vertbuf_get_vertex_alloc(handle->buf)) {
DRW: InstanceData: Remove hacks of batch freeing callback We instead use a handle reference counter on the GPUVertBufs used by the instancing batches. This make sure that if an update happens on the GPUVertBuf used to contruct the batch, they will never have the same memory address than the previously allocated ones (since they are still pending deletion thanks to the refcounter). This avoid the linear search to update the GPUBatch in the case a batch is deleted (which was even a bad option since they could be only cleared)
2020-08-10 01:43:50 +02:00
GPU_vertbuf_data_resize(handle->buf, target_buf_size);
Gawain: Refactor: VAOs caching AND use new VAOs manager. A major bottleneck of current implementation is the call to create_bindings() for basically every drawcalls. This is due to the VAO being tagged dirty when assigning a new shader to the Batch, defeating the purpose of the Batch (reuse it for drawing). Since managing hundreds of batches in DrawManager and DrawCache seems not fun enough to me, I prefered rewritting the batches itself. --- Batch changes --- For this to happen I needed to change the Instancing to be part of the Batch rather than being another batch supplied at drawtime. The Gwn_VertBuffers are copied from the batch to be instanciated and a new Gwn_VertBuffer is supplied for instancing attribs. This mean a VAO can be generated and cached for this instancing case. A Batch can be rendered with instancing, without instancing attribs and without the need for a new VAO using the GWN_batch_draw_range_ex with the force_instance parameter set to true. --- Draw manager changes --- The downside with this approach is that we must track the validity of the instanced batch (the original one). For this the only way (I could think of) is to set a callback for when the batch is getting free. This means a bit of refactor in the DrawManager with the separation of batching and instancing Batches. --- VAO cache --- Each VAO is generated for a given ShaderInterface. This means we can keep it alive as long as the shader interface lives. If a ShaderInterface is discarded, it needs to destroy every VAO associated to it. Otherwise, a new ShaderInterface with the same adress could be generated and reuse the same VAO with incorrect bindings. The VAO cache itself is using a mix between a static array of VAO and a dynamic array if the is not enough space in the static. Using this hybrid approach is a bit more performant than the dynamic array alone. The array will not resize down but empty entries will be filled up again. It's unlikely we get a buffer overflow from this. Resizing could be done on next allocation if needed. --- Results --- Using Cached VAOs means that we are not querying each vertex attrib for each vbo for each drawcall, every redraw! In a CPU limited test scene (10000 cubes in Clay engine) I get a reduction of CPU drawing time from ~20ms to 13ms. The only area that is not caching VAOs is the instancing from particles (see comment DRW_shgroup_instance_batch).
2018-02-20 01:55:19 +01:00
}
DRW: InstanceData: Remove hacks of batch freeing callback We instead use a handle reference counter on the GPUVertBufs used by the instancing batches. This make sure that if an update happens on the GPUVertBuf used to contruct the batch, they will never have the same memory address than the previously allocated ones (since they are still pending deletion thanks to the refcounter). This avoid the linear search to update the GPUBatch in the case a batch is deleted (which was even a bad option since they could be only cleared)
2020-08-10 01:43:50 +02:00
GPU_vertbuf_data_len_set(handle->buf, vert_len);
GPU_vertbuf_use(handle->buf); /* Send data. */
Gawain: Refactor: VAOs caching AND use new VAOs manager. A major bottleneck of current implementation is the call to create_bindings() for basically every drawcalls. This is due to the VAO being tagged dirty when assigning a new shader to the Batch, defeating the purpose of the Batch (reuse it for drawing). Since managing hundreds of batches in DrawManager and DrawCache seems not fun enough to me, I prefered rewritting the batches itself. --- Batch changes --- For this to happen I needed to change the Instancing to be part of the Batch rather than being another batch supplied at drawtime. The Gwn_VertBuffers are copied from the batch to be instanciated and a new Gwn_VertBuffer is supplied for instancing attribs. This mean a VAO can be generated and cached for this instancing case. A Batch can be rendered with instancing, without instancing attribs and without the need for a new VAO using the GWN_batch_draw_range_ex with the force_instance parameter set to true. --- Draw manager changes --- The downside with this approach is that we must track the validity of the instanced batch (the original one). For this the only way (I could think of) is to set a callback for when the batch is getting free. This means a bit of refactor in the DrawManager with the separation of batching and instancing Batches. --- VAO cache --- Each VAO is generated for a given ShaderInterface. This means we can keep it alive as long as the shader interface lives. If a ShaderInterface is discarded, it needs to destroy every VAO associated to it. Otherwise, a new ShaderInterface with the same adress could be generated and reuse the same VAO with incorrect bindings. The VAO cache itself is using a mix between a static array of VAO and a dynamic array if the is not enough space in the static. Using this hybrid approach is a bit more performant than the dynamic array alone. The array will not resize down but empty entries will be filled up again. It's unlikely we get a buffer overflow from this. Resizing could be done on next allocation if needed. --- Results --- Using Cached VAOs means that we are not querying each vertex attrib for each vbo for each drawcall, every redraw! In a CPU limited test scene (10000 cubes in Clay engine) I get a reduction of CPU drawing time from ~20ms to 13ms. The only area that is not caching VAOs is the instancing from particles (see comment DRW_shgroup_instance_batch).
2018-02-20 01:55:19 +01:00
}
}
DRW: Refactor: Use DRWCall to accumulate per instance attributes This is a big change that cleanup a lot of confusing code. - The instancing/batching data buffer distribution in draw_instance_data.c. - The selection & drawing code in draw_manager_exec.c - Prety much every non-meshes object drawing (object_mode.c). Most of the changes are just renaming but there still a chance a typo might have sneek through. The Batching/Instancing Shading groups are replace by DRWCallBuffers. This is cleaner and conceptually more in line with what a DRWShadingGroup should be. There is still some little confusion in draw_common.c where some function takes shgroup as input and some don't.
2019-05-13 17:56:20 +02:00
/* Finish pending instancing batches. */
DRW: InstanceData: Remove hacks of batch freeing callback We instead use a handle reference counter on the GPUVertBufs used by the instancing batches. This make sure that if an update happens on the GPUVertBuf used to contruct the batch, they will never have the same memory address than the previously allocated ones (since they are still pending deletion thanks to the refcounter). This avoid the linear search to update the GPUBatch in the case a batch is deleted (which was even a bad option since they could be only cleared)
2020-08-10 01:43:50 +02:00
DRWTempInstancingHandle *handle_inst;
DRW: Refactor: Use DRWCall to accumulate per instance attributes This is a big change that cleanup a lot of confusing code. - The instancing/batching data buffer distribution in draw_instance_data.c. - The selection & drawing code in draw_manager_exec.c - Prety much every non-meshes object drawing (object_mode.c). Most of the changes are just renaming but there still a chance a typo might have sneek through. The Batching/Instancing Shading groups are replace by DRWCallBuffers. This is cleaner and conceptually more in line with what a DRWShadingGroup should be. There is still some little confusion in draw_common.c where some function takes shgroup as input and some don't.
2019-05-13 17:56:20 +02:00
BLI_memblock_iternew(idatalist->pool_instancing, &iter);
DRW: InstanceData: Remove hacks of batch freeing callback We instead use a handle reference counter on the GPUVertBufs used by the instancing batches. This make sure that if an update happens on the GPUVertBuf used to contruct the batch, they will never have the same memory address than the previously allocated ones (since they are still pending deletion thanks to the refcounter). This avoid the linear search to update the GPUBatch in the case a batch is deleted (which was even a bad option since they could be only cleared)
2020-08-10 01:43:50 +02:00
while ((handle_inst = BLI_memblock_iterstep(&iter))) {
GPUBatch *batch = handle_inst->batch;
GPUBatch: Merge phase and ownership flags and cleanup there usage Also add new flags to communicate specific behavior to future backend.
2020-08-10 03:17:35 +02:00
if (batch && batch->flag == GPU_BATCH_BUILDING) {
DRW: InstanceData: Remove hacks of batch freeing callback We instead use a handle reference counter on the GPUVertBufs used by the instancing batches. This make sure that if an update happens on the GPUVertBuf used to contruct the batch, they will never have the same memory address than the previously allocated ones (since they are still pending deletion thanks to the refcounter). This avoid the linear search to update the GPUBatch in the case a batch is deleted (which was even a bad option since they could be only cleared)
2020-08-10 01:43:50 +02:00
GPUVertBuf *inst_buf = handle_inst->buf;
GPUBatch *inst_batch = handle_inst->instancer;
GPUBatch *geom = handle_inst->geom;
DRW: Refactor: Use DRWCall to accumulate per instance attributes This is a big change that cleanup a lot of confusing code. - The instancing/batching data buffer distribution in draw_instance_data.c. - The selection & drawing code in draw_manager_exec.c - Prety much every non-meshes object drawing (object_mode.c). Most of the changes are just renaming but there still a chance a typo might have sneek through. The Batching/Instancing Shading groups are replace by DRWCallBuffers. This is cleaner and conceptually more in line with what a DRWShadingGroup should be. There is still some little confusion in draw_common.c where some function takes shgroup as input and some don't.
2019-05-13 17:56:20 +02:00
GPU_batch_copy(batch, geom);
Overlay Engine: Refactor & Cleanup This is the unification of all overlays into one overlay engine as described in T65347. I went over all the code making it more future proof with less hacks and removing old / not relevent parts. Goals / Acheivements: - Remove internal shader usage (only drw shaders) - Remove viewportSize and viewportSizeInv and put them in gloabl ubo - Fixed some drawing issues: Missing probe option and Missing Alt+B clipping of some shader - Remove old (legacy) shaders dependancy (not using view UBO). - Less shader variation (less compilation time at first load and less patching needed for vulkan) - removed some geom shaders when I could - Remove static e_data (except shaders storage where it is OK) - Clear the way to fix some anoying limitations (dithered transparency, background image compositing etc...) - Wireframe drawing now uses the same batching capabilities as workbench & eevee (indirect drawing). - Reduced complexity, removed ~3000 Lines of code in draw (also removed a lot of unused shader in GPU). - Post AA to avoid complexity and cost of MSAA. Remaining issues: - ~~Armature edits, overlay toggles, (... others?) are not refreshing viewport after AA is complete~~ - FXAA is not the best for wires, maybe investigate SMAA - Maybe do something more temporally stable for AA. - ~~Paint overlays are not working with AA.~~ - ~~infront objects are difficult to select.~~ - ~~the infront wires sometimes goes through they solid counterpart (missing clear maybe?) (toggle overlays on-off when using infront+wireframe overlay in solid shading)~~ Note: I made some decision to change slightly the appearance of some objects to simplify their drawing. Namely the empty arrows end (which is now hollow/wire) and distance points of the cameras/spots being done by lines. Reviewed By: jbakker Differential Revision: https://developer.blender.org/D6296
2019-12-02 01:40:58 +01:00
if (inst_batch != NULL) {
for (int i = 0; i < GPU_BATCH_INST_VBO_MAX_LEN && inst_batch->verts[i]; i++) {
GPU_batch_instbuf_add_ex(batch, inst_batch->verts[i], false);
}
}
else {
GPU_batch_instbuf_add_ex(batch, inst_buf, false);
}
DRW: InstanceData: Remove hacks of batch freeing callback We instead use a handle reference counter on the GPUVertBufs used by the instancing batches. This make sure that if an update happens on the GPUVertBuf used to contruct the batch, they will never have the same memory address than the previously allocated ones (since they are still pending deletion thanks to the refcounter). This avoid the linear search to update the GPUBatch in the case a batch is deleted (which was even a bad option since they could be only cleared)
2020-08-10 01:43:50 +02:00
/* Add reference to avoid comparing pointers (in DRW_temp_batch_request) that could
* potentially be the same. This will delay the freeing of the GPUVertBuf itself. */
instancing_batch_references_add(batch);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
}
DRW: Add instance buffer manager. This manager allows to distribute existing batches for instancing attributes. This reduce the number of batches creation. Querying a batch is done with a vertex format. This format should be static so that it's pointer never changes (because we are using this pointer as identifier [we don't want to check the full format that would be too slow]). This might make the original Instance Data manager useless but it's currently used by DRW_object_engine_data_ensure().
2018-02-14 18:16:52 +01:00
}
DRW: Refactor: Use DRWCall to accumulate per instance attributes This is a big change that cleanup a lot of confusing code. - The instancing/batching data buffer distribution in draw_instance_data.c. - The selection & drawing code in draw_manager_exec.c - Prety much every non-meshes object drawing (object_mode.c). Most of the changes are just renaming but there still a chance a typo might have sneek through. The Batching/Instancing Shading groups are replace by DRWCallBuffers. This is cleaner and conceptually more in line with what a DRWShadingGroup should be. There is still some little confusion in draw_common.c where some function takes shgroup as input and some don't.
2019-05-13 17:56:20 +02:00
/* Resize pools and free unused. */
BLI_memblock_clear(idatalist->pool_buffers, (MemblockValFreeFP)temp_buffer_handle_free);
DRW: InstanceData: Remove hacks of batch freeing callback We instead use a handle reference counter on the GPUVertBufs used by the instancing batches. This make sure that if an update happens on the GPUVertBuf used to contruct the batch, they will never have the same memory address than the previously allocated ones (since they are still pending deletion thanks to the refcounter). This avoid the linear search to update the GPUBatch in the case a batch is deleted (which was even a bad option since they could be only cleared)
2020-08-10 01:43:50 +02:00
BLI_memblock_clear(idatalist->pool_instancing, (MemblockValFreeFP)temp_instancing_handle_free);
DRW: Instance Data: Replace GPUBatch bulk allocation by separate alloc This is suboptimal but needed for the new GPU abstraction. Maybe a better solution will be needed if performance is impacted.
2020-08-01 12:57:17 +02:00
BLI_memblock_clear(idatalist->pool_batching, (MemblockValFreeFP)temp_batch_free);
DRW: Add instance buffer manager. This manager allows to distribute existing batches for instancing attributes. This reduce the number of batches creation. Querying a batch is done with a vertex format. This format should be static so that it's pointer never changes (because we are using this pointer as identifier [we don't want to check the full format that would be too slow]). This might make the original Instance Data manager useless but it's currently used by DRW_object_engine_data_ensure().
2018-02-14 18:16:52 +01:00
}
/** \} */
/* -------------------------------------------------------------------- */
DRW: Add instance data memory manager. This is a special memory manager that keeps memory blocks ready to send as vbo data. Since we loose which memory block was used each DRWShadingGroup we need to redistribute them in the same order/size to avoid to realloc each frame. This is why DRWInstanceDatas are sorted in a list for each different data size.
2018-01-09 14:09:14 +01:00
/** \name Instance Data (DRWInstanceData)
* \{ */
Cleanup: replace attrib w/ attr Also rename GPUVertexAttribs to GPUVertAttrLayers, avoids confusion with GPUVertAttr which isn't closely related.
2019-01-29 07:46:25 +11:00
static DRWInstanceData *drw_instance_data_create(DRWInstanceDataList *idatalist, uint attr_size)
DRW: Add instance data memory manager. This is a special memory manager that keeps memory blocks ready to send as vbo data. Since we loose which memory block was used each DRWShadingGroup we need to redistribute them in the same order/size to avoid to realloc each frame. This is why DRWInstanceDatas are sorted in a list for each different data size.
2018-01-09 14:09:14 +01:00
{
Gawain: Refactor: VAOs caching AND use new VAOs manager. A major bottleneck of current implementation is the call to create_bindings() for basically every drawcalls. This is due to the VAO being tagged dirty when assigning a new shader to the Batch, defeating the purpose of the Batch (reuse it for drawing). Since managing hundreds of batches in DrawManager and DrawCache seems not fun enough to me, I prefered rewritting the batches itself. --- Batch changes --- For this to happen I needed to change the Instancing to be part of the Batch rather than being another batch supplied at drawtime. The Gwn_VertBuffers are copied from the batch to be instanciated and a new Gwn_VertBuffer is supplied for instancing attribs. This mean a VAO can be generated and cached for this instancing case. A Batch can be rendered with instancing, without instancing attribs and without the need for a new VAO using the GWN_batch_draw_range_ex with the force_instance parameter set to true. --- Draw manager changes --- The downside with this approach is that we must track the validity of the instanced batch (the original one). For this the only way (I could think of) is to set a callback for when the batch is getting free. This means a bit of refactor in the DrawManager with the separation of batching and instancing Batches. --- VAO cache --- Each VAO is generated for a given ShaderInterface. This means we can keep it alive as long as the shader interface lives. If a ShaderInterface is discarded, it needs to destroy every VAO associated to it. Otherwise, a new ShaderInterface with the same adress could be generated and reuse the same VAO with incorrect bindings. The VAO cache itself is using a mix between a static array of VAO and a dynamic array if the is not enough space in the static. Using this hybrid approach is a bit more performant than the dynamic array alone. The array will not resize down but empty entries will be filled up again. It's unlikely we get a buffer overflow from this. Resizing could be done on next allocation if needed. --- Results --- Using Cached VAOs means that we are not querying each vertex attrib for each vbo for each drawcall, every redraw! In a CPU limited test scene (10000 cubes in Clay engine) I get a reduction of CPU drawing time from ~20ms to 13ms. The only area that is not caching VAOs is the instancing from particles (see comment DRW_shgroup_instance_batch).
2018-02-20 01:55:19 +01:00
DRWInstanceData *idata = MEM_callocN(sizeof(DRWInstanceData), "DRWInstanceData");
DRW: Add instance data memory manager. This is a special memory manager that keeps memory blocks ready to send as vbo data. Since we loose which memory block was used each DRWShadingGroup we need to redistribute them in the same order/size to avoid to realloc each frame. This is why DRWInstanceDatas are sorted in a list for each different data size.
2018-01-09 14:09:14 +01:00
idata->next = NULL;
idata->used = true;
Cleanup: replace attrib w/ attr Also rename GPUVertexAttribs to GPUVertAttrLayers, avoids confusion with GPUVertAttr which isn't closely related.
2019-01-29 07:46:25 +11:00
idata->data_size = attr_size;
DRW: Instance Data: Replace with static allocation that can be referenced. This mean you can store data used for drawing inside the object engine data. Also fixes T55243 Crash in ASAN debug builds due to use-after-free memory in draw code - instances issue?
2018-05-30 12:19:20 +02:00
idata->mempool = BLI_mempool_create(sizeof(float) * idata->data_size, 0, 16, 0);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: replace attrib w/ attr Also rename GPUVertexAttribs to GPUVertAttrLayers, avoids confusion with GPUVertAttr which isn't closely related.
2019-01-29 07:46:25 +11:00
BLI_assert(attr_size > 0);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
DRW: Add instance data memory manager. This is a special memory manager that keeps memory blocks ready to send as vbo data. Since we loose which memory block was used each DRWShadingGroup we need to redistribute them in the same order/size to avoid to realloc each frame. This is why DRWInstanceDatas are sorted in a list for each different data size.
2018-01-09 14:09:14 +01:00
/* Push to linked list. */
Cleanup: replace attrib w/ attr Also rename GPUVertexAttribs to GPUVertAttrLayers, avoids confusion with GPUVertAttr which isn't closely related.
2019-01-29 07:46:25 +11:00
if (idatalist->idata_head[attr_size - 1] == NULL) {
idatalist->idata_head[attr_size - 1] = idata;
DRW: Add instance data memory manager. This is a special memory manager that keeps memory blocks ready to send as vbo data. Since we loose which memory block was used each DRWShadingGroup we need to redistribute them in the same order/size to avoid to realloc each frame. This is why DRWInstanceDatas are sorted in a list for each different data size.
2018-01-09 14:09:14 +01:00
}
else {
Cleanup: replace attrib w/ attr Also rename GPUVertexAttribs to GPUVertAttrLayers, avoids confusion with GPUVertAttr which isn't closely related.
2019-01-29 07:46:25 +11:00
idatalist->idata_tail[attr_size - 1]->next = idata;
DRW: Add instance data memory manager. This is a special memory manager that keeps memory blocks ready to send as vbo data. Since we loose which memory block was used each DRWShadingGroup we need to redistribute them in the same order/size to avoid to realloc each frame. This is why DRWInstanceDatas are sorted in a list for each different data size.
2018-01-09 14:09:14 +01:00
}
Cleanup: replace attrib w/ attr Also rename GPUVertexAttribs to GPUVertAttrLayers, avoids confusion with GPUVertAttr which isn't closely related.
2019-01-29 07:46:25 +11:00
idatalist->idata_tail[attr_size - 1] = idata;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
DRW: Add instance data memory manager. This is a special memory manager that keeps memory blocks ready to send as vbo data. Since we loose which memory block was used each DRWShadingGroup we need to redistribute them in the same order/size to avoid to realloc each frame. This is why DRWInstanceDatas are sorted in a list for each different data size.
2018-01-09 14:09:14 +01:00
return idata;
}
static void DRW_instance_data_free(DRWInstanceData *idata)
{
DRW: Instance Data: Replace with static allocation that can be referenced. This mean you can store data used for drawing inside the object engine data. Also fixes T55243 Crash in ASAN debug builds due to use-after-free memory in draw code - instances issue?
2018-05-30 12:19:20 +02:00
BLI_mempool_destroy(idata->mempool);
DRW: Add instance data memory manager. This is a special memory manager that keeps memory blocks ready to send as vbo data. Since we loose which memory block was used each DRWShadingGroup we need to redistribute them in the same order/size to avoid to realloc each frame. This is why DRWInstanceDatas are sorted in a list for each different data size.
2018-01-09 14:09:14 +01:00
}
/**
* Return a pointer to the next instance data space.
Cleanup: comment blocks
2019-03-19 15:17:46 +11:00
*/
DRW: Add instance data memory manager. This is a special memory manager that keeps memory blocks ready to send as vbo data. Since we loose which memory block was used each DRWShadingGroup we need to redistribute them in the same order/size to avoid to realloc each frame. This is why DRWInstanceDatas are sorted in a list for each different data size.
2018-01-09 14:09:14 +01:00
void *DRW_instance_data_next(DRWInstanceData *idata)
{
DRW: Instance Data: Replace with static allocation that can be referenced. This mean you can store data used for drawing inside the object engine data. Also fixes T55243 Crash in ASAN debug builds due to use-after-free memory in draw code - instances issue?
2018-05-30 12:19:20 +02:00
return BLI_mempool_alloc(idata->mempool);
DRW: Add instance data memory manager. This is a special memory manager that keeps memory blocks ready to send as vbo data. Since we loose which memory block was used each DRWShadingGroup we need to redistribute them in the same order/size to avoid to realloc each frame. This is why DRWInstanceDatas are sorted in a list for each different data size.
2018-01-09 14:09:14 +01:00
}
Cleanup: replace attrib w/ attr Also rename GPUVertexAttribs to GPUVertAttrLayers, avoids confusion with GPUVertAttr which isn't closely related.
2019-01-29 07:46:25 +11:00
DRWInstanceData *DRW_instance_data_request(DRWInstanceDataList *idatalist, uint attr_size)
DRW: Add instance data memory manager. This is a special memory manager that keeps memory blocks ready to send as vbo data. Since we loose which memory block was used each DRWShadingGroup we need to redistribute them in the same order/size to avoid to realloc each frame. This is why DRWInstanceDatas are sorted in a list for each different data size.
2018-01-09 14:09:14 +01:00
{
Cleanup: replace attrib w/ attr Also rename GPUVertexAttribs to GPUVertAttrLayers, avoids confusion with GPUVertAttr which isn't closely related.
2019-01-29 07:46:25 +11:00
BLI_assert(attr_size > 0 && attr_size <= MAX_INSTANCE_DATA_SIZE);
DRW: Add instance data memory manager. This is a special memory manager that keeps memory blocks ready to send as vbo data. Since we loose which memory block was used each DRWShadingGroup we need to redistribute them in the same order/size to avoid to realloc each frame. This is why DRWInstanceDatas are sorted in a list for each different data size.
2018-01-09 14:09:14 +01:00
Cleanup: replace attrib w/ attr Also rename GPUVertexAttribs to GPUVertAttrLayers, avoids confusion with GPUVertAttr which isn't closely related.
2019-01-29 07:46:25 +11:00
DRWInstanceData *idata = idatalist->idata_head[attr_size - 1];
DRW: Add instance data memory manager. This is a special memory manager that keeps memory blocks ready to send as vbo data. Since we loose which memory block was used each DRWShadingGroup we need to redistribute them in the same order/size to avoid to realloc each frame. This is why DRWInstanceDatas are sorted in a list for each different data size.
2018-01-09 14:09:14 +01:00
/* Search for an unused data chunk. */
for (; idata; idata = idata->next) {
if (idata->used == false) {
idata->used = true;
return idata;
}
}
Cleanup: replace attrib w/ attr Also rename GPUVertexAttribs to GPUVertAttrLayers, avoids confusion with GPUVertAttr which isn't closely related.
2019-01-29 07:46:25 +11:00
return drw_instance_data_create(idatalist, attr_size);
DRW: Add instance data memory manager. This is a special memory manager that keeps memory blocks ready to send as vbo data. Since we loose which memory block was used each DRWShadingGroup we need to redistribute them in the same order/size to avoid to realloc each frame. This is why DRWInstanceDatas are sorted in a list for each different data size.
2018-01-09 14:09:14 +01:00
}
/** \} */
/* -------------------------------------------------------------------- */
/** \name Instance Data List (DRWInstanceDataList)
* \{ */
DRWInstanceDataList *DRW_instance_data_list_create(void)
{
DRW: Add instance buffer manager. This manager allows to distribute existing batches for instancing attributes. This reduce the number of batches creation. Querying a batch is done with a vertex format. This format should be static so that it's pointer never changes (because we are using this pointer as identifier [we don't want to check the full format that would be too slow]). This might make the original Instance Data manager useless but it's currently used by DRW_object_engine_data_ensure().
2018-02-14 18:16:52 +01:00
DRWInstanceDataList *idatalist = MEM_callocN(sizeof(DRWInstanceDataList), "DRWInstanceDataList");
DRW: Refactor: Use DRWCall to accumulate per instance attributes This is a big change that cleanup a lot of confusing code. - The instancing/batching data buffer distribution in draw_instance_data.c. - The selection & drawing code in draw_manager_exec.c - Prety much every non-meshes object drawing (object_mode.c). Most of the changes are just renaming but there still a chance a typo might have sneek through. The Batching/Instancing Shading groups are replace by DRWCallBuffers. This is cleaner and conceptually more in line with what a DRWShadingGroup should be. There is still some little confusion in draw_common.c where some function takes shgroup as input and some don't.
2019-05-13 17:56:20 +02:00
DRW: Instance Data: Replace GPUBatch bulk allocation by separate alloc This is suboptimal but needed for the new GPU abstraction. Maybe a better solution will be needed if performance is impacted.
2020-08-01 12:57:17 +02:00
idatalist->pool_batching = BLI_memblock_create(sizeof(GPUBatch *));
DRW: InstanceData: Remove hacks of batch freeing callback We instead use a handle reference counter on the GPUVertBufs used by the instancing batches. This make sure that if an update happens on the GPUVertBuf used to contruct the batch, they will never have the same memory address than the previously allocated ones (since they are still pending deletion thanks to the refcounter). This avoid the linear search to update the GPUBatch in the case a batch is deleted (which was even a bad option since they could be only cleared)
2020-08-10 01:43:50 +02:00
idatalist->pool_instancing = BLI_memblock_create(sizeof(DRWTempInstancingHandle));
BLI_memblock: Refactor for faster iteration and allocation Remove the clear allocation flag as it has little impact since there should be very few allocation per redraw. Make BLI_memblock_alloc and BLI_memblock_iterstep much more cache efficient removing them almost entirely from performance profiles.
2019-05-21 00:54:03 +02:00
idatalist->pool_buffers = BLI_memblock_create(sizeof(DRWTempBufferHandle));
Gawain: Refactor: VAOs caching AND use new VAOs manager. A major bottleneck of current implementation is the call to create_bindings() for basically every drawcalls. This is due to the VAO being tagged dirty when assigning a new shader to the Batch, defeating the purpose of the Batch (reuse it for drawing). Since managing hundreds of batches in DrawManager and DrawCache seems not fun enough to me, I prefered rewritting the batches itself. --- Batch changes --- For this to happen I needed to change the Instancing to be part of the Batch rather than being another batch supplied at drawtime. The Gwn_VertBuffers are copied from the batch to be instanciated and a new Gwn_VertBuffer is supplied for instancing attribs. This mean a VAO can be generated and cached for this instancing case. A Batch can be rendered with instancing, without instancing attribs and without the need for a new VAO using the GWN_batch_draw_range_ex with the force_instance parameter set to true. --- Draw manager changes --- The downside with this approach is that we must track the validity of the instanced batch (the original one). For this the only way (I could think of) is to set a callback for when the batch is getting free. This means a bit of refactor in the DrawManager with the separation of batching and instancing Batches. --- VAO cache --- Each VAO is generated for a given ShaderInterface. This means we can keep it alive as long as the shader interface lives. If a ShaderInterface is discarded, it needs to destroy every VAO associated to it. Otherwise, a new ShaderInterface with the same adress could be generated and reuse the same VAO with incorrect bindings. The VAO cache itself is using a mix between a static array of VAO and a dynamic array if the is not enough space in the static. Using this hybrid approach is a bit more performant than the dynamic array alone. The array will not resize down but empty entries will be filled up again. It's unlikely we get a buffer overflow from this. Resizing could be done on next allocation if needed. --- Results --- Using Cached VAOs means that we are not querying each vertex attrib for each vbo for each drawcall, every redraw! In a CPU limited test scene (10000 cubes in Clay engine) I get a reduction of CPU drawing time from ~20ms to 13ms. The only area that is not caching VAOs is the instancing from particles (see comment DRW_shgroup_instance_batch).
2018-02-20 01:55:19 +01:00
BLI_addtail(&g_idatalists, idatalist);
DRW: Add instance buffer manager. This manager allows to distribute existing batches for instancing attributes. This reduce the number of batches creation. Querying a batch is done with a vertex format. This format should be static so that it's pointer never changes (because we are using this pointer as identifier [we don't want to check the full format that would be too slow]). This might make the original Instance Data manager useless but it's currently used by DRW_object_engine_data_ensure().
2018-02-14 18:16:52 +01:00
return idatalist;
DRW: Add instance data memory manager. This is a special memory manager that keeps memory blocks ready to send as vbo data. Since we loose which memory block was used each DRWShadingGroup we need to redistribute them in the same order/size to avoid to realloc each frame. This is why DRWInstanceDatas are sorted in a list for each different data size.
2018-01-09 14:09:14 +01:00
}
void DRW_instance_data_list_free(DRWInstanceDataList *idatalist)
{
DRWInstanceData *idata, *next_idata;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: use post increment/decrement When the result isn't used, prefer post increment/decrement (already used nearly everywhere in Blender).
2019-09-08 00:12:26 +10:00
for (int i = 0; i < MAX_INSTANCE_DATA_SIZE; i++) {
DRW: Add instance data memory manager. This is a special memory manager that keeps memory blocks ready to send as vbo data. Since we loose which memory block was used each DRWShadingGroup we need to redistribute them in the same order/size to avoid to realloc each frame. This is why DRWInstanceDatas are sorted in a list for each different data size.
2018-01-09 14:09:14 +01:00
for (idata = idatalist->idata_head[i]; idata; idata = next_idata) {
next_idata = idata->next;
DRW_instance_data_free(idata);
MEM_freeN(idata);
}
idatalist->idata_head[i] = NULL;
idatalist->idata_tail[i] = NULL;
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
DRW: Refactor: Use DRWCall to accumulate per instance attributes This is a big change that cleanup a lot of confusing code. - The instancing/batching data buffer distribution in draw_instance_data.c. - The selection & drawing code in draw_manager_exec.c - Prety much every non-meshes object drawing (object_mode.c). Most of the changes are just renaming but there still a chance a typo might have sneek through. The Batching/Instancing Shading groups are replace by DRWCallBuffers. This is cleaner and conceptually more in line with what a DRWShadingGroup should be. There is still some little confusion in draw_common.c where some function takes shgroup as input and some don't.
2019-05-13 17:56:20 +02:00
BLI_memblock_destroy(idatalist->pool_buffers, (MemblockValFreeFP)temp_buffer_handle_free);
DRW: InstanceData: Remove hacks of batch freeing callback We instead use a handle reference counter on the GPUVertBufs used by the instancing batches. This make sure that if an update happens on the GPUVertBuf used to contruct the batch, they will never have the same memory address than the previously allocated ones (since they are still pending deletion thanks to the refcounter). This avoid the linear search to update the GPUBatch in the case a batch is deleted (which was even a bad option since they could be only cleared)
2020-08-10 01:43:50 +02:00
BLI_memblock_destroy(idatalist->pool_instancing, (MemblockValFreeFP)temp_instancing_handle_free);
DRW: Instance Data: Replace GPUBatch bulk allocation by separate alloc This is suboptimal but needed for the new GPU abstraction. Maybe a better solution will be needed if performance is impacted.
2020-08-01 12:57:17 +02:00
BLI_memblock_destroy(idatalist->pool_batching, (MemblockValFreeFP)temp_batch_free);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Gawain: Refactor: VAOs caching AND use new VAOs manager. A major bottleneck of current implementation is the call to create_bindings() for basically every drawcalls. This is due to the VAO being tagged dirty when assigning a new shader to the Batch, defeating the purpose of the Batch (reuse it for drawing). Since managing hundreds of batches in DrawManager and DrawCache seems not fun enough to me, I prefered rewritting the batches itself. --- Batch changes --- For this to happen I needed to change the Instancing to be part of the Batch rather than being another batch supplied at drawtime. The Gwn_VertBuffers are copied from the batch to be instanciated and a new Gwn_VertBuffer is supplied for instancing attribs. This mean a VAO can be generated and cached for this instancing case. A Batch can be rendered with instancing, without instancing attribs and without the need for a new VAO using the GWN_batch_draw_range_ex with the force_instance parameter set to true. --- Draw manager changes --- The downside with this approach is that we must track the validity of the instanced batch (the original one). For this the only way (I could think of) is to set a callback for when the batch is getting free. This means a bit of refactor in the DrawManager with the separation of batching and instancing Batches. --- VAO cache --- Each VAO is generated for a given ShaderInterface. This means we can keep it alive as long as the shader interface lives. If a ShaderInterface is discarded, it needs to destroy every VAO associated to it. Otherwise, a new ShaderInterface with the same adress could be generated and reuse the same VAO with incorrect bindings. The VAO cache itself is using a mix between a static array of VAO and a dynamic array if the is not enough space in the static. Using this hybrid approach is a bit more performant than the dynamic array alone. The array will not resize down but empty entries will be filled up again. It's unlikely we get a buffer overflow from this. Resizing could be done on next allocation if needed. --- Results --- Using Cached VAOs means that we are not querying each vertex attrib for each vbo for each drawcall, every redraw! In a CPU limited test scene (10000 cubes in Clay engine) I get a reduction of CPU drawing time from ~20ms to 13ms. The only area that is not caching VAOs is the instancing from particles (see comment DRW_shgroup_instance_batch).
2018-02-20 01:55:19 +01:00
BLI_remlink(&g_idatalists, idatalist);
DRW: Add instance data memory manager. This is a special memory manager that keeps memory blocks ready to send as vbo data. Since we loose which memory block was used each DRWShadingGroup we need to redistribute them in the same order/size to avoid to realloc each frame. This is why DRWInstanceDatas are sorted in a list for each different data size.
2018-01-09 14:09:14 +01:00
}
void DRW_instance_data_list_reset(DRWInstanceDataList *idatalist)
{
DRWInstanceData *idata;
Cleanup: use post increment/decrement When the result isn't used, prefer post increment/decrement (already used nearly everywhere in Blender).
2019-09-08 00:12:26 +10:00
for (int i = 0; i < MAX_INSTANCE_DATA_SIZE; i++) {
DRW: Add instance data memory manager. This is a special memory manager that keeps memory blocks ready to send as vbo data. Since we loose which memory block was used each DRWShadingGroup we need to redistribute them in the same order/size to avoid to realloc each frame. This is why DRWInstanceDatas are sorted in a list for each different data size.
2018-01-09 14:09:14 +01:00
for (idata = idatalist->idata_head[i]; idata; idata = idata->next) {
idata->used = false;
}
}
}
void DRW_instance_data_list_free_unused(DRWInstanceDataList *idatalist)
{
DRWInstanceData *idata, *next_idata;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
DRW: Add instance data memory manager. This is a special memory manager that keeps memory blocks ready to send as vbo data. Since we loose which memory block was used each DRWShadingGroup we need to redistribute them in the same order/size to avoid to realloc each frame. This is why DRWInstanceDatas are sorted in a list for each different data size.
2018-01-09 14:09:14 +01:00
/* Remove unused data blocks and sanitize each list. */
Cleanup: use post increment/decrement When the result isn't used, prefer post increment/decrement (already used nearly everywhere in Blender).
2019-09-08 00:12:26 +10:00
for (int i = 0; i < MAX_INSTANCE_DATA_SIZE; i++) {
DRW: Add instance data memory manager. This is a special memory manager that keeps memory blocks ready to send as vbo data. Since we loose which memory block was used each DRWShadingGroup we need to redistribute them in the same order/size to avoid to realloc each frame. This is why DRWInstanceDatas are sorted in a list for each different data size.
2018-01-09 14:09:14 +01:00
idatalist->idata_tail[i] = NULL;
for (idata = idatalist->idata_head[i]; idata; idata = next_idata) {
next_idata = idata->next;
if (idata->used == false) {
if (idatalist->idata_head[i] == idata) {
idatalist->idata_head[i] = next_idata;
}
else {
Merge branch 'master' into blender2.8
2018-09-19 18:19:49 +02:00
/* idatalist->idata_tail[i] is guaranteed not to be null in this case. */
DRW: Add instance data memory manager. This is a special memory manager that keeps memory blocks ready to send as vbo data. Since we loose which memory block was used each DRWShadingGroup we need to redistribute them in the same order/size to avoid to realloc each frame. This is why DRWInstanceDatas are sorted in a list for each different data size.
2018-01-09 14:09:14 +01:00
idatalist->idata_tail[i]->next = next_idata;
}
DRW_instance_data_free(idata);
MEM_freeN(idata);
}
else {
if (idatalist->idata_tail[i] != NULL) {
idatalist->idata_tail[i]->next = idata;
}
idatalist->idata_tail[i] = idata;
}
}
}
}
void DRW_instance_data_list_resize(DRWInstanceDataList *idatalist)
{
DRWInstanceData *idata;
Cleanup: use post increment/decrement When the result isn't used, prefer post increment/decrement (already used nearly everywhere in Blender).
2019-09-08 00:12:26 +10:00
for (int i = 0; i < MAX_INSTANCE_DATA_SIZE; i++) {
DRW: Add instance data memory manager. This is a special memory manager that keeps memory blocks ready to send as vbo data. Since we loose which memory block was used each DRWShadingGroup we need to redistribute them in the same order/size to avoid to realloc each frame. This is why DRWInstanceDatas are sorted in a list for each different data size.
2018-01-09 14:09:14 +01:00
for (idata = idatalist->idata_head[i]; idata; idata = idata->next) {
DRW: Instance Data: Replace with static allocation that can be referenced. This mean you can store data used for drawing inside the object engine data. Also fixes T55243 Crash in ASAN debug builds due to use-after-free memory in draw code - instances issue?
2018-05-30 12:19:20 +02:00
BLI_mempool_clear_ex(idata->mempool, BLI_mempool_len(idata->mempool));
DRW: Add instance data memory manager. This is a special memory manager that keeps memory blocks ready to send as vbo data. Since we loose which memory block was used each DRWShadingGroup we need to redistribute them in the same order/size to avoid to realloc each frame. This is why DRWInstanceDatas are sorted in a list for each different data size.
2018-01-09 14:09:14 +01:00
}
}
}
/** \} */
Copy Permalink