RZ/G1E: WebGLの有効化 #21

ashie · 2016-10-04T09:43:27Z

RZ/G1EでWebGLを有効化できるようにする。

現状のコードでは、prefs.jsで以下の様にするとWebGLを有効化することができた。

user_pref("layers.acceleration.force-enabled", false);
user_pref("webgl.force-enabled", true);

layers.acceleration.force-enabledをtrueにすると、WebGLコンテンツを表示したときに一瞬レンダリングされた後にクラッシュする。両方とも有効化できるようにしたい。

どうもWebGLに限らず複数モジュールでGPUを有効化すると落ちるように見える。Skiaも以下のようにすると落ちるが、SkiaだけでGPUを使うようにすると落ちない（今のところアクセラレーション効果はあまり見られないが）

user_pref("gfx.canvas.azure.backends", "skia");
user_pref("gfx.content.azure.backends", "skia");
user_pref("gfx.canvas.azure.accelerated", true);
user_pref("layers.acceleration.force-enabled", true);

The text was updated successfully, but these errors were encountered:

ashie · 2016-10-04T10:06:21Z

PC用のWebGLのデモはどれも重すぎるかシンプル過ぎるかで、なかなか良いものが見当たらない。

ashie · 2016-10-04T10:16:10Z

落ちるのはGPUドライバの問題である可能性も考えられるが、どちらかと言えば現状のFirefoxへのパッチの方が怪しい。同一wl_surfaceに複数のwl_egl_windowを作ってしまう可能性がある。

ashie · 2016-10-04T10:21:01Z

PC用のWebGLのデモはどれも重すぎるかシンプル過ぎるかで、なかなか良いものが見当たらない。

例えば、以下のコンテンツはレンダリングはちゃんとできているが3fps程度?

http://helloracer.com/webgl/

ashie · 2016-10-05T02:43:18Z

例えば、以下のコンテンツはレンダリングはちゃんとできているが3fps程度?

これは1280x720の場合。

dynamis · 2016-10-05T04:24:30Z

WebGL コンテンツ例ちょっと探してきて追加しておきます (現時点では程よい軽いのはまだ無いかもですがもう少し軽いのあるのが何処だったか思い出します):
https://github.com/mozilla-japan/gecko-embedded/wiki/Sample-Contents#webgl

ashie · 2016-10-05T04:35:33Z

ありがとうございます！
どれも1280x720で1fpsですが、落ちずに安定して動きます。

dynamis · 2016-10-05T07:36:45Z

1fps かー。。。低スペックスマホくらいの挙動というか本来の性能的にはそれなりに出てくれるはずなので何かがおかしいのは間違いないですね。これくらいのコンテンツがある程度動いてくれるのが目標という意味では PlayCanvas のこのあたり…とは思うんですけどね。

TANK
SWOOP

ashie · 2016-12-16T07:26:47Z

45.6.0のリリースノートにWebGLに関する記載があったので一応試してみたが、特に状況変わらず。

cosmo0920 · 2017-05-24T04:46:46Z

ESR52のEGLを有効化したブランチ esr52-wayland-with-egl で WebGL用のEGLコンテキストがどのようにして作成できるかを確認してみたところ、 https://dxr.mozilla.org/mozilla-esr52/source/gfx/gl/GLContextProviderEGL.cpp#893 の https://dxr.mozilla.org/mozilla-esr52/source/gfx/gl/GLContextProviderEGL.cpp#904 で EGL_NO_CONFIGというエラーになり、EGLドライバが対応していないCONFIGが渡ってきてWebGL用のEGLが作れない状態ということがわかりました。
この結果はPC上のweston 1.12.0で試しています。

ashie · 2017-06-12T02:12:55Z

layers.acceleration.force-enabledをtrueにすると、WebGLコンテンツを表示したときに一瞬レンダリングされた後にクラッシュする。

gdbで見てみたところ、実機の場合、~SharedSurface_EGLImageでのeglDestroyImageKHR()の呼び出しでクラッシュしている。

gfx/gl/SharedSurfaceEGL.cpp:

SharedSurface_EGLImage::~SharedSurface_EGLImage()
{
    mEGL->fDestroyImage(Display(), mImage);
    ....

ashie · 2017-06-12T02:16:40Z

gdbで見てみたところ、実機の場合、~SharedSurface_EGLImageでのeglDestroyImageKHR()の呼び出しでクラッシュしている。

Gecko側の問題かドライバ側の問題かはっきりとは分かっていないが、該当箇所をコメントアウトすると

WebGLコンテンツを表示したときに一瞬レンダリングされた後にクラッシュする。

もう少し状況が改善されて、数フレーム程度は描画されるが、最終的にはやはりクラッシュする。

ashie · 2017-06-12T02:24:06Z

今のコードだとSharedSurface_EGLの再利用がされないようになっているが

gfx/gl/SharedSurfaceEGL.cpp

SharedSurface_EGLImage::SharedSurface_EGLImage(GLContext* gl,
                                               GLLibraryEGL* egl,
                                               const gfx::IntSize& size,
                                               bool hasAlpha,
                                               const GLFormats& formats,
                                               GLuint prodTex,
                                               EGLImage image)
    : SharedSurface(SharedSurfaceType::EGLImageShare,
                    AttachmentType::GLTexture,
                    gl,
                    size,
                    hasAlpha,
                    false) // Can't recycle, as mSync changes never update TextureHost.

これを再利用されるように変更すると、大きく改善した。
具体的には、以下のコンテンツがそこそこまともなフレームレートで描画されるようになった。

ashie · 2017-06-12T02:29:40Z

Gecko側の問題かドライバ側の問題かはっきりとは分かっていないが、

eglDestroyImageKHR()はドライバによって実装がまちまちのようだ:

ashie · 2017-06-12T02:41:45Z

1fps かー。。。低スペックスマホくらいの挙動というか本来の性能的にはそれなりに
出てくれるはずなので何かがおかしいのは間違いないですね。

CompositorOGLを有効化せずにWebGLを有効化すると、オフスクリーンバッファからメインメモリへのコピーが発生するので性能が低下する。

ashie · 2017-06-12T05:24:52Z

ただし、http://webglsamples.org/ のデモは今のところ全滅。
動作はするが、画面がぐちゃぐちゃになる。
コンテキストの作り方等に依るのではないか?と思うが、詳細はまた時間が出来たときに見てみる。

ashie · 2017-06-12T05:34:21Z

eglDestroyImageKHR()でクラッシュする原因はFirefox側かドライバ側か分かっていないので、単純なサンプルコードを書いて確認した方が良いだろう。

ashie · 2017-06-19T02:31:09Z

これを再利用されるように変更すると、大きく改善した。

Bug 1374136

cosmo0920 · 2017-06-24T01:04:47Z

根本解決には eglDestroyImageKHR() が正常に動かなければいけない様子。
see: https://bugzilla.mozilla.org/show_bug.cgi?id=1374136#c7
予想されていた反応ではある。

ashie · 2017-07-10T04:33:34Z

gdbで見てみたところ、実機の場合、~SharedSurface_EGLImageでのeglDestroyImageKHR()の呼び出しでクラッシュしている。

現在のレシピでの上記の再現手順:

https://github.com/mozilla-japan/meta-browser/wiki/Build-RZ-G1E-Yocto2.0 の手順に従ってmozilla-japan/meta-browserのfirefox-52.2esrブランチをチェックアウト後、以下のように修正して、ワークアラウンドパッチを外す。

diff --git a/recipes-mozilla/firefox/firefox_52.2.0esr.bb b/recipes-mozilla/firefox/firefox_52.2.0esr.bb
index 9ed4694..fc0d619 100644
--- a/recipes-mozilla/firefox/firefox_52.2.0esr.bb
+++ b/recipes-mozilla/firefox/firefox_52.2.0esr.bb
@@ -113,8 +113,6 @@ SRC_URI += "${@bb.utils.contains('PACKAGECONFIG', 'wayland', \
             file://wayland-patches/0001-Fix-setting-up-shellHasCSD-flag-position.patch \
             file://wayland-patches/0001-Fixed-fullscreen-on-Weston.patch \
             file://wayland-patches/0001-Fixed-clipboard-crashes-after-browser-start-rhbz-145.patch \
-            file://wayland-patches/0001-Enable-sharing-SharedSurface_EGLImage.patch \
-            file://wayland-patches/0002-Add-workaround-for-eglDestroyImageKHR-SEGV.patch \
             file://wayland-patches/0001-Fixed-error-handling-for-posix_fallocate-ftruncate-b.patch \
             file://wayland-patches/0002-Fixed-error-handling-for-posix_fallocate-and-formatt.patch \
             file://wayland-patches/0003-Fixed-rhbz-1464017-Wayland-Hamburger-menu-popup-and-.patch \

https://github.com/mozilla-japan/meta-browser/wiki/Build-RZ-G1E-Yocto2.0 の手順に従ってビルドし、ブートイメージを作成する。
上記ブートイメージでブート後、一度Firefoxを起動して終了させる
以下の内容で ~/.mozilla/firefox/xxxxxxxx.default/user.js を作成する

user_pref("webgl.force-enabled", true);

再度Firefoxを起動し、 http://helloracer.com/webgl/ を開く

最初の1フレーム目はレンダリングできるが、すぐにクラッシュする。

ashie · 2017-07-10T05:52:17Z

クラッシュ時のスタックトレース

#0  raise (sig=11) at ../sysdeps/unix/sysv/linux/pt-raise.c:38
#1  0xb4fc8024 in nsProfileLock::FatalSignalHandler(int, siginfo_t*, void*) () from /usr/lib/firefox-52.2.0/libxul.so
#2  <signal handler called>
#3  0x00000000 in ?? ()
#4  0xb3c276f0 in mozilla::gl::SharedSurface_EGLImage::~SharedSurface_EGLImage() () from /usr/lib/firefox-52.2.0/libxul.so
#5  0xb3c27790 in mozilla::gl::SharedSurface_EGLImage::~SharedSurface_EGLImage() () from /usr/lib/firefox-52.2.0/libxul.so
#6  0xb3c787f0 in mozilla::layers::SharedSurfaceTextureData::~SharedSurfaceTextureData() () from /usr/lib/firefox-52.2.0/libxul.so
#7  0xb3c7881c in mozilla::layers::SharedSurfaceTextureData::~SharedSurfaceTextureData() () from /usr/lib/firefox-52.2.0/libxul.so
#8  0xb3c8132c in mozilla::layers::SharedSurfaceTextureClient::~SharedSurfaceTextureClient() () from /usr/lib/firefox-52.2.0/libxul.so
#9  0xb3c8134c in mozilla::layers::SharedSurfaceTextureClient::~SharedSurfaceTextureClient() () from /usr/lib/firefox-52.2.0/libxul.so
#10 0xb3c24798 in mozilla::AtomicRefCountedWithFinalize<mozilla::layers::TextureClient>::Release() () from /usr/lib/firefox-52.2.0/libxul.so
#11 0xb3c247f4 in RefPtr<mozilla::layers::SharedSurfaceTextureClient>::~RefPtr() () from /usr/lib/firefox-52.2.0/libxul.so
#12 0xb3c28094 in mozilla::gl::SurfaceFactory::RecycleCallback(mozilla::layers::TextureClient*, void*) () from /usr/lib/firefox-52.2.0/libxul.so
#13 0xb3c247c4 in mozilla::AtomicRefCountedWithFinalize<mozilla::layers::TextureClient>::Release() () from /usr/lib/firefox-52.2.0/libxul.so
#14 0xb3c38bf0 in RefPtr<mozilla::layers::TextureClient>::~RefPtr() () from /usr/lib/firefox-52.2.0/libxul.so
#15 0xb3ca67f8 in mozilla::layers::CompositorBridgeChild::NotifyNotUsed(unsigned long long, unsigned long long) () from /usr/lib/firefox-52.2.0/libxul.so
#16 0xb3ca6868 in mozilla::layers::CompositorBridgeChild::RecvParentAsyncMessages(nsTArray<mozilla::layers::AsyncParentMessageData>&&) ()
   from /usr/lib/firefox-52.2.0/libxul.so
#17 0xb39858a0 in mozilla::layers::PCompositorBridgeChild::OnMessageReceived(IPC::Message const&) () from /usr/lib/firefox-52.2.0/libxul.so
#18 0xb37832c0 in mozilla::ipc::MessageChannel::DispatchAsyncMessage(IPC::Message const&) () from /usr/lib/firefox-52.2.0/libxul.so
#19 0xb3789f04 in mozilla::ipc::MessageChannel::DispatchMessage(IPC::Message&&) () from /usr/lib/firefox-52.2.0/libxul.so
#20 0xb378b498 in mozilla::ipc::MessageChannel::RunMessage(mozilla::ipc::MessageChannel::MessageTask&) () from /usr/lib/firefox-52.2.0/libxul.so
#21 0xb378b638 in mozilla::ipc::MessageChannel::MessageTask::Run() () from /usr/lib/firefox-52.2.0/libxul.so
#22 0xb33fa8d4 in nsThread::ProcessNextEvent(bool, bool*) () from /usr/lib/firefox-52.2.0/libxul.so
#23 0xb3418ab8 in NS_ProcessNextEvent(nsIThread*, bool) () from /usr/lib/firefox-52.2.0/libxul.so
#24 0xb3780468 in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) () from /usr/lib/firefox-52.2.0/libxul.so
#25 0xb3769240 in MessageLoop::Run() () from /usr/lib/firefox-52.2.0/libxul.so
#26 0xb48e92fc in nsBaseAppShell::Run() () from /usr/lib/firefox-52.2.0/libxul.so
#27 0xb4f7ab74 in nsAppStartup::Run() () from /usr/lib/firefox-52.2.0/libxul.so
#28 0xb4fcf4f0 in XREMain::XRE_mainRun() () from /usr/lib/firefox-52.2.0/libxul.so
#29 0xb4fcf7d4 in XREMain::XRE_main(int, char**, nsXREAppData const*) () from /usr/lib/firefox-52.2.0/libxul.so
#30 0xb4fcfa14 in XRE_main () from /usr/lib/firefox-52.2.0/libxul.so
#31 0x00014a98 in do_main(int, char**, char**, nsIFile*) [clone .constprop.4] ()
#32 0x0001410c in main ()

以下の箇所(eglDestroyImageKHR)でクラッシュしている:

https://dxr.mozilla.org/mozilla-esr52/source/gfx/gl/SharedSurfaceEGL.cpp#88

ashie · 2017-08-17T02:39:13Z

ただし、http://webglsamples.org/ のデモは今のところ全滅。
動作はするが、画面がぐちゃぐちゃになる。
コンテキストの作り方等に依るのではないか?と思うが、詳細はまた時間が出来たときに見てみる。

その後の調査で、Canvasのサイズに依存していることが分かった。
問題が出ているコンテンツの<canvas> のサイズは 1024 x 1024 だが、これを 800 x 600 に変更すると動作するようになる。

もう少し見ていくと、128 x 4095 = 524,160 pix あたりがギリギリで、32bitとすると2048KBとマジックナンバーっぽい値になる。
ドライバー側でこの辺りに制限があるのではないかと見ている。
入手できるドキュメント等を見る限りそのものズバリの制限は見当たらないが、MAX_TEXTURE_SIZEやMAX_RENDERBUFFER_SIZEは2048のようだ。

ashie · 2017-08-21T09:43:58Z

以下の箇所(eglDestroyImageKHR)でクラッシュしている:

https://dxr.mozilla.org/mozilla-esr52/source/gfx/gl/SharedSurfaceEGL.cpp#88

eglDestroyImageKHR()のシンボル解決の方法に問題があるようだ。クラッシュする問題のコードは
PR_FindFunctionSymbol()で取得しているが、eglGetProcAddress()で取得すると問題ない。
Firefoxの問題と見るべきか。

gfx/gl/GLLibraryEGL.cpp:

305bool
306GLLibraryEGL::EnsureInitialized(bool forceAccel, nsACString* const out_failureId)
307{
...
442    const auto lookupFunction =
443        (GLLibraryLoader::PlatformLookupFunction)mSymbols.fGetProcAddress;
...
610    if (IsExtensionSupported(KHR_image) || IsExtensionSupported(KHR_image_base)) {
611        GLLibraryLoader::SymLoadStruct imageSymbols[] = {
612            { (PRFuncPtr*) &mSymbols.fCreateImage,  { "eglCreateImageKHR",  nullptr } },
613            { (PRFuncPtr*) &mSymbols.fDestroyImage, { "eglDestroyImageKHR", nullptr } },
614            { nullptr, { nullptr } }
615        };
616
617        bool success = GLLibraryLoader::LoadSymbols(mEGLLibrary,
618                                                    &imageSymbols[0],
619                                                    lookupFunction);

gfx/gl/GLLibraryLoader.cpp:

PRFuncPtr
GLLibraryLoader::LookupSymbol(PRLibrary* lib,
                              const char* sym,
                              PlatformLookupFunction lookupFunction)
{
    PRFuncPtr res = 0;

    // try finding it in the library directly, if we have one                                                                                                                
    if (lib) {
        res = PR_FindFunctionSymbol(lib, sym);
    }

    // then try looking it up via the lookup symbol                                                                                                                          
    if (!res && lookupFunction) {
        res = lookupFunction(sym);
    }

ashie · 2017-08-24T08:59:11Z

今のところYocto 2.0・firefox-52.3esrブランチ限定だが、以下の設定でWebGLを有効化できるようにした。

PACKAGECONFIG_append_pn-firefox = " webgl "

ビルド手順も更新した: https://github.com/webdino/meta-browser/wiki/Build-RZ-G1E-Yocto2.0

この内容なら45esrブランチにもバックポートできるが、現行ブランチは52esrなので、ひとまず本issueはこれで完了として、残りの問題に対応する場合は別issueを立てる。

ashie · 2017-08-24T10:08:56Z

補足

eglGetProcAddress()で取れるのはeglDestroyImageKHRだけのようで、ドライバの問題なのかなんなのか判断が付いていない。

ashie · 2017-08-25T05:22:35Z

eglGetProcAddress()で取れるのはeglDestroyImageKHRだけのようで、ドライバの問題なのかなんなのか判断が付いていない。

ちがう、eglDestroyImageKHR()のみPR_FindFunctionSymbol()とeglGetProcAddress()の両方で取得でき、他のはeglGetProcAddress()でのみ取得できる、だ。

eglDestroyImageKHR()のみ間違ってエクスポートされてる?

ashie changed the title ~~RZ/G1E: WebGLの有効バケry~~ RZ/G1E: WebGLの有効化 Oct 4, 2016

ashie added Renesas RZ/G1 RZ/G1 で再現する問題 Wayland labels Oct 5, 2016

ashie mentioned this issue Oct 5, 2016

i.MX6: WebGLの有効化 #22

Open

ashie mentioned this issue Jun 12, 2017

Content/Canvasアクセラレーション #30

Closed

webdino deleted a comment from cosmo0920 Jul 10, 2017

ashie closed this as completed Aug 24, 2017

ashie mentioned this issue Oct 17, 2017

Firefox 45ESR が aarch64 で crash する #15

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

RZ/G1E: WebGLの有効化 #21

RZ/G1E: WebGLの有効化 #21

ashie commented Oct 4, 2016 •

edited

ashie commented Oct 4, 2016

ashie commented Oct 4, 2016 •

edited

ashie commented Oct 4, 2016

ashie commented Oct 5, 2016

dynamis commented Oct 5, 2016

ashie commented Oct 5, 2016

dynamis commented Oct 5, 2016

ashie commented Dec 16, 2016

cosmo0920 commented May 24, 2017 •

edited

ashie commented Jun 12, 2017 •

edited

ashie commented Jun 12, 2017

ashie commented Jun 12, 2017 •

edited

ashie commented Jun 12, 2017 •

edited

ashie commented Jun 12, 2017

ashie commented Jun 12, 2017

ashie commented Jun 12, 2017

ashie commented Jun 19, 2017

cosmo0920 commented Jun 24, 2017

ashie commented Jul 10, 2017 •

edited

ashie commented Jul 10, 2017 •

edited

ashie commented Aug 17, 2017 •

edited

ashie commented Aug 21, 2017

ashie commented Aug 24, 2017

ashie commented Aug 24, 2017

ashie commented Aug 25, 2017

RZ/G1E: WebGLの有効化 #21

RZ/G1E: WebGLの有効化 #21

Comments

ashie commented Oct 4, 2016 • edited

ashie commented Oct 4, 2016

ashie commented Oct 4, 2016 • edited

ashie commented Oct 4, 2016

ashie commented Oct 5, 2016

dynamis commented Oct 5, 2016

ashie commented Oct 5, 2016

dynamis commented Oct 5, 2016

ashie commented Dec 16, 2016

cosmo0920 commented May 24, 2017 • edited

ashie commented Jun 12, 2017 • edited

ashie commented Jun 12, 2017

ashie commented Jun 12, 2017 • edited

ashie commented Jun 12, 2017 • edited

ashie commented Jun 12, 2017

ashie commented Jun 12, 2017

ashie commented Jun 12, 2017

ashie commented Jun 19, 2017

cosmo0920 commented Jun 24, 2017

ashie commented Jul 10, 2017 • edited

ashie commented Jul 10, 2017 • edited

ashie commented Aug 17, 2017 • edited

ashie commented Aug 21, 2017

ashie commented Aug 24, 2017

ashie commented Aug 24, 2017

ashie commented Aug 25, 2017

ashie commented Oct 4, 2016 •

edited

ashie commented Oct 4, 2016 •

edited

cosmo0920 commented May 24, 2017 •

edited

ashie commented Jun 12, 2017 •

edited

ashie commented Jun 12, 2017 •

edited

ashie commented Jun 12, 2017 •

edited

ashie commented Jul 10, 2017 •

edited

ashie commented Jul 10, 2017 •

edited

ashie commented Aug 17, 2017 •

edited