Use ANGLE to render WebGL

RESOLVED FIXED

Status

()

Core
Canvas: WebGL
RESOLVED FIXED
7 years ago
3 years ago

People

(Reporter: Scoobidiver (away), Assigned: vlad)

Tracking

(Depends on: 1 bug)

Trunk
x86
Windows 7
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking2.0 betaN+)

Details

(Whiteboard: webglsamples, URL)

Attachments

(3 attachments)

(Reporter)

Description

7 years ago
Build: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101011 Firefox/4.0b8pre

Display and FPS of Aquarium webgl demo are worst in Minefield than in Chrome.

                    Minefield             Chrome 7.0.544.0
FPS                     14                       20
Museum display       invisible                 visible
Bubble display      cross inside                sharp
Aquarium display       lines                    circle
It would help to have screenshots here; also, knowing your graphics driver.
(Reporter)

Comment 2

7 years ago
Created attachment 482255 [details]
Several screenshots of Aquarium demo in Minefield and Chrome
(Reporter)

Comment 3

7 years ago
Graphic details :
Adapter Description: Mobile Intel(R) 4 Series Express Chipset Family
Vendor ID: 8086
Device ID: 2a42
Adapter RAM: Unknown
Adapter Drivers: igdumd64 igd10umd64 igdumdx32 igd10umd32
Driver Version: 8.15.10.2202
Driver Date: 8-25-2010
Direct2D Enabled: true
DirectWrite Enabled: true
GPU Accelerated Windows: 1/1 Direct3D 10
Thanks; of course, here on NVIDIA I can't reproduce, I do get in Minefield what you see in Chrome. So this really looks like yet another broken GL rendering on Intel bug, and again the only way to fix that will be to use ANGLE for GL rendering via D3D, like Chrome does...
blocking2.0: --- → ?
Summary: Display and FPS of Aquarium webgl demo are worst in Minefield than in Chrome → Display and FPS of Aquarium webgl demo are worse in Minefield than in Chrome
(Reporter)

Updated

7 years ago
(Reporter)

Updated

7 years ago
Whiteboard: webglsamples
Scoobidiver, this didn't get worse at any point, right? It's been bad all the time on your system?
Since this will be fixed by using ANGLE, let's morph this bug into a "use ANGLE" bug.
Assignee: nobody → vladimir
blocking2.0: ? → betaN+
Summary: Display and FPS of Aquarium webgl demo are worse in Minefield than in Chrome → Use ANGLE to render WebGL
Blocks: 569993
Created attachment 492544 [details] [diff] [review]
enable angle build and use it

Now that the dx sdk is installed, we can start to build ANGLE and ship libEGL.dll/libGLESv2.dll on win32.
Attachment #492544 - Flags: review?(bjacob)
Comment on attachment 492544 [details] [diff] [review]
enable angle build and use it

R+, but since this is only for 32-bit windows and not for 64-bit windows, this won't fix Scoobidiver's problems.

Is it a current ANGLE limitation, that it doesn't work on 64-bit windows?
Attachment #492544 - Flags: review?(bjacob) → review+
(Reporter)

Comment 9

7 years ago
> Is it a current ANGLE limitation, that it doesn't work on 64-bit windows?
Aquarium demo works well in Chrome on 64-bit Windows.

Comment 10

7 years ago
(In reply to comment #8)
> Comment on attachment 492544 [details] [diff] [review]
> enable angle build and use it
> 
> R+, but since this is only for 32-bit windows and not for 64-bit windows, this
> won't fix Scoobidiver's problems.
> 
> Is it a current ANGLE limitation, that it doesn't work on 64-bit windows?

I think he means that it won't work on the x64 build.

Comment 11

7 years ago
Minefield: http://img148.imageshack.us/img148/791/aquariumminefield.png

Chrome: http://img403.imageshack.us/img403/3638/aquariumchrome.png

Is this "tearing" thing at the top of the Minefield screenshot also related to this, or is it another bug?

Comment 12

7 years ago
Using ATI Radeon HD 4650 graphics card.
(In reply to comment #11)
> Minefield: http://img148.imageshack.us/img148/791/aquariumminefield.png
> 
> Chrome: http://img403.imageshack.us/img403/3638/aquariumchrome.png
> 
> Is this "tearing" thing at the top of the Minefield screenshot also related to
> this, or is it another bug?

This tearing is an artifact of the demo itself when its textures haven't finished loading. Normally if you give it some more time it ends up rendering correctly.

Not related to this bug.
(In reply to comment #8)
> Is it a current ANGLE limitation, that it doesn't work on 64-bit windows?

It does, the project file just isn't set up for it.  Should be a simple fix, but I want to get the base stuff in first given that we're not supporting 64-bit windows for Fx4.
Created attachment 494428 [details] [diff] [review]
updated patch, with some configure fixes

This has some configure.in goop to look up the SDK path in the registry if it's not already in INCLUDE/LIB and use it.  This is needed so that we can parallelize the work of getting this on developers' machines, onto tinderboxes, and eventually get the sdk check into mozilla-build without blocking on any of those pieces.  Tested on try server.
Attachment #494428 - Flags: review?(ted.mielczarek)
http://hg.mozilla.org/mozilla-central/rev/f1dd337db722
http://hg.mozilla.org/mozilla-central/rev/3bb7e1a3cb22

(sorry ted -- will fix up any review comments afterwards, needed to get this in to make sure it would be in b8)

Updated

7 years ago
Depends on: 616682

Updated

7 years ago
Depends on: 616685
(Reporter)

Updated

7 years ago
Blocks: 616682, 616685
No longer depends on: 616682, 616685

Updated

7 years ago
No longer blocks: 616682, 616685
Depends on: 616682, 616685
(Reporter)

Comment 17

7 years ago
This patch does not fix the problem I described in comment 0 whatever webgl.prefer_egl, webgl.prefer_gl values.
Attached screenshots are still applicable.

Updated

7 years ago
Depends on: 616714

Comment 18

7 years ago
You might want to test the latest Intel drivers (8.15.10.2226) released on 10/23/2010 which is newer than 2202 and see if it fixes anything when it comes to OpenGL and WebGL.

32bit
http://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=19468&ProdId=3231&lang=eng

64bit
http://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=19469&ProdId=3231&lang=eng
(Reporter)

Comment 19

7 years ago
Results in comment 17 are with the new Intel driver: 8.15.10.2226.
Anyway, it was working well in Chrome with Intel driver 8.15.10.2202 that use Angle to render WebGL.
There is something wrong in the code and Angle is not used to render WebGL.
As stated in comment #14, this doesn't do anything for 64-bit windows.  You are still rendering using Intel's OpenGL drivers there.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
(Reporter)

Comment 21

7 years ago
As this bug has been hijacked by the WebGL rendering on 32-bit Windows, I filed bug 616864 for the WebGL rendering on 64-bit Windows.
(Reporter)

Comment 22

7 years ago
> I filed bug 616864 for the WebGL rendering on 64-bit Windows
with a 32-bit build.
For WebGL rendering with ANGLE on 64-bit build, it is bug 616918.
Duplicate of this bug: 594357
Duplicate of this bug: 595793
Duplicate of this bug: 598939
Duplicate of this bug: 598940
Comment on attachment 494428 [details] [diff] [review]
updated patch, with some configure fixes

># HG changeset patch
># Parent 508f94ce63e4c2e66d2a36faa39fbcb1828e0681
>
>diff --git a/browser/installer/package-manifest.in b/browser/installer/package-manifest.in
>--- a/browser/installer/package-manifest.in
>+++ b/browser/installer/package-manifest.in
>@@ -405,6 +405,14 @@
> @BINPATH@/components/@DLL_PREFIX@mozgnome@DLL_SUFFIX@
> #endif
> 
>+; ANGLE on Win32
>+#ifdef XP_WIN32
>+#ifndef HAVE_64BIT_OS
>+@BINPATH@/libEGL.dll
>+@BINPATH@/libGLESv2.dll
>+#endif
>+#endif

Could you explicitly test MOZ_ANGLE here? (Might need to add it to DEFINES in the Makefile).

>diff --git a/configure.in b/configure.in
>--- a/configure.in
>+++ b/configure.in
>@@ -6315,6 +6315,51 @@ if test -n "${MOZ_JAVAXPCOM}"; then
> fi
> 
> dnl ========================================================
>+dnl = ANGLE OpenGL->D3D translator for WebGL
>+dnl = * only applies to win32
>+dnl = * enabled by default (shipping build); requires explicit --disable to disable
>+dnl ========================================================
>+MOZ_ANGLE=
>+MOZ_DIRECTX_SDK_PATH=
>+case "$target_os" in
>+    *msvc*|*mks*|*cygwin*|*mingw*)
>+        MOZ_ANGLE=1
>+        ;;
>+esac
>+
>+if test -n "$MOZ_ANGLE"; then
>+MOZ_ARG_DISABLE_BOOL(angle,
>+[  --disable-angle     Disable building of ANGLE for WebGL->D3D translation],
>+    MOZ_ANGLE=,
>+    MOZ_ANGLE=1)
>+
>+if test -n "$MOZ_ANGLE"; then
>+  if test -z "$_WIN32_MSVC"; then
>+    AC_MSG_ERROR([Building ANGLE requires MSVC.  To build without ANGLE, reconfigure with --disable-angle.])
>+  fi
>+
>+  AC_CHECK_HEADER(d3dx9.h, [], [MOZ_ANGLE=])
>+
>+  if test -z "$MOZ_ANGLE"; then
>+    # Try again, but try to get the SDK path from the registry.  We're going to hardcode
>+    # the February 2010 SDK, since that's the one that's installed on the tinderboxen.
>+    MOZ_DIRECTX_SDK_PATH=`reg query 'HKLM\Software\Microsoft\DirectX\Microsoft DirectX SDK (February 2010)' //v InstallPath | grep REG_SZ | sed 's,  *, ,g' | cut -d' ' -f4`
>+    if test -n "$MOZ_DIRECTX_SDK_PATH" ; then
>+      if test -f "$MOZ_DIRECTX_SDK_PATH"/include/d3dx9.h && test -f "$MOZ_DIRECTX_SDK_PATH"/lib/x86/dxguid.lib ; then
>+        AC_MSG_WARN([Found DirectX SDK in registry, using $MOZ_DIRECTX_SDK])
>+        MOZ_ANGLE=1
>+      fi
>+    fi
>+  fi

I know we talked about this at some point, but we do want to ship a MozillaBuild with support for detecting DirectX SDKs at some point, right? We should probably reopen bug 535590 and fix it.

>+
>+  if test -z "$MOZ_ANGLE"; then
>+    AC_MSG_WARN([Couldn't find d3dx9.h in your INCLUDE path, needed for ANGLE.  Please install the February 2010 DirectX SDK, or make another version available in your LIB and INCLUDE path env variables.  To explicitly build without ANGLE, reconfigure with --disable-angle.])
>+    AC_MSG_WARN([This will become an error in the future.])
>+  fi
>+fi
>+fi

Other than developer inconvenience, is there a reason not to make this an error? It sucks to have our official build and developers' builds drift out of sync.

>diff --git a/gfx/angle/Makefile.in b/gfx/angle/Makefile.in
>--- a/gfx/angle/Makefile.in
>+++ b/gfx/angle/Makefile.in
>@@ -130,10 +130,12 @@ include $(topsrcdir)/config/rules.mk
> CXXFLAGS := $(filter-out -pedantic,$(CXXFLAGS))
> CFLAGS := $(filter-out -pedantic,$(CFLAGS))
> 
>-ifdef _MSC_VER
>-# disabled for now, but we should be building it in the future once
>-# bug 529938 is fixed
>-#BUILD_ANGLE = 1
>+ifdef MOZ_ANGLE
>+# ANGLE only on Win32 for now, the solution isn't set up
>+# for 64-bit yet.
>+ifndef HAVE_64BIT_OS
>+BUILD_ANGLE = 1
>+endif

Just do the 64-bit check in configure so that BUILD_ANGLE is always correct.

r=me with those changes.
Attachment #494428 - Flags: review?(ted.mielczarek) → review+

Comment 28

7 years ago
This change appears to have broken a lot of complex shaders, including a lot of these:
http://www.iquilezles.org/apps/shadertoy/

Could we have an option to disable ANGLE and use OpenGL on Windows?
You have it already, although it's hidden (you have to create it): webgl.prefer_gl

Comment 30

7 years ago
Thanks, that fixes it. Is there any plan to improve ANGLE for shaders like these?

Comment 31

7 years ago
(In reply to comment #30)
> Thanks, that fixes it. Is there any plan to improve ANGLE for shaders like
> these?

I'd suggest filing an ANGLE bug at http://code.google.com/p/angleproject/ for any issues you find.
Blocks: 632148
Blocks: 1041670
You need to log in before you can comment on or make changes to this bug.