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
a9c297165878b3c427a20f787cc90a6ada4df253
blender-archive/source/blender/draw/intern/draw_instance_data.h

63 lines
2.2 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
/*
Cleanup: add BEGIN/END to GPL headers
2019-01-23 11:29:18 +11:00
* ***** BEGIN GPL LICENSE BLOCK *****
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
* Contributor(s): Blender Institute
*
Cleanup: add BEGIN/END to GPL headers
2019-01-23 11:29:18 +11:00
* ***** END GPL LICENSE BLOCK *****
*
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
*/
/** \file draw_instance_data.h
* \ingroup draw
*/
#ifndef __DRAW_INSTANCE_DATA_H__
#define __DRAW_INSTANCE_DATA_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 "BLI_compiler_attrs.h"
#include "BLI_sys_types.h"
#include "GPU_batch.h"
DRW: Fix crashes with instanced data Problem introduced on 101c277e3d8241ad55f6343690b5d96a5e37d1f0.
2018-06-04 19:17:26 +02:00
#define MAX_INSTANCE_DATA_SIZE 64 /* Can be adjusted for more */
DRW: Fix crash caused by fixing the leak (badly). Previous commit was af425f3f7a08c09f7fbc7076b364fac75163b296
2018-02-08 00:40:50 +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
typedef struct DRWInstanceData DRWInstanceData;
typedef struct DRWInstanceDataList DRWInstanceDataList;
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
struct DRWShadingGroup;
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);
DRWInstanceData *DRW_instance_data_request(
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
DRWInstanceDataList *idatalist, uint attrib_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
void DRW_batching_buffer_request(
GWN: Port to GPU module: Replace GWN prefix by GPU
2018-07-18 00:12:21 +02:00
DRWInstanceDataList *idatalist, GPUVertFormat *format, GPUPrimType type, struct DRWShadingGroup *shgroup,
GPUBatch **r_batch, GPUVertBuf **r_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
void DRW_instancing_buffer_request(
GWN: Port to GPU module: Replace GWN prefix by GPU
2018-07-18 00:12:21 +02:00
DRWInstanceDataList *idatalist, GPUVertFormat *format, GPUBatch *instance, struct DRWShadingGroup *shgroup,
GPUBatch **r_batch, GPUVertBuf **r_vert);
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
/* Upload all instance data to the GPU as soon as possible. */
void DRW_instance_buffer_finish(DRWInstanceDataList *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);
void DRW_instance_data_list_free_unused(DRWInstanceDataList *idatalist);
void DRW_instance_data_list_resize(DRWInstanceDataList *idatalist);
#endif /* __DRAW_INSTANCE_DATA_H__ */
Copy Permalink