WebGL graphics quality regression in Sponza by Babylon.js demo.

NEW
Unassigned

Status

()

P3
normal
3 years ago
2 years ago

People

(Reporter: jujjyl, Unassigned)

Tracking

({site-compat})

47 Branch
site-compat
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox47 affected)

Details

(Whiteboard: gfx-noted)

Attachments

(1 attachment)

(Reporter)

Description

3 years ago
STR: Visit http://www.babylonjs.com/demos/SponzaDynamicShadows/

Observed:

Chrome 48.0.2564.103 m: https://dl.dropboxusercontent.com/u/40949268/dump/sponza_chrome_48.png
Firefox Stable 44.0 32-bit: https://dl.dropboxusercontent.com/u/40949268/dump/sponza_firefox_44_32bit.png
Firefox Nightly 47.0a1 (2016-02-10): https://dl.dropboxusercontent.com/u/40949268/dump/sponza_firefox_47_64bit.png

Chrome and FF 44 look good, but FF Nightly 47 looks broken. The scene is overall much lighter, and there is odd banding in the shadows (see the wall on the left side), and the shadow edges are not smooth, but very hard (binary on/off), and pixelated.
(Reporter)

Comment 1

3 years ago
Bisected this down to https://hg.mozilla.org/integration/fx-team/pushloghtml?fromchange=cf17f3b3be6c6e7e0f891a90ab98db5c47f176af&tochange=31c4e5dbd4c3775df883c787988261f979925f6a, but that looks so suspicious that I had to bisect it again to confirm, and both times it led me to this range.

However the first bug there relates only to tests, and the second one only to Firefox for Android, so I am very suspicious of mozregression working correctly here.

Attaching the full bisection log for reference.

Restricting to looking at the bisection results only on mozilla-central side, it looks like this: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=0babaa3edcf908c393b68a3dc2d1c2a2450c31ed&tochange=0711218a018d912036f7d3be2ae2649e213cfb85
(Reporter)

Comment 2

3 years ago
Let me still ping Drew Willcoxon and Varun Joshi, who authored the changes that mozregression is pointing to. Can you guys think of any way that these could affect the behavior of the STR above?
Flags: needinfo?(varunj.1011)
Flags: needinfo?(adw)
I think mozregression is making a mistake here. There are a bunch of WebGL changes in mozilla-central range (including an ANGLE update) that are much more likely to have caused the regression.
Yeah, you can see mozregression getting lost here:

 https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=0babaa3edcf908c393b68a3dc2d1c2a2450c31ed&tochange=0711218a018d912036f7d3be2ae2649e213cfb85

 3:21.65 INFO: Switching bisection method to taskcluster
 3:21.65 INFO: Getting mozilla-central builds between 0babaa3edcf908c393b68a3dc2d1c2a2450c31ed and 0711218a018d912036f7d3be2ae2649e213cfb85
 3:23.55 WARNING: Skipping build 0711218a018d: Unable to find build info using the taskcluster route 'gecko.v2.mozilla-central.revision.0711218a018d912036f7d3be2ae2649e213cfb85.firefox.win64-opt'
 3:28.14 INFO: Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=0babaa3edcf908c393b68a3dc2d1c2a2450c31ed&tochange=f143af51f6e35932927b8ccac2509facbbe7b539
Depends on: 1247610
Whiteboard: gfx-noted,regression
Yeah, my changeset wouldn't have caused this.
Flags: needinfo?(adw)
Suspects:
	5ab4f7bd7eda	Jeff Gilbert — Bug 1231040 - Check for premulting better. - r=jrmuizel
	9fda66262ca8	Jeff Muizelaar — Bug 1232462. Only ask for a higher version of GLSL when using WebGL2. r=jgilbert

Wild cards:
	99cb8381f776	Jeff Muizelaar — Bug 1231657. Don't allow linking different versions shaders. r=jgilbert
	10283ef31aee	Jeff Gilbert — Bug 1232864 - Cauterize and release WebGL 2 to Nightly. - r=jrmuizel
	05b0e3cb50a4	Jeff Muizelaar — Bug 1229210. Handle the new formats required by WebGL2 in ReadPixels. r=jgilbert
It's WebGL 2:

> document.getElementsByTagName('canvas').length
> > 1
> c = document.getElementsByTagName('canvas')[0]
> c.getContext('webgl')
> > null
> c.getContext('webgl2')
> > <webgl2 object>
(Reporter)

Comment 8

3 years ago
64-bit FF Nightly 47.0a1 (2016-02-11), e10s enabled: glitched
64-bit FF Nightly 47.0a1 (2016-02-11), e10s disabled: glitched
64-bit FF Nightly 47.0a1 (2016-02-11), e10s enabled and webgl.enable-prototype-webgl2;false: correct output
64-bit FF Nightly 47.0a1 (2016-02-11), e10s enabled and webgl.bypass-shader-validation;true and webgl.disable-angle;true: glitched
(Reporter)

Comment 9

3 years ago
Thanks Jeff for observing the log and marking down bug 1247610. Let me clear needinfo from Varun, as it is pretty clear that is not related.
Flags: needinfo?(varunj.1011)
See Also: → bug 1247771
For the record, I'm betting that if the site stops requesting webgl2, and only requests webgl1, it will work again.

Whether the website should be expected to automagically work with webgl2, that'll take more effort. WebGL 1 content is not guaranteed to run win WebGL 2, IIRC.

However, for 'Get this site working again', the site should not be requesting 'webgl2' right now. Can we reach out to the devs?
Keywords: site-compat
Whiteboard: gfx-noted,regression → gfx-noted
(Reporter)

Comment 11

3 years ago
Jeff, I agree with that comment, but only if we can prove that it is a result of using some feature (an extension perhaps?) in a nonforwardcompatible manner. Do you know which such feature it is using badly that led to this conclusion?

I can't recall all of a sudden any case where if one restricts to core WebGL 1 features _without_ any extensions, that it would not work in core WebGL2. WebGL extensions (and native GL for that matter) are notoriously bad in that they don't have any forward compatibility, but is the site (mis-)using one that is the cause of the graphics glitch?
(In reply to Jukka Jylänki from comment #11)
> Jeff, I agree with that comment, but only if we can prove that it is a
> result of using some feature (an extension perhaps?) in a
> nonforwardcompatible manner. Do you know which such feature it is using
> badly that led to this conclusion?
> 
> I can't recall all of a sudden any case where if one restricts to core WebGL
> 1 features _without_ any extensions, that it would not work in core WebGL2.
> WebGL extensions (and native GL for that matter) are notoriously bad in that
> they don't have any forward compatibility, but is the site (mis-)using one
> that is the cause of the graphics glitch?

I do not have time to do this, but maybe someone else does. Investigating this is bug 1247771.

Until then, the easiest fix is on the site's developer to make.
Flags: needinfo?(milan)
The STR link has been fixed by the authors to only use webgl1, but I still have rendering issues on OSX+Intel. I don't know if it's a regression.

How's it look on Windows now?
Flags: needinfo?(jujjyl)
(Reporter)

Updated

3 years ago
Blocks: 1247804
(Reporter)

Comment 14

3 years ago
Renders correctly for me now on HASWELL. Great to have developer attention to this! Hopefully he knows the code to quickly pinpoint if there is something forward-incompatible that the code was doing.

Jeff, marked down https://bugzilla.mozilla.org/show_bug.cgi?id=1247804 for a small glitch I'm still seeing when running in native GL mode. Can you post a screenshot of the rendering issues that still remain?
Flags: needinfo?(jujjyl)
(In reply to Jukka Jylänki from comment #14)
> Renders correctly for me now on HASWELL. Great to have developer attention
> to this! Hopefully he knows the code to quickly pinpoint if there is
> something forward-incompatible that the code was doing.
> 
> Jeff, marked down https://bugzilla.mozilla.org/show_bug.cgi?id=1247804 for a
> small glitch I'm still seeing when running in native GL mode. Can you post a
> screenshot of the rendering issues that still remain?

This is exactly the bug I see when running OSX+NV. OSX+Intel doesn't render the shadows because the requested 1024x1024 cube map size is larger than we allow. (512!)

We have a longstanding task to relax our strict OSX texture size caps. I'll take a quick look at this.
Flags: needinfo?(milan)
You need to log in before you can comment on or make changes to this bug.