Transparency is broken on older Qualcomm Adreno GPUs

[oscrim]

Bevy version

8a523de

Relevant system information

`AdapterInfo { name: "Adreno (TM) 660", vendor: 20803, device: 0, device_type: IntegratedGpu, driver: "", driver_info: "", backend: Gl }`

Tested it on an Adreno 619 with the same issue
Tested it on an Adreno 730 without any issue

What you did

I ran the transparency 3D example on WASM on my OnePlus 9 Pro.

What went wrong

Originally posted by me in #8506 (comment)

Also found out that after removing the scattering, transparency is also broken as shown here when running the transparency_3d example. You can see when the shadows disappear is when the object is supposed to be completely see-through. But this bug was not introduced in the same commit but instead 603cb43

2023-04-28.09-47-22.mp4

Edit: Ill edit this comment as its not really connected to this issue, but from running the blend_modes example it seems the materials arent properly being updated.

As we can see we are able to see through the Add and Multiply but when I change the alpha value on my phone or try any of the other functionalities the materials dont change (but the alpha value top right does). Also changing the alpha to a lower value from the start does nothing.

Additional information

@gnargfu had a fix for this included in this closed pull request #8589

He posted this in my previous issue

#8506 (comment)

I managed to fix the issue with the transparency by moving the standard alpha blending bitflags to be lower in the u32 holding them. This tells me that there is probably something going on with how the wgsl gets the data. But were in the chain of things it happens is beyond me at this time. In the end I just added the fix that was proposed for this (limiting the directional lights) as a feature that can be added if the end user is targeting mobile webgl.

and

#8506 (comment)

It seems as though the Adreno series are alone in having an alignment of 64 bytes. According to the 'best practices' on the Qualcomm developer network each UBO should be no more than 8k. Even though they report that the maxUniformBufferRange is 65536 I've seen comments stating that the driver reports an inaccurate value and people are getting anomalies in the data much sooner. With 10 lights we are currently at 13120 bytes (aligned) which should be safe but that is the lights alone. I'm currently trying to understand the pipeline to see exactly how much is stuffed into the buffer in our examples.

[oscrim]

Realized that this is a copy of #10066