Closed Bug 603367 Opened 14 years ago Closed 14 years ago

Use ANGLE to render WebGL

Categories

(Core :: Graphics: CanvasWebGL, defect)

x86
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED FIXED
Tracking Status
blocking2.0 --- betaN+

People

(Reporter: scoobidiver, Assigned: vlad)

References

(Depends on 1 open bug, )

Details

(Whiteboard: webglsamples)

Attachments

(3 files)

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.
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
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
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+
> 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.
(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.
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?
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.
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)
Depends on: 616682
Depends on: 616685
Blocks: 616682, 616685
No longer depends on: 616682, 616685
No longer blocks: 616682, 616685
Depends on: 616682, 616685
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.
Depends on: 616714
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
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
Closed: 14 years ago
Resolution: --- → FIXED
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.
> 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.
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+
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
Thanks, that fixes it. Is there any plan to improve ANGLE for shaders like these?
(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.
You need to log in before you can comment on or make changes to this bug.