This functionality is exercised by running angle_deqp_gles31_tests with the
following sets of command arguments:
--gtest_filter=dEQP.GLES31/functional_texture_multisample* --use-angle=vulkan
--gtest_filter=dEQP.GLES31/functional_state_query_texture_level_texture_2d_multisample* --use-angle=vulkan
--gtest_filter=dEQP.GLES31/functional_state_query_texture_texture_2d_multisample_texture_immutable* --use-angle=vulkan
The following are some high-level design notes:
- Texture::setStorageMultisample() handles converting the "requested number of
samples" to the actual number of samples used (e.g. converting 3 to 4),
supported by the underlying back-end). The actual number used is stored in
gl::TextureState::mImageDescs, for use by other GLES commands.
- ANGLE uses the Vulkan standard sample locations/positions. If the underlying
Vulkan driver's VkPhysicalDeviceLimits::standardSampleLocations is false,
ANGLE limits itself to GLES 2.0 (i.e. before GLES 3.0 which adds multisample
renderbuffers).
- The Vulkan specification currently doesn't support ANGLE providing support
for GLES 1-sample textures, because of the following Vulkan specification
statement:
- If the image was created with VkImageCreateInfo::samples equal to
VK_SAMPLE_COUNT_1_BIT, the instruction must: have MS = 0.
- At least one Vulkan driver returns different
VkPhysicalDeviceLimits::*SampleCounts for different formats. Because of
this, ANGLE does a logical-AND of all values in order to only support the
commonly-available numbers of samples.
The detailed design document is located at:
https://docs.google.com/document/d/1NiM8gAR74iGGXGTE6IP1ChdDUZjhtXRuJdtEp_wGFEM/edit?usp=sharing
Bug: angleproject:3565
Bug: angleproject:4103
Bug: angleproject:4104
Bug: angleproject:4196
Bug: angleproject:4197
Bug: angleproject:4198
Change-Id: I28921badf9568427799b0af347198b5df06c2db0
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1919982
Commit-Queue: Ian Elliott <ianelliott@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
