Try to update WR to fe5b370d9dba3a12b64b4bd039cd0fa9e200c7d7, but the try is failed

[He-Jie Shih(Jerry)]

I try to update WR to fe5b370d9dba3a12b64b4bd039cd0fa9e200c7d7, but all reftests failed on try.
The git bisect shows that the test start failed after [1].

Here is one of the failed tests.
https://hg.mozilla.org/mozilla-central/raw-file/tip/layout/tools/reftest/reftest-analyzer.xhtml#logurl=https://queue.taskcluster.net/v1/task/VNEpAqq0SJ6_AB1-HENBBQ/runs/0/artifacts/public/logs/live_backing.log&only_show_unexpected=1

The first one shows that the yellow background is disappeared. The yellow background is a WebrenderColorLayer which uses a simple wr_dp_push_rect() command. Then, I create a simple test in webrender/simple/src/main.rs with a single push_rect() command. The single single push_rect() function looks good. I will discuess with Glenn for this problem.

[1]
https://github.com/servo/webrender/pull/648

-Jerry

[Kartikaya Gupta]

Thanks for tracking this down! I know Mason was trying to do a WR
update yesterday as well, but I guess we should hold off until this
issue is resolved.

Note that I just landed an update to README.webrender in bug 1328910
for the WR update process. This came up in discussion yesterday.
However it's unrelated to the reftest failures - I am getting the
failures as well when I tested the WR update using the new process.

> _______________________________________________
> dev-tech-gfx mailing list
> dev-te...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-gfx
>

[He-Jie Shih(Jerry)]

The WR changes in [1] needs z-buffer, but gecko doesn't turn on the z-buffer for webrender gl context.

Here is a try [2] with depth-buffer setting, but it shows that gecko can't create a gl context with d24s8 setting. The depth setting patches are at [3]. I can create both d24 and d24s8 context locally on my linux pc. I'm not sure the reason why gecko can't get the context on try. I will check the gl context creation flow later.

[1]
https://github.com/servo/webrender/pull/648
[2]
https://treeherder.mozilla.org/#/jobs?repo=try&revision=9786040aa8968b31d43b63fe933e66ef2b754002&selectedJob=66696598

[3]
https://hg.mozilla.org/try/rev/b678b51b02d5f26a1c9f5f9963f52db2d2608081

-Jerry

[He-Jie Shih(Jerry)]

Hi Matt,

I would like to create a gl context with depth-buffer for webrender. Some of FB configurations queried from try-server-linux environment contain depth-buffer, but gecko doesn't use those configurations. Why should we only use the configuration which matches the current x-window attribute[1][2]?

The x-window attributes only has:

GLX_BUFFER_SIZE:24
GLX_DEPTH_SIZE:0
GLX_STENCIL_SIZE:0

No depth-buffer here.

[1]
https://dxr.mozilla.org/mozilla-central/rev/4ece183563a44eab8f410818aa2c7984992dbb8d/gfx/gl/GLContextProviderGLX.cpp#1256
[2]
https://dxr.mozilla.org/mozilla-central/rev/4ece183563a44eab8f410818aa2c7984992dbb8d/gfx/gl/GLContextProviderGLX.cpp#1278

-Jerry

[Matt Woodrow]

If I remember correctly, we had issues binding the GL context to the window if the FB configurations weren't 'compatible'.

The presence of a depth buffer shouldn't matter for that compatibility though, so you should be able to pick one that has one while still matching the other parameters.

karlt might remember more about this too.

- Matt

[He-Jie Shih(Jerry)]

Bug 1329574 will track the WR updating and z-buffer status.

On Mon, Jan 9, 2017 at 9:50 AM, Karl Tomlinson <ktoml...@mozilla.com> wrote:

Yes, if the GL context is for rendering to a window, then the
visual for the GL context needs the same pixel bit layout as the
visual used to create the window.

But, as Matt indicates, other properties of the visuals may not
need to match.

Or alternatively, a different visual could be selected for
creating the window.

>>     <kgu...@mozilla.com <mailto:kgu...@mozilla.com>> wrote:
>>
>>         Thanks for tracking this down! I know Mason was trying to do a WR
>>         update yesterday as well, but I guess we should hold off until
>>         this
>>         issue is resolved.
>>
>>         Note that I just landed an update to README.webrender in bug
>>         1328910
>>         for the WR update process. This came up in discussion yesterday.
>>         However it's unrelated to the reftest failures - I am getting the
>>         failures as well when I tested the WR update using the new
>>         process.
>>
>>
>>         On Thu, Jan 5, 2017 at 6:02 AM, He-Jie Shih(Jerry)

>>         <jerry...@mozilla.com <mailto:jerry...@mozilla.com>> wrote:
>>         > I try to update WR to
>>         fe5b370d9dba3a12b64b4bd039cd0fa9e200c7d7, but all
>>         > reftests failed on try.
>>         > The git bisect shows that the test start failed after [1].
>>         >
>>         > Here is one of the failed tests.
>>         >
>>         https://hg.mozilla.org/mozilla-central/raw-file/tip/layout/tools/reftest/reftest-analyzer.xhtml#logurl=https://queue.taskcluster.net/v1/task/VNEpAqq0SJ6_AB1-HENBBQ/runs/0/artifacts/public/logs/live_backing.log&only_show_unexpected=1
>>         <https://hg.mozilla.org/mozilla-central/raw-file/tip/layout/tools/reftest/reftest-analyzer.xhtml#logurl=https://queue.taskcluster.net/v1/task/VNEpAqq0SJ6_AB1-HENBBQ/runs/0/artifacts/public/logs/live_backing.log&only_show_unexpected=1>
>>         >
>>         > The first one shows that the yellow background is disappeared. The
>>         > yellow
>>         > background is a WebrenderColorLayer which uses a simple
>>         > wr_dp_push_rect()
>>         > command. Then, I create a simple test in

>>         webrender/simple/src/main.rs <http://main.rs> with a

>>         > single push_rect() command. The single single push_rect() function
>>         > looks
>>         > good. I will discuess with Glenn for this problem.
>>         >
>>         > [1]
>>         > https://github.com/servo/webrender/pull/648
>>         <https://github.com/servo/webrender/pull/648>
>>         >
>>         > -Jerry
>>         >
>>         > _______________________________________________
>>         > dev-tech-gfx mailing list
>>         > dev-te...@lists.mozilla.org

>>         <mailto:dev-tech-gfx@lists.mozilla.org>
>>         > https://lists.mozilla.org/listinfo/dev-tech-gfx

>>         <https://lists.mozilla.org/listinfo/dev-tech-gfx>
>>         >
>>         _______________________________________________
>>         dev-tech-gfx mailing list
>>         dev-te...@lists.mozilla.org

>>         <mailto:dev-tech-gfx@lists.mozilla.org>
>>         https://lists.mozilla.org/listinfo/dev-tech-gfx

[He-Jie Shih(Jerry)]

Finally, all linux reftests pass.

try:

https://treeherder.mozilla.org/#/jobs?repo=try&revision=1eca32b6dca1a1c16f36d3ae530a06f634bb096a

The mac build break issue is due to the new version of core-graphics used by WR.
https://bugzilla.mozilla.org/show_bug.cgi?id=1329574#c18

Kats,
Do you have the idea about |cargo update --aggressive -p webrender| which will update the corresponding Cargo.lock files with the latest webrender dependencies?

I try to fix the version in cargo.toml, but it still updates to 0.4.3.

webrender/Cargo.toml
core-graphics = "0.4.1"

webrender_traits/Cargo.toml
core-graphics = "0.4.1"

>>         <mailto:dev-te...@lists.mozilla.org>

>>         > https://lists.mozilla.org/listinfo/dev-tech-gfx
>>         <https://lists.mozilla.org/listinfo/dev-tech-gfx>
>>         >
>>         _______________________________________________
>>         dev-tech-gfx mailing list
>>         dev-te...@lists.mozilla.org

>>         <mailto:dev-te...@lists.mozilla.org>

[Kartikaya Gupta]

Thanks for the doing the update! I pushed patches to downgrade
core-graphics back to 0.4.1.

The problem is that even if the Cargo.toml file says |core-graphics =
"0.4.1"| cargo treats it like |core-graphics = "^0.4.1"| which allows
minor version updates [1]. In theory the minor version updates are not
supposed to break anything but in practice I find lots of people
introduce breaking changes in minor version updates. Doing cargo
update --aggressive as the README says will update to the latest
available minor version, and that was causing the problem here. The
fix is to manually downgrade the package back to 0.4.1. using |cargo
update -p <package> --precise <version>|. I added this to the README
as well.

[1] http://doc.crates.io/specifying-dependencies.html

On Fri, Jan 13, 2017 at 9:07 AM, He-Jie Shih(Jerry)

[Kartikaya Gupta]

Pedantic correction: when I said "minor version" in my previous email
I really meant "patch version" (i.e. the "z" in "x.y.z" semantic
versions).