We need to run our reftests (at least) with OpenGL hardware accelerated layers on Linux and Mac. (We might want to do it on Windows at some point too, but we currently expect to use Direct3D 9 for accelerating layers on that platform.)

Some information on what is required to do that would be very helpful.

It'll be very much like the d2d tests. My first task is to make sure that these tests actually run to completion, and then I'll pass it off to you fine folk with the requisite prefs to be set to enable it in automation.

Essentially setting MOZ_ACCELERATED=1 in the environment before running the tests; the same class of machines that we're using to run the d2d reftests should work, though obviously for a different platform. But we should test the GL backend on Windows as well. (Newest generation Mac Minis would be even better, since they have a better GPU.)

Right now Firefox crashes on startup for me on OS X when I set MOZ_ACCELERATED in the environment, which Vlad tells me will be fixed by bug 574481.

Here's the way to run with hardware acceleration: export MOZ_ACCELERATED=11 make reftests Everything should 'just work' more or less (of course right now we get reftest failures). This successfully runs to completion on OS X at least.

Currently we run unit tests for Mac and Linux on test-master01 and test-master02 masters which are currently suffering a lot. I will make this work on staging but I will not enable this on production until the situation improves. Adding one more test suite will make things worse at this moment. Let's see what the situation is by the end of next week. Makes sense?

We should really split this bug up -- we care a lot more about running this on Mac rather than on Linux, and getting it going on Mac is also going to be much simpler due to no need to screw around with Linux OpenGL drivers.

I already have patches on bug 581213 for both Direct 3D 9 and OpenGL. Disabling/enabling these suites for the platforms is very easy. It is a matter of just letting me know which matrix of platforms and branches you want. catlee landed a fix on bug 563458 which has put our masters into good shape again. Now the only issues is that there are not enough machines due to the amount of pushes we are receiving. I vote for having all platforms and all branches and hunt whoever we need to get more machines ;)

To get retained layers working properly in reftests we need to make sure the window is at least 800x1000. We probably need to increase the size of the virtual screen used on the slaves. Armen, can you do that? We need to make sure that DRAWWINDOW_USE_WIDGET_LAYERS is present in the "REFTEST INFO | drawWindow flags = " line.

(In reply to comment #9) > To get retained layers working properly in reftests we need to make sure the > window is at least 800x1000. We probably need to increase the size of the > virtual screen used on the slaves. Armen, can you do that? We need to make sure > that DRAWWINDOW_USE_WIDGET_LAYERS is present in the "REFTEST INFO | drawWindow > flags = " line. Is this line related? REFTEST INFO | drawWindow flags = DRAWWINDOW_DRAW_CARET | DRAWWINDOW_DRAW_VIEW | DRAWWINDOW_USE_WIDGET_LAYERS; window.innerWidth/Height = 801,1000; browser.width/height = 800,1000 This is the first run for Linux64 on our staging environments (I have it stopped so don't look for more until early next week :) http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTest/1281723827.1281724773.25470.gz&fulltext=1

That looks great. Ultimately we want DRAWWINDOW_USE_WIDGET_LAYERS on all our boxes, although right now we're not getting it on most of them.

Could you guys look at these logs and let me know if it looks like what you would expect? * Fedora32: http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTest/1281976053.1281977151.5672.gz * Fedora64: http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTest/1281969809.1281970795.8356.gz * 10.5: http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTest/1281971686.1281972976.18572.gz * 10.6: http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTest/1281973041.1281973110.19349.gz 10.6's output looks very weird. Is it working properly? Fedora32/64 have a very large number of test failures. Are we ready to enable this test suite?

(In reply to comment #11) > That looks great. Ultimately we want DRAWWINDOW_USE_WIDGET_LAYERS on all our > boxes, although right now we're not getting it on most of them. Is this something that I should try to understand for this bug or is this a separate/independent issue that could be filed in another bug?

The failures are OK; we need to enable this to track progress. All the test logs look OK; on 10.6 we are apparently unable to start GL, though: 2010-08-16 08:38:16.405 firefox-bin[311:903] invalid pixel format 2010-08-16 08:38:16.408 firefox-bin[311:903] invalid context We'll need to look into this.

What hardware is this being run on? It's hard to tell without a stack trace but I'd assume CGLLibrary::PixelFormat (GLContextProviderCGL.mm:76) is returning NULL which would imply that hardware acceleration isn't available. Might be worth trying with the attached patch to see if it stops crashing (will just revert to software rendering instead though).

(In reply to comment #13) > (In reply to comment #11) > > That looks great. Ultimately we want DRAWWINDOW_USE_WIDGET_LAYERS on all our > > boxes, although right now we're not getting it on most of them. > > Is this something that I should try to understand for this bug or is this a > separate/independent issue that could be filed in another bug? Independent issue, except that if DRAWWINDOW_USE_WIDGET_LAYERS is not used, reftests will not actually be testing the accelerated layer manager. So, in those logs, your two Fedora builds did test GL properly because they have DRAWWINDOW_USE_WIDGET_LAYERS. Your Leopard build did not test GL properly because the screen was too small to get DRAWWINDOW_USE_WIDGET_LAYERS.

(In reply to comment #16) > So, in those logs, your two Fedora builds did test GL properly because they > have DRAWWINDOW_USE_WIDGET_LAYERS. Your Leopard build did not test GL properly > because the screen was too small to get DRAWWINDOW_USE_WIDGET_LAYERS. From looking at the 10.5 log: REFTEST INFO | drawWindow flags = DRAWWINDOW_DRAW_CARET | DRAWWINDOW_DRAW_VIEW; window.innerWidth/Height = 802,889; browser.width/height = 800,1000 I have tried the following resolutions on one of the 10.5 machines and I got the DRAWWINDOW_USE_WIDGET_LAYERS flag added (1400x1050 and 1600x1200 60HZ): REFTEST INFO | drawWindow flags = DRAWWINDOW_DRAW_CARET | DRAWWINDOW_DRAW_VIEW | DRAWWINDOW_USE_WIDGET_LAYERS; window.innerWidth/Height = 802,1001; browser.width/height = 800,1000 I believe that from 1024 we loose pixels on OSX's menu bar (22 pixels) and minefield's title bar (22 pixels) totaling to 44 pixels and leaving a maximum of 980 pixels available. Not sure why we got 889 pixels but even 980 pixels would not be sufficient; right? Both tried resolutions are 1.33 ratio rather than current 1.25. We have to be very careful with a resolution change since it could affect talos numbers. Do you guys want us to enable this week the test suites only for Fedora (opengl) and Windows (Direct3D) until we figure out why 10.6 does not run and I discover if there is talos regressions? (I am out from Thursday and back on Tuesday) For reference, here is the code being talked about: http://mxr.mozilla.org/mozilla-central/source/layout/tools/reftest/reftest.js#1007

Is there a way we could modify the test suite so it could even work on smaller windows?

(In reply to comment #15) > Created attachment 466423 [details] [diff] [review] > Crash fix > > What hardware is this being run on? > Rev 3 minis 2.26 GHz Intel Core 2 Duo 2GB 1067MHz DDR3 OSX 10.5.8 > It's hard to tell without a stack trace but I'd assume CGLLibrary::PixelFormat > (GLContextProviderCGL.mm:76) is returning NULL which would imply that hardware > acceleration isn't available. > > Might be worth trying with the attached patch to see if it stops crashing (will > just revert to software rendering instead though). > I pushed the change to try: http://hg.mozilla.org/try/rev/1531d3376d9d and will try it later.

(In reply to comment #19) > I pushed the change to try: > http://hg.mozilla.org/try/rev/1531d3376d9d > and will try it later. Failed push. This is the right one: http://hg.mozilla.org/try/rev/4776a3e9f725

As per conversation with roc on IRC. He says that it might be possible to do code changes to allow the test suite to run within the current resolution of our testing machines (modifying the resolution could affect talos numbers and would require much more testing). At this time he does not have time to borrow one of our Mac machines to work on it and see why things are not working as in his local development systems (IIUC). For now let's go and enable this for Fedora 32-bit and 64-bit and let's see what the state is when I get back on Tuesday.

We are now running OpenGL test suite for Fedora 32-bit and 64-bit. I have added scrapping for some of the tinderboxes pages where these test suite has already been run (if it has not run at least once I cannot add scrapping) but I have *hidden* it until the GFX team gets the number of permanent oranges to zero (bug 586463 for Linux and bug 586465 for OS X - I think). With regards to running OpenGL on Mac I have filed bug 588493 to keep track of the GFX team picking up a Mac machine and try to make the test suite work with the current resolution. The attached patch shows all that it is required to enable OpenGL for Mac once dependent bugs get fixed. I will keep the bug open but reduce the priority until the dependent bugs get fixed. NOTE: I will be taking vacation starting tomorrow and will be back on Tuesday.

Excellent. We will look in to Mac OpenGL sometime soon. Thank you!

So, er -- precisely zero of our mac users will be running at 1024x768. Seems like we should be testing something that they're actually running?

(Also, how come this isn't a problem on OSX without GL layers?)

This bug is pointed towards a very bad trade: having our critically-constrained product developers changing test suites to accommodate a configuration that is in no way representative of our userbase. We should fix the resolution setting on the minis, and let roc/joe/jeff etc. work on solving other problems. In addition to not taking up their time, it will also have the reftests and other use of these Mac systems be more similar to what *any* of our Mac users will be doing.

(Or changing our code to do larger-than-window layers only because of the mini configuration.)

(In reply to comment #24) > So, er -- precisely zero of our mac users will be running at 1024x768. Seems > like we should be testing something that they're actually running? I'm happy to change the resolution to something else if you prefer. Until now, Talos has always used 1024x768 (maybe it was a default resolution on some OS early on?) We can certainly change the resolution on the pools of minis if that helps. If you want us to make this change, please file a separate mozilla.org:RelEng bug, (to avoid confusing this bug here), specifying: - what resolution you want to change to - whether you want us to change osx10.6 only or all OS (currently Talos has all OS use consistent screen resolution) ...and we'll make it happen. Note: changing this resolution is almost certain to impact perf numbers. Not a blocker, but just something we have to consider during rollout if we go ahead with this change. (In reply to comment #25) > (Also, how come this isn't a problem on OSX without GL layers?) Really good question.

(In reply to comment #28) > (In reply to comment #24) > > So, er -- precisely zero of our mac users will be running at 1024x768. Seems > > like we should be testing something that they're actually running? > > > I'm happy to change the resolution to something else if you prefer. Until now, > Talos has always used 1024x768 (maybe it was a default resolution on some OS > early on?) We can certainly change the resolution on the pools of minis if that > helps. vlad: Correction: all the talos machines are running 1280x1024. Where do you see 1024x768?

(In reply to comment #29) > (In reply to comment #28) > > (In reply to comment #24) > > > So, er -- precisely zero of our mac users will be running at 1024x768. Seems > > > like we should be testing something that they're actually running? > > > > > > I'm happy to change the resolution to something else if you prefer. Until now, > > Talos has always used 1024x768 (maybe it was a default resolution on some OS > > early on?) We can certainly change the resolution on the pools of minis if that > > helps. > > vlad: Correction: all the talos machines are running 1280x1024. Where do you > see 1024x768? vlad: followon question - did you use RDP or VNC to connect to the slave? jhford reminds me in irc that RDP will change the resolution of the slave on connection to match RDP settings (which default to 1024x768).

If the screen is 1280 pixels high, why can we only create a window with 889 pixels of content? Is it the Dock? Do we need to turn the dock off in all the slaves, or maybe move it to the left or right of the screen?

(In reply to comment #28) > (In reply to comment #25) > > (Also, how come this isn't a problem on OSX without GL layers?) > Really good question. It's because currently we're only testing the fallback rendering path, which can only test the "BasicLayerManager" that renders entirely with cairo. To test GL and D3D layers, we need to render the layer tree that was created for the window, so everything we want to test must be visible in the window.

OK. I have poked machines and resolutions and docks and all that and this is what is going on: * the 10.5 staging machine that run the test suite had the dock enabled in contrast to the production machines and the other staging machine (this is unfortunate but these are good news in the sense that things can work without resolution change) * the 10.5 machines have the dock disabled; the 10.6 machines do not have it disabled. Let's fix this on bug bug 590197. * The correct answer is 1280x1024 (see pasted code at bottom of comment). I don't know where 1024x768 was brought into the conversation. Said all these, if anyone believes that 1280x1024 is not representative (instead of the 1024x768 mentioned) please file a separate bug. I believe this bug can now be fixed knowing that the test suite was run in a staging machine that was out of sync with the rest of the production pool (98-99 pixels get recovered after autohiding the Dock). Makes sense? [1] talos-r3-leopard-002:~ cltbld$ cat /Library/LaunchAgents/cscreen.resize.plist <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>EnvironmentVariables</key> <dict> <key>PATH</key> <string>/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin</string> </dict> <key>Label</key> <string>cscreen.resize</string> <key>ProgramArguments</key> <array> <string>/Users/cltbld/cscreen</string> <string>-x</string> <string>1280</string> <string>-y</string> <string>1024</string> <string>-r</string> <string>60</string> <string>-d</string> <string>32</string> <string>-f</string> </array> <key>RunAtLoad</key> <true/> <key>UserName</key> <string>cltbld</string> <key>WorkingDirectory</key> <string>/Users/cltbld/</string> </dict> </plist>

(In reply to comment #17) I am doing another run on staging and these are the current conditions: * 1280x1024 * No Dock * I have VNCed to the machine and the window looks maximized (there 4 pixels at the bottom where the mouse is supposed to hover to bring the dock back from auto-hide) Nevertheless I am getting this: > REFTEST INFO | drawWindow flags = DRAWWINDOW_DRAW_CARET | > DRAWWINDOW_DRAW_VIEW; window.innerWidth/Height = 802,976; > browser.width/height = 800,1000 My previous fast finger calculations made me believe that there was enough room to get those 1000 pixels but we are not getting enough pixels. We have only 976 usable pixels (22 pixels from OSX's menu bar on the top, 22 pixels from Minefield's top and 4 pixels at the bottom for where the mouse should hover to pop the dock back). We are missing 24 pixels in height to make this work. Is there a not-so-costly-way-for-GFX-team to modify this test suite to work within 976 pixels instead of a 1000 or no-way-Jose? If not who can tell me what the reasonable resolution bump should be? 1600x1200? This resolution is next bigger resolution that would gives us the 100 pixels. FTR: http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTest/1282679687.1282680951.11862.gz

I think I've figured this out!!! MacOS truncates the window height to make sure the window doesn't overlap the Dock. Even if the Dock is hiding, the bottom of the window won't be allowed to go off the bottom of the screen. Unless you move the Dock to the left or right side of the window, which is what I've always done on my laptop!! I also did another experiment using 'hidechrome' in reftest.xul to hide the reftest window title bar. That seems to allow the window to be any size regardless of where the Dock is! Here is a patch that does that. So there are two options that I think we could use here: 1) move the Dock to the left or right of the screen on all test machines 2) apply this patch to hide the reftest window titlebar I would prefer to avoid option 2 since the titlebar is useful to move the reftest window around and to display the progress of the reftests.

This seems doable. I will test this tomorrow or Firday but for now (as per discussion with vlad) I am putting more priority on the OSMesa bug for Windows.

With the dock on the right we get this (4 pixels gained): > REFTEST INFO | drawWindow flags = DRAWWINDOW_DRAW_CARET | > DRAWWINDOW_DRAW_VIEW; window.innerWidth/Height = 802,980; > browser.width/height = 800,1000 With your patch plus a) the dock moved to the right *OR* b) dock at the bottom but hidden (4 + 43 = 47 pixels): > REFTEST INFO | drawWindow flags = DRAWWINDOW_DRAW_CARET | > DRAWWINDOW_DRAW_VIEW | > DRAWWINDOW_USE_WIDGET_LAYERS; window.innerWidth/Height = 802,1023; > browser.width/height = 800,1000 On bug 590197 I am going to move the dock to the right and try to manage the resolution on our macs through puppet. There are two paths as I understand: 1) Land proposed one line patch to remove Minefield's title bar (just moving dock to the right or hiding it is not enough) 2) Increase the resolution of Macs to 1680 x 1050 (that is the only higher options on the Mac ref platforms - not sure why the rest of the pool offers even higher resolutions) or other higher resolution if needed. Regardless of paths 1 or 2 I will manage the dock and the resolution through puppet as this is not the first time that we have had to consider any of these options. Later we can determine what is the right combinations (autohide/to the right/modified resolution).

(In reply to comment #37) > With the dock on the right we get this (4 pixels gained): > > REFTEST INFO | drawWindow flags = DRAWWINDOW_DRAW_CARET | > > DRAWWINDOW_DRAW_VIEW; window.innerWidth/Height = 802,980; > > browser.width/height = 800,1000 Hmm, now that I test this again, it's not working for me either :-(. I wonder what I did differently before... Sorry for the bad info. > With your patch plus a) the dock moved to the right *OR* b) dock at the bottom > but hidden (4 + 43 = 47 pixels): > > REFTEST INFO | drawWindow flags = DRAWWINDOW_DRAW_CARET | > > DRAWWINDOW_DRAW_VIEW | > > DRAWWINDOW_USE_WIDGET_LAYERS; window.innerWidth/Height = 802,1023; > > browser.width/height = 800,1000 > > On bug 590197 I am going to move the dock to the right and try to manage the > resolution on our macs through puppet. > > There are two paths as I understand: > 1) Land proposed one line patch to remove Minefield's title bar (just moving > dock to the right or hiding it is not enough) > 2) Increase the resolution of Macs to 1680 x 1050 (that is the only higher > options on the Mac ref platforms - not sure why the rest of the pool offers > even higher resolutions) or other higher resolution if needed. 1680x1050 works fine on my laptop with the dock on the left or right, or on the bottom and hidden. That's definitely the most straightforward option from my point of view!

--> beta6+

roc, I just chatted with vlad and he says that it should be fine to commit your patch. Is there any reason not to commit it besides the inconvenience of not having the title bar to move the window around? As soon as you land it I can enable OpenGL for Mac 10.5. Otherwise, I would have to measure the hit on talos numbers if I changed the resolution. It can be done but it will take longer and might bring up more unexpected problems.

OK, land the patch ... but we'll want to fix the screen resolution soon anyway.

Good. Could you please land the patch before the end of the week? I would like to enable this first thing on Monday. Please if you (or anyone that can make the call) feel that we have to increase the screen resolution for any of our platforms please file a new bug with the reasons to do so. We now manage the resolution through puppet for Mac 10.5 and 10.6 slaves.

Filed bug 592903. I'll land that patch as a temporary fix.

Landed that patch: http://hg.mozilla.org/mozilla-central/rev/04e11820280c

Let's get the review through as I am trying to see how the run goes on staging. I will paste the logs later.

Attached the wrong patch. Here is the correct one

roc will running on 1280x1024 with the current patch disabling the titlebar meet the needs for running this on production until we change to a higher resolution? (a.k.a. closing this bug) (I will post the 1280x1024 current result later tonight) For Fedora, could we land a similar patch until we get to bug 593874? roc, joe shall I pass the following question to someone else? what will meet the coverage that the GFX team needs for beta6? (I just want to be sure that we meet them as there are many things that we are working on and that have been enabled in the recent weeks) [1] Run with 1400x1050 resolution (dock on the right): http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTest/1283808561.1283811646.30924.gz&fulltext=1 4852/14/218 REFTEST INFO | drawWindow flags = DRAWWINDOW_DRAW_CARET | DRAWWINDOW_DRAW_VIEW | DRAWWINDOW_USE_WIDGET_LAYERS; window size = 802,1023; test browser size = 800,1000 I have another run going with 1280x1024 resolution. I will post the results later tonight. REFTEST TEST-UNEXPECTED-FAIL | file:///Users/cltbld/talos-slave/mozilla-central_leopard_test-opengl/build/reftest/tests/layout/reftests/bugs/545049-1.html | REFTEST TEST-UNEXPECTED-FAIL | file:///Users/cltbld/talos-slave/mozilla-central_leopard_test-opengl/build/reftest/tests/layout/reftests/bugs/584699-1.html | REFTEST TEST-UNEXPECTED-FAIL | file:///Users/cltbld/talos-slave/mozilla-central_leopard_test-opengl/build/reftest/tests/layout/reftests/canvas/image-rendering-test.html | REFTEST TEST-UNEXPECTED-PASS | file:///Users/cltbld/talos-slave/mozilla-central_leopard_test-opengl/build/reftest/tests/layout/reftests/css-gradients/height-dependence-2.html | REFTEST TEST-UNEXPECTED-FAIL | file:///Users/cltbld/talos-slave/mozilla-central_leopard_test-opengl/build/reftest/tests/layout/reftests/ogg-video/aspect-ratio-1a.xhtml | REFTEST TEST-UNEXPECTED-FAIL | file:///Users/cltbld/talos-slave/mozilla-central_leopard_test-opengl/build/reftest/tests/layout/reftests/ogg-video/aspect-ratio-1b.xhtml | REFTEST TEST-UNEXPECTED-FAIL | file:///Users/cltbld/talos-slave/mozilla-central_leopard_test-opengl/build/reftest/tests/layout/reftests/ogg-video/aspect-ratio-2a.xhtml | REFTEST TEST-UNEXPECTED-FAIL | file:///Users/cltbld/talos-slave/mozilla-central_leopard_test-opengl/build/reftest/tests/layout/reftests/ogg-video/aspect-ratio-2b.xhtml | REFTEST TEST-UNEXPECTED-FAIL | file:///Users/cltbld/talos-slave/mozilla-central_leopard_test-opengl/build/reftest/tests/layout/reftests/ogg-video/basic-1.xhtml | REFTEST TEST-UNEXPECTED-FAIL | file:///Users/cltbld/talos-slave/mozilla-central_leopard_test-opengl/build/reftest/tests/layout/reftests/ogg-video/canvas-1a.xhtml | REFTEST TEST-UNEXPECTED-FAIL | file:///Users/cltbld/talos-slave/mozilla-central_leopard_test-opengl/build/reftest/tests/layout/reftests/ogg-video/canvas-1b.xhtml | REFTEST TEST-UNEXPECTED-FAIL | file:///Users/cltbld/talos-slave/mozilla-central_leopard_test-opengl/build/reftest/tests/layout/reftests/ogg-video/clipping-1a.html | REFTEST TEST-UNEXPECTED-FAIL | file:///Users/cltbld/talos-slave/mozilla-central_leopard_test-opengl/build/reftest/tests/layout/reftests/ogg-video/offset-1.xhtml | REFTEST TEST-UNEXPECTED-FAIL | file:///Users/cltbld/talos-slave/mozilla-central_leopard_test-opengl/build/reftest/tests/layout/reftests/ogg-video/zoomed-1.xhtml |

(In reply to comment #47) > roc will running on 1280x1024 with the current patch disabling the titlebar > meet the needs for running this on production until we change to a higher > resolution? (a.k.a. closing this bug) (I will post the 1280x1024 current result > later tonight) I think so, but we should look at a reftest log to make sure. > For Fedora, could we land a similar patch until we get to bug 593874? The titlebar is currently disabled on Fedora, but the window manager resizes our window anyway, unfortunately. > roc, joe shall I pass the following question to someone else? what will meet > the coverage that the GFX team needs for beta6? (I just want to be sure that > we meet them as there are many things that we are working on and that have > been enabled in the recent weeks) We're not turning on GL for Mac or Linux in beta6. So I don't think any of this blocks beta6.

* With 1280x1024 resolution (dock at the right): REFTEST INFO | drawWindow flags = DRAWWINDOW_DRAW_CARET | DRAWWINDOW_DRAW_VIEW | DRAWWINDOW_USE_WIDGET_LAYERS; window size = 802,1023; test browser size = 800,1000 It seems that for both resolution the test takes the same height. roc I would like to enable this for 10.5 by Wednesday. Could you please have a look at the results? It seems that it is OK from my understanding. List of failures: REFTEST TEST-UNEXPECTED-FAIL | file:///Users/cltbld/talos-slave/mozilla-central_leopard_test-opengl/build/reftest/tests/layout/reftests/bugs/545049-1.html | REFTEST TEST-UNEXPECTED-FAIL | file:///Users/cltbld/talos-slave/mozilla-central_leopard_test-opengl/build/reftest/tests/layout/reftests/bugs/584699-1.html | REFTEST TEST-UNEXPECTED-FAIL | file:///Users/cltbld/talos-slave/mozilla-central_leopard_test-opengl/build/reftest/tests/layout/reftests/canvas/image-rendering-test.html | REFTEST TEST-UNEXPECTED-PASS | file:///Users/cltbld/talos-slave/mozilla-central_leopard_test-opengl/build/reftest/tests/layout/reftests/css-gradients/height-dependence-2.html | REFTEST TEST-UNEXPECTED-FAIL | file:///Users/cltbld/talos-slave/mozilla-central_leopard_test-opengl/build/reftest/tests/layout/reftests/ogg-video/aspect-ratio-1a.xhtml | REFTEST TEST-UNEXPECTED-FAIL | file:///Users/cltbld/talos-slave/mozilla-central_leopard_test-opengl/build/reftest/tests/layout/reftests/ogg-video/aspect-ratio-1b.xhtml | REFTEST TEST-UNEXPECTED-FAIL | file:///Users/cltbld/talos-slave/mozilla-central_leopard_test-opengl/build/reftest/tests/layout/reftests/ogg-video/aspect-ratio-2a.xhtml | REFTEST TEST-UNEXPECTED-FAIL | file:///Users/cltbld/talos-slave/mozilla-central_leopard_test-opengl/build/reftest/tests/layout/reftests/ogg-video/aspect-ratio-2b.xhtml | REFTEST TEST-UNEXPECTED-FAIL | file:///Users/cltbld/talos-slave/mozilla-central_leopard_test-opengl/build/reftest/tests/layout/reftests/ogg-video/basic-1.xhtml | REFTEST TEST-UNEXPECTED-FAIL | file:///Users/cltbld/talos-slave/mozilla-central_leopard_test-opengl/build/reftest/tests/layout/reftests/ogg-video/canvas-1a.xhtml | REFTEST TEST-UNEXPECTED-FAIL | file:///Users/cltbld/talos-slave/mozilla-central_leopard_test-opengl/build/reftest/tests/layout/reftests/ogg-video/canvas-1b.xhtml | REFTEST TEST-UNEXPECTED-FAIL | file:///Users/cltbld/talos-slave/mozilla-central_leopard_test-opengl/build/reftest/tests/layout/reftests/ogg-video/clipping-1a.html | REFTEST TEST-UNEXPECTED-FAIL | file:///Users/cltbld/talos-slave/mozilla-central_leopard_test-opengl/build/reftest/tests/layout/reftests/ogg-video/offset-1.xhtml | REFTEST TEST-UNEXPECTED-FAIL | file:///Users/cltbld/talos-slave/mozilla-central_leopard_test-opengl/build/reftest/tests/layout/reftests/ogg-video/zoomed-1.xhtml |

(In reply to comment #48) > > roc, joe shall I pass the following question to someone else? what will meet > > the coverage that the GFX team needs for beta6? (I just want to be sure that > > we meet them as there are many things that we are working on and that have > > been enabled in the recent weeks) > > We're not turning on GL for Mac or Linux in beta6. So I don't think any of this > blocks beta6. Could we remove the beta6+ flag to make things clear for beltzner and drivers? or move it to betaN (or whatever is the better suiting flag)?

That looks good to me!

Comment on attachment 472485 [details] [diff] [review] enable opengl for 10.5 Ugh, not the easiest thing to parse, but looks correct. Is there a better way to per-platform suite changes?

This was planned to be deployed on Thursday morning as discussed with joe, jeff, vlad and beltzner. Due to some internal discussions this got post-poned and I would like to deploy it tomorrow morning to not block the GFX team anymore. Again, this is self-contained, just a 4 line patch, this is already enabled for Fedora, will not be noticed by developers as everything will be hidden by default, does NOT require any tree closure and only adds a little more load to 10.5 machines.

Comment on attachment 472485 [details] [diff] [review] enable opengl for 10.5 This landed as: http://hg.mozilla.org/build/buildbot-configs/rev/5e81c6bc7898 I have reconfigured test-master02 and test_scheduler on pm02. We should soon have the OpenGL reftest runs on all branches for 10.5 but hidden by default. Let me post some logs once I have some finished jobs.

REFTEST INFO | drawWindow flags = DRAWWINDOW_DRAW_CARET | DRAWWINDOW_DRAW_VIEW | DRAWWINDOW_USE_WIDGET_LAYERS; window size = 802,1023; test browser size = 800,1000 * Rev3 MacOSX Leopard 10.5.8 mozilla-central opt test opengl http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1284133054.1284136172.9208.gz&fulltext=1 * Rev3 MacOSX Leopard 10.5.8 mozilla-central debug test opengl http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1284129645.1284137195.13813.gz&fulltext=1 It seems that we currently won't have try coverage (bug 595232) but we will have it for all other branches. I have hidden the builds on the tinderbox pages. *GFX team*: I leave into your hands keeping track of the oranges and adding "scrapping" to the tinderbox pages once you want the test jobs to appear on TBPL.

Armen means 'scraping', at the admin page for a tree on tinderbox.m.o. Specifically in the 'Scrape' column in the 'Individual tree administration' table.

Here is an status update of where we are in here: * OSX 10.5 reftests for OpenGL are running every where (including try server) ** It still has perma-oranges and that is why still hidden everywhere ** We will have to change the screen resolution to be able to back out attachment 468826 [details] [diff] [review] * Fedora and Fedora64 are running as well but: ** It seems that during the execution of the test the window size gets modified and will require changing the screen resolution (see bug 593874) * 10.6 is not running at all on the testing machines as per comment 14 ** anyone from GFX that would loan a machine? What is left and in which order to tackle (considering my overload of goals, work week next week, beta 7 on my hands and being builduty): 1) Change screen resolution on Fedora and Fedora 64 2) Change screen resolution on OSX 10.5 (this 2nd to Fedora since at least we are running it on 10.5) 3) Make 10.6 to work (I could get a hand by someone loaning a machine) Timing: * For #1 I expect to have it working on production on the week of the 28th (after beta 7) * For #2 I expect to have it working on the week after the 28th * For #3 I won't give an estimate as I might have to reevaluate my goals on the week of the 28th depending on what happens with my other goals

(In reply to comment #17) > We have to be very careful with a resolution change since it could affect talos > numbers. Could we just change the resolution for running the reftests? We could then change the resolution back when we're done. This would also let us test at multiple resolutions, if we were so inclined. The code to change resolutions programmatically on OS X looks pretty simple: http://hintsforums.macworld.com/showpost.php?p=419594&postcount=16

(In reply to comment #58) > (In reply to comment #17) > > We have to be very careful with a resolution change since it could affect talos > > numbers. > > Could we just change the resolution for running the reftests? We could then > change the resolution back when we're done. This would also let us test at > multiple resolutions, if we were so inclined. > > The code to change resolutions programmatically on OS X looks pretty simple: > > http://hintsforums.macworld.com/showpost.php?p=419594&postcount=16 I tried to compile it but I was not able to. I would love if we could change the resolution only for running the test suites but I would need help with finding how to do it for both platforms on the run. Could this be done from the test harness? The resolution for Mac slaves is currently reset to its default on every reboot.

Precompiled version is here, might work better. http://www.barbariangroup.com/posts/619-changing_screen_resolution_from_the_command_line_on_a_mac

(In reply to comment #60) > Precompiled version is here, might work better. > > http://www.barbariangroup.com/posts/619-changing_screen_resolution_from_the_command_line_on_a_mac It seems to do what is expected to do and it reboots back into the default screen resolution :) Thanks Mike!

Is there a known-easy-way to change screen resolution on the fly on Fedora machines? If not I assume we most likely want to make all platforms deal with screen resolutions in the same ways and not each platform in a different ways. jhford (who setted up the Fedora machines) has told me that it is not easy/viable. PS = I vote for an open source project cross-platform to manage screen resolutions :)

xrandr should work, unless there's some limitation of the driver we're using. does it not?

we are using the proprietary driver. I do not believe that it supports the xrandr extension in the version we were using.

Status update (a lot of chatting with joe): * This bug is blocking a beta7+ bug (bug 580405) but: ** We have 10.5 coverage ** 10.6 does not run on the 10.6 testing machines (see comment 14) and GFX will let me know when to enable it once it works (they are going to loan and 10.6 machine and see what is going on) * I am removing any coverage of Linux and OpenGL from this bug as bug 594876 is not a FF4 blocker I have determined that I have nothing to do for beta7 but I have discussed that for sure we need for beta 8: * change screen resolution for 10.5 * determine why 10.6 test machines don't run OpenGL reftests

(In reply to comment #64) > we are using the proprietary driver. I do not believe that it supports the > xrandr extension in the version we were using. Sucks. Sent you mail about this a bit. Of course, we're on Linux, so we can just start a second X server with the resolution we need, right?

AFAIK we are running reftests with OpenGL for 10.5 by default. For further discussion on changing resolutions on the fly please follow up in: * bug 592903 for Mac. Even though joe is going to suggest at the devs meeting to change the resolution to the new default * bug 593874 for Linux We will be able to run reftests with OpenGL for 10.6 as soon as IT install the dongles (bug 600899).