On 2020-07-13, we discussed robust buffer access (RBA) edge cases. The discussion can be seen in the minutes <here>. It seems like these resolutions mostly exist in the spec, but we wanted to note them here for future reference or further discussion.
Scenario 1: An out-of-bounds vertex read in Vulkan can be several things (zero, any value from within buffer, (0,0,0,x) vectors).
Resolution: There are portability concerns, but unless performance tests show that manually implemented RBA can be efficient, we will allow this. If we want to swap out RBA for something stricter later on, we can do so under this rule (for example restricting to only zeros would be backwards compatible behavior).
Scenario 2: For out-of-bounds, do we care about the size of the buffer, or the size of the binding? (Vulkan RBA will allow any value from within buffer, even outside binding).
Resolution: Seems like we don't have a choice if we are using Vulkan RBA but to allow this. It should be noted, and we should make sure to check if this causes any unwanted side effects.
Scenario 3: Can an implementation no-op out-of-bounds calls?
Resolution: We've decided that discarding is allowed as one of the ways to handle an invalid call. Up to the implementation if it wants to execute a partially complete call.
Scenario 4: There are simple cases we could validate on the CPU for OOB behavior, such as making an indexed draw call with an index buffer that's too small. Do we want to make these things validation errors?
Resolution: Not for now. Maybe this can be enabled in some debug mode for implementations. Not putting this in the spec makes things simpler and avoids edge cases such as browsers no-oping at different stages.
Scenario 5: What should we do when an indirect buffer is too small to contain the command? For example, calling DrawIndirect on a buffer with only 4 bytes size, there wouldn't be enough information for the draw call parameters.
Resolution: All of these are similar cases (DrawIndexed with index buffer too small, Draw with vertex buffer too small, DrawIndirect with indirect buffer too small). Adopt same rules as before, nothing special for this case.
On 2020-07-13, we discussed robust buffer access (RBA) edge cases. The discussion can be seen in the minutes <here>. It seems like these resolutions mostly exist in the spec, but we wanted to note them here for future reference or further discussion.
Scenario 1: An out-of-bounds vertex read in Vulkan can be several things (zero, any value from within buffer, (0,0,0,x) vectors).
Resolution: There are portability concerns, but unless performance tests show that manually implemented RBA can be efficient, we will allow this. If we want to swap out RBA for something stricter later on, we can do so under this rule (for example restricting to only zeros would be backwards compatible behavior).
Scenario 2: For out-of-bounds, do we care about the size of the buffer, or the size of the binding? (Vulkan RBA will allow any value from within buffer, even outside binding).
Resolution: Seems like we don't have a choice if we are using Vulkan RBA but to allow this. It should be noted, and we should make sure to check if this causes any unwanted side effects.
Scenario 3: Can an implementation no-op out-of-bounds calls?
Resolution: We've decided that discarding is allowed as one of the ways to handle an invalid call. Up to the implementation if it wants to execute a partially complete call.
Scenario 4: There are simple cases we could validate on the CPU for OOB behavior, such as making an indexed draw call with an index buffer that's too small. Do we want to make these things validation errors?
Resolution: Not for now. Maybe this can be enabled in some debug mode for implementations. Not putting this in the spec makes things simpler and avoids edge cases such as browsers no-oping at different stages.
Scenario 5: What should we do when an indirect buffer is too small to contain the command? For example, calling DrawIndirect on a buffer with only 4 bytes size, there wouldn't be enough information for the draw call parameters.
Resolution: All of these are similar cases (DrawIndexed with index buffer too small, Draw with vertex buffer too small, DrawIndirect with indirect buffer too small). Adopt same rules as before, nothing special for this case.