commit 6b2754066af240bce382baf4ac5720ac998aa306
author Shahbaz Youssefi <syoussefi@chromium.org> Thu Jan 09 11:14:47 2020 -0500
committer Commit Bot <commit-bot@chromium.org> Sat Jan 11 06:07:42 2020 +0000
tree 698e1a57b2828266d61031132288455b2199e85d
parent 8fde115144145bab66e8c33ab3c1b3033febd80f

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>