tree 0468a9e9ec517d1d68de6ec59e0ef67bf140876e
parent 4088363f1982ed5133b785ff4b196ff3c091b818
author Nicolas Capens <capn@google.com> 1629829924 -0400
committer Nicolas Capens <nicolascapens@google.com> 1629930613 +0000

Eliminate custom Vulkan constants

VK_PIPELINE_BIND_POINT_RANGE_SIZE and VK_IMAGE_VIEW_TYPE_END_RANGE
were added to one of SwiftShader's own headers, when they were deleted
from the official Vulkan headers, as part of b/153337629.

A header version check was put in place to alert us to manually verify
that no new official Vulkan constants would be defined that clash with
ours. This check is annoying every time we update the Vulkan headers,
and hasn't resulted in requiring changes thus far. Also note that as
part of b/154215163 we ensured all our builds use SwiftShader's copy
of the Vulkan headers.

This change eliminates these constants entirely, so we no longer need
the header version check either. VK_PIPELINE_BIND_POINT_RANGE_SIZE only
affected our pipeline bind point array. Since we only support graphics
and compute pipelines for the foreseeable future, the array size has
been hard-coded to 2, a comment has been added to clarify the index
mapping, and the assert which bounds checks the array access is
preserved.

VK_IMAGE_VIEW_TYPE_END_RANGE was only being used to discern between
image views and buffer views, but this turns out not to be used at all
any more, as we treat them the same as 1D images. b/152224843 removed
the need to specialize for texel buffers due to them requiring support
for larger dimensions than 1D images, and b/152227757 ensured that the
generation of routines does not use more state than what's associated
with the descriptor identifiers. Hence the hacky use of a custom
constant to represent buffer views can safely be eliminated.

Bug: b/155153221
Change-Id: I4566b558d9f3f009e9a1f319c8cb1453c89d52fd
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/56608
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>