Bug 137842

Summary: REGRESSION(r174107): [EFL] WebGL broken
Product: WebKit Reporter: Carlos Alberto Lopez Perez <clopez>
Component: WebKit EFLAssignee: Nobody <webkit-unassigned>
Status: RESOLVED WONTFIX    
Severity: Normal CC: gyuyoung.kim, hs85.jeong, jinwoo7.song, lucas.de.marchi, mcatanzaro, mtiborinf, ossy, ryuan.choi, yoon
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
See Also: https://bugs.webkit.org/show_bug.cgi?id=143561
Bug Depends on: 144247    
Bug Blocks:    
Attachments:
Description Flags
Using Xorg driver for WTR until fix the GL issue on xvfb driver. none

Carlos Alberto Lopez Perez
Reported 2014-10-17 19:22:07 PDT
Revision r174107 <http://trac.webkit.org/r174107> updated the EFL libraries used by WebKitEFL to a major new version. WebGL support is broken since that. On the terminal, I get "evas_gl_new() Evas GL engine not available." errors. I'm using the internal jhbuild, and I execute the minibrowser as follows: $ cd WebKit $ LD_LIBRARY_PATH=$(pwd)/WebKitBuild/Dependencies/Root/lib WebKitBuild/Release/bin/MiniBrowser http://get.webgl.org/ When it loads, the page says "Your browser supports WebGL", *but* the cube don't shows. I also tried https://webglsamples.googlecode.com/hg/aquarium/aquarium.html and it don't shows any fish on the screen (however it still reports the number of fps despite only showing a grey screen) I tested to revert r174107, then I wiped out WebKitBuild/Dependencies and rebuilt all the jhbuild dependencies (Tools/Scripts/update-webkitefl-libs), and tried the test again. Now it works as expected in both tests. For the record: I tried this on two machines. One with a Nvidia GPU and the proprietary drivers, and another one with an Intel GPU (sandybridge) and the free Mesa drivers (both machines running Debian testing). The same result on both machines: WebGL is broken, but reverting r174107 fixes it.
Attachments
Using Xorg driver for WTR until fix the GL issue on xvfb driver. (1.08 KB, patch)
2015-04-26 19:23 PDT, Hunseop Jeong
no flags
Csaba Osztrogonác
Comment 1 2014-11-03 01:57:09 PST
WebGL tests are skipped since 7+ months: https://trac.webkit.org/changeset/167345 , so I'm not sure if it is important for EFL port nowadays.
Csaba Osztrogonác
Comment 2 2014-11-26 04:04:00 PST
WebGL is still broken with the latest EFL too. Any plan to fix it? If it isn't imporant / supported to have working WebGL with EFL, why not simple disable building it?
Csaba Osztrogonác
Comment 3 2014-12-02 05:05:07 PST
Can we get a feedback from EFL maintainers if WebGL is supported / important?
Csaba Osztrogonác
Comment 4 2014-12-05 07:33:54 PST
ping?
Gyuyoung Kim
Comment 5 2014-12-07 17:19:19 PST
(In reply to comment #3) > Can we get a feedback from EFL maintainers if WebGL is supported / important? I think WebGL is important to us. Besides Tizen also has supported WebGL based on WebKit. Let me check if after finishing my local work.
Jinwoo Song
Comment 6 2014-12-07 17:43:44 PST
FYI, in my local environment, webGL runs well with latest code. I'm using ubuntu 13.10 and NVIDIA driver. ELM_ENGINE=opengl_x11 ./MiniBrowser http://get.webgl.org/
Csaba Osztrogonác
Comment 7 2014-12-08 02:27:44 PST
(In reply to comment #6) > FYI, in my local environment, webGL runs well with latest code. > I'm using ubuntu 13.10 and NVIDIA driver. > > ELM_ENGINE=opengl_x11 ./MiniBrowser http://get.webgl.org/ Ah, one more magic environment variable. It really works. Thanks. But it worked out-of-the-box previously - with EFL 1.10, but something changed with 1.11, and now we need this magic. We already tried the -e option of MiniBrowser, but it doesn't work, only this env magic helps. Can't we make it work out-of-the-box somehow?
Csaba Osztrogonác
Comment 8 2014-12-08 03:14:45 PST
I checked, MiniBrowser calls elm_config_preferred_engine_set("opengl_x11") by default if we don't pass -e command line argument. Something must be changed in elementary between 1.10 and 1.11.
Gwang Yoon Hwang
Comment 9 2014-12-08 03:24:00 PST
For me, I couldn't use evas_gl backend without EVAS_GL_NO_BLACKLIST environment. As you can see, several GPUs are blacklisted (including llvm!), I cannot run WebKitEFL with OpenGL acceleration using out-of-box. https://github.com/kakaroto/e17/blob/master/evas/src/modules/engines/gl_x11/evas_x_main.c
Csaba Osztrogonác
Comment 10 2014-12-08 10:52:41 PST
The problem is come from elementary/src/lib/elm_win.c: ... static Eina_Bool _accel_is_gl(void) { const char *env = NULL; const char *str = NULL; if (_elm_config->accel) str = _elm_config->accel; if (_elm_accel_preference) str = _elm_accel_preference; if ((_elm_config->accel_override) && (_elm_config->accel)) str = _elm_config->accel; env = getenv("ELM_ACCEL"); if (env) str = env; if ((str) && ((!strcasecmp(str, "gl")) || (!strcasecmp(str, "opengl")) || (!strcasecmp(str, "3d")) || (!strcasecmp(str, "hw")) || (!strcasecmp(str, "accel")) || (!strcasecmp(str, "hardware")) )) return EINA_TRUE; return EINA_FALSE; <-------------- BANG!!! } ... else if ((getenv("DISPLAY")) && (!getenv("ELM_ENGINE"))) { if (_accel_is_gl()) { enginelist[0] = ELM_OPENGL_X11; enginelist[1] = ELM_SOFTWARE_X11; enginelist[2] = NULL; } else { enginelist[0] = ELM_SOFTWARE_X11; < -------- BANG !!!!! enginelist[1] = ELM_OPENGL_X11; enginelist[2] = NULL; } } ... To put ELM_OPENGL_X11 in the first place, we should set the ELM_ENGINE environment variable automatically for MiniBrowser and WebKitTestrunner too, or make _accel_is_gl() is true with setting ELM_ACCEL env or elm_config_accel_preference_set("opengl") or something different API call, which modifies _elm_accel_preference and _elm_config->accel_override. Additional problem is to run webgl tests. EFL /elementary / whatever else disables gl if we use xvfb. We shouldn't do it or should have a dedicated tester machine with DISABLE_XVFB_DRIVER=1 environment variable.
Carlos Alberto Lopez Perez
Comment 11 2014-12-09 10:20:04 PST
I don't know why upstream (EFL) disables GL at the first shot. I guess they have a good reason, it would be nice to know that reason. But at least on the WebKitEFL jhbuild I guess some patches are needed to ensure that it runs with GL support enabled even when using the LLVM pipe software rasterizer (the one that is used with xvfb for the tests)
Csaba Osztrogonác
Comment 12 2015-01-08 14:49:29 PST
Any plan to make WebGL work out-of-the-box without magic environment variable hacks?
Csaba Osztrogonác
Comment 13 2015-01-14 01:33:22 PST
ping?
Csaba Osztrogonác
Comment 14 2015-02-26 03:34:34 PST
I skipped these tests properly in http://trac.webkit.org/changeset/180670. Please unskip once WebGL works out of the box on the EFL bot.
Gyuyoung Kim
Comment 15 2015-04-24 02:38:50 PDT
Currently openGL only works on EFL MiniBrowser. It isn't supported by EFL WebKitTestRunner. According to our investigation, EFL seems to only support openGL backend when using elementary. That's why EFL MiniBrowser is able to use openGL. - https://lists.webkit.org/pipermail/webkit-dev/2015-April/027391.html To fix this problem, we may need to fix EFL itself, or make WKR to use Elementary.
Hunseop Jeong
Comment 16 2015-04-26 19:23:47 PDT
Created attachment 251719 [details] Using Xorg driver for WTR until fix the GL issue on xvfb driver.
Gyuyoung Kim
Comment 17 2015-06-15 18:31:16 PDT
(In reply to comment #16) > Created attachment 251719 [details] > Using Xorg driver for WTR until fix the GL issue on xvfb driver. When we enable USE_NATIVE_XDISPLAY, too many flaky tests have been generated. When using it, WTR compares image buffer during layout test (I don't know why WTR compare image buffer when enabling the USE_NATIVE_XDISPLAY yet). However test results are different during the two test cycles. That's why there are too many flaky tests on EFL bot.
Michael Catanzaro
Comment 18 2017-03-11 10:35:45 PST
Closing this bug because the EFL port has been removed from trunk. If you feel this bug applies to a different upstream WebKit port and was closed in error, please either update the title and reopen the bug, or leave a comment to request this.
Note You need to log in before you can comment on or make changes to this bug.