Status Update
No update yet.
Comments
ch...@google.com
ch...@google.com
Here's a renderdoc capture of the issue taken on a Pixel2XL with a very recent Android build.
ap...@google.com
Branch: master
commit a3b16c6b50a64df299cfde89dcbe3068777a4adb
Author: Shahbaz Youssefi <syoussefi@chromium.org>
Date: Fri Aug 28 16:14:30 2020
Vulkan: Workaround vkCmdClearAttachment bug on Pixel
Adds a workaround to use draw calls to clear color instead of
vkCmdClearAttachment when the clear happens in the middle of render
pass. On Pixel phones, vkCmdClearAttachment races with the previous
draw calls in the render pass.
Bug:
Change-Id: I8c96b87793da191757635658ad4ee2c3a7875aca
Reviewed-on:
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Courtney Goeltzenleuchter <courtneygo@google.com>
Reviewed-by: Tim Van Patten <timvp@google.com>
M include/platform/FeaturesVk.h
M src/libANGLE/renderer/vulkan/FramebufferVk.cpp
M src/libANGLE/renderer/vulkan/RendererVk.cpp
ap...@google.com
The issue is not limited to color clears. The following test added in
ClearTestES3.ClearMaxAttachmentsAfterDraw/ES3_Vulkan
ap...@google.com
The following CL is enabling using vkCmdClearAttachements for scissored clears, rather than drawing:
3388635: Vulkan: Use vkCmdClearAttachments for scissored clears |
With that CL, the following tests expose another issue with Pixel 4 Qualcomm drivers:
FramebufferMultiviewLayeredClearTest.ScissoredClear/ES3_Vulkan__vertex_shader_multiview2
FramebufferMultiviewLayeredClearTest.ScissoredClear/ES3_Vulkan__vertex_shader_multiview
QC is not interpretting the VkClearRect.layerCount value incorrectly and is clearing too many layers. Looking at FramebufferMultiviewLayeredClearTest.ScissoredClear/ES3_Vulkan__vertex_shader_multiview specifically, the vkCmdClearAttachements command is being issued with VkClearRect.layerCount = 2, but is actually clearing layers 1, 2, and 3. Layer 0 is correctly being skipped.
To work around this, preferDrawClearOverVkCmdClearAttachments will be enabled for QC in general, rather than just specific Pixel devices.
Description
The example app speaks for itself. But basically, if you try to call Bundle.putParcelableArray(key, new Bundle[0]) and Bundle.putParcelableArray(key, new Intent[0]) from within a switch statement that is inside of a loop, you'll get the following error if your app is minified:
Caused by: java.lang.VerifyError: Verifier rejected class com.example.verify.a: void com.example.verify.a.a(org.json.JSONObject) failed to verify: void com.example.verify.a.a(org.json.JSONObject): [0x14] register v1 has type Reference: java.lang.Object[] but expected Reference: android.os.Parcelable[] (declaration of 'com.example.verify.a' appears in /data/app/com.example.verify-2/base.apk:classes4.dex)
To workaround this, you either need to set minifyEnabled to false or perform an unnecessary cast:
b.putParcelableArray("bundles", (Parcelable[])new Bundle[0]);
or
b.putParcelableArray("intents", (Parcelable[])new Intent[0]);
Either line works and the error is avoided. But you'll now get a lint error about the cast being redundant.
There are also some other strange ways to avoid the error like not calling any methods on the passed in JSONObject. You can also put the two putParcelableArray statements under the same case statement and the error goes away.
I know the example code doesn't make a lot of sense. But I discovered this in a much more complex app and the switch inside a loop seems to be the trigger.
Android Studio Version: 3.3.2
Android Gradle Plugin: 3.3.2