835135 - modify buildbot mochitest commandline for ubuntu to add --setpref=webgl.force-enabled=true

Status: RESOLVED FIXED

(Release Engineering :: General, defect, P2)

Description

[Joel Maher ( :jmaher ) (UTC -8)]

Now that the webgl conformance tests have support for llvm and the ubuntu vm image does, we need to launch our instance of firefox with:
LD_LIBRARY_PATH=/usr/lib/libLLVMgold.so

and we will need to add this preference to the pre seeded profile:
user_pref("webgl.force-enabled", true);

We can do this for all platforms if we want, but I would argue for a command line argument which would handle the environment variable and the preference.  

Another alternative would be to have the ubuntu VM setup with the LD_LIBRARY_PATH setup already, then we just need to add the preference.  That can be done for all platforms (it shouldn't be a problem, except for new platforms it might be confusing to debug) or via the command line.

we already have this option for the mochitest harness: --setenv=NAME=VALUE 
for the reftest harness we have: --setpref=PREF=VALUE

I will be afk, for a week, it would be nice to have releng weigh in on what they would be comfortable doing from the command line/env perspective.

Comment 1

[Benoit Jacob [:bjacob] (mostly away)]

Could you please explain why we would need to have libLLVMgold.so in our library path? Does the llvmpipe driver actually require it to link GLSL programs? (I had no idea!)

Comment 2

[Joel Maher ( :jmaher ) (UTC -8)]

It could be this is not needed.  I saw on the mesa page (http://www.mesa3d.org/llvmpipe.html), that you need to set the path via LD_LIBRARY_PATH.  I will look at it when I get back online with access to the vm.

Comment 3

[(not currently active) Ted Mielczarek]

Setting LD_LIBRARY_PATH to a filename doesn't really make sense, it's supposed to be a path.

If we need to set an environment variable we should have RelEng set that in the machine's environment, since we don't have a straightforward way of doing that from the test harnesses.

Benoit: can we safely set webgl.force-enabled all the time for Mochitests? Will that break on developer machines where we would otherwise blacklist WebGL?

Comment 4

[Benoit Jacob [:bjacob] (mostly away)]

(In reply to Ted Mielczarek [:ted.mielczarek] from comment #3)
> Benoit: can we safely set webgl.force-enabled all the time for Mochitests?
> Will that break on developer machines where we would otherwise blacklist
> WebGL?

The only problem with force-enabling WebGL in mochitests is that this loses our ability to test that WebGL is not accidentally blacklisted.

However, we could have a separate mochitest for testing just that (just creating a WebGL context).

Comment 5

[cmtalbert]

Adding bc because this might prove to be a useful work around for the open GL support issues with x86 android emulators running on VMs.

Comment 6

[Joel Maher ( :jmaher ) (UTC -8)]

ok, we don't need to ENV variable, we just need the preference set.  In order to do this and ensure proper coverage, we should only set the preference on the ubuntu machines, this means we need to adjust the cli by adding this to the line:
--setpref=webgl.force-enabled=true

I might not have the right place for this, but we adjust some preference here for mochitest:
https://hg.mozilla.org/build/buildbotcustom/file/tip/steps/unittest.py#l312

we might need to add something that defined a unique suite or toggles off the platform or machine name to determine if we add this --setpref option.

Comment 7

[Rail Aliiev [:rail]]

What happens if we set webgl.force-enabled=true on Fedora slaves?

Comment 8

[Joel Maher ( :jmaher ) (UTC -8)]

I tested this on try server and it worked just fine.  We need to only do this for linux though and ideally only Ubuntu.  As long as it is passed in on the commandline it prevents us from setting it as default.

Comment 9

[Rail Aliiev [:rail]]

Attachment: Mozharness configs

Comment 10

[Rail Aliiev [:rail]]

Attachment: buildbotcustom

Sad to say, but there is no easy way to use configs here. :/

Needs to be tested.

Comment 11

[Aki Sasaki (not active)]

Comment on attachment 711324 [details] [diff] [review]
Mozharness configs

This will enable it on Fedora as well as Ubuntu.  Is that wanted?

Comment 12

[Rail Aliiev [:rail]]

(In reply to Aki Sasaki [:aki] from comment #11)
> Comment on attachment 711324 [details] [diff] [review]
> Mozharness configs
> 
> This will enable it on Fedora as well as Ubuntu.  Is that wanted?

Yeah, that's ok.

Comment 13

[Rail Aliiev [:rail]]

Comment on attachment 711324 [details] [diff] [review]
Mozharness configs

http://hg.mozilla.org/build/mozharness/rev/5e713c054b5e

Comment 14

[Aki Sasaki (not active)]

Merged to production.

Comment 15

[cmtalbert]

Should this be fixed?(In reply to Aki Sasaki [:aki] from comment #14)
> Merged to production.

Should this be --> FIXED then?

Comment 16

[Rail Aliiev [:rail]]

Yes. I left the bug open in case mozharness doesn't stick.