[Mesa-dev] [Freedreno] WebProcess crash on DB410c
zan at falconsigh.net
zan at falconsigh.net
Thu Feb 9 15:33:38 UTC 2017
Hi,
I'm not sure exactly what mechanism you're using to implement the WPE
interfaces, so I'll just list a few options.
Focusing on wpe_renderer_backend_egl_offscreen_target_interface that's
used as the basis for the sharing context and WebGL contexts, the
simplest implementation would just return NULL in get_native_window().
That effectively enforces creation of a pbuffer-based context, but that
isn't available on some platforms.
A workaround for this is using dummy surfaces, if possible. Here's
implementations for WPE backend implementations that are based on libgbm
and wayland-egl:
https://github.com/WebKitForWayland/wpe-mesa/blob/master/src/gbm/renderer-backend-egl-gbm.cpp#L237
https://github.com/WebKitForWayland/wpe-mesa/blob/master/src/nc/renderer-backend-egl.cpp#L269
Those were developed and tested on top of the Mesa library, but weren't
tested with the Freedreno driver, at least not to my knowledge.
Hope that helps,
Zan
On Mon, Feb 6, 2017, at 07:32 AM, Sivasubramanian Patchaiperumal wrote:
> Tried writing a simple EGL pbuffer application and tested it on
> DB410c. As expected, eglChooseConfig returned no matched config
> available. Is there something we can do to get pbuffer support
> on Mesa?
>
> On 3 February 2017 at 20:33, Rob Clark <robdclark at gmail.com> wrote:
>> Hmm, could be that westeros is doing something wrong that causes the
>> pbuffer path to be hit. I'm not entirely sure why pbuffer is not
>> supported in wayland (other than just that these days there are
>> better
>> ways to do things than pbuffer), although I thought I remembered
>> seeing a fallback to surfaceless in webkit..
>>
>> BR,
>> -R
>>
>> On Fri, Feb 3, 2017 at 1:05 AM, Sivasubramanian Patchaiperumal
>>
>> <sivasubramanian.patchaiperumal at linaro.org> wrote:
>> > One more point is westeros always return null window for offscreen
>> > target,
>> > that why WPE falls back to pbuffer on HiKey and DB410c cases.
>> >
>> > On 3 February 2017 at 11:30, Sivasubramanian Patchaiperumal
>> > <sivasubramanian.patchaiperumal at linaro.org> wrote:
>> >>
>> >> Thanks Rob for your inputs. Yes, you are looking at the right
>> >> place. But
>> >> the HiKey which takes same pbuffer path and it working with Mali
>> >> is the
>> >> reference now. I'm trying to write a simple egl app that uses
>> >> pbuffer to
>> >> confirm the support with Mesa. Does it sounds correct or you have
>> >> any
>> >> suggestions?
>> >>
>> >> On 3 February 2017 at 02:06, Rob Clark <robdclark at gmail.com>
>> >> wrote:
>> >>>
>> >>> btw, where exactly is it crashing? I grabbed the
>> >>> WebKitForWayland
>> >>> tree.. if I'm looking at the right thing, the only place where
>> >>> it
>> >>> should try to create a pbuffer is in
>> >>> Source/WebCore/platform/graphics/egl/GLContextEGL.cpp and that
>> >>> looks
>> >>> like it should only be a fallback after createWaylandContext()
>> >>> fails??
>> >>>
>> >>> I suspect pbuffer is not the root problem, that looks like a
>> >>> fallback
>> >>> path that shouldn't be hit..
>> >>>
>> >>> BR,
>> >>> -R
>> >>>
>> >>> On Thu, Feb 2, 2017 at 9:55 AM, Rob Clark <robdclark at gmail.com>
>> >>> wrote:
>> >>> > hmm, just looking at dri2_wl_display_vtbl:
>> >>> >
>> >>> > .create_pbuffer_surface =
>> >>> > dri2_fallback_create_pbuffer_surface,
>> >>> >
>> >>> > which just returns null.. so I guess pbuffers are not
>> >>> > supported under
>> >>> > wayland.
>> >>> >
>> >>> > Bit of google search reveals:
>> >>> >
>> >>> >
>> >>> > https://lists.freedesktop.org/archives/wayland-devel/2012-April/002928.html
>> >>> >
>> >>> > so I think the answer is don't use pbuffers.
>> >>> >
>> >>> > BR,
>> >>> > -R
>> >>> >
>> >>> > On Thu, Feb 2, 2017 at 9:50 AM, Rob Clark
>> >>> > <robdclark at gmail.com> wrote:
>> >>> >> hmm, tons of older stuff uses pbuffers w/ x11.. although a
>> >>> >> quick look
>> >>> >> at mesa/demos.git and it doesn't look like any of them that
>> >>> >> build for
>> >>> >> wayland do. I don't think pbuffers are used much anymore.
>> >>> >> But I
>> >>> >> would expect there should be some piglit tests which do.
>> >>> >>
>> >>> >> (Plus, firefox and chromium have been ported to wayland.. and
>> >>> >> quite a
>> >>> >> lot of other sw. And a lot of us are using wayland on our
>> >>> >> laptops/desktops these days.)
>> >>> >>
>> >>> >> BR,
>> >>> >> -R
>> >>> >>
>> >>> >> On Thu, Feb 2, 2017 at 9:39 AM, Sivasubramanian
>> >>> >> Patchaiperumal
>> >>> >> <sivasubramanian.patchaiperumal at linaro.org> wrote:
>> >>> >>> Yes, WebProcess(in WebKit) is crashing on DB410c. Any client
>> >>> >>> that
>> >>> >>> uses
>> >>> >>> pbuffer surfaces will crash I suspect. Is there is any
>> >>> >>> simple egl
>> >>> >>> application that uses pixel buffer to verify and confirm?
>> >>> >>>
>> >>> >>> On 2 February 2017 at 19:00, Rob Clark <robdclark at gmail.com>
>> >>> >>> wrote:
>> >>> >>>>
>> >>> >>>> hmm, ok, so it is a *client* process that is crashing? The
>> >>> >>>> wayland
>> >>> >>>> winsys (used by client processes, as opposed to gbm/drm
>> >>> >>>> winsys used
>> >>> >>>> by
>> >>> >>>> compositor) does support pbuffers.
>> >>> >>>>
>> >>> >>>> BR,
>> >>> >>>> -R
>> >>> >>>>
>> >>> >>>> On Thu, Feb 2, 2017 at 7:43 AM, Sivasubramanian
>> >>> >>>> Patchaiperumal
>> >>> >>>> <sivasubramanian.patchaiperumal at linaro.org> wrote:
>> >>> >>>> > Westeros code uses EGL window surface only, but the WPE
>> >>> >>>> > code (at
>> >>> >>>> > https://github.com/Metrological/WebKitForWayland/) which
>> >>> >>>> > uses
>> >>> >>>> > pbuffer
>> >>> >>>> > works
>> >>> >>>> > on HiKey and RPI as mentioned.
>> >>> >>>> >
>> >>> >>>> > On 2 February 2017 at 17:38, Rob Clark
>> >>> >>>> > <robdclark at gmail.com>
>> >>> >>>> > wrote:
>> >>> >>>> >>
>> >>> >>>> >> On Thu, Feb 2, 2017 at 2:13 AM, Sivasubramanian
>> >>> >>>> >> Patchaiperumal
>> >>> >>>> >> <sivasubramanian.patchaiperumal at linaro.org> wrote:
>> >>> >>>> >> > Hi,
>> >>> >>>> >> > I'm trying to port WPE on DB410c with Westeros
>> >>> >>>> >> > compositor, but
>> >>> >>>> >> > the
>> >>> >>>> >> > webprocess crashes due to null sharingcontext.
>> >>> >>>> >> > Webprocess fails
>> >>> >>>> >> > to
>> >>> >>>> >> > create gl
>> >>> >>>> >> > context as eglChooseConfig fails when the surface type
>> >>> >>>> >> > attribute is
>> >>> >>>> >> > pbuffer.
>> >>> >>>> >> > Also, Westeros sample app works fine and the issue is
>> >>> >>>> >> > only when
>> >>> >>>> >> > surface
>> >>> >>>> >> > type
>> >>> >>>> >> > attribute is pbuffer. But the same issue is not
>> >>> >>>> >> > observed on
>> >>> >>>> >> > similar
>> >>> >>>> >> > scenerios, HiKey and RPI with westeros. Is there
>> >>> >>>> >> > something to
>> >>> >>>> >> > do with
>> >>> >>>> >> > db410c
>> >>> >>>> >> > for eglChooseConfig failure when surface type is
>> >>> >>>> >> > pbuffer?
>> >>> >>>> >>
>> >>> >>>> >> Can you point me at the code? Not 100% sure but
>> >>> >>>> >> possibly gbm/drm
>> >>> >>>> >> egl
>> >>> >>>> >> implementation does not support pbuffer surfaces. I
>> >>> >>>> >> don't see
>> >>> >>>> >> weston
>> >>> >>>> >> using pbuffer's, for example.
>> >>> >>>> >>
>> >>> >>>> >> Has this code ever worked with anything other than
>> >>> >>>> >> closed src
>> >>> >>>> >> gles
>> >>> >>>> >> drivers? (Like the vc4 driver on r-pi or on x86?)
>> >>> >>>> >>
>> >>> >>>> >> BR,
>> >>> >>>> >> -R
>> >>> >>>> >
>> >>> >>>> >
>> >>> >>>> >
>> >>> >>>> >
>> >>> >>>> > --
>> >>> >>>> > Regards,
>> >>> >>>> > Sivasubramanian
>> >>> >>>
>> >>> >>>
>> >>> >>>
>> >>> >>>
>> >>> >>> --
>> >>> >>> Regards,
>> >>> >>> Sivasubramanian
>> >>
>> >>
>> >>
>> >>
>> >> --
>> >> Regards,
>> >> Sivasubramanian
>> >
>> >
>> >
>> >
>> > --
>> > Regards,
>> > Sivasubramanian
>
>
>
> --
> Regards,
> Sivasubramanian
> _________________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170209/43de761a/attachment-0001.html>
More information about the mesa-dev
mailing list