Work around an apparent driver bug that caused wrong corner radii.

[mstange]

Fixes #1809.

Using the driver of the Intel GPU in my Macbook Pro (Intel HD Graphics 530
1536 MB, 0x191b, Skylake GT2) on macOS 10.12.6, the integer calculation that was
used in order to compute the lookup address gave wrong results, and the corner
radius for the wrong corner was looked up.
The only way to get correct results from it was to move the entire adjustment of
the address ivec2 variable into the caller. Now all values in the calculations
were integer literals.
I then replaced the multiplications with gradual "+= 2" adjustments of the
address variable in fetch_clip, because that looked better and might even be
easier to reason about than the original code.

---

This change is 

[mstange]

r? @glennw or @kvark

[glennw]

Fun! Could you add a comment in that shader code just outlining roughly what's in the commit message and then r=me. Thanks for digging into it!

[nical]

I added this to the driver issues page. Unfortunately my descriptions of the problem and resolution are super vague, if you have any idea how to better explain this for future reference don't hesitate to fill in the blanks.

[kvark]

omg, this is an aweful bug
thanks @mstange for exposing and fixing it!

[mstange]

Here's an alternative fix that also works:

diff --git a/webrender/res/cs_clip_rectangle.glsl b/webrender/res/cs_clip_rectangle.glsl
--- a/webrender/res/cs_clip_rectangle.glsl
+++ b/webrender/res/cs_clip_rectangle.glsl
@@ -27,8 +27,8 @@ struct ClipCorner {
     vec4 outer_inner_radius;
 };

-ClipCorner fetch_clip_corner(ivec2 address, int index) {
-    address += ivec2(2 + 2 * index, 0);
+ClipCorner fetch_clip_corner(ivec2 address, float index) {
+    address += ivec2(2 + 2 * int(index), 0);
     vec4 data[2] = fetch_from_resource_cache_2_direct(address);
     return ClipCorner(RectWithSize(data[0].xy, data[0].zw), data[1]);
 }

It looks like what's broken is: reading from integer variables (or integer arguments) when doing any kind of integer calculation, in the right circumstances. If I store the number in a float, everything works. If I do the calculation without making use of an integer variable as part of the inputs of that calculation, things work as well.

I'll stick with the original fix though, and I'll add a comment.

[leeoniya]

those pesky integers are at it again? #1728 (comment)

[mstange]

They sure are. And there's still at least one more instance of this problem left to find (#1738).

[kvark]

@bors-servo r+

[bors-servo]

📌 Commit d8f31f4 has been approved by kvark

[bors-servo]

⌛ Testing commit d8f31f4 with merge eb30eb7...

[bors-servo]

☀️ Test successful - status-appveyor, status-travis
Approved by: kvark
Pushing eb30eb7 to master...