Give a choice to use OpenGL ES (ANGLE) on Windows

[techtonik]

Reticketed from #3632.

OpenGL really suxx on my hardware (just 5 years old notebook) and I want to play with Godot. I had some success making it run with regal by @nigels-com, but it is still too slow.

Chrome uses OpenGL ES for WebGL and it works ok through ANGLE library. Firefox uses it too.

Ideally, it should be possible to select ANGLE renderer with command line.

[reduz]

The amount of people with your hardware is reaaally small and will keep
decreasing. It doesn't make much sense to do all this work to support it.

On Tue, Feb 9, 2016 at 11:51 AM, anatoly techtonik <notifications@github.com

wrote:

Reticketed from #3632 #3632.

OpenGL really suxx on my hardware (just 5 years old notebook) and I want
to play with Godot. I had some success making it run with regal
https://github.com/p3/regal by @nigels-com
https://github.com/nigels-com, but it is still too slow.

Chrome uses OpenGL ES for WebGL and it works ok through ANGLE
https://en.wikipedia.org/wiki/ANGLE_(software) library. Firefox uses it
too.

Ideally, it should be possible to select ANGLE renderer with command line.

—
Reply to this email directly or view it on GitHub
#3634.

[techtonik]

How much work exactly and what is this work? Generate stubs for dynamic linking. Is that all?

[techtonik]

The amount of people with hardware may be small, but OpenGL support in Windows drivers is much worse for a bigger audience. That's why Google decided to create ANGLE and translate calls into DirectX. This will at least benefit Godot performance on this platform.

[punto-]

I think the way to do this is making a gl_context that uses egl (there's
one in the winrt port, but uses some windows 8 specific stuff, it shouldn't
be too hard to make one for normal windows), then get angle to compile
inside our tree. The rest should work normally, angle provides the egl and
gles headers, so you have to tell the rasterizer to include those (instead
of the desktop gl ones, or glew)

I don't know if dynamic linking with stubs works because angle is gles and
godot on pc is desktop gl.

On 9 February 2016 at 15:23, anatoly techtonik notifications@github.com
wrote:

How much work exactly and what is this work? Generate stubs for dynamic
linking. Is that all?

—
Reply to this email directly or view it on GitHub
#3634 (comment).

[techtonik]

It would be much-much clearer is somebody could draw diagrams. =/ regal somehow does all the hard stuff of dynamic linking for many OpenGL features and even opens web port with debug info, but I have no idea what Godot requires on its side. I guess I need to get that compiled first to see.

[punto-]

Since we got kicked out of the other issue :p, here's a link to a 32 bit
build with ANGLE:

http://op.godotengine.org:81/godot.windows.tools.angle.32.exe

(it's new, I made it with the 32 bit cmd prompt this time) we need people
with the intel cards where normal godot fails to test it, also check if you
have "d3dcompiler_47.dll" on your system, the Angle people tell me this is
what's causing the "failed to create d3d shaders" error.
Also try this on chrome on the same computer:

http://tof.p1x.in/html5/

It's a game exported to html5, chrome supposedly uses the same Angle code,
so if it works there it should work on ours.

On 9 February 2016 at 16:53, anatoly techtonik notifications@github.com
wrote:

It would be much-much clearer is somebody could draw diagrams. =/ regal
somehow does all the hard stuff of dynamic linking for many OpenGL features
and even opens web port with debug info, but I have no idea what Godot
requires on his side. I guess I need to get that compiled first.

—
Reply to this email directly or view it on GitHub
#3634 (comment).

[punto-]

Also check for the error ""No D3D compiler module found - aborting!\n", or
similar, anything from this function
https://github.com/punto-/godot/blob/angle/drivers/angle/libANGLE/renderer/d3d/HLSLCompiler.cpp#L109

On 20 February 2016 at 13:50, Ariel Manzur ariel@godotengine.org wrote:

Since we got kicked out of the other issue :p, here's a link to a 32 bit
build with ANGLE:

http://op.godotengine.org:81/godot.windows.tools.angle.32.exe

(it's new, I made it with the 32 bit cmd prompt this time) we need people
with the intel cards where normal godot fails to test it, also check if you
have "d3dcompiler_47.dll" on your system, the Angle people tell me this is
what's causing the "failed to create d3d shaders" error.
Also try this on chrome on the same computer:

http://tof.p1x.in/html5/

It's a game exported to html5, chrome supposedly uses the same Angle code,
so if it works there it should work on ours.

On 9 February 2016 at 16:53, anatoly techtonik notifications@github.com
wrote:

It would be much-much clearer is somebody could draw diagrams. =/ regal
somehow does all the hard stuff of dynamic linking for many OpenGL features
and even opens web port with debug info, but I have no idea what Godot
requires on his side. I guess I need to get that compiled first.

—
Reply to this email directly or view it on GitHub
#3634 (comment)
.

[techtonik]

Current output is below. There is no system-wide d3dcompiler_47.dll so I am going to steal one from Chrome.

...
S3TC: 1 ATITC: 0
ERROR: ShaderGLES2::get_current_version: CanvasShaderGLES2: Program LINK FAILED:
Failed to create D3D shaders.

   At: drivers\gles2\shader_gles2.cpp:544
ERROR: ShaderGLES2::get_current_version: Method/Function Failed, returning: 0
   At: drivers\gles2\shader_gles2.cpp:551
ERROR: ShaderGLES2::bind: Condition ' !version ' is true. returned: false
   At: drivers\gles2\shader_gles2.cpp:126
ERROR: ShaderGLES2::_get_uniform: Condition ' !version ' is true. returned: -1
   At: C:\msys\1.0\home\ariel\godot-angle\drivers/gles2/shader_gles2.h:354
ERROR: ShaderGLES2::_get_uniform: Condition ' !version ' is true. returned: -1
   At: C:\msys\1.0\home\ariel\godot-angle\drivers/gles2/shader_gles2.h:354
ERROR: ShaderGLES2::_get_uniform: Condition ' !version ' is true. returned: -1
   At: C:\msys\1.0\home\ariel\godot-angle\drivers/gles2/shader_gles2.h:354
ERROR: ShaderGLES2::_get_uniform: Condition ' !version ' is true. returned: -1
   At: C:\msys\1.0\home\ariel\godot-angle\drivers/gles2/shader_gles2.h:354
ERROR: ShaderGLES2::_get_uniform: Condition ' !version ' is true. returned: -1
   At: C:\msys\1.0\home\ariel\godot-angle\drivers/gles2/shader_gles2.h:354
ERROR: ShaderGLES2::_get_uniform: Condition ' !version ' is true. returned: -1
   At: C:\msys\1.0\home\ariel\godot-angle\drivers/gles2/shader_gles2.h:354

[techtonik]

Copying d3dcompiler_47.dll from Chrome makes it work. =) Even faster than with regal.

[punto-]

Ok.. so apparently you can have direct x but not have this mysterious dll..
I guess that's a solution for these old cards then, if they get this dll
with the .exe..

On 24 February 2016 at 09:24, anatoly techtonik notifications@github.com
wrote:

Copying d3dcompiler_47.dll from Chrome makes it work. =) Even faster than
with regal.

—
Reply to this email directly or view it on GitHub
#3634 (comment).

[techtonik]

There a lot of copies of this .dll with installed apps, but nothing system-wide.

[techtonik]

@punto- can you rebase the binary against 2.0 release? So that it is possible to work with Godot on Intel GPU card and report bugs there.

[punto-]

There seems to be other system wide versions of the dll tho, I have from
d3dcompiler_33 up to 47, maybe people have the older versions installed
with their older installation of the d3d distributable? The angle people
tell me we could try loading older versions but they might crash.

I'll try the git thing later.

On 24 February 2016 at 10:39, anatoly techtonik notifications@github.com
wrote:

@punto- https://github.com/punto- can you rebase the binary against 2.0
release? So that it is possible to work with Godot on Intel GPU card and
report bugs there.

—
Reply to this email directly or view it on GitHub
#3634 (comment).

[techtonik]

I have those D3DCompiler_33 up to 43 in system32.

[27thLiz]

Ok, I finally got around to testing this again on my gma X3100 laptop.
I took the d3dcompiler_47.dll from firefox and it works.
Performance is not too great (~40 fps for platformer2d vs ~120 on linux/mesa), but that's still ok.. kinda ^^
However, there seem to be issues with 3d, the world in the truck town demo is completely blank. You can only see the car. Console spams these errors:

ERROR: ShaderGLES2::get_custom_uniform_location: Index p_idx out of size (version->custom_uniform_locations.size()).
   At: C:\msys\1.0\home\ariel\godot-angle\drivers/gles2/shader_gles2.h:336
ERROR: ShaderGLES2::set_custom_uniform: Index p_idx out of size (version->custom_uniform_locations.size()).
   At: C:\msys\1.0\home\ariel\godot-angle\drivers/gles2/shader_gles2.h:329

[techtonik]

@punto- so is it ready to be made an official backend / video driver?

[punto-]

I don't know.. There's a bug in the rasterizer, the "screen space shaders"
demo doesn't work (also doesn't work on browsers). And I haven't tried any
3d examples with it, but it looks like if fails even worse there.. I wonder
if the same example works on a browser tho

On 7 March 2016 at 16:01, anatoly techtonik notifications@github.com
wrote:

@punto- https://github.com/punto- so is it ready to be made an official
backend / video driver?

—
Reply to this email directly or view it on GitHub
#3634 (comment).

[techtonik]

I don't understand why those "screen space shaders" are in 2D section. Should everything that requires 3D acceleration be in 3D or 2.5D section?

[27thLiz]

Well, I guess technically all the 2D demos also need 3D acceleration to work. Nowadays there's no specialized 2d hardware anymore ^^

[techtonik]

@Hinsbart and why ordinary CPU / video card is not enough to run 2D stuff nowadays? It is game engine fault when 2D games like FTL with few pixels movement is so awfully slow on modern PC with 2 core 3GHz CPU and 8 Gb of memory. Back in 1995 we had 486 with 0.016GHz running full screen demos like Second Reality at full speed. And in 3D we had Quake on about 0.166GHz processors working flawlessly.

[punto-]

The screen space shader stuff is no "ordinary" game, it has to capture the
screen and feed it back to the shader.. Also angle seems to be failing with
3d too.. I still agree that modern computers should be able to handle them,
but these are the cases where angle fails..

On 8 March 2016 at 04:11, anatoly techtonik notifications@github.com
wrote:

@Hinsbart https://github.com/Hinsbart and why ordinary CPU / video card
is not enough to run 2D stuff nowadays? It is game engine fault when 2D
games like FTL with few pixels movement is so awfully slow on modern PC
with 2 core 3GHz CPU and 8 Gb of memory. Back in 1995 we had 486 with
0.016GHz running full screen demos like Second Reality at full speed. And
in 3D we had Quake on about 0.166GHz processors working flawlessly.

—
Reply to this email directly or view it on GitHub
#3634 (comment).

[techtonik]

@punto- can ANGLE backend be compiled in godot as optional to be
selected with video driver command line option? If it is downloadable
and reproducible, then I can at least make apitrace and ask in ANGLE
mailing list.

[punto-]

It's a bit more difficult to compile it as a selectable video driver
because we'd have to compile the "rasterizer_gles2" twice, one using normal
gl, another using angle. It's the same source file that compiles with 2
different sets of options. That case doesn't really exist anywhere else..

I did merge my angle branch with the 2.0 branch of the main tree, it's here:

https://github.com/punto-/godot/tree/angle-2.0

Another way of testing this is by exporting to a browser, as far as I can
tell the same bugs we're having with angle are also happening on chrome and
firefox with the html5 export.

On 9 March 2016 at 11:31, anatoly techtonik notifications@github.com
wrote:

@punto- https://github.com/punto- can ANGLE backend be compiled in
godot as optional to be
selected with video driver command line option? If it is downloadable
and reproducible, then I can at least make apitrace and ask in ANGLE
mailing list.

—
Reply to this email directly or view it on GitHub
#3634 (comment).

[techtonik]

@punto- it makes sense to export all demos to html5 for each release (#4000)
Then I could just post a link to ANGLE / WebGL developers. I suspect that
HTML5 / WebGL may deny access to screen buffer because of security,

For dynamic video driver selection - is it possible select driver and do feature
selection dynamically as opposed to hardcoded defines? Is the new plugin
system capable of that?

[techtonik]

@punto- I can't compile it with MinGW-W64 5.3.0

> git clone https://github.com/punto-/godot/ angle-2.0 -b angle-2.0
> cd angle-2.0
> scons platform=windows angle=yes
...
drivers\angle/common/angleutils.h:64:6: note:   template argument deduction/substitution failed:
drivers\angle/common/angleutils.h:75:27: note:   mismatched types 'T*' and 'int'
         SafeDelete(element);
                           ^

Full build log https://pastebin.mozilla.org/8864717

[techtonik]

Fixed this with enabling C++11 mode:

diff --git a/drivers/angle/SCsub b/drivers/angle/SCsub
index ab9c69e..225985f 100644
--- a/drivers/angle/SCsub
+++ b/drivers/angle/SCsub
@@ -274,6 +274,7 @@ Import('env')

 env_angle = env.Clone()
 env_angle.Append(CCFLAGS=['-DANGLE_ENABLE_ESSL', '-DANGLE_ENABLE_GLSL', '-DANGLE_ENABLE_HLSL', '-DANGLE_ENABLE_D3D9', '-DANGLE_ENABLE_D3D11', '-DANGLE_TRANSLATOR_STATIC'])
+env_angle.Append(CXXFLAGS=['-std=c++11'])
 env_angle.Append(CPPPATH=['#drivers/angle', '#drivers/angle/include'])
 env_angle.add_source_files(env.drivers_sources,sources)

[techtonik]

Now the problem is:

drivers\angle\libANGLE\renderer\d3d\d3d11\win32\NativeWindow.cpp:15:19: fatal error: dcomp.h: No such file or directory

Now looking how to disable D3D11 in https://groups.google.com/d/topic/angleproject/4O00UBCP3T8/discussion

[techtonik]

For now I am trying to remove files mentioned in D3D11 option in https://chromium.googlesource.com/angle/angle/+/master/src/libGLESv2.gypi

[techtonik]

Now I am trying to workaround with -msse flag after an error mentioned in http://stackoverflow.com/questions/31846389/why-do-i-get-this-compile-error-with-gcc-5-and-cilk-plus

[techtonik]

-msse didn't work. Trying with -msse2, because the offending file is called ./libANGLE/renderer/d3d/loadimageSSE2.cpp

And here is why it appeared https://bugs.chromium.org/p/angleproject/issues/attachmentText?aid=2166

[techtonik]

It is impossible to disable D3D11 for now. Waiting for a fix https://groups.google.com/d/msg/angleproject/4O00UBCP3T8/f6DG6yhcDgAJ

[techtonik]

Fix for me to be able to run this on D3D9 is in the process - https://chromium-review.googlesource.com/#/c/336780/

[techtonik]

Fix committed. Need to update ANGLE sources and try again https://bugs.chromium.org/p/angleproject/issues/detail?id=1345

[techtonik]

Working on this.. Got stuck in Google workflow tools.

[punto-]

What are the current issues? I remember a couple of the demos don't work,
but they also fail the same way in the html5 export

On 28 May 2016 at 01:52, anatoly techtonik notifications@github.com wrote:

Working on this.. Got stuck in Google workflow tools.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#3634 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AGVmPQGeGXzXC0Ls2pd-6GlmSn25lQksks5qF8oZgaJpZM4HWc2p
.

[techtonik]

@punto- I need to update ANGLE the code to tell about current issues, because it needs to run on DirectX 9 for MinGW gcc that I've got on my Vista. So far I am trying to figure out which files to copy there.

[techtonik]

@punto- can you rebase your branch on top of current master? I've got some merge conflicts that I am unable to resolve.

[techtonik]

Closing this to restart from scratch with new information in #6726