[Mesa-dev] [Freedreno] WebProcess crash on DB410c

[Rob Clark]

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