In the current wording of a recently added field (#3005) https://www.w3.org/TR/webgpu/#dom-gpurenderpassdescriptor-maxdrawcount, it reads
"
The maximum number of draw calls that will be done in the render pass. Used by some implementations to size work injected before the render pass. Keeping the default value is a good default, unless it is known that more draw calls will be done.
"
This leads to developers naturally asking themselves, what is the drawback of increasing this value? Or conversely (and more practically), what is the benefit of reducing this value, if they aren't doing 50 million draw calls per pass?
If I understood #2189 (comment) correctly, an implementation will need to retain a GPU buffer of size maxDrawCount * 5 * sizeof(uint32_t) of space for a validation buffer? (that does not quite seem right as it is a huge number of bytes)
So reducing this value they would be able to free up GPU resources for more actual geometry and texture data?
In the current wording of a recently added field (#3005) https://www.w3.org/TR/webgpu/#dom-gpurenderpassdescriptor-maxdrawcount, it reads
"
The maximum number of draw calls that will be done in the render pass. Used by some implementations to size work injected before the render pass. Keeping the default value is a good default, unless it is known that more draw calls will be done.
"
This leads to developers naturally asking themselves, what is the drawback of increasing this value? Or conversely (and more practically), what is the benefit of reducing this value, if they aren't doing 50 million draw calls per pass?
If I understood #2189 (comment) correctly, an implementation will need to retain a GPU buffer of size
maxDrawCount * 5 * sizeof(uint32_t)of space for a validation buffer? (that does not quite seem right as it is a huge number of bytes)So reducing this value they would be able to free up GPU resources for more actual geometry and texture data?