kc3-lang/angle

2020-01-09T11:14:47

Vulkan: Workaround vertex attributes vs stride issue on AMD Under robustBufferAccess, Vulkan states that: Vertex input attributes are considered out of bounds if the offset of the attribute in the bound vertex buffer range plus the size of the attribute is greater than either: - vertexBufferRangeSize, if bindingStride == 0; or - (vertexBufferRangeSize - (vertexBufferRangeSize % bindingStride)) The latter implies that if the buffer size is not a multiple of the vertex attribute stride, what lies beyond the last multiple of stride is considered out of bounds. It also says: Out-of-bounds buffer loads will return any of the following values: - Values from anywhere within the memory range(s) bound to the buffer (possibly including bytes of memory past the end of the buffer, up to the end of the bound range). - Zero values, or (0,0,0,x) vectors for vector reads where x is a valid value represented in the type of the vector components and may be any of ... The first bullet point indicates that the driver is allowed to load the attribute values from the buffer if its range still lies within the buffer size. Take the following example: - Buffer size = 12 - Attribute stride = 8 - Attribute offset = 0 - Attribute size = 4 Basically the buffer is thus laid out as follows: attr stride _________/\_________ / \ +----------+----------+----------+ | vertex 0 | padding | vertex 1 | +----------+----------+----------+ \___ ____/ V attr size In the above example, the attribute for vertex 1 is considered out of bounds, but the driver is allowed to either read it correctly, or return (0, 0, 0, 1) for it. Most drivers implement the former, while AMD implements the latter. This change introduces a workaround for AMD where GL_MAX_VERTEX_ATTRIB_STRIDE is limited to 2048 (the common value for it according to gpuinfo.org) and conservatively rounds up every buffer allocation to that size. While technically, this workaround should be applied on any device with the robustBufferAccess feature enabled, it is currently limited to AMD to avoid the inefficiency. A possible future revision of Vulkan may relax the above restrictions. Bug: angleproject:2848 Change-Id: Ida5ae5d777da10f22ce8be5a09a7644b5bbd778e Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1991709 Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>