Instead of fixed size, IMM_BUFFER_SIZE is adjustable now. The internal buffer can expand if there is a need a bigger buffer. All other behaviors are still the same.
Details
Details
- Reviewers
Clément Foucault (fclem) - Group Reviewers
GPU / Viewport - Maniphest Tasks
- T68950: Edge loops crashing blender (exeeding IMM_BUFFER_SIZE)
- Commits
- rB6222cb575fa5: Fix T68950: Adding lots of edge loops to cylinder produces a crash
Diff Detail
Diff Detail
- Repository
- rB Blender
Event Timeline
Comment Actions
The buffer size never shrinks, shouldn't the immediate mode buffer expand as neeeded and returns to it's default size on immUnbindProgram?
Comment Actions
In immBegin, it seems wrong that available_bytes is immediately based off the value produced in the imm_buffer_size = bytes_needed line. Those extra bytes are not available yet, but the rest of the logic assumes they will be and it could actually skip the glBufferData call below depending on the outcome of the if ((bytes_needed + pre_padding) <= available_bytes) conditional.
Comment Actions
Since new buffer size will be the same value as bytes_needed, I thought if ((bytes_needed + pre_padding) <= available_bytes) conditional was always going to fail and the code was going to create a new fresh buffer with the new size. It will most of the time but not always. If imm.buffer_offset and pre_padding are 0, the conditional is going to succeed because available_bytes will be equal to bytes_needed and it is going to skip new buffer creation code. You are right @Jesse Yurkovich (deadpin), I should handle this case.
Comment Actions
Ensure the internal buffer will be recreated after size expand and size shrink. Shrink the internal buffer on immBegin.