Hash :
6b275406
Author :
Date :
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>