v3dv: Incorrect rendering in complex fragment shader
System:
Host: raspberrypi-64 Kernel: 5.10.17-v8+ aarch64 bits: 64 compiler: N/A
Desktop: LXDE 0.10.0 wm: Openbox dm: LightDM
Distro: Debian GNU/Linux 10 (buster)
CPU:
Topology: Quad Core model: N/A variant: cortex-a72 bits: 64 type: MCP
arch: ARMv8 rev: 3
features: Use -f option to see features bogomips: 432
Speed: 1500 MHz min/max: 600/1500 MHz Core speeds (MHz): 1: 1500 2: 1500
3: 1500 4: 1500
Graphics:
Device-1: bcm2711-vc5 driver: vc4_drm v: N/A bus ID: N/A chip ID: brcm:gpu
Device-2: bcm2711-hdmi0 driver: N/A bus ID: N/A chip ID: brcm:soc
Device-3: bcm2711-hdmi1 driver: N/A bus ID: N/A chip ID: brcm:soc
Display: x11 server: X.Org 1.20.4 driver: modesetting unloaded: fbdev
compositor: xcompmgr resolution: 1920x1080~60Hz, 1920x1080~60Hz
OpenGL: renderer: V3D 4.2 v: 2.1 Mesa 19.3.2 direct render: Yes Note that OpenGL renderer above is misleading, I'm actually using latest git master, commit e25daef16f1ac3436e03f6ab9a3f7d65015fe5da. It's not installed system-wide, loading the Vulkan driver by setting VK_ICD_FILENAMES.
Also happens identically on the 32-bit OS and driver.
SMAA effect renders incorrectly in my demo https://github.com/turol/smaaDemo. The blend weights pass is broken, see attached images. They've been exported from RenderDoc, if viewing in the demo it will look slightly different because of sRGB differences. The correct image was taken with Nvidia proprietary driver but looks the same on AMD. This is not a regression, at least as far as I've used this (several months). No validation errors (on any platform).
In the attached RenderDoc trace the interesting draw call is number 33 (VkCmdDraw) in color pass #3. Trying to open the preceding vkCmdBeginRenderPass can result in assert failure in the driver.
If you wish to run the demo yourself use this command line to match the trace:
binaries/smaaDemo-bin --debug --trace --validate --noopt -d Weights
Also the GUI can bug out. This appears to be unrelated to the broken effect since it also happens with AA turned off. It might be whatever is causing dEQP-VK.synchronization.op.single_queue.binary_semaphore.write_update_buffer_read_vertex_input to be listed in flaky tests.
