Artifacts and flickering when rendering gradients on webrender on android
Categories
(Core :: Graphics: WebRender, defect, P3)
Tracking
()
People
(Reporter: jnicol, Assigned: jnicol)
References
(Blocks 1 open bug)
Details
Attachments
(2 files)
| Assignee | ||
Comment 1•7 years ago
|
||
| Assignee | ||
Updated•7 years ago
|
| Assignee | ||
Comment 2•7 years ago
|
||
Updated•7 years ago
|
Comment 3•7 years ago
|
||
Assuming this happens on newer Adrenos as well since it sounds like a GLES thing.
| Assignee | ||
Comment 4•7 years ago
|
||
Yes, it's a GLES spec thing rather than a device-specific driver bug. Affects most/all devices AFAIK, including the pixel 2.
| Assignee | ||
Comment 5•7 years ago
|
||
I was wondering for a while why only gradients were affected and not other primitives, since they all need to fetch data from the gpu cache.
The reason is that linear and radial gradients are the only primitives which fetch data in the fragment shader, all others only do so in the vertex shader. For vertex shaders highp is the default, whereas mediump is the default for fragment shaders.
| Assignee | ||
Comment 6•7 years ago
|
||
In GLES 3 GLSL, the default precision for ints is highp (32 bit) in
vertex shaders, but only mediump (16 bit) in fragment shaders.
To render linear and radial gradients the fragment shader must fetch
the gradient stops from the gpu cache, using an address variable. This
variable is a 16 bit int, so if the stops data is located at
too high an address (row 32 or greater) then this value will have
overflown and we fetch from the wrong location. This was resulting in
garbage being drawn instead of the correct gradients.
To fix this, any address used in a fragment shader must be marked as
highp. This includes the varying input which supplies the address, and
the arguments to any functions used for the fetch.
Comment 8•7 years ago
|
||
| bugherder | ||
Updated•7 years ago
|
Description
•