Bug 36925

Summary: Snow Leopard bot does not support EXT_packed_depth_stencil
Product: WebKit Reporter: Zhenyao Mo <zmo>
Component: WebGLAssignee: Nobody <webkit-unassigned>
Status: RESOLVED WONTFIX    
Severity: Normal CC: bfulgham, cmarrin, commit-queue, enne, eric, kbr, mrowe, oliver, zmo
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: PC   
OS: OS X 10.5   
Bug Depends on: 35897    
Bug Blocks:    

Description Zhenyao Mo 2010-03-31 20:02:25 PDT
Snow Leopard bot does not support EXT_packed_depth_stencil, which is required by WebGL.

Currently we skipped fast/canvas/webgl/framebuffer-object-attachment.html test.
See https://bugs.webkit.org/show_bug.cgi?id=35611.

Please upgrade OS or graphics hardware so WebGL can run properly.
Comment 1 Eric Seidel (no email) 2010-03-31 20:05:44 PDT
I don't know who maintains that bot, but I doubt they're on the current CC list.

http://build.webkit.org/builders/SnowLeopard%20Intel%20Release%20%28Tests%29
seems to think Mark Rowe is the admin.
Comment 2 Mark Rowe (bdash) 2010-04-01 07:14:08 PDT
I don’t understand the point of this bug.  The bots are not the only machines that run tests.  A regression test that is hardware-dependent and fails on certain classes of hardware is just going to be terribly confusing for people that happen to be using WebKit on such hardware.
Comment 3 Mark Rowe (bdash) 2010-04-01 07:36:54 PDT
Bug 36910 seems to suggest that the tests are incorrect in assuming that this extension will be supported.
Comment 4 Kenneth Russell 2010-04-01 08:56:59 PDT
This bot is currently basically incapable of running WebGL tests. All of these tests have an expected.txt which assumes that WebGL is supported, and having the EXT_packed_depth_stencil OpenGL extension available is a basic capability required by WebGL. We'll probably need to change the WebKit WebGL implementation to return null from Canvas.getContext("webgl") if this extension isn't available. This will cause all of the WebGL tests to fail on this bot and not just these few. Rather than skip them all, it would be really nice if the bot could be upgraded.
Comment 5 Mark Rowe (bdash) 2010-04-01 09:34:21 PDT
Firstly, if WebGL isn’t supported the tests should not fail.  They should be skipped.

The reason this extension isn’t supported on the bots is that they run headless, and this results in the software OpenGL renderer being used.  I’m not sure that it’s practical to require that the build bots run with a display attached.  This would also seem to rule out the use of virtual machines for build bots as they also appear to use the software OpenGL renderer (at least with Mac OS X running inside VMWare Fusion).
Comment 6 Chris Marrin 2010-04-01 11:29:25 PDT
This is another case of a runtime test being needed to determine machine capabilities before running tests. In http://trac.webkit.org/changeset/55467 I added the ability to do this runtime check and turn on and off test directories appropriately. It's done by running DRT with the --print-supported-features flag. This returns a string with supported features. Currently it only includes AcceleratedCompositing and 3DRendering, but you could add WebGL to the list.

To do this you'd have to add a acceleratedCompositingEnabled function to WebPreferences. This would return true only if the WebGL flag is enabled on the machine AND the hardware can support WebGL. For HW Accel we do the runtime check in one of the platform specific files. For WebGL it would probably want to go in GraphicsContext3D.

Once you have the pref, you'd just need to add logic to run-webkit-tests to check for the flag and turn on or off the WebGL directories.
Comment 7 Kenneth Russell 2010-04-01 14:24:06 PDT
It seems that all of the bots except the Snow Leopard one have capable enough graphics hardware to run these tests. It would be really great if they all did so that we can have automated test coverage. The bots are really helpful in catching accidental regressions before they reach the tree.
Comment 8 Mark Rowe (bdash) 2010-04-01 15:05:36 PDT
(In reply to comment #7)
> It seems that all of the bots except the Snow Leopard one have capable enough
> graphics hardware to run these tests.

As I’ve already explained, it’s not related to the graphics hardware in the machine.  It’s related to the presence of a display attached to the machine.

> It would be really great if they all did so that we can have automated test coverage.
> The bots are really helpful in catching accidental regressions before they reach the tree.

By definition the build bots do not catch regressions before they reach the tree, only afterwards.
Comment 9 Kenneth Russell 2010-04-01 15:11:47 PDT
(In reply to comment #8)
> (In reply to comment #7)
> > It seems that all of the bots except the Snow Leopard one have capable enough
> > graphics hardware to run these tests.
> 
> As I’ve already explained, it’s not related to the graphics hardware in the
> machine.  It’s related to the presence of a display attached to the machine.

Then, restated, the Leopard and other bots seem to have displays attached.

> > It would be really great if they all did so that we can have automated test coverage.
> > The bots are really helpful in catching accidental regressions before they reach the tree.
> 
> By definition the build bots do not catch regressions before they reach the
> tree, only afterwards.

The commit queue seems to fail patches that break tests. That's what I'm referring to.
Comment 10 Mark Rowe (bdash) 2010-04-01 15:38:29 PDT
(In reply to comment #9)
> (In reply to comment #8)
> > As I’ve already explained, it’s not related to the graphics hardware in the
> > machine.  It’s related to the presence of a display attached to the machine.
> 
> Then, restated, the Leopard and other bots seem to have displays attached.

One of the Leopard bots is an iMac, so it inherently has a display attached.  Another is an Xserve that happens to have a display attached.  It’s a single display that is shared amongst an entire rack of Xserves and is used only when doing the initial configuration of the machines.

I said this earlier:

> I’m not sure that it’s practical to require that the build bots run with a display attached.
> This would also seem to rule out the use of virtual machines for build bots as they also
> appear to use the software OpenGL renderer (at least with Mac OS X running inside VMWare Fusion).

To expand on this:
Requiring displays for each build bot makes it impossible to use rack-mount machines and dramatically increases the amount of space required to house them.  It also increases the cost of adding new hardware.

Making it impossible to run the regression tests in a virtual machine also limits our ability to make more efficient use of hardware in the future. 

> > By definition the build bots do not catch regressions before they reach the
> > tree, only afterwards.
> 
> The commit queue seems to fail patches that break tests. That's what I'm
> referring to.

The commit queue is not related to the build bots.  Conflating them only confuses the discussion.
Comment 11 Zhenyao Mo 2010-04-01 15:50:16 PDT
We DO need to test WebGL's full functionalities.  Skipping a lot of carefully designed tests that are designed to catch potential bugs is pretty dangerous.  Please advise how we can achieve this.
Comment 12 Chris Marrin 2010-04-01 16:16:09 PDT
It seems that the problem is that the software OpenGL driver, which is used when a machine is headless, doesn't not support depth+stencil. We should really tolerate this case. We should only fail to create a WebGL context on machines that do not support depth+stencil when asking for depth and stencil both.

Let's talk about this on the WebGL mailing list.
Comment 13 Brent Fulgham 2014-01-09 20:44:11 PST
We don't support systems below Lion for development anymore.