Re: [Mesa-dev] [PATCH] llvmpipe: Always return some fence in flush (v2)

[Tomasz Figa]

Hi Roland,

On Thu, Jan 10, 2019 at 1:36 AM Roland Scheidegger  wrote:
>
> Sorry but I had to revert this, as we've seen lots of assertion failures
> (src/gallium/drivers/llvmpipe/lp_fence.c:120: lp_fence_wait: Assertion
> `f->issued' failed.). For instance with libgl_xlib state tracker and piglit.
> I'm not entirely sure if it's really safe to just remove the assert or

Understood. Sorry for not spotting this in my testing. Would you be
able to help with more details on how to reproduce these failures?

> if it needs some more work, and I don't have time right now for a
> thorough investigation, but I'll happily take new patches...

Perhaps we could make these dummy fences "issued". I'll check how this
works in the code.

Best regards,
Tomasz

>
> Roland
>
>
> Am 09.01.19 um 02:09 schrieb Roland Scheidegger:
> > Am 07.01.19 um 09:54 schrieb Tomasz Figa:
> >> On Sun, Dec 23, 2018 at 12:55 AM Roland Scheidegger  
> >> wrote:
> >>>
> >>> Alright, I guess it should work...
> >>>
> >>> Reviewed-by: Roland Scheidegger 
> >>>
> >>
> >> Thanks!
> >>
> >> Would we have anyone who could help to commit it?
> >
> > Pushed (albeit I forgot the R-b on it, ah well...)
> >
> > Roland
> >
> >>
> >> (I know that I was supposed to apply for commit rights, but I expect
> >> my contribution rate to be relatively low, due to a shift to different
> >> areas, so I don't think I'm a good candidate for a committer anymore.)
> >>
> >> Best regards,
> >> Tomasz
> >>
> >>>
> >>> Am 14.12.18 um 09:17 schrieb Tomasz Figa:
> >>>> If there is no last fence, due to no rendering happening yet, just
> >>>> create a new signaled fence and return it, to match the expectations of
> >>>> the EGL sync fence API.
> >>>>
> >>>> Fixes random "Could not create sync fence 0x3003" assertion failures from
> >>>> Skia on Android, coming from the following code:
> >>>>
> >>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fandroid.googlesource.com%2Fplatform%2Fframeworks%2Fbase%2F%2B%2Fmaster%2Flibs%2Fhwui%2Fpipeline%2Fskia%2FSkiaOpenGLPipeline.cpp%23427data=02%7C01%7Csroland%40vmware.com%7Ccb06f4e1c9164a7871cb08d675cf20c7%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636825929820495738sdata=6hmZk%2BXWaQk%2B5XAKjxFSybOSpCVwzvKemYgZQ1rtpvg%3Dreserved=0
> >>>>
> >>>> Reproducible especially with thread count >= 4.
> >>>>
> >>>> One could make the driver always keep the reference to the last fence,
> >>>> but:
> >>>>
> >>>>  - the driver seems to explicitly destroy the fence whenever a rendering
> >>>>pass completes and changing that would require a significant 
> >>>> functional
> >>>>change to the code. (Specifically, in lp_scene_end_rasterization().)
> >>>>
> >>>>  - it still wouldn't solve the problem of an EGL sync fence being created
> >>>>and waited on without any rendering happening at all, which is
> >>>>also likely to happen with Android code pointed to in the commit.
> >>>>
> >>>> Therefore, the simple approach of always creating a fence is taken,
> >>>> similarly to other drivers, such as radeonsi.
> >>>>
> >>>> Tested with piglit llvmpipe suite with no regressions and following
> >>>> tests fixed:
> >>>>
> >>>> egl_khr_fence_sync
> >>>>  conformance
> >>>>   eglclientwaitsynckhr_flag_sync_flush
> >>>>   eglclientwaitsynckhr_nonzero_timeout
> >>>>   eglclientwaitsynckhr_zero_timeout
> >>>>   eglcreatesynckhr_default_attributes
> >>>>   eglgetsyncattribkhr_invalid_attrib
> >>>>   eglgetsyncattribkhr_sync_status
> >>>>
> >>>> v2:
> >>>>  - remove the useless lp_fence_reference() dance (Nicolai),
> >>>>  - explain why creating the dummy fence is the right approach.
> >>>>
> >>>> Signed-off-by: Tomasz Figa 
> >>>> ---
> >>>>  src/gallium/drivers/llvmpipe/lp_setup.c | 2 ++
> >>>>  1 file changed, 2 insertions(+)
> >>>>
> >>>> diff --git a/src/gallium/drivers/llvmpipe/lp_setup.c 
> >>>> b/src/gallium/drivers/llvmpipe/lp_setup.c
> >>>> index b087369473..e72e119c8a 100644
> >>>> --- a/src/gallium/drivers/llvmpipe/lp_setup.c
> >>>> +++ b/src/gallium/drivers/llvmpipe/lp_setup.c
> >>>> @@ -361,6 +361,8 @@ lp_setup_flush( struct lp_setup_context *setup,
> >>>>
> >>>> if (fence) {
> >>>>lp_fence_reference((struct lp_fence **)fence, setup->last_fence);
> >>>> +  if (!*fence)
> >>>> + *fence = (struct pipe_fence_handle *)lp_fence_create(0);
> >>>> }
> >>>>  }
> >>>>
> >>>>
> >>>
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fmesa-devdata=02%7C01%7Csroland%40vmware.com%7Ccb06f4e1c9164a7871cb08d675cf20c7%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636825929820495738sdata=FeFqwQi9AUVDWaUw7lLMtAci6wWjE44vqwwjVwysY3o%3Dreserved=0
> >
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] llvmpipe: Always return some fence in flush (v2)

[Tomasz Figa]

On Sun, Dec 23, 2018 at 12:55 AM Roland Scheidegger  wrote:
>
> Alright, I guess it should work...
>
> Reviewed-by: Roland Scheidegger 
>

Thanks!

Would we have anyone who could help to commit it?

(I know that I was supposed to apply for commit rights, but I expect
my contribution rate to be relatively low, due to a shift to different
areas, so I don't think I'm a good candidate for a committer anymore.)

Best regards,
Tomasz

>
> Am 14.12.18 um 09:17 schrieb Tomasz Figa:
> > If there is no last fence, due to no rendering happening yet, just
> > create a new signaled fence and return it, to match the expectations of
> > the EGL sync fence API.
> >
> > Fixes random "Could not create sync fence 0x3003" assertion failures from
> > Skia on Android, coming from the following code:
> >
> > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fandroid.googlesource.com%2Fplatform%2Fframeworks%2Fbase%2F%2B%2Fmaster%2Flibs%2Fhwui%2Fpipeline%2Fskia%2FSkiaOpenGLPipeline.cpp%23427data=02%7C01%7Csroland%40vmware.com%7Cbbfaf154367d449a153608d6619ca298%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636803722709844114sdata=Jau0msKOhAhDMMklBWCtuse40%2FMxpLR50vqjtiyVBYw%3Dreserved=0
> >
> > Reproducible especially with thread count >= 4.
> >
> > One could make the driver always keep the reference to the last fence,
> > but:
> >
> >  - the driver seems to explicitly destroy the fence whenever a rendering
> >pass completes and changing that would require a significant functional
> >change to the code. (Specifically, in lp_scene_end_rasterization().)
> >
> >  - it still wouldn't solve the problem of an EGL sync fence being created
> >and waited on without any rendering happening at all, which is
> >also likely to happen with Android code pointed to in the commit.
> >
> > Therefore, the simple approach of always creating a fence is taken,
> > similarly to other drivers, such as radeonsi.
> >
> > Tested with piglit llvmpipe suite with no regressions and following
> > tests fixed:
> >
> > egl_khr_fence_sync
> >  conformance
> >   eglclientwaitsynckhr_flag_sync_flush
> >   eglclientwaitsynckhr_nonzero_timeout
> >   eglclientwaitsynckhr_zero_timeout
> >   eglcreatesynckhr_default_attributes
> >   eglgetsyncattribkhr_invalid_attrib
> >   eglgetsyncattribkhr_sync_status
> >
> > v2:
> >  - remove the useless lp_fence_reference() dance (Nicolai),
> >  - explain why creating the dummy fence is the right approach.
> >
> > Signed-off-by: Tomasz Figa 
> > ---
> >  src/gallium/drivers/llvmpipe/lp_setup.c | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/src/gallium/drivers/llvmpipe/lp_setup.c 
> > b/src/gallium/drivers/llvmpipe/lp_setup.c
> > index b087369473..e72e119c8a 100644
> > --- a/src/gallium/drivers/llvmpipe/lp_setup.c
> > +++ b/src/gallium/drivers/llvmpipe/lp_setup.c
> > @@ -361,6 +361,8 @@ lp_setup_flush( struct lp_setup_context *setup,
> >
> > if (fence) {
> >lp_fence_reference((struct lp_fence **)fence, setup->last_fence);
> > +  if (!*fence)
> > + *fence = (struct pipe_fence_handle *)lp_fence_create(0);
> > }
> >  }
> >
> >
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] llvmpipe: Always return some fence in flush (v2)

[Tomasz Figa]

Hi everyone,

On Fri, Dec 14, 2018 at 5:17 PM Tomasz Figa  wrote:
>
> If there is no last fence, due to no rendering happening yet, just
> create a new signaled fence and return it, to match the expectations of
> the EGL sync fence API.
>
> Fixes random "Could not create sync fence 0x3003" assertion failures from
> Skia on Android, coming from the following code:
>
> https://android.googlesource.com/platform/frameworks/base/+/master/libs/hwui/pipeline/skia/SkiaOpenGLPipeline.cpp#427
>
> Reproducible especially with thread count >= 4.
>
> One could make the driver always keep the reference to the last fence,
> but:
>
>  - the driver seems to explicitly destroy the fence whenever a rendering
>pass completes and changing that would require a significant functional
>change to the code. (Specifically, in lp_scene_end_rasterization().)
>
>  - it still wouldn't solve the problem of an EGL sync fence being created
>and waited on without any rendering happening at all, which is
>also likely to happen with Android code pointed to in the commit.
>
> Therefore, the simple approach of always creating a fence is taken,
> similarly to other drivers, such as radeonsi.
>
> Tested with piglit llvmpipe suite with no regressions and following
> tests fixed:
>
> egl_khr_fence_sync
>  conformance
>   eglclientwaitsynckhr_flag_sync_flush
>   eglclientwaitsynckhr_nonzero_timeout
>   eglclientwaitsynckhr_zero_timeout
>   eglcreatesynckhr_default_attributes
>   eglgetsyncattribkhr_invalid_attrib
>   eglgetsyncattribkhr_sync_status
>
> v2:
>  - remove the useless lp_fence_reference() dance (Nicolai),
>  - explain why creating the dummy fence is the right approach.
>
> Signed-off-by: Tomasz Figa 
> ---
>  src/gallium/drivers/llvmpipe/lp_setup.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/src/gallium/drivers/llvmpipe/lp_setup.c 
> b/src/gallium/drivers/llvmpipe/lp_setup.c
> index b087369473..e72e119c8a 100644
> --- a/src/gallium/drivers/llvmpipe/lp_setup.c
> +++ b/src/gallium/drivers/llvmpipe/lp_setup.c
> @@ -361,6 +361,8 @@ lp_setup_flush( struct lp_setup_context *setup,
>
> if (fence) {
>lp_fence_reference((struct lp_fence **)fence, setup->last_fence);
> +  if (!*fence)
> + *fence = (struct pipe_fence_handle *)lp_fence_create(0);
> }
>  }
>
> --
> 2.20.0.405.gbc1bbc6f85-goog
>

Gentle ping. :)

Best regards,
Tomasz
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] llvmpipe: Always return some fence in flush (v2)

[Tomasz Figa]

If there is no last fence, due to no rendering happening yet, just
create a new signaled fence and return it, to match the expectations of
the EGL sync fence API.

Fixes random "Could not create sync fence 0x3003" assertion failures from
Skia on Android, coming from the following code:

https://android.googlesource.com/platform/frameworks/base/+/master/libs/hwui/pipeline/skia/SkiaOpenGLPipeline.cpp#427

Reproducible especially with thread count >= 4.

One could make the driver always keep the reference to the last fence,
but:

 - the driver seems to explicitly destroy the fence whenever a rendering
   pass completes and changing that would require a significant functional
   change to the code. (Specifically, in lp_scene_end_rasterization().)

 - it still wouldn't solve the problem of an EGL sync fence being created
   and waited on without any rendering happening at all, which is
   also likely to happen with Android code pointed to in the commit.

Therefore, the simple approach of always creating a fence is taken,
similarly to other drivers, such as radeonsi.

Tested with piglit llvmpipe suite with no regressions and following
tests fixed:

egl_khr_fence_sync
 conformance
  eglclientwaitsynckhr_flag_sync_flush
  eglclientwaitsynckhr_nonzero_timeout
  eglclientwaitsynckhr_zero_timeout
  eglcreatesynckhr_default_attributes
  eglgetsyncattribkhr_invalid_attrib
  eglgetsyncattribkhr_sync_status

v2:
 - remove the useless lp_fence_reference() dance (Nicolai),
 - explain why creating the dummy fence is the right approach.

Signed-off-by: Tomasz Figa 
---
 src/gallium/drivers/llvmpipe/lp_setup.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/gallium/drivers/llvmpipe/lp_setup.c 
b/src/gallium/drivers/llvmpipe/lp_setup.c
index b087369473..e72e119c8a 100644
--- a/src/gallium/drivers/llvmpipe/lp_setup.c
+++ b/src/gallium/drivers/llvmpipe/lp_setup.c
@@ -361,6 +361,8 @@ lp_setup_flush( struct lp_setup_context *setup,
 
if (fence) {
   lp_fence_reference((struct lp_fence **)fence, setup->last_fence);
+  if (!*fence)
+ *fence = (struct pipe_fence_handle *)lp_fence_create(0);
}
 }
 
-- 
2.20.0.405.gbc1bbc6f85-goog

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] llvmpipe: Always return some fence in flush

[Tomasz Figa]

Hi Nicolai,

On Thu, Nov 22, 2018 at 6:19 PM Haehnle, Nicolai
 wrote:
>
> On 22.11.18 06:40, Tomasz Figa wrote:
> > Hi Brian, Keith,
> >
> > +Some more Chromium folks for visibility.
> >
> > On Wed, Aug 22, 2018 at 4:21 PM Tomasz Figa  wrote:
> >>
> >> Hi Michel,
> >>
> >> On Thu, Aug 16, 2018 at 6:43 PM Michel Dänzer  wrote:
> >>>
> >>> On 2018-08-16 11:34 AM, Tomasz Figa wrote:
> >>>> If there is no last fence, due to no rendering happening yet, just
> >>>> create a new signaled fence and return it, to match the expectations of
> >>>> the EGL sync fence API.
> >>>>
> >>>> Fixes random "Could not create sync fence 0x3003" assertion failures from
> >>>> Skia on Android, coming from the following code:
> >>>>
> >>>> https://android.googlesource.com/platform/frameworks/base/+/master/libs/hwui/pipeline/skia/SkiaOpenGLPipeline.cpp#427
> >>>>
> >>>> Reproducible especially with thread count >= 4.
> >>>>
> >>>> Signed-off-by: Tomasz Figa 
> >>>> ---
> >>>>   src/gallium/drivers/llvmpipe/lp_setup.c | 8 +++-
> >>>>   1 file changed, 7 insertions(+), 1 deletion(-)
> >>>>
> >>>> diff --git a/src/gallium/drivers/llvmpipe/lp_setup.c 
> >>>> b/src/gallium/drivers/llvmpipe/lp_setup.c
> >>>> index b087369473..a6f1b54d69 100644
> >>>> --- a/src/gallium/drivers/llvmpipe/lp_setup.c
> >>>> +++ b/src/gallium/drivers/llvmpipe/lp_setup.c
> >>>> @@ -360,7 +360,13 @@ lp_setup_flush( struct lp_setup_context *setup,
> >>>>  set_scene_state( setup, SETUP_FLUSHED, reason );
> >>>>
> >>>>  if (fence) {
> >>>> -  lp_fence_reference((struct lp_fence **)fence, setup->last_fence);
> >>>> +  struct lp_fence *lp_fence = NULL;
> >>>> +
> >>>> +  lp_fence_reference(_fence, setup->last_fence);
> >>>> +  if (!lp_fence)
> >>>> + lp_fence = lp_fence_create(0);
> >>>> +  lp_fence_reference((struct lp_fence **)fence, lp_fence);
> >>>> +  lp_fence_reference(_fence, NULL);
> >>>>  }
> >>>>   }
> >>>>
> >>>>
> >>>
> >>> Other drivers keep around a reference to the last fence in the context,
> >>> and return that if there's no new work to flush.
> >>
> >> Thanks for taking a look.
> >>
> >> Right, it sounds like a sane thing to do. LLVMpipe, however, seems to
> >> explicitly destroy the fence whenever a rendering pass completes and I
> >> didn't want to change that without understanding the intentions behind
> >> that. Precisely, it's lp_scene_end_rasterization():
> >> https://gitlab.freedesktop.org/mesa/mesa/blob/master/src/gallium/drivers/llvmpipe/lp_scene.c#L292
> >>
> >> Also, this still wouldn't solve the problem of an EGL sync fence being
> >> created and waited on without any rendering happening at all, which is
> >> also likely to happen with Android code pointed to in the commit
> >> message. Obviously that could be dealt with by creating a signaled
> >> fence in lp_setup_create(), though.
> >>
> >> Let me add Keith and Brian for more visibility.
> >
> > Any thoughts on this?
>
> Your analysis seems correct to me.
>
> Note that I wouldn't worry too much about creating a new fence object.
> radeonsi creates a new Gallium pipe fence object on every call to
> pipe->flush, regardless of the state of the system. This is because
> internally, radeonsi's Gallium pipe fences are a union of an SDMA and a
> GFX fence.
>
> So creating a new fence, as your patch does, should be perfectly fine if
> you know that all previous work has finished.
>
> I do think your patch is needlessly convoluted though. Why not just
>
> lp_fence_reference((struct lp_fence **)fence, setup->last_fence);
> +  if (!*fence)
> + *fence = (struct pipe_fence_handle *)lp_fence_create(0);

Indeed, there is no need for this reference dance, not sure what I had
in mind when writing that. Let me respin a simplified version. Thanks
for feedback!

Best regards,
Tomasz
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] llvmpipe: Always return some fence in flush

[Tomasz Figa]

Hi Brian, Keith,

+Some more Chromium folks for visibility.

On Wed, Aug 22, 2018 at 4:21 PM Tomasz Figa  wrote:
>
> Hi Michel,
>
> On Thu, Aug 16, 2018 at 6:43 PM Michel Dänzer  wrote:
> >
> > On 2018-08-16 11:34 AM, Tomasz Figa wrote:
> > > If there is no last fence, due to no rendering happening yet, just
> > > create a new signaled fence and return it, to match the expectations of
> > > the EGL sync fence API.
> > >
> > > Fixes random "Could not create sync fence 0x3003" assertion failures from
> > > Skia on Android, coming from the following code:
> > >
> > > https://android.googlesource.com/platform/frameworks/base/+/master/libs/hwui/pipeline/skia/SkiaOpenGLPipeline.cpp#427
> > >
> > > Reproducible especially with thread count >= 4.
> > >
> > > Signed-off-by: Tomasz Figa 
> > > ---
> > >  src/gallium/drivers/llvmpipe/lp_setup.c | 8 +++-
> > >  1 file changed, 7 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/src/gallium/drivers/llvmpipe/lp_setup.c 
> > > b/src/gallium/drivers/llvmpipe/lp_setup.c
> > > index b087369473..a6f1b54d69 100644
> > > --- a/src/gallium/drivers/llvmpipe/lp_setup.c
> > > +++ b/src/gallium/drivers/llvmpipe/lp_setup.c
> > > @@ -360,7 +360,13 @@ lp_setup_flush( struct lp_setup_context *setup,
> > > set_scene_state( setup, SETUP_FLUSHED, reason );
> > >
> > > if (fence) {
> > > -  lp_fence_reference((struct lp_fence **)fence, setup->last_fence);
> > > +  struct lp_fence *lp_fence = NULL;
> > > +
> > > +  lp_fence_reference(_fence, setup->last_fence);
> > > +  if (!lp_fence)
> > > + lp_fence = lp_fence_create(0);
> > > +  lp_fence_reference((struct lp_fence **)fence, lp_fence);
> > > +  lp_fence_reference(_fence, NULL);
> > > }
> > >  }
> > >
> > >
> >
> > Other drivers keep around a reference to the last fence in the context,
> > and return that if there's no new work to flush.
>
> Thanks for taking a look.
>
> Right, it sounds like a sane thing to do. LLVMpipe, however, seems to
> explicitly destroy the fence whenever a rendering pass completes and I
> didn't want to change that without understanding the intentions behind
> that. Precisely, it's lp_scene_end_rasterization():
> https://gitlab.freedesktop.org/mesa/mesa/blob/master/src/gallium/drivers/llvmpipe/lp_scene.c#L292
>
> Also, this still wouldn't solve the problem of an EGL sync fence being
> created and waited on without any rendering happening at all, which is
> also likely to happen with Android code pointed to in the commit
> message. Obviously that could be dealt with by creating a signaled
> fence in lp_setup_create(), though.
>
> Let me add Keith and Brian for more visibility.

Any thoughts on this?

Best regards,
Tomasz
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2] egl/android: rework device probing

[Tomasz Figa]

On Mon, Sep 3, 2018 at 3:25 PM Tomasz Figa  wrote:
>
> On Mon, Sep 3, 2018 at 2:45 PM Tomasz Figa  wrote:
> >
> > Hi Emil,
> >
> > On Sat, Sep 1, 2018 at 2:03 AM Emil Velikov  
> > wrote:
> > >
> > > From: Emil Velikov 
> > >
> >
> > Thanks for the patch! Please see my comments below.
> >
> > [snip]
> > > @@ -1214,10 +1215,13 @@ droid_open_device_drm_gralloc(struct 
> > > dri2_egl_display *dri2_dpy)
> > >);
> > > if (err || fd < 0) {
> > >_eglLog(_EGL_WARNING, "fail to get drm fd");
> > > -  fd = -1;
> > > +  return EGL_FALSE;
> > > }
> > >
> > > -   return (fd >= 0) ? fcntl(fd, F_DUPFD_CLOEXEC, 3) : -1;
> > > +   if (dri2_dpy->fd = fcntl(fd, F_DUPFD_CLOEXEC, 3) < 0)
> >
> > This will assign the boolean result of the comparison to dri2_dpy->fd.
> > To avoid parenthesis hell, I'd rewrite this to:
> >
> > dri2_dpy->fd = fcntl(fd, F_DUPFD_CLOEXEC, 3);
> > if (dri2_dpy->fd < 0)
> >return EGL_FALSE;
> >
> > > + return EGL_FALSE;
> > > +
> > > +   return droid_probe_device(disp);
> > >  }
> > >  #endif /* HAVE_DRM_GRALLOC */
> > >
> > > @@ -1365,7 +1369,7 @@ static const __DRIextension 
> > > *droid_image_loader_extensions[] = {
> > >  EGLBoolean
> > >  droid_load_driver(_EGLDisplay *disp)
> >
> > Not related to this patch, but I guess we could fix it up, while at
> > it. Fails to build with:
> >
> > src/egl/drivers/dri2/platform_android
> > .c:1369:1: error: no previous prototype for function
> > 'droid_load_driver' [-Werror,-Wmissing-prototypes]
> > droid_load_driver(_EGLDisplay *disp)
> > ^
> >
> > The function should be static.
> >
> > >  {
> > > -   struct dri2_egl_display *dri2_dpy = disp->DriverData;
> > > +   struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
> > > const char *err;
> > >
> > > dri2_dpy->driver_name = loader_get_driver_for_fd(dri2_dpy->fd);
> > > @@ -1404,6 +1408,17 @@ error:
> > > return false;
> > >  }
> > [snip]
> > > +static EGLBoolean
> > >  droid_open_device(_EGLDisplay *disp)
> > >  {
> > >  #define MAX_DRM_DEVICES 32
> > > +   struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
> > > drmDevicePtr device, devices[MAX_DRM_DEVICES] = { NULL };
> > > int prop_set, num_devices;
> >
> > Not related to this patch, but prop_set is unused. We could add a
> > fixup in this patch, while reworking this already.
> >
> > I'm going to test it on Chrome OS with the fixups above applied.
>
> The probing itself seems to be working fine, but it looks like there
> is some EGL image regression in master, which I don't have time to
> investigate.

Never mind, it looks like I had libdrm in some weird state. After a
complete clean build, it worked fine.

Best regards,
Tomasz
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v3] egl/android: rework device probing

[Tomasz Figa]

On Mon, Sep 3, 2018 at 9:42 PM Emil Velikov  wrote:
>
> From: Emil Velikov 
>
> Unlike the other platforms, here we aim do guess if the device that we
> somewhat arbitrarily picked, is supported or not.
>
> In particular: when a vendor is _not_ requested we loop through all
> devices, picking the first one which can create a DRI screen.
>
> When a vendor is requested - we use that and do _not_ fall-back to any
> other device.
>
> The former seems a bit fiddly, but considering EGL_EXT_explicit_device and
> EGL_MESA_query_renderer are MIA, this is the best we can do for the
> moment.
>
> With those (proposed) extensions userspace will be able to create a
> separate EGL display for each device, query device details and make the
> conscious decision which one to use.
>
> v2:
>  - update droid_open_device_drm_gralloc()
>  - set the dri2_dpy->fd before using it
>  - return a EGLBoolean for droid_{probe,open}_device*
>  - do not warn on droid_load_driver failure (Tomasz)
>  - plug mem leak on dri2_create_screen failure (Tomasz)
>  - fixup function name typo (Tomasz, Rob)
>
> v3:
>  - add forward declaration for droid_load_driver()
> Fixes the HAVE_DRM_GRALLOC build (Mauro)
>  - split dup() assignment and check in separate lines (Tomasz, Eric)
>  - make droid_load_driver() static (Tomasz)
>  - drop unused prop_set variable (Tomasz)

Thanks a lot!

Reviewed-by: Tomasz Figa 

Best regards,
Tomasz
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2] egl/android: rework device probing

[Tomasz Figa]

On Mon, Sep 3, 2018 at 2:45 PM Tomasz Figa  wrote:
>
> Hi Emil,
>
> On Sat, Sep 1, 2018 at 2:03 AM Emil Velikov  wrote:
> >
> > From: Emil Velikov 
> >
>
> Thanks for the patch! Please see my comments below.
>
> [snip]
> > @@ -1214,10 +1215,13 @@ droid_open_device_drm_gralloc(struct 
> > dri2_egl_display *dri2_dpy)
> >);
> > if (err || fd < 0) {
> >_eglLog(_EGL_WARNING, "fail to get drm fd");
> > -  fd = -1;
> > +  return EGL_FALSE;
> > }
> >
> > -   return (fd >= 0) ? fcntl(fd, F_DUPFD_CLOEXEC, 3) : -1;
> > +   if (dri2_dpy->fd = fcntl(fd, F_DUPFD_CLOEXEC, 3) < 0)
>
> This will assign the boolean result of the comparison to dri2_dpy->fd.
> To avoid parenthesis hell, I'd rewrite this to:
>
> dri2_dpy->fd = fcntl(fd, F_DUPFD_CLOEXEC, 3);
> if (dri2_dpy->fd < 0)
>return EGL_FALSE;
>
> > + return EGL_FALSE;
> > +
> > +   return droid_probe_device(disp);
> >  }
> >  #endif /* HAVE_DRM_GRALLOC */
> >
> > @@ -1365,7 +1369,7 @@ static const __DRIextension 
> > *droid_image_loader_extensions[] = {
> >  EGLBoolean
> >  droid_load_driver(_EGLDisplay *disp)
>
> Not related to this patch, but I guess we could fix it up, while at
> it. Fails to build with:
>
> src/egl/drivers/dri2/platform_android
> .c:1369:1: error: no previous prototype for function
> 'droid_load_driver' [-Werror,-Wmissing-prototypes]
> droid_load_driver(_EGLDisplay *disp)
> ^
>
> The function should be static.
>
> >  {
> > -   struct dri2_egl_display *dri2_dpy = disp->DriverData;
> > +   struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
> > const char *err;
> >
> > dri2_dpy->driver_name = loader_get_driver_for_fd(dri2_dpy->fd);
> > @@ -1404,6 +1408,17 @@ error:
> > return false;
> >  }
> [snip]
> > +static EGLBoolean
> >  droid_open_device(_EGLDisplay *disp)
> >  {
> >  #define MAX_DRM_DEVICES 32
> > +   struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
> > drmDevicePtr device, devices[MAX_DRM_DEVICES] = { NULL };
> > int prop_set, num_devices;
>
> Not related to this patch, but prop_set is unused. We could add a
> fixup in this patch, while reworking this already.
>
> I'm going to test it on Chrome OS with the fixups above applied.

The probing itself seems to be working fine, but it looks like there
is some EGL image regression in master, which I don't have time to
investigate.

Tested without the vendor property set, with both cases of the desired
device being probed in first or some later iteration. In both cases
the initialization succeeded and I could see the right GL renderer
string.

Tested-by: Tomasz Figa 

Best regards,
Tomasz
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH V2] Check if the window is non-NULL before setting swap interval.

[Tomasz Figa]

On Thu, Aug 30, 2018 at 11:23 PM Emil Velikov  wrote:
>
> On 30 August 2018 at 11:41, Eric Engestrom  wrote:
> > On Thursday, 2018-08-30 17:55:14 +0900, Tomasz Figa wrote:
> >> Hi Erik, Emil, Eric,
> >>
> >> On Tue, Jul 10, 2018 at 12:41 AM Erik Faye-Lund  
> >> wrote:
> >> >
> >> > On Thu, Jul 5, 2018 at 7:02 PM Emil Velikov  
> >> > wrote:
> >> > >
> >> > > On 5 July 2018 at 17:17, Eric Engestrom  
> >> > > wrote:
> >> > > > On Thursday, 2018-07-05 14:43:02 +0100, Emil Velikov wrote:
> >> > > >> On 5 July 2018 at 10:53, Eric Engestrom  
> >> > > >> wrote:
> >> > > >> > On Monday, 2018-07-02 14:12:44 +0530, samiuddi wrote:
> >> > > >> >> This fixes crash due to NULL window when swap interval is set
> >> > > >> >> for pbuffer surface.
> >> > > >> >>
> >> > > >> >> Test: CtsDisplayTestCases pass
> >> > > >> >>
> >> > > >> >> Signed-off-by: samiuddi 
> >> > > >> >> ---
> >> > > >> >>
> >> > > >> >> Kindly ignore this patch
> >> > > >> >> https://lists.freedesktop.org/archives/mesa-dev/2018-July/199098.html
> >> > > >> >>
> >> > > >> >>  src/egl/drivers/dri2/platform_android.c | 2 +-
> >> > > >> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >> > > >> >>
> >> > > >> >> diff --git a/src/egl/drivers/dri2/platform_android.c 
> >> > > >> >> b/src/egl/drivers/dri2/platform_android.c
> >> > > >> >> index ca8708a..b5b960a 100644
> >> > > >> >> --- a/src/egl/drivers/dri2/platform_android.c
> >> > > >> >> +++ b/src/egl/drivers/dri2/platform_android.c
> >> > > >> >> @@ -485,7 +485,7 @@ droid_swap_interval(_EGLDriver *drv, 
> >> > > >> >> _EGLDisplay *dpy,
> >> > > >> >> struct dri2_egl_surface *dri2_surf = dri2_egl_surface(surf);
> >> > > >> >> struct ANativeWindow *window = dri2_surf->window;
> >> > > >> >>
> >> > > >> >> -   if (window->setSwapInterval(window, interval))
> >> > > >> >> +   if (window && window->setSwapInterval(window, interval))
> >> > > >> >>return EGL_FALSE;
> >> > > >> >
> >> > > >> > Shouldn't we return false if we couldn't set the swap interval?
> >> > > >> >
> >> > > >> > I think this should be:
> >> > > >> >if (!window || window->setSwapInterval(window, interval))
> >> > > >> >   return EGL_FALSE;
> >> > > >> >
> >> > > >> Changing the patch as above will lead to eglSwapInterval 
> >> > > >> consistently
> >> > > >> failing for pbuffer surfaces.
> >> > > >
> >> > > > I'm not that familiar with pbuffers, but does SwapInterval really 
> >> > > > make
> >> > > > sense for them? I thought you couldn't swap a pbuffer.
> >> > > >
> >> > > > If so, failing an invalid op seems like the right thing to do.
> >> > > > Otherwise, I guess sure, no-op returning success is fine.
> >> > > >
> >> > > Looking at eglSwapInterval manpage [1] (with my annotation):
> >> > > "eglSwapInterval — specifies the minimum number of video frame periods
> >> > > per buffer swap for the _window_ associated with the current context."
> >> > > While the spec does not mention window/pbuffer/pixmap at all - it
> >> > > extensively refers to eglSwapBuffers.
> >> > >
> >> > > Wrt eglSwapBuffers manpage [2] and spec are consistent:
> >> > >
> >> > > "If surface is a pixel buffer or a pixmap, eglSwapBuffers has no
> >> > > effect, and no error is generated."
> >> > >
> >> > > Perhaps it's wrong to set eglSwapInterval for !window surfaces, but
> >> > > its sibling (eglSwapBuffers) does not error out.
> >> > > Hence I doubt many users make a distinction between window

Re: [Mesa-dev] [PATCH v2] egl/android: rework device probing

[Tomasz Figa]

Hi Emil,

On Sat, Sep 1, 2018 at 2:03 AM Emil Velikov  wrote:
>
> From: Emil Velikov 
>

Thanks for the patch! Please see my comments below.

[snip]
> @@ -1214,10 +1215,13 @@ droid_open_device_drm_gralloc(struct dri2_egl_display 
> *dri2_dpy)
>);
> if (err || fd < 0) {
>_eglLog(_EGL_WARNING, "fail to get drm fd");
> -  fd = -1;
> +  return EGL_FALSE;
> }
>
> -   return (fd >= 0) ? fcntl(fd, F_DUPFD_CLOEXEC, 3) : -1;
> +   if (dri2_dpy->fd = fcntl(fd, F_DUPFD_CLOEXEC, 3) < 0)

This will assign the boolean result of the comparison to dri2_dpy->fd.
To avoid parenthesis hell, I'd rewrite this to:

dri2_dpy->fd = fcntl(fd, F_DUPFD_CLOEXEC, 3);
if (dri2_dpy->fd < 0)
   return EGL_FALSE;

> + return EGL_FALSE;
> +
> +   return droid_probe_device(disp);
>  }
>  #endif /* HAVE_DRM_GRALLOC */
>
> @@ -1365,7 +1369,7 @@ static const __DRIextension 
> *droid_image_loader_extensions[] = {
>  EGLBoolean
>  droid_load_driver(_EGLDisplay *disp)

Not related to this patch, but I guess we could fix it up, while at
it. Fails to build with:

src/egl/drivers/dri2/platform_android
.c:1369:1: error: no previous prototype for function
'droid_load_driver' [-Werror,-Wmissing-prototypes]
droid_load_driver(_EGLDisplay *disp)
^

The function should be static.

>  {
> -   struct dri2_egl_display *dri2_dpy = disp->DriverData;
> +   struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
> const char *err;
>
> dri2_dpy->driver_name = loader_get_driver_for_fd(dri2_dpy->fd);
> @@ -1404,6 +1408,17 @@ error:
> return false;
>  }
[snip]
> +static EGLBoolean
>  droid_open_device(_EGLDisplay *disp)
>  {
>  #define MAX_DRM_DEVICES 32
> +   struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
> drmDevicePtr device, devices[MAX_DRM_DEVICES] = { NULL };
> int prop_set, num_devices;

Not related to this patch, but prop_set is unused. We could add a
fixup in this patch, while reworking this already.

I'm going to test it on Chrome OS with the fixups above applied.

Best regards,
Tomasz
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH V2] Check if the window is non-NULL before setting swap interval.

[Tomasz Figa]

Hi Erik, Emil, Eric,

On Tue, Jul 10, 2018 at 12:41 AM Erik Faye-Lund  wrote:
>
> On Thu, Jul 5, 2018 at 7:02 PM Emil Velikov  wrote:
> >
> > On 5 July 2018 at 17:17, Eric Engestrom  wrote:
> > > On Thursday, 2018-07-05 14:43:02 +0100, Emil Velikov wrote:
> > >> On 5 July 2018 at 10:53, Eric Engestrom  wrote:
> > >> > On Monday, 2018-07-02 14:12:44 +0530, samiuddi wrote:
> > >> >> This fixes crash due to NULL window when swap interval is set
> > >> >> for pbuffer surface.
> > >> >>
> > >> >> Test: CtsDisplayTestCases pass
> > >> >>
> > >> >> Signed-off-by: samiuddi 
> > >> >> ---
> > >> >>
> > >> >> Kindly ignore this patch
> > >> >> https://lists.freedesktop.org/archives/mesa-dev/2018-July/199098.html
> > >> >>
> > >> >>  src/egl/drivers/dri2/platform_android.c | 2 +-
> > >> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> > >> >>
> > >> >> diff --git a/src/egl/drivers/dri2/platform_android.c 
> > >> >> b/src/egl/drivers/dri2/platform_android.c
> > >> >> index ca8708a..b5b960a 100644
> > >> >> --- a/src/egl/drivers/dri2/platform_android.c
> > >> >> +++ b/src/egl/drivers/dri2/platform_android.c
> > >> >> @@ -485,7 +485,7 @@ droid_swap_interval(_EGLDriver *drv, _EGLDisplay 
> > >> >> *dpy,
> > >> >> struct dri2_egl_surface *dri2_surf = dri2_egl_surface(surf);
> > >> >> struct ANativeWindow *window = dri2_surf->window;
> > >> >>
> > >> >> -   if (window->setSwapInterval(window, interval))
> > >> >> +   if (window && window->setSwapInterval(window, interval))
> > >> >>return EGL_FALSE;
> > >> >
> > >> > Shouldn't we return false if we couldn't set the swap interval?
> > >> >
> > >> > I think this should be:
> > >> >if (!window || window->setSwapInterval(window, interval))
> > >> >   return EGL_FALSE;
> > >> >
> > >> Changing the patch as above will lead to eglSwapInterval consistently
> > >> failing for pbuffer surfaces.
> > >
> > > I'm not that familiar with pbuffers, but does SwapInterval really make
> > > sense for them? I thought you couldn't swap a pbuffer.
> > >
> > > If so, failing an invalid op seems like the right thing to do.
> > > Otherwise, I guess sure, no-op returning success is fine.
> > >
> > Looking at eglSwapInterval manpage [1] (with my annotation):
> > "eglSwapInterval — specifies the minimum number of video frame periods
> > per buffer swap for the _window_ associated with the current context."
> > While the spec does not mention window/pbuffer/pixmap at all - it
> > extensively refers to eglSwapBuffers.
> >
> > Wrt eglSwapBuffers manpage [2] and spec are consistent:
> >
> > "If surface is a pixel buffer or a pixmap, eglSwapBuffers has no
> > effect, and no error is generated."
> >
> > Perhaps it's wrong to set eglSwapInterval for !window surfaces, but
> > its sibling (eglSwapBuffers) does not error out.
> > Hence I doubt many users make a distinction between window and pbuffer
> > surfaces for eglSwap*.
> >
> > Worth bringing to the WG meeting - it' planned for 1st August.
> >
>
> As I pointed out when I proposed this variant here:
> https://patchwork.freedesktop.org/patch/219313/
>
> "Also, I don't think EGL_FALSE is the right return-value, as it doesn't
> seem the EGL 1.5 spec defines any such error. Also, for instance
> dri2_swap_interval returns EGL_TRUE when there's no driver-function,
> which further backs the "silent failure" in this case IMO."
>
> So I think EGL_TRUE is the correct return-value for now. If the spec
> gets changed, we can of course update our implementation.

What happens to this patch in the end? It looks like we're observing a
similar problem in Chrome OS.

Emil, was there any follow-up on the WG meeting?

Best regards,
Tomasz
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] egl/android: rework device probing

[Tomasz Figa]

Hi Emil,

On Fri, Aug 24, 2018 at 9:25 PM Emil Velikov  wrote:
>
> From: Emil Velikov 
>
> Unlike the other platforms, here we aim do guess if the device that we
> somewhat arbitrarily picked, is supported or not.
>
> In particular: when a vendor is _not_ requested we loop through all
> devices, picking the first one which can create a DRI screen.
>
> When a vendor is requested - we use that and do _not_ fall-back to any
> other device.
>
> The former seems a bit fiddly, but considering EGL_EXT_explicit_device and
> EGL_MESA_query_renderer are MIA, this is the best we can do for the
> moment.
>
> With those (proposed) extensions userspace will be able to create a
> separate EGL display for each device, query device details and make the
> conscious decision which one to use.
>
> Cc: Robert Foss 
> Cc: Tomasz Figa 
> Signed-off-by: Emil Velikov 
> ---
> Thanks for the clarification Tomasz. The original code was using a
> fall-back even a vendor was explicitly requested, confusing me a bit ;-)

Yeah, it was surprisingly difficult to get it right and I missed that
in the review. Thanks for figuring this out.

> ---
>  src/egl/drivers/dri2/platform_android.c | 71 +++--
>  1 file changed, 43 insertions(+), 28 deletions(-)
>
> diff --git a/src/egl/drivers/dri2/platform_android.c 
> b/src/egl/drivers/dri2/platform_android.c
> index 1f9fe27ab85..5bf627dec7d 100644
> --- a/src/egl/drivers/dri2/platform_android.c
> +++ b/src/egl/drivers/dri2/platform_android.c
> @@ -1420,13 +1420,32 @@ droid_filter_device(_EGLDisplay *disp, int fd, const 
> char *vendor)
> return 0;
>  }
>
> +static int
> +droid_probe_device(_EGLDisplay *disp)
> +{
> +  /* Check that the device is supported, by attempting to:
> +   * - load the dri module
> +   * - and, create a screen
> +   */
> +   if (!droid_load_driver(disp)) {
> +  _eglLog(_EGL_WARNING, "DRI2: failed to load driver");

Failing to create a screen is probably critical enough to be worth a
message, even if just probing, but failing to load a driver would like
mean that there is no driver for the device, so perhaps we don't need
to clutter the log in such case?

> +  return -1;
> +   }
> +
> +   if (!dri2_create_screen(disp)) {
> +  _eglLog(_EGL_WARNING, "DRI2: failed to create screen");

I don't remember if I got an answer to this question, sorry if I did:

Is there really nothing to clean up after droid_load_driver()? Not
leaking anything here, when probing though the subsequent devices?

> +  return -1;
> +   }
> +   return 0;
> +}
> +
>  static int
>  droid_open_device(_EGLDisplay *disp)
>  {
>  #define MAX_DRM_DEVICES 32
> drmDevicePtr device, devices[MAX_DRM_DEVICES] = { NULL };
> int prop_set, num_devices;
> -   int fd = -1, fallback_fd = -1;
> +   int fd = -1;
>
> char *vendor_name = NULL;
> char vendor_buf[PROPERTY_VALUE_MAX];
> @@ -1451,33 +1470,39 @@ droid_open_device(_EGLDisplay *disp)
>   continue;
>}
>
> -  if (vendor_name && droid_filter_device(disp, fd, vendor_name)) {
> - /* Match requested, but not found - set as fallback */
> - if (fallback_fd == -1) {
> -fallback_fd = fd;
> - } else {
> +  /* If a vendor is explicitly provided, we use only that.
> +   * Otherwise we fall-back the first device that is supported.
> +   */
> +  if (vendor_name) {
> + if (droid_filter_device(disp, fd, vendor_name)) {
> +/* Device does not match - try next device */
>  close(fd);
>  fd = -1;
> +continue;
>   }
> -
> + /* If the requested device matches use it, regardless if
> +  * init fails. Do not fall-back to any other device.
> +  */
> + if (droid_probbe_device(disp)) {

typo: droid_probe_device

> +close(fd);
> +fd = -1;
> + }
> + break;
> +  }
> +  /* No explicit request - attempt the next device */
> +  if (droid_probbe_device(disp)) {

typo: droid_probe_device

> + close(fd);
> + fd = -1;
>   continue;
>}
> -  /* Found a device */
>break;

A break at the end of a loop is really confusing to read. Could we
rewrite the last block to avoid it? E.g.

   if (!droid_probe_device(disp)) {
  /* Found a device */
  break;
   }
   /* No explicit request - attempt the next device. */
   close(fd);
   fd = -1;
}

Best regards,
Tomasz
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 6/5] egl/android: continue to next device if dri2_create_screen fails

[Tomasz Figa]

On Thu, Aug 23, 2018 at 1:44 AM Emil Velikov  wrote:
>
> Hi Tomasz,
>
> On 21 August 2018 at 14:54, Tomasz Figa  wrote:
> > Hi Emil,
> >
> > On Tue, Aug 14, 2018 at 2:05 AM Emil Velikov  
> > wrote:
> >>
> >> From: Emil Velikov 
> >>
> >> Unlike the other platforms, here we aim do guess if the device that we
> >> somewhat arbitrarily picked, is supported or not.
> >>
> >> It seems a bit fiddly, but considering EGL_EXT_explicit_device and
> >> EGL_MESA_query_renderer are MIA, this is the best we can do for the
> >> moment.
> >>
> >> With those (proposed) extensions userspace will be able to create a
> >> separate EGL display for each device, query device details and make the
> >> conscious decision which one to use.
> >>
> >> Cc: Robert Foss 
> >> Cc: Tomasz Figa 
> >> Signed-off-by: Emil Velikov 
> >> ---
> >>  src/egl/drivers/dri2/platform_android.c | 29 -
> >>  1 file changed, 19 insertions(+), 10 deletions(-)
> >>
> >> diff --git a/src/egl/drivers/dri2/platform_android.c 
> >> b/src/egl/drivers/dri2/platform_android.c
> >> index 50dd7a5e1b4..cac59847b89 100644
> >> --- a/src/egl/drivers/dri2/platform_android.c
> >> +++ b/src/egl/drivers/dri2/platform_android.c
> >> @@ -1295,6 +1295,25 @@ droid_open_device(_EGLDisplay *disp)
> >>   continue;
> >>}
> >>/* Found a device */
> >> +
> >> +  /* Check that the device is supported, by attempting to:
> >> +   * - load the dri module
> >> +   * - and, create a screen
> >> +   */
> >> +  if (!droid_load_driver(disp)) {
> >> + _eglLog(_EGL_WARNING, "DRI2: failed to load driver");
> >> + close(fd);
> >> + fd = -1;
> >> + continue;
> >> +  }
> >> +
> >> +  if (!dri2_create_screen(disp)) {
> >> + _eglLog(_EGL_WARNING, "DRI2: failed to create screen");
> >> + close(fd);
> >> + fd = -1;
> >> + continue;
> >> +  }
> >
> > Don't we also need to do these tests when determining if the device is
> > a suitable fallback? The fallback fd is set much earlier, in the same
> > block as the continue statement, so the code below wouldn't execute.
> >
> Let me see if I got this correctly:
>  - when a "vendor" is requested we use that, falling back to the first
> other driver where screen creation succeeds
>  - if one isn't requested, we pick the first device that can create a screen
>
> Is that right?

Yes, seems to match my idea.

Just to make sure we're not going to be masking some failures with
fallbacks, I think we should make sure that if "vendor" is requested
and found, we don't fallback, even if the matched device fails to
create a screen.

Best regards,
Tomasz
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] llvmpipe: Always return some fence in flush

[Tomasz Figa]

Hi Michel,

On Thu, Aug 16, 2018 at 6:43 PM Michel Dänzer  wrote:
>
> On 2018-08-16 11:34 AM, Tomasz Figa wrote:
> > If there is no last fence, due to no rendering happening yet, just
> > create a new signaled fence and return it, to match the expectations of
> > the EGL sync fence API.
> >
> > Fixes random "Could not create sync fence 0x3003" assertion failures from
> > Skia on Android, coming from the following code:
> >
> > https://android.googlesource.com/platform/frameworks/base/+/master/libs/hwui/pipeline/skia/SkiaOpenGLPipeline.cpp#427
> >
> > Reproducible especially with thread count >= 4.
> >
> > Signed-off-by: Tomasz Figa 
> > ---
> >  src/gallium/drivers/llvmpipe/lp_setup.c | 8 +++-
> >  1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/gallium/drivers/llvmpipe/lp_setup.c 
> > b/src/gallium/drivers/llvmpipe/lp_setup.c
> > index b087369473..a6f1b54d69 100644
> > --- a/src/gallium/drivers/llvmpipe/lp_setup.c
> > +++ b/src/gallium/drivers/llvmpipe/lp_setup.c
> > @@ -360,7 +360,13 @@ lp_setup_flush( struct lp_setup_context *setup,
> > set_scene_state( setup, SETUP_FLUSHED, reason );
> >
> > if (fence) {
> > -  lp_fence_reference((struct lp_fence **)fence, setup->last_fence);
> > +  struct lp_fence *lp_fence = NULL;
> > +
> > +  lp_fence_reference(_fence, setup->last_fence);
> > +  if (!lp_fence)
> > + lp_fence = lp_fence_create(0);
> > +  lp_fence_reference((struct lp_fence **)fence, lp_fence);
> > +  lp_fence_reference(_fence, NULL);
> > }
> >  }
> >
> >
>
> Other drivers keep around a reference to the last fence in the context,
> and return that if there's no new work to flush.

Thanks for taking a look.

Right, it sounds like a sane thing to do. LLVMpipe, however, seems to
explicitly destroy the fence whenever a rendering pass completes and I
didn't want to change that without understanding the intentions behind
that. Precisely, it's lp_scene_end_rasterization():
https://gitlab.freedesktop.org/mesa/mesa/blob/master/src/gallium/drivers/llvmpipe/lp_scene.c#L292

Also, this still wouldn't solve the problem of an EGL sync fence being
created and waited on without any rendering happening at all, which is
also likely to happen with Android code pointed to in the commit
message. Obviously that could be dealt with by creating a signaled
fence in lp_setup_create(), though.

Let me add Keith and Brian for more visibility.

Best regards,
Tomasz
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/5] egl/android: remove droid_probe_driver()

[Tomasz Figa]

Hi Emil,

On Mon, Aug 20, 2018 at 10:47 PM Emil Velikov  wrote:
>
> On 13 August 2018 at 17:18, Tomasz Figa  wrote:
> > On Tue, Aug 14, 2018 at 1:09 AM Emil Velikov  
> > wrote:
> >>
> >> On 13 August 2018 at 16:43, Tomasz Figa  wrote:
> >> > On Tue, Aug 14, 2018 at 12:35 AM Emil Velikov  
> >> > wrote:
> >> >>
> >> >> On 13 August 2018 at 16:16, Tomasz Figa  wrote:
> >> >> > Hi Emil,
> >> >> >
> >> >> > On Mon, Aug 13, 2018 at 11:48 PM Emil Velikov 
> >> >> >  wrote:
> >> >> >>
> >> >> >> From: Emil Velikov 
> >> >> >>
> >> >> >> The function name is misleading - it effectively checks if
> >> >> >> loader_get_driver_for_fd fails. Which can happen only only on strdup
> >> >> >> error - a close to impossible scenario.
> >> >> >
> >> >> > How about a DRI node which doesn't have a driver in Mesa?
> >> >> >
> >> >> Can you elaborate a bit - are you thinking of any of the following or
> >> >> something else:
> >> >>  - no support for vendor X
> >> >>  - supported vendor, missing vendor/device pci id for device X
> >> >>  - supported vendor, built w/o it
> >> >>
> >> >> All these are fairly different cases, with somewhat different solution
> >> >> for each one.
> >> >
> >> > Let's say "no support for vendor X", but supported vendor Y GPU next
> >> > to it. We want this code to skip vendor X DRI node and choose vendor Y
> >> > DRI node.
> >> >
> >> >>
> >> >> Fwiw the function loader_get_driver_for_fd does:
> >> >>  - gets the vendor/device pci id and maps that to a driver_name
> >> >>  - if device not a pci device (or query fails) - fallback to the name
> >> >> as returned in drmGetVersion
> >> >
> >> > Good catch. Looks like I misunderstood what it does when reviewing
> >> > Rob's series and existing code doesn't work as I expected. I think it
> >> > would just error out in the case above, right?
> >> >
> >> Determining if a device is "supported" is fairly subtle:
> >> For example, even if you open the foo_dri.so the driver can fail due
> >> to old kernel module, LLVM version, etc.
> >> One solution is to continue loading up-to dri2_create_screen() - if it
> >> fails fall-back to the next device.
> >>
> >> Any objections if I do that as follow-up patch, if you agree of course?
> >
> > Our downstream patch [1] actually loaded until
> > dri2_load_driver(_dri3)() in probe, but if you think
> > dri2_create_screen() could make more sense, I'm okay with it. Thanks.
> >
> Right, patch that does that can be seen here (copy in your inbox)
> https://patchwork.freedesktop.org/patch/244276/
>
> Can you Ack/R-b/T-b the series - I think all your concerns have been 
> addressed.
>
> https://patchwork.freedesktop.org/patch/244366/
> https://patchwork.freedesktop.org/patch/244243/
> https://patchwork.freedesktop.org/patch/244244/
> https://patchwork.freedesktop.org/patch/244240/
> https://patchwork.freedesktop.org/patch/244242/
>

Sorry for being late. Generally, for the original series of 5 patches:

Reviewed-by: Tomasz Figa 

As for patch 6/5, it needs one fix I mentioned there and I also need
to get a chance to test it.

Best regards,
Tomasz
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 6/5] egl/android: continue to next device if dri2_create_screen fails

[Tomasz Figa]

Hi Emil,

On Tue, Aug 14, 2018 at 2:05 AM Emil Velikov  wrote:
>
> From: Emil Velikov 
>
> Unlike the other platforms, here we aim do guess if the device that we
> somewhat arbitrarily picked, is supported or not.
>
> It seems a bit fiddly, but considering EGL_EXT_explicit_device and
> EGL_MESA_query_renderer are MIA, this is the best we can do for the
> moment.
>
> With those (proposed) extensions userspace will be able to create a
> separate EGL display for each device, query device details and make the
> conscious decision which one to use.
>
> Cc: Robert Foss 
> Cc: Tomasz Figa 
> Signed-off-by: Emil Velikov 
> ---
>  src/egl/drivers/dri2/platform_android.c | 29 -
>  1 file changed, 19 insertions(+), 10 deletions(-)
>
> diff --git a/src/egl/drivers/dri2/platform_android.c 
> b/src/egl/drivers/dri2/platform_android.c
> index 50dd7a5e1b4..cac59847b89 100644
> --- a/src/egl/drivers/dri2/platform_android.c
> +++ b/src/egl/drivers/dri2/platform_android.c
> @@ -1295,6 +1295,25 @@ droid_open_device(_EGLDisplay *disp)
>   continue;
>}
>/* Found a device */
> +
> +  /* Check that the device is supported, by attempting to:
> +   * - load the dri module
> +   * - and, create a screen
> +   */
> +  if (!droid_load_driver(disp)) {
> + _eglLog(_EGL_WARNING, "DRI2: failed to load driver");
> + close(fd);
> + fd = -1;
> + continue;
> +  }
> +
> +  if (!dri2_create_screen(disp)) {
> + _eglLog(_EGL_WARNING, "DRI2: failed to create screen");
> + close(fd);
> + fd = -1;
> + continue;
> +  }

Don't we also need to do these tests when determining if the device is
a suitable fallback? The fallback fd is set much earlier, in the same
block as the continue statement, so the code below wouldn't execute.

Best regards,
Tomasz
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] llvmpipe: Always return some fence in flush

[Tomasz Figa]

If there is no last fence, due to no rendering happening yet, just
create a new signaled fence and return it, to match the expectations of
the EGL sync fence API.

Fixes random "Could not create sync fence 0x3003" assertion failures from
Skia on Android, coming from the following code:

https://android.googlesource.com/platform/frameworks/base/+/master/libs/hwui/pipeline/skia/SkiaOpenGLPipeline.cpp#427

Reproducible especially with thread count >= 4.

Signed-off-by: Tomasz Figa 
---
 src/gallium/drivers/llvmpipe/lp_setup.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/llvmpipe/lp_setup.c 
b/src/gallium/drivers/llvmpipe/lp_setup.c
index b087369473..a6f1b54d69 100644
--- a/src/gallium/drivers/llvmpipe/lp_setup.c
+++ b/src/gallium/drivers/llvmpipe/lp_setup.c
@@ -360,7 +360,13 @@ lp_setup_flush( struct lp_setup_context *setup,
set_scene_state( setup, SETUP_FLUSHED, reason );
 
if (fence) {
-  lp_fence_reference((struct lp_fence **)fence, setup->last_fence);
+  struct lp_fence *lp_fence = NULL;
+
+  lp_fence_reference(_fence, setup->last_fence);
+  if (!lp_fence)
+ lp_fence = lp_fence_create(0);
+  lp_fence_reference((struct lp_fence **)fence, lp_fence);
+  lp_fence_reference(_fence, NULL);
}
 }
 
-- 
2.18.0.865.gffc8e1a3cd6-goog

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/5] egl/android: use strcmp with drmVersion::name

[Tomasz Figa]

On Tue, Aug 14, 2018 at 12:47 AM Emil Velikov  wrote:
>
> On 13 August 2018 at 16:21, Tomasz Figa  wrote:
> > On Mon, Aug 13, 2018 at 11:48 PM Emil Velikov  
> > wrote:
> >>
> >> From: Emil Velikov 
> >>
> >> The name string is guaranteed to be NULL terminated. Drop the explicit
> >> length check that comes with strncmp().
> >
> > Is there anything wrong with that length check? I feel like it's a
> > good practice to keep it anyway.
> >
> Consider the a long DRM driver name, that goes over PROPERTY_VALUE_MAX.
> One could replace it with min(PROP.., version::name_len), although it
> does seem over pedantic.
>
> I'm yet to see a single instance that does strncmp for the name.

Fair enough. Sorry for the noise.

Best regards,
Tomasz
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/5] egl/android: remove droid_probe_driver()

[Tomasz Figa]

On Tue, Aug 14, 2018 at 1:09 AM Emil Velikov  wrote:
>
> On 13 August 2018 at 16:43, Tomasz Figa  wrote:
> > On Tue, Aug 14, 2018 at 12:35 AM Emil Velikov  
> > wrote:
> >>
> >> On 13 August 2018 at 16:16, Tomasz Figa  wrote:
> >> > Hi Emil,
> >> >
> >> > On Mon, Aug 13, 2018 at 11:48 PM Emil Velikov  
> >> > wrote:
> >> >>
> >> >> From: Emil Velikov 
> >> >>
> >> >> The function name is misleading - it effectively checks if
> >> >> loader_get_driver_for_fd fails. Which can happen only only on strdup
> >> >> error - a close to impossible scenario.
> >> >
> >> > How about a DRI node which doesn't have a driver in Mesa?
> >> >
> >> Can you elaborate a bit - are you thinking of any of the following or
> >> something else:
> >>  - no support for vendor X
> >>  - supported vendor, missing vendor/device pci id for device X
> >>  - supported vendor, built w/o it
> >>
> >> All these are fairly different cases, with somewhat different solution
> >> for each one.
> >
> > Let's say "no support for vendor X", but supported vendor Y GPU next
> > to it. We want this code to skip vendor X DRI node and choose vendor Y
> > DRI node.
> >
> >>
> >> Fwiw the function loader_get_driver_for_fd does:
> >>  - gets the vendor/device pci id and maps that to a driver_name
> >>  - if device not a pci device (or query fails) - fallback to the name
> >> as returned in drmGetVersion
> >
> > Good catch. Looks like I misunderstood what it does when reviewing
> > Rob's series and existing code doesn't work as I expected. I think it
> > would just error out in the case above, right?
> >
> Determining if a device is "supported" is fairly subtle:
> For example, even if you open the foo_dri.so the driver can fail due
> to old kernel module, LLVM version, etc.
> One solution is to continue loading up-to dri2_create_screen() - if it
> fails fall-back to the next device.
>
> Any objections if I do that as follow-up patch, if you agree of course?

Our downstream patch [1] actually loaded until
dri2_load_driver(_dri3)() in probe, but if you think
dri2_create_screen() could make more sense, I'm okay with it. Thanks.

[1] 
https://chromium-review.googlesource.com/c/chromiumos/third_party/mesa/+/558138

Best regards,
Tomasz
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/5] egl/android: remove droid_probe_driver()

[Tomasz Figa]

On Tue, Aug 14, 2018 at 12:35 AM Emil Velikov  wrote:
>
> On 13 August 2018 at 16:16, Tomasz Figa  wrote:
> > Hi Emil,
> >
> > On Mon, Aug 13, 2018 at 11:48 PM Emil Velikov  
> > wrote:
> >>
> >> From: Emil Velikov 
> >>
> >> The function name is misleading - it effectively checks if
> >> loader_get_driver_for_fd fails. Which can happen only only on strdup
> >> error - a close to impossible scenario.
> >
> > How about a DRI node which doesn't have a driver in Mesa?
> >
> Can you elaborate a bit - are you thinking of any of the following or
> something else:
>  - no support for vendor X
>  - supported vendor, missing vendor/device pci id for device X
>  - supported vendor, built w/o it
>
> All these are fairly different cases, with somewhat different solution
> for each one.

Let's say "no support for vendor X", but supported vendor Y GPU next
to it. We want this code to skip vendor X DRI node and choose vendor Y
DRI node.

>
> Fwiw the function loader_get_driver_for_fd does:
>  - gets the vendor/device pci id and maps that to a driver_name
>  - if device not a pci device (or query fails) - fallback to the name
> as returned in drmGetVersion

Good catch. Looks like I misunderstood what it does when reviewing
Rob's series and existing code doesn't work as I expected. I think it
would just error out in the case above, right?

Best regards,
Tomasz
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/5] egl/android: use strcmp with drmVersion::name

[Tomasz Figa]

On Mon, Aug 13, 2018 at 11:48 PM Emil Velikov  wrote:
>
> From: Emil Velikov 
>
> The name string is guaranteed to be NULL terminated. Drop the explicit
> length check that comes with strncmp().

Is there anything wrong with that length check? I feel like it's a
good practice to keep it anyway.

Best regards,
Tomasz
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/5] egl/android: remove droid_probe_driver()

[Tomasz Figa]

Hi Emil,

On Mon, Aug 13, 2018 at 11:48 PM Emil Velikov  wrote:
>
> From: Emil Velikov 
>
> The function name is misleading - it effectively checks if
> loader_get_driver_for_fd fails. Which can happen only only on strdup
> error - a close to impossible scenario.

How about a DRI node which doesn't have a driver in Mesa?

Best regards,
Tomasz
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] ANDROID: eglCreateImageKHR missing modifiers

[Tomasz Figa]

On Tue, Jul 24, 2018 at 10:25 PM Martin Fuzzey
 wrote:
>
> Hi Thomasz,
>
> thanks for your reply
>
> On 21/07/18 04:27, Tomasz Figa wrote:
> >
> > As you noticed, this adds back the dependency on gralloc handle
> > structure. Moreover, it actually adds a dependency on the handle
> > having a binary format compatible with gralloc_gbm_handle_t. This is
> > not something that we can do in upstream Mesa, since there are more
> > platforms running gralloc implementations other than gbm_gralloc.
>
> Looking at it a bit more is it really that bad?
>
> The compile time dependency is on gralloc_handle.h which is actually
> part of libdrm not a specific gralloc implementation.
> Does mesa need to compile with old versions of libdrm?
> 0r is the structure going to be removed from libdrm?
>
> As you say there is also the runtime dependency on the binary format of
> the handle structure *but* checking the magic will ensure that if we run
> with a different implementation of gralloc which doesn't have the same
> magic we will gracefully fall back to not supporting modifiers, just as
> we would with a new optional gralloc perform call.
> We should probably also check the numFds, numInts field in the
> native_handle_t header to ensure that we can safely access the magic
> field to protect against any other gralloc implementations having a tiny
> handle format.
>

Alright, if we ensure that we can safely check for the right handle
format at runtime then I don't have anything against it.

Obviously it would be much better if we could have a generic way to
handle this, but given the Android way of doing things it doesn't
sound likely.

Best regards,
Tomasz

>
> >>
> >> --- a/src/egl/drivers/dri2/platform_android.c
> >> +++ b/src/egl/drivers/dri2/platform_android.c
> >> @@ -43,6 +43,8 @@
> >>#include "gralloc_drm.h"
> >>#endif /* HAVE_DRM_GRALLOC */
> >>
> >> +#include 
> >> +
> >>#define ALIGN(val, align)  (((val) + (align) - 1) & ~((align) - 1))
> >>
> >>struct droid_yuv_format {
> >> @@ -801,6 +803,9 @@ droid_create_image_from_prime_fd(_EGLDisplay *disp,
> >> _EGLContext *ctx,
> >> struct ANativeWindowBuffer *buf, int 
> >> fd)
> >>{
> >>   unsigned int pitch;
> >> +   struct gralloc_gbm_handle_t *grh;
> >> +   uint64_t modifier = 0;
> >> +   bool have_modifier = false;
> >>
> >>   if (is_yuv(buf->format)) {
> >>  _EGLImage *image;
> >> @@ -829,17 +834,34 @@ droid_create_image_from_prime_fd(_EGLDisplay
> >> *disp, _EGLContext *ctx,
> >>  return NULL;
> >>   }
> >>
> >> -   const EGLint attr_list[] = {
> >> +   grh = (struct gralloc_gbm_handle_t *)buf->handle;
> >> +   if (grh->magic == GRALLOC_HANDLE_MAGIC) {
> >> +  modifier = grh->modifier;
> >> +  have_modifier = true;
> >> +   }
> >> +
> >> +   EGLint attr_list[] = {
> >>  EGL_WIDTH, buf->width,
> >>  EGL_HEIGHT, buf->height,
> >>  EGL_LINUX_DRM_FOURCC_EXT, fourcc,
> >>  EGL_DMA_BUF_PLANE0_FD_EXT, fd,
> >>  EGL_DMA_BUF_PLANE0_PITCH_EXT, pitch,
> >>  EGL_DMA_BUF_PLANE0_OFFSET_EXT, 0,
> >> +  EGL_DMA_BUF_PLANE0_MODIFIER_LO_EXT, modifier & 0x,
> >> +  EGL_DMA_BUF_PLANE0_MODIFIER_HI_EXT, modifier >> 32,
> >>  EGL_NONE, 0
> >>   };
> >>
> >> -   return dri2_create_image_dma_buf(disp, ctx, NULL, attr_list);
> >> +   if (!have_modifier) {
> >> +  for (int i=0; i < ARRAY_SIZE(attr_list); i+=2) {
> >> + if (attr_list[i] == EGL_DMA_BUF_PLANE0_MODIFIER_LO_EXT) {
> >> +attr_list[i] = EGL_NONE;
> >> +break;
> >> + }
> >> +  }
> >> +   }
> >> +
> >> +   return dri2_create_image_dma_buf(disp, ctx, NULL, (const EGLint
> >> *)attr_list);
> >>}
> >>
> >> What is the preferred way of fixing this?
> > Unfortunately, I don't have a very good solution for this. In Chrome
> > OS we just don't support modifiers in EGL/GLES on Android. Obviously
> > it would be a good idea to have some way to query gralloc for the
> > modifier, but I don't see Android providing any generic way to do it.
> >
> > The least evil I can think of as a makeshift for now could be an
> > optional gralloc0 perform call that returns the modifier for given
> > buffer.
>
> An advantage of a new perform call would be that other gralloc
> implementations could be extended to support it without changing their
> handle structure but is that really likely?
>
> Regards,
>
> Martin
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gallium/auxiliary: Fix Autotools on Android (v2)

[Tomasz Figa]

On Fri, Jul 27, 2018 at 6:52 AM Chad Versace  wrote:
>
> On Wed 25 Jul 2018, Tomasz Figa wrote:
> > Hi Chad,
> >
> > On Wed, Jul 25, 2018 at 10:11 AM Chad Versace  
> > wrote:
> > >
> > > Problem 1: u_debug_stack_android.cpp transitively included
> > > "pipe/p_compiler.h", but src/gallium/include was missing from the C++
> > > include path.
> > >
> > > Problem 2: Add -std=c++11 to AM_CXXFLAGS. Android's libbacktrace headers
> > > require C++11, but the Android toolchain (at least in the Chrome OS SDK)
> > > does not enable C++11 by default.
> > >
> > > v2: Add -std=c++11.
> > >
> > > Cc: Gurchetan Singh 
> > > Cc: Eric Engestrom 
> > > ---
> > >  src/gallium/auxiliary/Makefile.am | 6 +-
> > >  1 file changed, 5 insertions(+), 1 deletion(-)
>
> [snip]
>
> > >  if HAVE_PLATFORM_ANDROID
> > > +# Android's libbacktrace headers required C++11, but the Android 
> > > toolchain (at
> > > +# least in the Chrome OS SDK) does not enable C++11 by default.
> > > +AM_CXXFLAGS += $(CXX11_CXXFLAGS)
> > > +
> >
> > This is something that would normally be handled by the .pc file for
> > given library. Package build system shouldn't be polluted with such
> > system-specific low level dependencies.
>
> Normally, I would agree. "If libbacktrace needs a CXXFLAG, then put in
> the pc file". That's reasonable for most flags, because most flags are
> *additive*. But the -std flag is not. If backtrace.pc added '-std=c++11'
> to CXXFLAGS, but a different package required c++14, how should Mesa
> resolve that conflict?
>
> As precedent, I searched all pc files on my Debian machine. The only pc
> files that add -std to CFLAGS or CXXFLAGS are the icu-*.pc files. And
> those files should serve as anti-precedent in most cases; they are badly
> written compared to all other pc files I've seen.

Okay, fair enough. Sorry for the noise then. Thanks for rechecking.

Reviewed-by: Tomasz Figa 

Best regards,
Tomasz
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gallium/auxiliary: Fix Autotools on Android (v2)

[Tomasz Figa]

Hi Chad,

On Wed, Jul 25, 2018 at 10:11 AM Chad Versace  wrote:
>
> Problem 1: u_debug_stack_android.cpp transitively included
> "pipe/p_compiler.h", but src/gallium/include was missing from the C++
> include path.
>
> Problem 2: Add -std=c++11 to AM_CXXFLAGS. Android's libbacktrace headers
> require C++11, but the Android toolchain (at least in the Chrome OS SDK)
> does not enable C++11 by default.
>
> v2: Add -std=c++11.
>
> Cc: Gurchetan Singh 
> Cc: Eric Engestrom 
> ---
>  src/gallium/auxiliary/Makefile.am | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/auxiliary/Makefile.am 
> b/src/gallium/auxiliary/Makefile.am
> index 03908198772..4bfa7648389 100644
> --- a/src/gallium/auxiliary/Makefile.am
> +++ b/src/gallium/auxiliary/Makefile.am
> @@ -13,6 +13,7 @@ AM_CFLAGS = \
> $(MSVC2013_COMPAT_CFLAGS)
>
>  AM_CXXFLAGS = \
> +   $(GALLIUM_CFLAGS) \
> $(VISIBILITY_CXXFLAGS) \
> $(MSVC2013_COMPAT_CXXFLAGS)
>
> @@ -22,6 +23,10 @@ libgallium_la_SOURCES = \
> $(GENERATED_SOURCES)
>
>  if HAVE_PLATFORM_ANDROID
> +# Android's libbacktrace headers required C++11, but the Android toolchain 
> (at
> +# least in the Chrome OS SDK) does not enable C++11 by default.
> +AM_CXXFLAGS += $(CXX11_CXXFLAGS)
> +

This is something that would normally be handled by the .pc file for
given library. Package build system shouldn't be polluted with such
system-specific low level dependencies.

Best regards,
Tomasz
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] ANDROID: eglCreateImageKHR missing modifiers

[Tomasz Figa]

Hi Martin,

On Sat, Jul 21, 2018 at 1:01 AM Martin Fuzzey
 wrote:
>
> Hi,
>
> I am testing mesa / etnaviv / gbm_gralloc under Android 8.1 on i.MX6
>
> I discovered the screen capture function was not working (it was
> producing empty buffers).
>
> The reason for this seems to be that eglCreateImageKHR() with
> EGL_NATIVE_BUFFER_ANDROID does not import the modifier information.
>
> I fixed it with the patch below, but I don't think this is the right way
> as it is adding back a dependency on the gralloc_handle structure.

As you noticed, this adds back the dependency on gralloc handle
structure. Moreover, it actually adds a dependency on the handle
having a binary format compatible with gralloc_gbm_handle_t. This is
not something that we can do in upstream Mesa, since there are more
platforms running gralloc implementations other than gbm_gralloc.

>
>
> --- a/src/egl/drivers/dri2/platform_android.c
> +++ b/src/egl/drivers/dri2/platform_android.c
> @@ -43,6 +43,8 @@
>   #include "gralloc_drm.h"
>   #endif /* HAVE_DRM_GRALLOC */
>
> +#include 
> +
>   #define ALIGN(val, align)  (((val) + (align) - 1) & ~((align) - 1))
>
>   struct droid_yuv_format {
> @@ -801,6 +803,9 @@ droid_create_image_from_prime_fd(_EGLDisplay *disp,
> _EGLContext *ctx,
>struct ANativeWindowBuffer *buf, int fd)
>   {
>  unsigned int pitch;
> +   struct gralloc_gbm_handle_t *grh;
> +   uint64_t modifier = 0;
> +   bool have_modifier = false;
>
>  if (is_yuv(buf->format)) {
> _EGLImage *image;
> @@ -829,17 +834,34 @@ droid_create_image_from_prime_fd(_EGLDisplay
> *disp, _EGLContext *ctx,
> return NULL;
>  }
>
> -   const EGLint attr_list[] = {
> +   grh = (struct gralloc_gbm_handle_t *)buf->handle;
> +   if (grh->magic == GRALLOC_HANDLE_MAGIC) {
> +  modifier = grh->modifier;
> +  have_modifier = true;
> +   }
> +
> +   EGLint attr_list[] = {
> EGL_WIDTH, buf->width,
> EGL_HEIGHT, buf->height,
> EGL_LINUX_DRM_FOURCC_EXT, fourcc,
> EGL_DMA_BUF_PLANE0_FD_EXT, fd,
> EGL_DMA_BUF_PLANE0_PITCH_EXT, pitch,
> EGL_DMA_BUF_PLANE0_OFFSET_EXT, 0,
> +  EGL_DMA_BUF_PLANE0_MODIFIER_LO_EXT, modifier & 0x,
> +  EGL_DMA_BUF_PLANE0_MODIFIER_HI_EXT, modifier >> 32,
> EGL_NONE, 0
>  };
>
> -   return dri2_create_image_dma_buf(disp, ctx, NULL, attr_list);
> +   if (!have_modifier) {
> +  for (int i=0; i < ARRAY_SIZE(attr_list); i+=2) {
> + if (attr_list[i] == EGL_DMA_BUF_PLANE0_MODIFIER_LO_EXT) {
> +attr_list[i] = EGL_NONE;
> +break;
> + }
> +  }
> +   }
> +
> +   return dri2_create_image_dma_buf(disp, ctx, NULL, (const EGLint
> *)attr_list);
>   }
>
> What is the preferred way of fixing this?

Unfortunately, I don't have a very good solution for this. In Chrome
OS we just don't support modifiers in EGL/GLES on Android. Obviously
it would be a good idea to have some way to query gralloc for the
modifier, but I don't see Android providing any generic way to do it.

The least evil I can think of as a makeshift for now could be an
optional gralloc0 perform call that returns the modifier for given
buffer.

Best regards,
Tomasz
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 0/4] Android kms_swrast support

[Tomasz Figa]

On Thu, Jul 19, 2018 at 12:08 AM Robert Foss  wrote:
>
> Hey Rob,
>
> On 2018-07-18 15:30, Rob Herring wrote:
> > On Tue, Jul 17, 2018 at 4:33 AM Robert Foss  
> > wrote:
> >>
> >> This series implements kms_swrast support for the Android
> >> platform. And since having to debug a null pointer dereference,
> >> simplify that process for the next guy.
> >
> > So is this working for you now?
>
> I'm seeing page-flips happen in the logs, but have no graphical output on the
> Qemu-based setup I'm using now.
>
> When using virgl I'm seeing the same page-flipping in the logs, but no 
> graphical
> output.
>
> >
> >> As it stands now, any kernel must have the following ioctls flagged with
> >> DRM_RENDER_ALLOW[1], which isn't the case in the mainline kernel.
> >>
> >> DRM_IOCTL_MODE_CREATE_DUMB
> >> DRM_IOCTL_MODE_MAP_DUMB
> >
> > Ah, sorry. I should have mentioned this. We have discussed this issue
> > in the past, but to no further conclusion.
> >
> > But as I recall, I thought the issue was also allowing import and
> > export of dumb buffers?
>
> Yeah, it's a two-parter for any AOSP Treble build.
> 1) Allow dumb buffer ioctls fom render nodes
> 2) Support moving buffers across processes.

Wouldn't 2) be automatically solved by 1), since we should be able to
run drmPrimeHandleToFD for dumb buffers already?

>
> >
> >> While it would be possible to open a non-render node to pass the
> >> authentication check, this would still cause authentication issues
> >> when the /dev/dri/cardX node needs to be opened as master by both mesa
> >> and the compositor.
> >
> > Right. We've pretty much stripped the support that was there out. Plus
> > I don't think it will work with Treble.
> >
> >> I don't know how acceptable this series is for upstreaming, while relying 
> >> on
> >> a non-mainline kernel. I think the policy is to not accept changes that
> >> don't have both a user and kernel space solution in place.
> >>
> >> Like I noted yesterday[2] the alternative to using dumb buffers and having
> >> authentication issues is using VGEM, which is new territory to me, and it 
> >> would
> >> take me a little bit of time to figure exactly how it fits into the current
> >> kms_swrast approach.
> >> Input, like noted before, is very much welcome.
> >
> > I'm very much in favor of the former approach. VGEM seems like an
> > overly complicated solution when there's a very simple solution.
> >
>
> The former solution being what we have now, dumb buffers?
> I don't think dumb buffers are a viable path due to 2) listed above.

I don't understand what 2) is about. Could you elaborate on it?

I'd personally be for dropping those strange restrictions from render
nodes. I don't see why a render node couldn't allocate and map a dumb
buffer (for software rendering) and share it with another process that
opened a control node (to display it).

>
> If there are any other options I'm not aware of, I'm very much listening.

One could just call mmap() on DMA-buf FDs directly rather than
importing them, but that could open another can of worms, because FDs
don't give us any way to deduplicate buffers (you might be given
several FDs pointing to the same buffer, which in case of importing to
DRM would end up with the same GEM handle every time).

Best regards,
Tomasz
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC 3/5] platform/android: Enable kms_swrast fallback

[Tomasz Figa]

Hi Rob,

On Thu, Jul 5, 2018 at 7:07 PM Robert Foss  wrote:
>
> Add support for the ForceSoftware option, which is togglable
> on the Android platform through setting the "drm.gpu.force_software"
> property to a non-zero value.
>
> kms_swrast is also enabled as a fallback for when a driver is not
> able to be loaded for for a drm node that was opened.
>
> Signed-off-by: Robert Foss 
> ---
>  src/egl/drivers/dri2/platform_android.c | 26 +
>  1 file changed, 18 insertions(+), 8 deletions(-)

Thanks for the patch. Please see my comments inline.

>
> diff --git a/src/egl/drivers/dri2/platform_android.c 
> b/src/egl/drivers/dri2/platform_android.c
> index 92b2d2b343e..bc644c25bf9 100644
> --- a/src/egl/drivers/dri2/platform_android.c
> +++ b/src/egl/drivers/dri2/platform_android.c
> @@ -1193,17 +1193,21 @@ static const __DRIextension 
> *droid_image_loader_extensions[] = {
>  };
>
>  EGLBoolean
> -droid_load_driver(_EGLDisplay *disp)
> +droid_load_driver(_EGLDisplay *disp, EGLBoolean force_software)
>  {
> struct dri2_egl_display *dri2_dpy = disp->DriverData;
> const char *err;
>
> -   dri2_dpy->driver_name = loader_get_driver_for_fd(dri2_dpy->fd);
> +   if (force_software) {
> +  dri2_dpy->driver_name = strdup("kms_swrast");
> +   } else {
> +  dri2_dpy->driver_name = loader_get_driver_for_fd(dri2_dpy->fd);
> +   }
> +
> if (dri2_dpy->driver_name == NULL)
>return false;
>
> dri2_dpy->is_render_node = drmGetNodeTypeFromFd(dri2_dpy->fd) == 
> DRM_NODE_RENDER;
> -

Unrelated whitespace change.

> if (!dri2_dpy->is_render_node) {
> #ifdef HAVE_DRM_GRALLOC
> /* Handle control nodes using __DRI_DRI2_LOADER extension and GEM 
> names
> @@ -1359,6 +1363,7 @@ EGLBoolean
>  dri2_initialize_android(_EGLDriver *drv, _EGLDisplay *disp)
>  {
> struct dri2_egl_display *dri2_dpy;
> +   int force_software = disp->Options.ForceSoftware;

EGLBoolean

> const char *err;
> int ret;
>
> @@ -1384,13 +1389,18 @@ dri2_initialize_android(_EGLDriver *drv, _EGLDisplay 
> *disp)
>
> dri2_dpy->fd = droid_open_device(disp);
> if (dri2_dpy->fd < 0) {
> -  err = "DRI2: failed to open device";
> -  goto cleanup;
> +  err = "DRI2: failed to open device, trying software device";
> }
>
> -   if (!droid_load_driver(disp)) {
> -  err = "DRI2: failed to load driver";
> -  goto cleanup;
> +load_driver:
> +   if (!droid_load_driver(disp, force_software)) {
> +  if (force_software) {
> + err = "DRI2: failed to load driver";
> + goto cleanup;
> +  } else {
> + force_software = true;
> + goto load_driver;
> +  }

I believe we don't need this retry here, because if we fail here once,
_eglMatchDriver() would retry us with ForceSoftware = EGL_TRUE [1].

[1] https://cgit.freedesktop.org/mesa/mesa/tree/src/egl/main/egldriver.c#n80

Best regards,
Tomasz
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC 2/5] egl/android: Add Android property for forcing kms_swrast

[Tomasz Figa]

On Thu, Jul 5, 2018 at 7:07 PM Robert Foss  wrote:
>
> In order to simplify Android bringup on new devices,
> provide the property "drm.gpu.force_software" which
> forces kms_swrast to be used.
>
> Signed-off-by: Robert Foss 
> ---
>  src/egl/main/egldriver.c | 10 ++
>  1 file changed, 10 insertions(+)
>
> diff --git a/src/egl/main/egldriver.c b/src/egl/main/egldriver.c
> index 218b3daef25..bb9e90c157d 100644
> --- a/src/egl/main/egldriver.c
> +++ b/src/egl/main/egldriver.c
> @@ -39,6 +39,10 @@
>  #include 
>  #include "c11/threads.h"
>
> +#ifdef HAVE_ANDROID_PLATFORM
> +#include 
> +#endif
> +
>  #include "egldefines.h"
>  #include "egldisplay.h"
>  #include "egldriver.h"
> @@ -87,6 +91,12 @@ _eglMatchDriver(_EGLDisplay *dpy)
> dpy->Options.ForceSoftware =
>env_var_as_boolean("LIBGL_ALWAYS_SOFTWARE", false);
>
> +#ifdef HAVE_ANDROID_PLATFORM
> +   char prop_val[PROPERTY_VALUE_MAX];
> +   property_get("drm.gpu.force_software", prop_val, "0");
> +   dpy->Options.ForceSoftware |= strncmp(prop_val, "0", PROPERTY_VALUE_MAX);

ForceSoftware is an EGLBoolean, which is just an unsigned int, not
stdbool, so no implicit conversion into {0, 1} for us here. I think
what we want here is

dpy->Options.ForceSoftware |= strncmp(prop_val, "0", PROPERTY_VALUE_MAX) != 0;

Best regards,
Tomasz
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC 1/5] st/dri: Allow kms_swrast to work without a device FD

[Tomasz Figa]

Hi Emil, Robert,

On Thu, Jul 5, 2018 at 9:57 PM Emil Velikov  wrote:
>
> On 5 July 2018 at 12:32, Robert Foss  wrote:
> > Hey Eric!
> >
> > On 05/07/18 12:35, Eric Engestrom wrote:
> >>
> >> On Thursday, 2018-07-05 12:07:36 +0200, Robert Foss wrote:
> >>>
> >>> From: Tomeu Vizoso 
> >>>
> >>> A KMS device isn't strictly needed for the kms_swrast to work, so stop
> >>> failing to init if the FD is -1. Also don't call DRM_IOCTL_GET_CAP in
> >>> that case.
> >>>
> >>> This allows the driver to be used in machines where no KMS device at all
> >>> is present.
> >>>
> >>> Signed-off-by: Tomeu Vizoso 
> >>> ---
> >>>   src/gallium/state_trackers/dri/dri2.c | 6 --
> >>>   1 file changed, 4 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/src/gallium/state_trackers/dri/dri2.c
> >>> b/src/gallium/state_trackers/dri/dri2.c
> >>> index 58a6757f037..c262c0ca118 100644
> >>> --- a/src/gallium/state_trackers/dri/dri2.c
> >>> +++ b/src/gallium/state_trackers/dri/dri2.c
> >>> @@ -2189,7 +2189,8 @@ dri_kms_init_screen(__DRIscreen * sPriv)
> >>>sPriv->driverPrivate = (void *)screen;
> >>>   -   if (screen->fd < 0 || (fd = fcntl(screen->fd, F_DUPFD_CLOEXEC, 3))
> >>> < 0)
> >>> +   /* We don't really need a device FD if we are soft-rendering */
> >>> +   if (screen->fd >= 0 && (fd = fcntl(screen->fd, F_DUPFD_CLOEXEC, 3)) <
> >>> 0)
> >>> goto free_screen;
> >>>if (pipe_loader_sw_probe_kms(>dev, fd)) {
> >>
> >>
> >> Aren't you going to use an uninitialised `fd` here if `screen->fd < 0`?
> >
> >
> > From my understanding during dri2_initialize_android(), droid_open_device[1]
> > will always allocate an FD or fail, before a screen is created in
> > dri2_create_screen[2].
> >
> > But maybe there is some part I don't quite understand.
> >
> You're tracking a single instance instead of looking at the function in 
> itself.
> When screen->fd is invalid, fd will be uninitialised. The
> pipe_loader_sw_probe_kms() call will then use that uninitialised
> value.
>
> I believe a better solution is to have distinct dri/null/kms backends
> to swrast, instead of hacking it in this way.
> Some ideas are listed in here [1].
>
> -Emil
>
> [1] 
> https://gitlab.collabora.com/tomeu/mesa/commit/54adda6a4d7b5c783d54dfd37d38d1a5a0f3187f

First of all, do we really need this patch at all? If you ended up
booting Android with Mesa, you must have had a DRM driver for the
display anyway, so what prevents you from using it as the KMS device
for kms_swrast?

Best regards,
Tomasz
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gallium: Fix automake for Android

[Tomasz Figa]

On Thu, Jun 28, 2018 at 4:50 AM Chad Versace  wrote:
>
>
> Chromium OS uses Autotools and pkg-config when building Mesa for
> Android. The gallium drivers were failing to find the headers and
> libraries for zlib and Android's libbacktrace.
>
> v2:
>   - Don't add a check for zlib.pc. configure.ac already checks for
> zlib.pc elsewhere. [for tfiga]
>   - Check for backtrace.pc separately from the other Android libs.
> [for tfiga]
> ---
>
> Tomasz, I added the suggestions that worked. I tried moving
> $(ANDROID_LIBS) and $(BACKTRACE_LIBS) to the hunk in
> src/gallium/auxiliary/Makefile.am, but the build no longer worked.
> libEGL failed to link.

Fair enough. Thanks.

Reviewed-by: Tomasz Figa 

Best regards,
Tomasz
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v4 3/3] egl/android: Add DRM node probing and filtering

[Tomasz Figa]

Hi Rob,

On Wed, Jun 20, 2018 at 10:26 PM Robert Foss  wrote:
>
> This patch both adds support for probing & filtering DRM nodes
> and switches away from using the GRALLOC_MODULE_PERFORM_GET_DRM_FD
> gralloc call.
>
> Currently the filtering is based just on the driver name,
> and the desired name is supplied using the "drm.gpu.vendor_name"
> Android property.
>
> Signed-off-by: Robert Foss 
> ---
>
> Changes since v3:
>  - Reduced number of probing return codes
>  - Simplified driver vendor check in droid_probe_device()
>  - Fixed type with ';' prepended to a if-statement
>  - Removed a strlen call
>  - Switched a sprintf to snprintf
>  - Replaced fd == -1 check with < 0
>  - Simplified switch+goto statements

Only 2 nits. Please feel free to add my R-b after fixing them (or
maybe a willing committer could fix them up when applying ;)). Thanks!

[snip]
> +static probe_ret_t
> +droid_probe_device(_EGLDisplay *disp, int fd, char *vendor)

const char *vendor

[snip]
> +static int
> +droid_open_device(_EGLDisplay *disp)
> +{
[snip]
> +  int ret = droid_probe_device(disp, fd, vendor_name);
> +  switch (ret) {
> +  case probe_success:
> + goto success;
> +  case probe_filtered_out:
> + /* Set as fallback */
> + if (fallback_fd == -1)
> +fallback_fd = fd;
> + break;
> +  case probe_fail:
> + break;
> +  }
> +
> +  if (fallback_fd != fd)
> + close(fd);
> +  fd = -1;
> +  continue;

This continue doesn't do anything.

Best regards,
Tomasz
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gallium: Fix automake for Android

[Tomasz Figa]

Hi Chad,

On Tue, Jun 19, 2018 at 3:46 PM Chad Versace  wrote:
>
> Chromium OS uses Autotools and pkg-config when building Mesa for
> Android. The gallium drivers were failing to find the headers and
> libraries for zlib and Android's libbacktrace.
> ---
>  configure.ac  | 6 +-
>  src/gallium/Automake.inc  | 5 +
>  src/gallium/auxiliary/Makefile.am | 4 
>  3 files changed, 14 insertions(+), 1 deletion(-)
>

Please see my comments inline.

> diff --git a/configure.ac b/configure.ac
> index 7a0e4754208..5f0792cd8ef 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1830,7 +1830,11 @@ for plat in $platforms; do
>  ;;
>
>  android)
> -PKG_CHECK_MODULES([ANDROID], [cutils hardware sync])
> +android_modules='cutils hardware sync zlib'

What's Android-specific in zlib? We already check higher for zlib,
shouldn't we just add ZLIB_CFLAGS/LIBS to the respective Makefile.in?

> +if test -n "$with_gallium_drivers"; then
> +android_modules+=' backtrace'

I'd also say this should have a separate PKG_CHECK_MODULES clause, say
"BACKTRACE" and BACKTRACE_CFLAGS/LIBS added to respective Makefile.in.
Especially since we only need libbacktrace in u_debug_stack*.

> +fi
> +PKG_CHECK_MODULES([ANDROID], ["$android_modules"])
>  DEFINES="$DEFINES -DHAVE_ANDROID_PLATFORM"
>  ;;
>
> diff --git a/src/gallium/Automake.inc b/src/gallium/Automake.inc
> index 3e21aa71b5c..8181927a396 100644
> --- a/src/gallium/Automake.inc
> +++ b/src/gallium/Automake.inc
> @@ -59,6 +59,11 @@ GALLIUM_COMMON_LIB_DEPS += \
> $(LIBDRM_LIBS)
>  endif
>
> +if HAVE_PLATFORM_ANDROID
> +GALLIUM_COMMON_LIB_DEPS += \
> +   $(ANDROID_LIBS)
> +endif
> +
>  GALLIUM_WINSYS_CFLAGS = \
> -I$(top_srcdir)/src \
> -I$(top_srcdir)/include \
> diff --git a/src/gallium/auxiliary/Makefile.am 
> b/src/gallium/auxiliary/Makefile.am
> index 6b048b8eebf..03908198772 100644
> --- a/src/gallium/auxiliary/Makefile.am
> +++ b/src/gallium/auxiliary/Makefile.am
> @@ -21,6 +21,10 @@ libgallium_la_SOURCES = \
> $(NIR_SOURCES) \
> $(GENERATED_SOURCES)
>
> +if HAVE_PLATFORM_ANDROID
> +libgallium_la_SOURCES += util/u_debug_stack_android.cpp

Shouldn't we add ANDROID_CFLAGS and ANDROID_LIBS here rather than in
src/gallium/Automake.inc, since this is the module that actually needs
them?

Best regards,
Tomasz
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v3 2/3] egl/android: #ifdef out flink name support

[Tomasz Figa]

Hi Rob,

On Sun, Jun 10, 2018 at 2:28 AM Robert Foss  wrote:
>
> From: Rob Herring 
>
> Maintaining both flink names and prime fd support which are provided by
> 2 different gralloc implementations is problematic because we have a
> dependency on a specific gralloc implementation header.
>
> This mostly disables the dependency on the gralloc implementation and
> headers. The dependency on GRALLOC_MODULE_PERFORM_GET_DRM_FD remains for
> now, but the definition is added locally to remove the header
> dependency.
>
> drm_gralloc support can be enabled by setting
> BOARD_USES_DRM_GRALLOC=true in BoardConfig.mk.
>
> Signed-off-by: Rob Herring 
> Signed-off-by: Robert Foss 
> ---
>
> Changes since RFC:
>  - Instead of removing code, #ifdef it out.

FWIW,

Reviewed-by: Tomasz Figa 

Best regards,
Tomasz
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v3 1/3] gallium/util: Fix build error due to cast to different size

[Tomasz Figa]

Hi Rob,

On Sun, Jun 10, 2018 at 2:28 AM Robert Foss  wrote:
>
> Signed-off-by: Robert Foss 
> ---
>  src/gallium/auxiliary/util/u_debug_stack_android.cpp | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/auxiliary/util/u_debug_stack_android.cpp 
> b/src/gallium/auxiliary/util/u_debug_stack_android.cpp
> index b3d56aebe6..395a1fe911 100644
> --- a/src/gallium/auxiliary/util/u_debug_stack_android.cpp
> +++ b/src/gallium/auxiliary/util/u_debug_stack_android.cpp
> @@ -49,10 +49,10 @@ debug_backtrace_capture(debug_stack_frame *mesa_backtrace,
>backtrace_table = _mesa_hash_table_create(NULL, _mesa_hash_pointer,
>  _mesa_key_pointer_equal);
>
> -   backtrace_entry = _mesa_hash_table_search(backtrace_table, (void*) tid);
> +   backtrace_entry = _mesa_hash_table_search(backtrace_table, (void*) 
> (uintptr_t)tid);
> if (!backtrace_entry) {
>backtrace = Backtrace::Create(getpid(), tid);
> -  _mesa_hash_table_insert(backtrace_table, (void*) tid, backtrace);
> +  _mesa_hash_table_insert(backtrace_table, (void*) (uintptr_t)tid, 
> backtrace);
> } else {
>backtrace = (Backtrace *) backtrace_entry->data;
> }
> --
> 2.17.1
>

FWIW,

Reviewed-by: Tomasz Figa 

Best regards,
Tomasz
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v3 3/3] egl/android: Add DRM node probing and filtering

[Tomasz Figa]

Hi Rob,

Thanks for sending v3. Please see few more comments inline.

On Sun, Jun 10, 2018 at 2:28 AM Robert Foss  wrote:
>
> This patch both adds support for probing & filtering DRM nodes
> and switches away from using the GRALLOC_MODULE_PERFORM_GET_DRM_FD
> gralloc call.
>
> Currently the filtering is based just on the driver name,
> and the desired name is supplied using the "drm.gpu.vendor_name"
> Android property.
>
> Signed-off-by: Robert Foss 
> ---
>
> Changes since v2:
>  - Switch from drmGetDevices2 to manual renderD node iteration
>  - Add probe_res enum to communicate probing results better
>  - Avoid using _eglError() in internal static functions
>  - Avoid actually loading the driver while probing, just verify
>that it exists.
>  - Replace strlen call with the assumed length PROPERTY_VALUE_MAX

[snip]

> +static probe_ret_t
> +droid_probe_device(_EGLDisplay *disp, int fd, char *vendor)
> +{
> +   int ret;
> +
> +   drmVersionPtr ver = drmGetVersion(fd);
> +   if (!ver)
> +  return probe_error;
> +
> +   if (vendor != NULL && ver->name != NULL &&
> +   strncmp(vendor, ver->name, PROPERTY_VALUE_MAX) != 0) {

Shouldn't we fail the match if vendor != NULL, but ver->name == NULL? i.e.

if (vendor && (!ver->name || strcmp(...)) { ...

> +  ret = probe_filtered_out;
> +  goto cleanup;
> +   }
> +
> +
> +   if (!droid_probe_driver(fd)) {
> +  ret = probe_no_driver;
> +  goto cleanup;
> +   }
> +
> +   ret = probe_success;
> +
> +cleanup:
> +   drmFreeVersion(ver);
> +   return ret;
> +}
> +
> +static int
> +droid_open_device(_EGLDisplay *disp)
> +{
> +   const int MAX_DRM_DEVICES = 32;
> +   int prop_set, num_devices;
> +   int fd = -1, fallback_fd = -1;
> +
> +   char *vendor_name = NULL;
> +   char vendor_buf[PROPERTY_VALUE_MAX];
> +   if (property_get("drm.gpu.vendor_name", vendor_buf, NULL) > 0);
> +  vendor_name = vendor_buf;
> +
> +   const char *drm_dir_name = "/dev/dri";
> +   DIR *sysdir = opendir(drm_dir_name);
> +   if (!sysdir)
> +   return -errno;
> +
> +   struct dirent *dent;
> +   while ((dent = readdir(sysdir))) {
> +  char dev_path[128];
> +  char *render_dev_prefix = "renderD";
> +  size_t prefix_len = strlen(render_dev_prefix);

If a const array like below is used instead

const char render_dev_prefix[] = "renderD";

you can just use sizeof(render_dev_prefix), without the need for strlen().

> +
> +  if (strncmp(render_dev_prefix, dent->d_name, prefix_len) != 0)
> + continue;
> +
> +  sprintf(dev_path, "%s/%s", drm_dir_name, dent->d_name);

snprintf(dev_path, sizeof(dev_path), ...);

> +  fd = loader_open_device(dev_path);
> +  if (fd == -1) {

nit: Perhaps fd < 0, just to be safe?

> + _eglLog(_EGL_WARNING, "%s() Failed to open DRM device %s",
> + __func__, dev_path);
> + continue;
> +  }
> +
> +  int ret = droid_probe_device(disp, fd, vendor_name);
> +  switch (ret) {
> +  case probe_success:
> + goto success;
> +  case probe_filtered_out:
> + goto allow_fallback;

The 2 lines of code at the "allow_fallback" label could be just moved here.

> +  case probe_error:
> +  case probe_no_driver:

Do we need 2 separate cases for these? Just one "probe_fail" should be enough.

> + goto next;

If we move the fallback handling to "probe_filtered_out" case, we
could remove the "next" label too and simply "break" here.

> +  }
> +
> +allow_fallback:
> +  if (fallback_fd == -1)
> + fallback_fd = fd;
> +next:
> +  if (fallback_fd != fd)
> + close(fd);
> +  fd = -1;
> +  continue;
> +   }
> +
> +success:
> +   closedir(sysdir);
> +
> +   if (fallback_fd < 0 && fd < 0) {
> +  _eglLog(_EGL_WARNING, "Failed to open any DRM device");
> +  return -1;
> +   }
> +
> +   if (fd < 0) {
> +  _eglLog(_EGL_WARNING, "Failed to open desired DRM device, using 
> fallback");
> +  return fallback_fd;
> +   }
> +
> +   close(fallback_fd);
> +   return fd;
> +}

[Leaving context for readability.]

Best regards,
Tomasz
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v3 3/3] egl/android: Add DRM node probing and filtering

[Tomasz Figa]

On Thu, Jun 14, 2018 at 4:14 AM Rob Herring  wrote:
>
> On Wed, Jun 13, 2018 at 12:19 PM, Amit Pundir  wrote:
> > On 13 June 2018 at 20:45, Rob Herring  wrote:
> >>
> >> +Amit and John
> >>
> >> On Sat, Jun 9, 2018 at 11:27 AM, Robert Foss  
> >> wrote:
> >> > This patch both adds support for probing & filtering DRM nodes
> >> > and switches away from using the GRALLOC_MODULE_PERFORM_GET_DRM_FD
> >> > gralloc call.
> >> >
> >> > Currently the filtering is based just on the driver name,
> >> > and the desired name is supplied using the "drm.gpu.vendor_name"
> >> > Android property.
> >>
> >> There's a potential issue with this whole approach and that is
> >> SELinux. With the way SELinux locks down accesses, getting probing
> >> thru device files to work can be a pain. It may be better now than the
> >> prior version because sysfs is not probed. I'll leave it to Amit or
> >> John to comment.
> >
> > Right.. so ICYMI, this patch is already pulled into external/mesa3d
> > project of AOSP and I stumbled upon one such /dev/dri/ access denial
> > on db820c recently.
>
> A prior version of the patch series which accesses sysfs too (via libdrm).
>
> >
> > In AOSP, zygote spawned apps already have access to GPU device nodes
> > in the form of /dev/gpu_device file, but the missing part is the
>
> It's "gpu_device" in terms a a SELinux context, right? Not an actual /dev 
> path?
>
> > open-read access to "/dev/dri/" which need to be allowed explicitly.
>
> Or we need a way to just open a specific device.

How does this work in drm_gralloc (or any other existing gralloc that
implements GRALLOC_MODULE_PERFORM_GET_DRM_FD)? What device node does
it open? I have some loose recollection that it had a property
specifying exact device. I guess we could use that property as the top
level override, bypassing the whole probing logic, if present.

Best regards,
Tomasz
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 0/3] egl/android: Remove dependencies on specific grallocs

[Tomasz Figa]

On Sat, May 26, 2018 at 12:38 AM Rob Herring <r...@kernel.org> wrote:

> On Fri, May 25, 2018 at 9:25 AM, Tomasz Figa <tf...@chromium.org> wrote:
> > On Fri, May 25, 2018 at 10:59 PM Rob Herring <r...@kernel.org> wrote:
> >
> >> On Fri, May 25, 2018 at 4:15 AM, Robert Foss <robert.f...@collabora.com

> > wrote:
> >> >
> >> >
> >> > On 2018-05-25 10:38, Tomasz Figa wrote:
> >> >>
> >> >> On Fri, May 25, 2018 at 5:33 PM Robert Foss <
robert.f...@collabora.com>
> >> >> wrote:
> >> >>
> >> >>> Hey,
> >> >>
> >> >>
> >> >>> On 2018-05-25 02:17, Rob Herring wrote:
> >> >>>>
> >> >>>> On Thu, May 24, 2018 at 6:23 AM, Robert Foss <
> > robert.f...@collabora.com>
> >> >>
> >> >> wrote:
> >> >>>>>
> >> >>>>> Hey,
> >> >>>>>
> >> >>>>> I don't think I've received any feedback on this version yet.
> >> >>>>> If anyone has some time to spare, it would be nice to get it
merged.
> >> >>>>>
> >> >>>>> Just to be clear about the libdrm branch linked in the cover
letter,
> >> >>>>> it is not required. Only for virgl platforms which happens to be
> > what
> >> >>>>> I tested on.
> >> >>>>
> >> >>>>
> >> >>>> virgl will still fallback to using the first render node without
> > those
> >> >>>> libdrm changes, right? If not, I don't think we should apply until
> >> >>>> we're not breaking a platform...
> >> >>
> >> >>
> >> >>> No it will not fall back. I agree that holding off makes more
sense.
> >> >>
> >> >>
> >> >> What's the reason of this problems? Is it because of
drmGetDevices()?
> >> >> Since
> >> >> we don't really use it for anything other than getting the list of
> > render
> >> >> nodes in the system, maybe we could just iterate over any
/dev/renderD*
> >> >> nodes explicitly and avoid introducing new problems?
> >> >
> >> >
> >> > That's exactly the problem, and yes we could 100% solve by iterating
> > over
> >> > /dev/renderD* nodes. I originally assumed we wouldn't want to do
that,
> > but
> >> > rather use the libdrm interfaces.
> >> >
> >> > But for the next spin I could avoid using libdrm, should I?
> >
> >> I don't have an opinion on libdrm really, but I do think we should
> >> fallback to the 1st (only) render node rather than just fail.
> >
> > We do, even with libdrm.
> >
> > AFAICT, the problem with virgl seems to be that drmGetDevices() doesn't
> > include devices on virtio bus in the results, which means that there
likely
> > wouldn't be any render node returned.

> Okay. I still don't get why we search by bus in the first place. Who
> cares what bus the gpu sits on.

We don't search by bus. drmGetDevices() iterates over DRI nodes, queries
them and discards those of which bus type it fails to recognize. I have no
idea why it does so, though.


> Now I have an opinion. We should just iterate over render nodes
> matching by name or use the first node if we don't have a set name.

Yeah, I suggested that too in my previous reply. It doesn't look like
libdrm has any sane helper that could help us.

Best regards,
Tomasz
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 0/3] egl/android: Remove dependencies on specific grallocs

[Tomasz Figa]

On Fri, May 25, 2018 at 10:59 PM Rob Herring <r...@kernel.org> wrote:

> On Fri, May 25, 2018 at 4:15 AM, Robert Foss <robert.f...@collabora.com>
wrote:
> >
> >
> > On 2018-05-25 10:38, Tomasz Figa wrote:
> >>
> >> On Fri, May 25, 2018 at 5:33 PM Robert Foss <robert.f...@collabora.com>
> >> wrote:
> >>
> >>> Hey,
> >>
> >>
> >>> On 2018-05-25 02:17, Rob Herring wrote:
> >>>>
> >>>> On Thu, May 24, 2018 at 6:23 AM, Robert Foss <
robert.f...@collabora.com>
> >>
> >> wrote:
> >>>>>
> >>>>> Hey,
> >>>>>
> >>>>> I don't think I've received any feedback on this version yet.
> >>>>> If anyone has some time to spare, it would be nice to get it merged.
> >>>>>
> >>>>> Just to be clear about the libdrm branch linked in the cover letter,
> >>>>> it is not required. Only for virgl platforms which happens to be
what
> >>>>> I tested on.
> >>>>
> >>>>
> >>>> virgl will still fallback to using the first render node without
those
> >>>> libdrm changes, right? If not, I don't think we should apply until
> >>>> we're not breaking a platform...
> >>
> >>
> >>> No it will not fall back. I agree that holding off makes more sense.
> >>
> >>
> >> What's the reason of this problems? Is it because of drmGetDevices()?
> >> Since
> >> we don't really use it for anything other than getting the list of
render
> >> nodes in the system, maybe we could just iterate over any /dev/renderD*
> >> nodes explicitly and avoid introducing new problems?
> >
> >
> > That's exactly the problem, and yes we could 100% solve by iterating
over
> > /dev/renderD* nodes. I originally assumed we wouldn't want to do that,
but
> > rather use the libdrm interfaces.
> >
> > But for the next spin I could avoid using libdrm, should I?

> I don't have an opinion on libdrm really, but I do think we should
> fallback to the 1st (only) render node rather than just fail.

We do, even with libdrm.

AFAICT, the problem with virgl seems to be that drmGetDevices() doesn't
include devices on virtio bus in the results, which means that there likely
wouldn't be any render node returned.

Best regards,
Tomasz
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 0/3] egl/android: Remove dependencies on specific grallocs

[Tomasz Figa]

On Fri, May 25, 2018 at 5:33 PM Robert Foss 
wrote:

> Hey,

> On 2018-05-25 02:17, Rob Herring wrote:
> > On Thu, May 24, 2018 at 6:23 AM, Robert Foss 
wrote:
> >> Hey,
> >>
> >> I don't think I've received any feedback on this version yet.
> >> If anyone has some time to spare, it would be nice to get it merged.
> >>
> >> Just to be clear about the libdrm branch linked in the cover letter,
> >> it is not required. Only for virgl platforms which happens to be what
> >> I tested on.
> >
> > virgl will still fallback to using the first render node without those
> > libdrm changes, right? If not, I don't think we should apply until
> > we're not breaking a platform...

> No it will not fall back. I agree that holding off makes more sense.

What's the reason of this problems? Is it because of drmGetDevices()? Since
we don't really use it for anything other than getting the list of render
nodes in the system, maybe we could just iterate over any /dev/renderD*
nodes explicitly and avoid introducing new problems?

Best regards,
Tomasz
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 0/3] egl/android: Remove dependencies on specific grallocs

[Tomasz Figa]

Hi Rob,

On Thu, May 24, 2018 at 8:23 PM Robert Foss 
wrote:

> Hey,

> I don't think I've received any feedback on this version yet.
> If anyone has some time to spare, it would be nice to get it merged.

Really sorry for taking so long to review. Posted my comments just now.

Best regards,
Tomasz


> Just to be clear about the libdrm branch linked in the cover letter,
> it is not required. Only for virgl platforms which happens to be what
> I tested on.


> Rob.

> On 2018-05-11 15:47, Robert Foss wrote:
> > This series replaces the dependency on
> > GRALLOC_MODULE_PERFORM_GET_DRM_FD with DRM node
> > probing and disables the support for drm_gralloc.
> >
> > The series has been tested on Qemu+AOSP, where a
> > virtio gpu was successfully probed for and
> > opened.
> >
> > This however required adding support in libdrm
> > for virtio gpus, and virtio buses. An initial
> > patch for this can be found here:
> >
> > https://gitlab.collabora.com/robertfoss/libdrm/tree/virtio_rfc
> >
> > Changes since v1:
> >   - Added fix for build issue
> >   - Do not rely on libdrm for probing
> >   - Distinguish between errors and when no drm devices are found
> >
> > Changes since RFC:
> >   - Rebased work on the libdrm patch [2].
> >   - Included patch from Rob Herring disabling drm_gralloc/flink
> > support by default.
> >   - Added device handler driver probing.
> >
> >
> > Rob Herring (1):
> >egl/android: #ifdef out flink name support
> >
> > Robert Foss (2):
> >gallium/util: Fix build error due to cast to different size
> >egl/android: Add DRM node probing and filtering
> >
> >   src/egl/Android.mk|   6 +-
> >   src/egl/drivers/dri2/egl_dri2.h   |   2 -
> >   src/egl/drivers/dri2/platform_android.c   | 206 ++
> >   .../auxiliary/util/u_debug_stack_android.cpp  |   4 +-
> >   4 files changed, 174 insertions(+), 44 deletions(-)
> >
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/3] egl/android: Add DRM node probing and filtering

[Tomasz Figa]

Hi Rob,

Finally got to review this. Please see my comments inline.

On Fri, May 11, 2018 at 10:48 PM Robert Foss 
wrote:
[snip]
> +EGLBoolean
> +droid_load_driver(_EGLDisplay *disp)

Since this is not EGL-facing, I'd personally use bool.

> +{
> +   struct dri2_egl_display *dri2_dpy = disp->DriverData;
> +   const char *err;
> +
> +   dri2_dpy->driver_name = loader_get_driver_for_fd(dri2_dpy->fd);
> +   if (dri2_dpy->driver_name == NULL) {
> +  err = "DRI2: failed to get driver name";
> +  goto error;

It shouldn't be an error if there is no driver for given render node. We
should just skip it and try next one, which I believe would be achieved by
just returning false here.

> +   }
> +
> +   dri2_dpy->is_render_node = drmGetNodeTypeFromFd(dri2_dpy->fd) ==
DRM_NODE_RENDER;
> +
> +   if (!dri2_dpy->is_render_node) {
> +   #ifdef HAVE_DRM_GRALLOC
> +   /* Handle control nodes using __DRI_DRI2_LOADER extension and GEM
names
> +* for backwards compatibility with drm_gralloc. (Do not use on
new
> +* systems.) */
> +   dri2_dpy->loader_extensions = droid_dri2_loader_extensions;
> +   if (!dri2_load_driver(disp)) {
> +  err = "DRI2: failed to load driver";
> +  goto error;
> +   }
> +   #else
> +   err = "DRI2: handle is not for a render node";
> +   goto error;
> +   #endif
> +   } else {
> +   dri2_dpy->loader_extensions = droid_image_loader_extensions;
> +   if (!dri2_load_driver_dri3(disp)) {
> +  err = "DRI3: failed to load driver";
> +  goto error;
> +   }
> +}
> +
> +   return EGL_TRUE;
> +
> +error:
> +   free(dri2_dpy->driver_name);
> +   dri2_dpy->driver_name = NULL;
> +   return _eglError(EGL_NOT_INITIALIZED, err);

Hmm, if we signal EGL error here, we should break the probing loop and just
bail out. This would suggest that a boolean is not the right type for this
function to return. Perhaps something like negative error, 0 for skip and 1
for success would make sense?

Also, how does it play with the _eglError() called from the error path of
dri2_initialize_android()?

> +}
> +
> +static int
> +droid_probe_driver(_EGLDisplay *disp, int fd)
> +{
> +   struct dri2_egl_display *dri2_dpy = disp->DriverData;
> +   dri2_dpy->fd = fd;
> +
> +   if (!droid_load_driver(disp))
> +  return false;

Given my other suggestion about distinguishing failure, render node skip
and success, I think it should be more like this:

int ret = droid_load_driver(disp);
if (ret <= 0)
   return ret;

Or actually, maybe we don't really need to go as far as loading the driver.
I'd say it should be enough to just check if we have a driver for the
device by looking at what loader_get_driver_for_fd() returns. (In that
case, we can ignore my comment about returning error on
loader_get_driver_for_fd() failure in droid_load_driver(), since the
skipping would be handling only here.)

> +
> +   /* Since this probe can succeed, but another filter may fail,

What another filter could fail? I can see the vendor name being checked
before calling this function.

The free() below is actually needed, just the comment is off. We need to
free the name to be able to probe remaining nodes, without leaking the name.

> +  this string needs to be deallocated either way.
> +  Once an FD has been found, this string will be set a second time.
*/
> +   free(dri2_dpy->driver_name);

Don't we also need to unload the driver?

> +   dri2_dpy->driver_name = NULL;
> +   return true;

To match the change above:

return 1;

> +}
> +
> +static int
> +droid_probe_device(_EGLDisplay *disp, int fd, drmDevicePtr dev, char
*vendor)
> +{
> +   drmVersionPtr ver = drmGetVersion(fd);
> +   if (!ver)
> +   goto fail;

Something wrong with indentation here.

> +
> +   size_t vendor_len = strlen(vendor);
> +   if (vendor_len != 0 && strncmp(vendor, ver->name, vendor_len))
> +  goto fail;

Maybe it's just me, but I don't see any point in using strncmp() if the
length argument is obtained by calling strlen() first. Especially if the
strlen() call is on a string that comes from some external code
(property_get()).

Perhaps we could just call strncmp() with PROPERTY_VALUE_MAX? This would
actually play nice with my other comment about using NULL for vendor
string, if the property is not present.

Also nit: The label could be named in a more meaningful way, e.g.
err_free_version.

> +
> +   if (!droid_probe_driver(disp, fd))
> +  goto fail;
> +
> +   drmFreeVersion(ver);
> +   return true;
> +
> +fail:
> +   drmFreeVersion(ver);
> +   return false;

Given my other suggestion about distinguishing failure, render node skip
and success, I think it should be more like this:

ret = droid_probe_driver(disp, fd);
err_free_version:
drmFreeVersion(ver);
return ret;

> +}
> +
> +static int
> +droid_open_device(_EGLDisplay *disp)
> +{
> +   const int MAX_DRM_DEVICES = 32;
> +   int prop_set, num_devices, 

Re: [Mesa-dev] [PATCH 2/3] egl/android: #ifdef out flink name support

[Tomasz Figa]

Hi Rob,

Sorry for late review. Had some really busy time.

On Fri, May 11, 2018 at 10:48 PM Robert Foss 
wrote:
[snip]
> @@ -1230,20 +1256,26 @@ dri2_initialize_android(_EGLDriver *drv,
_EGLDisplay *disp)

>  dri2_dpy->is_render_node = drmGetNodeTypeFromFd(dri2_dpy->fd) ==
DRM_NODE_RENDER;

> -   /* render nodes cannot use Gem names, and thus do not support
> -* the __DRI_DRI2_LOADER extension */
>  if (!dri2_dpy->is_render_node) {
> -  dri2_dpy->loader_extensions = droid_dri2_loader_extensions;
> -  if (!dri2_load_driver(disp)) {
> - err = "DRI2: failed to load driver";
> - goto cleanup;
> -  }
> +   #ifdef HAVE_DRM_GRALLOC
> +   /* Handle control nodes using __DRI_DRI2_LOADER extension and GEM
names
> +* for backwards compatibility with drm_gralloc. (Do not use on
new
> +* systems.) */
> +   dri2_dpy->loader_extensions = droid_dri2_loader_extensions;
> +   if (!dri2_load_driver(disp)) {
> +  err = "DRI2: failed to load driver";
> +  goto cleanup;
> +   }
> +   #else
> +   err = "DRI2: handle is not for a render node";
> +   goto cleanup;
> +   #endif
>  } else {
> -  dri2_dpy->loader_extensions = droid_image_loader_extensions;
> -  if (!dri2_load_driver_dri3(disp)) {
> - err = "DRI3: failed to load driver";
> - goto cleanup;
> -  }
> +   dri2_dpy->loader_extensions = droid_image_loader_extensions;
> +   if (!dri2_load_driver_dri3(disp)) {
> +  err = "DRI3: failed to load driver";
> +  goto cleanup;
> +   }

Is it just me or there is something wrong with indentation here?

Besides this nit, the patch looks good to me, so feel free to add my
Reviewed-by after fixing it up.

Best regards,
Tomasz
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v1 1/2] egl/android: #ifdef out flink name support

[Tomasz Figa]

On Tue, May 1, 2018 at 11:20 AM Rob Herring  wrote:

> On Fri, Apr 27, 2018 at 6:57 AM, Robert Foss 
wrote:
> > From: Rob Herring 
[snip]
> > @@ -1228,20 +1254,31 @@ dri2_initialize_android(_EGLDriver *drv,
_EGLDisplay *disp)
> >
> > dri2_dpy->is_render_node = drmGetNodeTypeFromFd(dri2_dpy->fd) ==
DRM_NODE_RENDER;
> >
> > -   /* render nodes cannot use Gem names, and thus do not support
> > -* the __DRI_DRI2_LOADER extension */
> > if (!dri2_dpy->is_render_node) {
> > +#ifdef HAVE_DRM_GRALLOC
> >dri2_dpy->loader_extensions = droid_dri2_loader_extensions;
> >if (!dri2_load_driver(disp)) {
> >   err = "DRI2: failed to load driver";
> >   goto cleanup;
> >}
> > } else {
> > +  /* render nodes cannot use Gem names, and thus do not support
> > +   * the __DRI_DRI2_LOADER extension */

I think we can replace this comment with something properly reflecting the
bad nature of this code. See below.

> >dri2_dpy->loader_extensions = droid_image_loader_extensions;
> >if (!dri2_load_driver_dri3(disp)) {
> >   err = "DRI3: failed to load driver";
> >   goto cleanup;
> >}
> > +#else
> > +  err = "DRI2: handle is not for a render node";
> > +  goto cleanup;
> > +   }
> > +
> > +   dri2_dpy->loader_extensions = droid_image_loader_extensions;
> > +   if (!dri2_load_driver_dri3(disp)) {

> Do we really need this twice?

Yeah, I think we could do with something like below:

if (!dri2_dpy->is_render_node) {
#ifdef HAVE_DRM_GRALLOC
/* Handle control nodes using __DRI_DRI2_LOADER extension and GEM names
 * for backwards compatibility with drm_gralloc. (Do not use on new
systems.) */
dri2_dpy->loader_extensions = droid_dri2_loader_extensions;
if (!dri2_load_driver(disp)) {
   err = "DRI2: failed to load driver";
   goto cleanup;
}
#else
err = "DRI2: handle is not for a render node";
goto cleanup;
#endif
} else {
dri2_dpy->loader_extensions = droid_image_loader_extensions;
if (!dri2_load_driver_dri3(disp)) {
   err = "DRI3: failed to load driver";
   goto cleanup;
}
}

Best regards,
Tomasz
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] egl/android: prevent deadlock in droid_query_buffer_age

[Tomasz Figa]

Hi Min,

On Sat, Apr 28, 2018 at 11:56 AM He, Min <min...@intel.com> wrote:

> Hi, Tomasz

> On 4/27/2018 5:01 PM, Tomasz Figa wrote:
> > Hi Min,
> >
> > On Fri, Apr 27, 2018 at 11:36 AM Min He <min...@intel.com> wrote:
> >
> >> To avoid blocking other EGL calls, release the display mutex before
> >> calling update_buffers(), which will call
droid_window_dequeue_buffer().
> >> The lock appears like below:
> >> 1. Consumer thread: updateTexImage() -> updateAndReleaseLocked() ->
> >> syncForReleaseLocked() -> eglDupNativeFenceFDANDROID() ->
> >> _eglLockDisplay() -> waiting for the dpy lock.
> >> 2. Producer thread: eglQuerySurface() (acquired dpy lock) ->
> >> droid_query_buffer_age() -> update_buffers() ->
> >> android::Surface::dequeueBuffer() ->
> >> android::BufferQueueProducer::waitForFreeSlotThenRelock()
> >> This patch fixes some failure cases in android graphics cts test.
> >> Signed-off-by: Min He <min...@intel.com>
> >> Signed-off-by: Chenglei Ren <chenglei@intel.com>
> >> Tested-by: Chenglei Ren <chenglei@intel.com>
> >> ---
> >>src/egl/drivers/dri2/platform_android.c | 7 +++
> >>1 file changed, 7 insertions(+)
> >> diff --git a/src/egl/drivers/dri2/platform_android.c
> > b/src/egl/drivers/dri2/platform_android.c
> >> index 7f1a496..c6f895a 100644
> >> --- a/src/egl/drivers/dri2/platform_android.c
> >> +++ b/src/egl/drivers/dri2/platform_android.c
> >> @@ -610,11 +610,18 @@ droid_query_buffer_age(_EGLDriver *drv,
> >>{
> >>   struct dri2_egl_surface *dri2_surf = dri2_egl_surface(surface);
> >> +   /* To avoid blocking other EGL calls, release the display mutex
before
> >> +* we enter droid_window_dequeue_buffer() and re-acquire the mutex
> > upon
> >> +* return.
> >> +*/
> >> +   mtx_unlock(>Mutex);
> >>   if (update_buffers(dri2_surf) < 0) {
> >>  _eglError(EGL_BAD_ALLOC, "droid_query_buffer_age");
> >> +  mtx_lock(>Mutex);
> >>  return -1;
> >>   }
> >> +   mtx_lock(>Mutex);
> > With droid_window_enqueue_buffer(), we put the unlock just around
> > window->queueBuffer(). I'd say that at least for consistency, we should
do
> > similar thing inside droid_window_dequeue_buffer(). Moreover,
> > droid_window_dequeue_buffer() actually does much more inside than
> > droid_window_enqueue_buffer(), so we might actually want to have the
mutex
> > held there, when accessing internal data.
> I don't see the disp variable passed to update_buffer(), will it be used
> inside of later
> calls to droid_window_dequeue_buffer() ? If not, why can't we release
> the lock here and
> then capture it later? I'm new to the mesa, so please correct me if I
> made any mistakes.

It's not obvious for me either. Right now disp->Mutex works like a global
lock and it serializes any EGL calls between threads. Even though the code
is not accessing members of disp itself, current semantics effectively
grant it exclusive access to any other EGL data structures as well. If we
relax this too much, some assumptions might stop holding and we could
introduce races.

As for droid_window_dequeue_buffer(), I think we actually had a case with a
non-Intel driver that required similar workaround as
droid_window_enqueue_buffer(). I think we changed how the driver behaves
instead, but I'd say that holding a global EGL lock when calling back into
native window system is a bad idea in general and shouldn't be worked
around by drivers.

Given the above, I'd lean towards having the mutex unlocked just for the
time of window->dequeueBuffer() call.

Ultimately, we should probably revisit how locking is done in Mesa EGL,
because it feels too course grained (and too strict) compared to other
implementations.

Best regards,
Tomasz
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] egl/android: prevent deadlock in droid_query_buffer_age

[Tomasz Figa]

Hi Min,

On Fri, Apr 27, 2018 at 11:36 AM Min He  wrote:

> To avoid blocking other EGL calls, release the display mutex before
> calling update_buffers(), which will call droid_window_dequeue_buffer().
> The lock appears like below:
> 1. Consumer thread: updateTexImage() -> updateAndReleaseLocked() ->
> syncForReleaseLocked() -> eglDupNativeFenceFDANDROID() ->
> _eglLockDisplay() -> waiting for the dpy lock.

> 2. Producer thread: eglQuerySurface() (acquired dpy lock) ->
> droid_query_buffer_age() -> update_buffers() ->
> android::Surface::dequeueBuffer() ->
> android::BufferQueueProducer::waitForFreeSlotThenRelock()

> This patch fixes some failure cases in android graphics cts test.

> Signed-off-by: Min He 
> Signed-off-by: Chenglei Ren 
> Tested-by: Chenglei Ren 
> ---
>   src/egl/drivers/dri2/platform_android.c | 7 +++
>   1 file changed, 7 insertions(+)

> diff --git a/src/egl/drivers/dri2/platform_android.c
b/src/egl/drivers/dri2/platform_android.c
> index 7f1a496..c6f895a 100644
> --- a/src/egl/drivers/dri2/platform_android.c
> +++ b/src/egl/drivers/dri2/platform_android.c
> @@ -610,11 +610,18 @@ droid_query_buffer_age(_EGLDriver *drv,
>   {
>  struct dri2_egl_surface *dri2_surf = dri2_egl_surface(surface);

> +   /* To avoid blocking other EGL calls, release the display mutex before
> +* we enter droid_window_dequeue_buffer() and re-acquire the mutex
upon
> +* return.
> +*/
> +   mtx_unlock(>Mutex);
>  if (update_buffers(dri2_surf) < 0) {
> _eglError(EGL_BAD_ALLOC, "droid_query_buffer_age");
> +  mtx_lock(>Mutex);
> return -1;
>  }

> +   mtx_lock(>Mutex);

With droid_window_enqueue_buffer(), we put the unlock just around
window->queueBuffer(). I'd say that at least for consistency, we should do
similar thing inside droid_window_dequeue_buffer(). Moreover,
droid_window_dequeue_buffer() actually does much more inside than
droid_window_enqueue_buffer(), so we might actually want to have the mutex
held there, when accessing internal data.

Best regards,
Tomasz
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] egl/android: remove flink name support

[Tomasz Figa]

Hi Rob,
On Fri, Apr 27, 2018 at 12:43 PM Chih-Wei Huang 
wrote:

> 2018-04-27 2:19 GMT+08:00 Robert Foss :
> >
> > I've spent some time today preparing a #ifdef version of what robher
> > submitted.
> >
> > It's fine, but there is no way automatically enable the HAVE_DRM_GRALLOC
> > #define through the build tools. So a small simple patch adding the
shared
> > library dependency, and adding the -DHAVE_DRM_GRALLOC cflag is needed.

> I can add BOARD_USES_DRM_GRALLOC=true
> (like BOARD_USES_DRM_HWCOMPOSER=true)
> in our BoardConfig.mk.
> Then you can add these in Android.mk of mesa:

> ifeq ($(BOARD_USES_DRM_GRALLOC),true)
> LOCAL_CFLAGS += -DHAVE_DRM_GRALLOC
> endif

+1 to as Chih-Wei says for Android.mk.

For autotools or meson builds we don't need to define it at all, so no need
for any changes.

Best regards,
Tomasz
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] egl/android: remove flink name support

[Tomasz Figa]

On Tue, Apr 24, 2018 at 4:26 PM Robert Foss 
wrote:

> Hey Chih-Wei,

> On 04/23/2018 04:17 AM, Chih-Wei Huang wrote:
> > What's the impact to drm_gralloc?

> I'm not terribly familiar with drm_gralloc, but as far as I understand it
> depends on flink name support at the moment.

> The overarching idea here is to make mesa gralloc independent, but also
at the
> same time provide some infrastructure for making the grallocs able to be
separate.

> I'm not sure what the best way to keep drm_gralloc support alive and at
the same
> time make mesa gralloc independent is.

Right now we're punishing users of the proper DMA-buf based API by making
them carry local patches to remove the dependencies on drm_gralloc.
Reversing this and putting the burden on users of deprecated (and insecure)
flink API might finally encourage them to fix their systems.

Alternatively, rather than removing, we could just put this behind a macro
that is unset by default and one would need to explicitly set
BOARD_something or pass an argument to ./configure (probably not even
needed, as Chrome OS might be the only user) to enable it.

Best regards,
Tomasz



> Rob.

> >
> >
> > 2018-04-20 5:09 GMT+08:00 Rob Herring :
> >> Maintaining both flink names and prime fd support which are provided by
> >> 2 different gralloc implementations is problematic because we have a
> >> dependency on a specific gralloc implementation header.
> >>
> >> This mostly removes the dependency on the gralloc implementation and
> >> headers. The dependency on GRALLOC_MODULE_PERFORM_GET_DRM_FD remains
for
> >> now, but the definition is added locally to remove the header
> >> dependency.
> >>
> >> Signed-off-by: Rob Herring 
> >> ---
> >> With this plus Robert's probing patch, we remove any gralloc
> >> implementation dependency (other than it has to be a pre 1.0
> >> implementation...).
> >>
> >>   src/egl/drivers/dri2/egl_dri2.h |   1 -
> >>   src/egl/drivers/dri2/platform_android.c | 172

> >>   2 files changed, 17 insertions(+), 156 deletions(-)
> >>
> >> diff --git a/src/egl/drivers/dri2/egl_dri2.h
b/src/egl/drivers/dri2/egl_dri2.h
> >> index cc76c73eab2f..d9e1f466fbeb 100644
> >> --- a/src/egl/drivers/dri2/egl_dri2.h
> >> +++ b/src/egl/drivers/dri2/egl_dri2.h
> >> @@ -61,7 +61,6 @@ struct zwp_linux_dmabuf_v1;
> >>
> >>   #include 
> >>   #include 
> >> -#include 
> >>
> >>   #endif /* HAVE_ANDROID_PLATFORM */
> >>
> >> diff --git a/src/egl/drivers/dri2/platform_android.c
b/src/egl/drivers/dri2/platform_android.c
> >> index 4f25cb746915..68c85d7f99fa 100644
> >> --- a/src/egl/drivers/dri2/platform_android.c
> >> +++ b/src/egl/drivers/dri2/platform_android.c
> >> @@ -37,7 +37,6 @@
> >>   #include "loader.h"
> >>   #include "egl_dri2.h"
> >>   #include "egl_dri2_fallbacks.h"
> >> -#include "gralloc_drm.h"
> >>
> >>   #define ALIGN(val, align)  (((val) + (align) - 1) & ~((align) -
1))
> >>
> >> @@ -164,12 +163,6 @@ get_native_buffer_fd(struct ANativeWindowBuffer
*buf)
> >>  return (handle && handle->numFds) ? handle->data[0] : -1;
> >>   }
> >>
> >> -static int
> >> -get_native_buffer_name(struct ANativeWindowBuffer *buf)
> >> -{
> >> -   return gralloc_drm_get_gem_handle(buf->handle);
> >> -}
> >> -
> >>   static EGLBoolean
> >>   droid_window_dequeue_buffer(struct dri2_egl_surface *dri2_surf)
> >>   {
> >> @@ -822,50 +815,6 @@ droid_create_image_from_prime_fd(_EGLDisplay
*disp, _EGLContext *ctx,
> >>  return dri2_create_image_dma_buf(disp, ctx, NULL, attr_list);
> >>   }
> >>
> >> -static _EGLImage *
> >> -droid_create_image_from_name(_EGLDisplay *disp, _EGLContext *ctx,
> >> - struct ANativeWindowBuffer *buf)
> >> -{
> >> -   struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
> >> -   struct dri2_egl_image *dri2_img;
> >> -   int name;
> >> -   int format;
> >> -
> >> -   name = get_native_buffer_name(buf);
> >> -   if (!name) {
> >> -  _eglError(EGL_BAD_PARAMETER, "eglCreateEGLImageKHR");
> >> -  return NULL;
> >> -   }
> >> -
> >> -   format = get_format(buf->format);
> >> -   if (format == -1)
> >> -   return NULL;
> >> -
> >> -   dri2_img = calloc(1, sizeof(*dri2_img));
> >> -   if (!dri2_img) {
> >> -  _eglError(EGL_BAD_ALLOC, "droid_create_image_mesa_drm");
> >> -  return NULL;
> >> -   }
> >> -
> >> -   _eglInitImage(_img->base, disp);
> >> -
> >> -   dri2_img->dri_image =
> >> -  dri2_dpy->image->createImageFromName(dri2_dpy->dri_screen,
> >> -  buf->width,
> >> -  buf->height,
> >> -  format,
> >> -  name,
> >> -  buf->stride,
> >> -  dri2_img);
> >> -   if (!dri2_img->dri_image) {
> >> -  free(dri2_img);
> >> -  

Re: [Mesa-dev] [RFC] egl/android: Add DRM node probing and filtering

[Tomasz Figa]

On Fri, Apr 20, 2018 at 4:17 PM Robert Foss <robert.f...@collabora.com>
wrote:



> On 04/20/2018 06:41 AM, Tomasz Figa wrote:
> > Hi Rob,
> >
> > On Thu, Apr 19, 2018 at 1:03 AM Robert Foss <robert.f...@collabora.com>
> > wrote:
> >
> >> This patch both adds support for probing & filtering DRM nodes
> >> and switches away from using the GRALLOC_MODULE_PERFORM_GET_DRM_FD
> >> gralloc call.
> >
> >> Currently the filtering is based just on the driver name,
> >> and the desired name is supplied using the "drm.gpu.vendor_name"
> >> Android property.
> >
> >> The filtering itself is done using the newly introduced
> >> libdrm drmHandleMatch() call.
> >
> >> Signed-off-by: Robert Foss <robert.f...@collabora.com>
> >> ---
> >
> >> This patch is based on[1], which contains a new libdrm function,
> >> called drmHandleMatch(), which allows for matching an opened
> >> drm node handle against some desired properties.
> >
> >> A choice that was made for this patch was to add support for
> >> falling back to to DRM nodes that have failed the filtering,
> >> if no node passes the filter.
> >> If this wouldn't be useful to anyone, I would suggest ripping it
> >> out since it is a little bit ugly
> >
> > This is actually not only useful, but quite of a requirement for Chrome
OS,
> > where we use the same Android image for devices with different GPU
vendors.
> > (Technically we could hack it up by injecting some per-board properties,
> > but it would be painful from maintenance point of view.)

> Ack, I'll remove the fallback.

Sorry, I mean a fallback is needed. :) (+/- the missing driver check)


> >
> > But actually, the way it is implemented in this patch will not work. The
> > code assumes that the first DRM node that could be opened
> > (loader_open_device()) is fine, but if you look at what we do in our
> > Chromium patch [2], it is actually necessary to check if Mesa includes a
> > driver for it (loader_get_driver_for_fd()).
> >
> > [2]
> >
https://chromium-review.googlesource.com/c/chromiumos/third_party/mesa/+/780797

> Ack, I'll add a check for a driver existing.

SGTM.

Best regards,
Tomasz
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] egl/android: remove flink name support

[Tomasz Figa]

Hi Rob,

On Fri, Apr 20, 2018 at 6:09 AM Rob Herring <r...@kernel.org> wrote:

> Maintaining both flink names and prime fd support which are provided by
> 2 different gralloc implementations is problematic because we have a
> dependency on a specific gralloc implementation header.

> This mostly removes the dependency on the gralloc implementation and
> headers. The dependency on GRALLOC_MODULE_PERFORM_GET_DRM_FD remains for
> now, but the definition is added locally to remove the header
> dependency.

> Signed-off-by: Rob Herring <r...@kernel.org>
> ---
> With this plus Robert's probing patch, we remove any gralloc
> implementation dependency (other than it has to be a pre 1.0
> implementation...).

Big

Acked-by: Tomasz Figa <tf...@chromium.org>

from me. +/- 1 nit inline

This relic of the past should have disappeared long ago, together with all
the problems it brings. :)

[snip]
> @@ -1216,17 +1081,14 @@ dri2_initialize_android(_EGLDriver *drv,
_EGLDisplay *disp)
>  /* render nodes cannot use Gem names, and thus do not support
>   * the __DRI_DRI2_LOADER extension */
>  if (!dri2_dpy->is_render_node) {
> -  dri2_dpy->loader_extensions = droid_dri2_loader_extensions;
> -  if (!dri2_load_driver(disp)) {
> - err = "DRI2: failed to load driver";
> - goto cleanup;
> -  }
> -   } else {
> -  dri2_dpy->loader_extensions = droid_image_loader_extensions;
> -  if (!dri2_load_driver_dri3(disp)) {
> - err = "DRI3: failed to load driver";
> - goto cleanup;
> -  }
> +  err = "DRI2: driver is not a render node";

Perhaps "device" or "handle" rather than "driver"?

Best regards,
Tomasz
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC] egl/android: Add DRM node probing and filtering

[Tomasz Figa]

Hi Rob,

On Thu, Apr 19, 2018 at 1:03 AM Robert Foss 
wrote:

> This patch both adds support for probing & filtering DRM nodes
> and switches away from using the GRALLOC_MODULE_PERFORM_GET_DRM_FD
> gralloc call.

> Currently the filtering is based just on the driver name,
> and the desired name is supplied using the "drm.gpu.vendor_name"
> Android property.

> The filtering itself is done using the newly introduced
> libdrm drmHandleMatch() call.

> Signed-off-by: Robert Foss 
> ---

> This patch is based on[1], which contains a new libdrm function,
> called drmHandleMatch(), which allows for matching an opened
> drm node handle against some desired properties.

> A choice that was made for this patch was to add support for
> falling back to to DRM nodes that have failed the filtering,
> if no node passes the filter.
> If this wouldn't be useful to anyone, I would suggest ripping it
> out since it is a little bit ugly

This is actually not only useful, but quite of a requirement for Chrome OS,
where we use the same Android image for devices with different GPU vendors.
(Technically we could hack it up by injecting some per-board properties,
but it would be painful from maintenance point of view.)

But actually, the way it is implemented in this patch will not work. The
code assumes that the first DRM node that could be opened
(loader_open_device()) is fine, but if you look at what we do in our
Chromium patch [2], it is actually necessary to check if Mesa includes a
driver for it (loader_get_driver_for_fd()).

[2]
https://chromium-review.googlesource.com/c/chromiumos/third_party/mesa/+/780797



> [1] https://www.spinics.net/lists/dri-devel/msg172497.html


>   src/egl/drivers/dri2/platform_android.c | 72
-
>   1 file changed, 62 insertions(+), 10 deletions(-)

> diff --git a/src/egl/drivers/dri2/platform_android.c
b/src/egl/drivers/dri2/platform_android.c
> index 7f1a496ea24..0b082fe5dcc 100644
> --- a/src/egl/drivers/dri2/platform_android.c
> +++ b/src/egl/drivers/dri2/platform_android.c
> @@ -27,6 +27,7 @@
>* DEALINGS IN THE SOFTWARE.
>*/

> +#include 
>   #include 
>   #include 
>   #include 
> @@ -1117,18 +1118,69 @@ droid_add_configs_for_visuals(_EGLDriver *drv,
_EGLDisplay *dpy)
>   static int
>   droid_open_device(struct dri2_egl_display *dri2_dpy)
>   {
> -   int fd = -1, err = -EINVAL;
> -
> -   if (dri2_dpy->gralloc->perform)
> - err = dri2_dpy->gralloc->perform(dri2_dpy->gralloc,
> -
  GRALLOC_MODULE_PERFORM_GET_DRM_FD,
> -  );
> -   if (err || fd < 0) {
> -  _eglLog(_EGL_WARNING, "fail to get drm fd");
> -  fd = -1;
> +   int prop_set, num_devices, ret;
> +   const int node_type = DRM_NODE_RENDER;
> +   int fd = -1, fallback_fd = -1;
> +
> +   const int MAX_DRM_DEVICES = 32;
> +   char vendor_name[PROPERTY_VALUE_MAX];
> +   prop_set = property_get("drm.gpu.vendor_name", vendor_name, NULL);
> +   drmVersion ver_filter;
> +   ver_filter.name = vendor_name;
> +
> +   drmDevicePtr devices[MAX_DRM_DEVICES];
> +   num_devices = drmGetDevices2(0, devices, MAX_DRM_DEVICES);
> +   if (num_devices < 0) {
> +  _eglLog(_EGL_WARNING, "Failed to find any DRM devices");
> +  return -1;
> +   }
> +
> +   for (int i = 0; i < num_devices; i++) {
> +  /* Filter out DRM_NODE_ types we aren't interested in */
> +  if (!(devices[i]->available_nodes & (1 << node_type))) {
> + continue;
> +  }
> +
> +  /* Open DRM node FD */
> +  fd = loader_open_device(devices[i]->nodes[node_type]);
> +  if (fd == -1 && errno == EINVAL) {
> + _eglLog(_EGL_WARNING, "%s()  node #%d failed to open",
__func__, i);
> + continue;
> +  }

What should happen if (fd == -1 && errno != EINVAL)? I don't think we
should run the code below in such case.

> +
> +  /* See if FD matches the driver vendor we want */
> +  if (prop_set && !drmHandleMatch(fd, _filter, NULL)){
> + _eglLog(_EGL_WARNING, "%s()  node #%d  FD=%d does not match
filter", __func__, i , fd);

How about printing the actual node (i.e. devices[i]->nodes[node_type]),
rather than index in devices array?

Also, should it be _EGL_DEBUG? I'd expect it to be a normal event, which
should not concern the user.

> + goto next;
> +  }
> +
> +  /* Successfully found matching FD */
> +  close(fallback_fd);
> +  fallback_fd = -1;
> +  break;
> +
> +next:
> +  if (fallback_fd == -1) {
> + fallback_fd = fd;
> + fd = -1;
> +  } else {
> + close(fd);
> + fd = -1;
> +  }
> +  continue;
> +   }

How about simplifying the code a bit:

+   for (int i = 0; i < num_devices; i++) {
+  /* Filter out DRM_NODE_ types we aren't interested in */
+  if (!(devices[i]->available_nodes & (1 << node_type))) {
+ continue;
+  }
+
+  /* Open DRM node FD */
+  fd = 

Re: [Mesa-dev] Removing GRALLOC_MODULE_PERFORM_GET_DRM_FD

[Tomasz Figa]

On Mon, Mar 26, 2018 at 9:45 PM, Robert Foss <robert.f...@collabora.com> wrote:
> Hey,
>
> On 03/23/2018 06:21 PM, Emil Velikov wrote:
>>
>> On 23 March 2018 at 16:20, Tomasz Figa <tf...@chromium.org> wrote:
>>>
>>> On Sat, Mar 24, 2018 at 12:55 AM, Emil Velikov <emil.l.veli...@gmail.com>
>>> wrote:
>>>>
>>>> On 23 March 2018 at 13:15, Tomasz Figa <tf...@chromium.org> wrote:
>>>>
>>>>>
>>>>> Perhaps we could try to use drmOpenWithType() [2]. We could have one
>>>>> property that would be passed as "name" argument and another property
>>>>> for "busid" argument. I assume "type" would be always RENDER?
>>>>>
>>>> I would strongly encourage against using the drmOpen* API, it's a DRI1
>>>> remnant.
>>>> It might work in a particular instance, but has a number of serious
>>>> flaws. Some highlights:
>>>>   - using busid works only with PCI devices
>>>>   - open() w/o O_CLOEXEC
>>>>   - when build w/o udev - it creates a node: mkdir, chown(root), chmod,
>>>> mknod
>>>>   - calls back into Xserver/DDX module
>>>>   - last but no least - borderline hacks with massive documentation [1]
>>>> to keep this running.
>>>
>>>
>>> I wasn't aware of that. Thanks for pointing this out.
>>>
>>> Still, I think matching by name and/or bus ID would make sense,
>>> wouldn't it? Perhaps Mesa already has some helpers for that?
>>>
>> Indeed it does make sense. AFAICT there's no such helper - yet no
>> objections to adding one ;-)
>
>
> So, I guess having one would be helpful.
> Where should it live, and what should it be built ontop of?

There is some code of similar purpose in src/loader/loader.c, e.g.
loader_open_device(). Emil, does it sound like a reasonable place?

Best regards,
Tomasz
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Removing GRALLOC_MODULE_PERFORM_GET_DRM_FD

[Tomasz Figa]

On Sat, Mar 24, 2018 at 12:55 AM, Emil Velikov <emil.l.veli...@gmail.com> wrote:
> On 23 March 2018 at 13:15, Tomasz Figa <tf...@chromium.org> wrote:
>
>>
>> Perhaps we could try to use drmOpenWithType() [2]. We could have one
>> property that would be passed as "name" argument and another property
>> for "busid" argument. I assume "type" would be always RENDER?
>>
> I would strongly encourage against using the drmOpen* API, it's a DRI1 
> remnant.
> It might work in a particular instance, but has a number of serious
> flaws. Some highlights:
>  - using busid works only with PCI devices
>  - open() w/o O_CLOEXEC
>  - when build w/o udev - it creates a node: mkdir, chown(root), chmod, mknod
>  - calls back into Xserver/DDX module
>  - last but no least - borderline hacks with massive documentation [1]
> to keep this running.

I wasn't aware of that. Thanks for pointing this out.

Still, I think matching by name and/or bus ID would make sense,
wouldn't it? Perhaps Mesa already has some helpers for that?

Best regards,
Tomasz
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v1 0/7] Implement commont gralloc_handle_t in libdrm

[Tomasz Figa]

On Fri, Mar 23, 2018 at 10:15 PM, Stefan Schake <stsch...@gmail.com> wrote:
> On Fri, Mar 23, 2018 at 1:02 PM, Tomasz Figa <tf...@chromium.org> wrote:
>> On Fri, Mar 23, 2018 at 8:52 PM, Robert Foss <robert.f...@collabora.com> 
>> wrote:
>>> Hey Chih-Wei,
>>>
>>>
>>> On 03/23/2018 03:43 AM, Chih-Wei Huang wrote:
>>>>
>>>> 2018-03-22 16:23 GMT+08:00 Tomasz Figa <tf...@chromium.org>:
>>>>>
>>>>> Hi Chih-Wei,
>>>>>
>>>>> On Thu, Feb 22, 2018 at 2:53 PM, Chih-Wei Huang <cwhu...@linux.org.tw>
>>>>> wrote:
>>>>>>
>>>>>> 2018-02-21 3:03 GMT+08:00 Rob Herring <r...@kernel.org>:
>>>>>>>
>>>>>>>
>>>>>>> Perhaps worth revisiting. Given we've failed to progress at all since
>>>>>>> then may change opinions some. We already have to handle multiple
>>>>>>> opens share the same pipe_screen, so I don't think reusing the fd buys
>>>>>>> us anything.
>>>>>>>
>>>>>>> Maybe we're close to the point of removing the flink name support too.
>>>>>>> The android-x86 folks have been working to get dma-bufs working.
>>>>>>> Chih-Wei, any comments on this?
>>>>>>
>>>>>>
>>>>>> Ah! Sorry. I didn't catch or understand the details.
>>>>>> Did you mean the attempts to use drm_hwcomposer
>>>>>> in android-x86?
>>>>>> My understanding so far is most x86 GPUs won't work
>>>>>> except some very limited models.
>>>>>> It's due to kernel driver issues which may never be solved.
>>>>>> So we can't drop the flink name support.
>>>>>> Please correct me if I am wrong.
>>>>>
>>>>>
>>>>> Could you elaborate a bit more on those GPUs that won't work and
>>>>> corresponding driver issues? We're running cros_gralloc on Intel and
>>>>> AMD GPUs, with DMA-buf and render-node only setup and we haven't seen
>>>>> any problems.
>>>>
>>>>
>>>> Hi Tomasz,
>>>> I remember (in our previous discussion) you said
>>>> CrOS uses your own hwcomposer (proprietary?) so
>>>> the story may be different.
>>>>
>>>> What we have tried is gbm_gralloc + drm_hwcomposer
>>>> and I reported the issues here:
>>>>
>>>> https://lists.freedesktop.org/archives/dri-devel/2017-September/153580.html
>>>
>>>
>>> I took the liberty of moving you nouveau issue into the drm_hwc gitlab
>>> bugtracker.
>>>
>>> https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/issues/1
>>
>> Hmm, reading further in that thread, that seemed to be related to
>> missing nouveau.atomic=1 in kernel command line:
>> https://lists.freedesktop.org/archives/dri-devel/2017-September/153681.html
>>
>> It went further, but didn't work very well. I suspect that could have
>> been related to DRM_GRALLOC_GET_FD being used, which makes the mess
>> from the system due to gralloc and Mesa stepping on each other's GEM
>> handles (which aren't reference counted by design and importing a
>> buffer several time will always return the same handle).
>
> I think mixing in drm_hwcomposer here would be trying to do too much at once.
> It has a lot of requirements (atomic driver, fence fds, alpha/rotation props)
> and no fallback path to speak of. Coming from drm_gralloc where I think in
> practice all composition is punted to the hwui GL compositor and DRM is
> only around for putting the final framebuffer on a display, it's asking a lot
> of some of the (legacy) hardware used for Android-x86.

Do we have any feasible alternative?

Chih-Wei pointed me to the drm_gralloc used on android-x86 and it
seems to seriously pre-date any DMA-buf support. Everything there is
done with the assumption that GEM names are used and adding DMA-buf
would require a significant rework of all the code.

That leaves us with gbm_gralloc (or possibly Chromium minigbm, used by
Android-IA too), which doesn't implement the legacy FB management, so
some hwcomposer would be needed.

Best regards,
Tomasz
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Removing GRALLOC_MODULE_PERFORM_GET_DRM_FD

[Tomasz Figa]

On Fri, Mar 23, 2018 at 3:03 AM, Robert Foss <robert.f...@collabora.com> wrote:
> Hey Tomasz,
>
>
> On 03/22/2018 09:27 AM, Tomasz Figa wrote:
>>
>> Hi Stefan,
>>
>> On Thu, Mar 22, 2018 at 8:42 AM, Stefan Schake <stsch...@gmail.com> wrote:
>>>
>>> Hey Robert,
>>>
>>> On Wed, Mar 21, 2018 at 4:16 PM, Robert Foss <robert.f...@collabora.com>
>>> wrote:
>>>>
>>>> Hey,
>>>>
>>>> I've started looking into removing the gralloc method
>>>> GRALLOC_MODULE_PERFORM_GET_DRM_FD.
>>>>
>>>> The issues around this seems to be two parts:
>>>> 1) Finding the right device to open
>>>> 2) Sharing the device between components
>>>>
>>>> Sharing the device between components
>>>> -
>>>>
>>>> Currently the device is used by drm_hwc, gbm_gralloc and mesa.
>>>>
>>>> drm_hwc opens the *primary* node in DrmResources::Init() and creates an
>>>> internal model of what properties/components the device has.
>>>>
>>>> gbm_gralloc uses the *render* node during in gbm_dev_create().
>>>>
>>>> Mesa uses uses the *render* node during dri_screen creation in
>>>> dri2_create_screen() and for loading the driver in
>>>> dri2_initialize_android().
>>>>
>>>> However, problematically, drm_hwc uses OpenGL composition as a fallback
>>>> method, and when doing so mesa has to be able to import buffers, which
>>>> means
>>>> mesa has to use a *primary* node.
>>>>
>>>> The way this is currently worked around in production systems seems to
>>>> be to
>>>> disable drm master authentication. This is at least what ChromeOS &
>>>> Intel
>>>> are doing as far as I understand it.
>>>>
>>>
>>> Thanks for kicking this off.
>>>
>>> I've done a few tests on 2) with VC4 and 8.1.0_r18. With drm_hwc the
>>> primary
>>> or master on card0 and gbm_gralloc & Mesa each getting their own fd from
>>> render128, I didn't need any of the DRM authentication hacks in the
>>> kernel
>>> anymore. That's with full overlay composition, everything forced to hwui
>>> GL
>>> composition or everything done through my hacked up ES2 version of
>>> glworker
>>> in drm_hwc (well it made it to launcher until succumbing to a resource
>>> leak).
>>> So I don't think mesa would need a master node and could make do with
>>> render.
>>
>>
>> Thanks for checking this. It seems to match my assumptions, which I
>> described in my reply to Rob's email.
>
>
> Alright, so some kind of probing seems to be the way forward then.
> What I'm wondering is what kind of properties of a render node would be the
> best
> to match against.
>
> For a quick reference of what information is available through
> drmGetDevices2, ran drmdevice[1], which gave this output:
>
> Opening device 0 node /dev/dri/renderD129
> device[0]
> available_nodes 0005
> nodes
> nodes[0] /dev/dri/card1
> nodes[2] /dev/dri/renderD129
> bustype 
> businfo
> pci
> domain  
> bus 00
> dev 02
> func0
> deviceinfo
> pci
> vendor_id   8086
> device_id   191b
> subvendor_id1028
> subdevice_id06e4
> revision_id 06
>
>
> [1] https://github.com/grate-driver/libdrm/blob/master/tests/drmdevice.c

Perhaps we could try to use drmOpenWithType() [2]. We could have one
property that would be passed as "name" argument and another property
for "busid" argument. I assume "type" would be always RENDER?

[2] https://cgit.freedesktop.org/mesa/drm/tree/xf86drm.c#n733

Best regards,
Tomasz
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v1 0/7] Implement commont gralloc_handle_t in libdrm

[Tomasz Figa]

On Fri, Mar 23, 2018 at 8:52 PM, Robert Foss <robert.f...@collabora.com> wrote:
> Hey Chih-Wei,
>
>
> On 03/23/2018 03:43 AM, Chih-Wei Huang wrote:
>>
>> 2018-03-22 16:23 GMT+08:00 Tomasz Figa <tf...@chromium.org>:
>>>
>>> Hi Chih-Wei,
>>>
>>> On Thu, Feb 22, 2018 at 2:53 PM, Chih-Wei Huang <cwhu...@linux.org.tw>
>>> wrote:
>>>>
>>>> 2018-02-21 3:03 GMT+08:00 Rob Herring <r...@kernel.org>:
>>>>>
>>>>>
>>>>> Perhaps worth revisiting. Given we've failed to progress at all since
>>>>> then may change opinions some. We already have to handle multiple
>>>>> opens share the same pipe_screen, so I don't think reusing the fd buys
>>>>> us anything.
>>>>>
>>>>> Maybe we're close to the point of removing the flink name support too.
>>>>> The android-x86 folks have been working to get dma-bufs working.
>>>>> Chih-Wei, any comments on this?
>>>>
>>>>
>>>> Ah! Sorry. I didn't catch or understand the details.
>>>> Did you mean the attempts to use drm_hwcomposer
>>>> in android-x86?
>>>> My understanding so far is most x86 GPUs won't work
>>>> except some very limited models.
>>>> It's due to kernel driver issues which may never be solved.
>>>> So we can't drop the flink name support.
>>>> Please correct me if I am wrong.
>>>
>>>
>>> Could you elaborate a bit more on those GPUs that won't work and
>>> corresponding driver issues? We're running cros_gralloc on Intel and
>>> AMD GPUs, with DMA-buf and render-node only setup and we haven't seen
>>> any problems.
>>
>>
>> Hi Tomasz,
>> I remember (in our previous discussion) you said
>> CrOS uses your own hwcomposer (proprietary?) so
>> the story may be different.
>>
>> What we have tried is gbm_gralloc + drm_hwcomposer
>> and I reported the issues here:
>>
>> https://lists.freedesktop.org/archives/dri-devel/2017-September/153580.html
>
>
> I took the liberty of moving you nouveau issue into the drm_hwc gitlab
> bugtracker.
>
> https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/issues/1

Hmm, reading further in that thread, that seemed to be related to
missing nouveau.atomic=1 in kernel command line:
https://lists.freedesktop.org/archives/dri-devel/2017-September/153681.html

It went further, but didn't work very well. I suspect that could have
been related to DRM_GRALLOC_GET_FD being used, which makes the mess
from the system due to gralloc and Mesa stepping on each other's GEM
handles (which aren't reference counted by design and importing a
buffer several time will always return the same handle).

Best regards,
Tomasz
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v1 0/7] Implement commont gralloc_handle_t in libdrm

[Tomasz Figa]

On Fri, Mar 23, 2018 at 11:43 AM, Chih-Wei Huang <cwhu...@linux.org.tw> wrote:
> 2018-03-22 16:23 GMT+08:00 Tomasz Figa <tf...@chromium.org>:
>> Hi Chih-Wei,
>>
>> On Thu, Feb 22, 2018 at 2:53 PM, Chih-Wei Huang <cwhu...@linux.org.tw> wrote:
>>> 2018-02-21 3:03 GMT+08:00 Rob Herring <r...@kernel.org>:
>>>>
>>>> Perhaps worth revisiting. Given we've failed to progress at all since
>>>> then may change opinions some. We already have to handle multiple
>>>> opens share the same pipe_screen, so I don't think reusing the fd buys
>>>> us anything.
>>>>
>>>> Maybe we're close to the point of removing the flink name support too.
>>>> The android-x86 folks have been working to get dma-bufs working.
>>>> Chih-Wei, any comments on this?
>>>
>>> Ah! Sorry. I didn't catch or understand the details.
>>> Did you mean the attempts to use drm_hwcomposer
>>> in android-x86?
>>> My understanding so far is most x86 GPUs won't work
>>> except some very limited models.
>>> It's due to kernel driver issues which may never be solved.
>>> So we can't drop the flink name support.
>>> Please correct me if I am wrong.
>>
>> Could you elaborate a bit more on those GPUs that won't work and
>> corresponding driver issues? We're running cros_gralloc on Intel and
>> AMD GPUs, with DMA-buf and render-node only setup and we haven't seen
>> any problems.
>
> Hi Tomasz,
> I remember (in our previous discussion) you said
> CrOS uses your own hwcomposer (proprietary?) so
> the story may be different.
>
> What we have tried is gbm_gralloc + drm_hwcomposer
> and I reported the issues here:
> https://lists.freedesktop.org/archives/dri-devel/2017-September/153580.html
>
> Sorry I didn't make more tests recently.
> I CC Mauro to comment. He should have made more tests
> with newer kernel and mesa.

Thanks for clarification.

This sounds like something that could be fixed by making sure DMA-buf
support is properly implemented in gralloc and hwcomposer used by
android-x86. I can help figuring this out, if anyone would be
interested in driving this on your side. FYI, I'm UTC+9 time zone, so
based on .tw domain in your email, it should be possible for us to
communicate easily, for example by IRC.

If i915 DRI driver is also needed, it would need wiring support for
DMA-buf as well, but it shouldn't be too hard as mentioned earlier

Best regards,
Tomasz
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Removing GRALLOC_MODULE_PERFORM_GET_DRM_FD

[Tomasz Figa]

Hi Stefan,

On Thu, Mar 22, 2018 at 8:42 AM, Stefan Schake  wrote:
> Hey Robert,
>
> On Wed, Mar 21, 2018 at 4:16 PM, Robert Foss  
> wrote:
>> Hey,
>>
>> I've started looking into removing the gralloc method
>> GRALLOC_MODULE_PERFORM_GET_DRM_FD.
>>
>> The issues around this seems to be two parts:
>> 1) Finding the right device to open
>> 2) Sharing the device between components
>>
>> Sharing the device between components
>> -
>>
>> Currently the device is used by drm_hwc, gbm_gralloc and mesa.
>>
>> drm_hwc opens the *primary* node in DrmResources::Init() and creates an
>> internal model of what properties/components the device has.
>>
>> gbm_gralloc uses the *render* node during in gbm_dev_create().
>>
>> Mesa uses uses the *render* node during dri_screen creation in
>> dri2_create_screen() and for loading the driver in
>> dri2_initialize_android().
>>
>> However, problematically, drm_hwc uses OpenGL composition as a fallback
>> method, and when doing so mesa has to be able to import buffers, which means
>> mesa has to use a *primary* node.
>>
>> The way this is currently worked around in production systems seems to be to
>> disable drm master authentication. This is at least what ChromeOS & Intel
>> are doing as far as I understand it.
>>
>
> Thanks for kicking this off.
>
> I've done a few tests on 2) with VC4 and 8.1.0_r18. With drm_hwc the primary
> or master on card0 and gbm_gralloc & Mesa each getting their own fd from
> render128, I didn't need any of the DRM authentication hacks in the kernel
> anymore. That's with full overlay composition, everything forced to hwui GL
> composition or everything done through my hacked up ES2 version of glworker
> in drm_hwc (well it made it to launcher until succumbing to a resource leak).
> So I don't think mesa would need a master node and could make do with render.

Thanks for checking this. It seems to match my assumptions, which I
described in my reply to Rob's email.

>
> The one thing that mesa on a render node definitely breaks is flink/GEM names
> which drm_gralloc uses (the Android-x86 version anyway). No flink anything
> with render nodes; drm_gralloc would have to move to dmabuf fds.

I really wonder why those are still in use...

>
> That said, it would finally get rid of the strict coupling between Mesa and
> gralloc. Ripping out the PERFORM and drm_gralloc facsimile in gbm_gralloc
> saves a big bunch of code:
>
> https://github.com/stschake/gbm_gralloc/tree/libdrm_handle_def
>
> With more in mesa/platform_android from the flink stuff.

Nice diffstat. ;)

Best regards,
Tomasz
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v1 0/7] Implement commont gralloc_handle_t in libdrm

[Tomasz Figa]

Hi Chih-Wei,

On Thu, Feb 22, 2018 at 2:53 PM, Chih-Wei Huang  wrote:
> 2018-02-21 3:03 GMT+08:00 Rob Herring :
>>
>> Perhaps worth revisiting. Given we've failed to progress at all since
>> then may change opinions some. We already have to handle multiple
>> opens share the same pipe_screen, so I don't think reusing the fd buys
>> us anything.
>>
>> Maybe we're close to the point of removing the flink name support too.
>> The android-x86 folks have been working to get dma-bufs working.
>> Chih-Wei, any comments on this?
>
> Ah! Sorry. I didn't catch or understand the details.
> Did you mean the attempts to use drm_hwcomposer
> in android-x86?
> My understanding so far is most x86 GPUs won't work
> except some very limited models.
> It's due to kernel driver issues which may never be solved.
> So we can't drop the flink name support.
> Please correct me if I am wrong.

Could you elaborate a bit more on those GPUs that won't work and
corresponding driver issues? We're running cros_gralloc on Intel and
AMD GPUs, with DMA-buf and render-node only setup and we haven't seen
any problems.

Best regards,
Tomasz
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Removing GRALLOC_MODULE_PERFORM_GET_DRM_FD

[Tomasz Figa]

Hi Rob,

On Thu, Mar 22, 2018 at 12:16 AM, Robert Foss  wrote:
> Hey,
>
> I've started looking into removing the gralloc method
> GRALLOC_MODULE_PERFORM_GET_DRM_FD.

Thanks a lot for looking into this.

>
> The issues around this seems to be two parts:
> 1) Finding the right device to open
> 2) Sharing the device between components
>
>
> Finding the right device to open
> 
>
> Using a static path for the device is problematic if an image is used on
> more than a single HW revision, since no static device <-> device path
> mapping can be guaranteed.
>
> For a single HW revision the device <-> device path mapping will probably be
> the same, but it is still dependent on the order of devices being probed
> during initialization.
>
> Previously I've hacked up a solution for selecting the device path from an
> Android property. This property still has to be set somewhere, and I ended
> up having the bootloader provide it since it was device specific anyway. But
> it was hardly a neat solution, and I don't see any other static solutions
> that are all that much more neat. But suggestions are welcome.
>
> So that leaves probing, I'm not sure what a good probing solution would look
> at this point.

One idea I suggested in another thread[1], and which apparently didn't
run into too much opposition, was having a property to force matching
with given DRM driver name or bus ID, but if one is not present, just
use the first node that matches any existing driver.

[1] https://lists.freedesktop.org/archives/mesa-dev/2018-February/186400.html

>
>
> Sharing the device between components
> -
>
> Currently the device is used by drm_hwc, gbm_gralloc and mesa.
>
> drm_hwc opens the *primary* node in DrmResources::Init() and creates an
> internal model of what properties/components the device has.
>
> gbm_gralloc uses the *render* node during in gbm_dev_create().
>
> Mesa uses uses the *render* node during dri_screen creation in
> dri2_create_screen() and for loading the driver in
> dri2_initialize_android().
>
> However, problematically, drm_hwc uses OpenGL composition as a fallback
> method, and when doing so mesa has to be able to import buffers, which means
> mesa has to use a *primary* node.

Hmm, I don't see why Mesa in drm_hwc process couldn't open a render
node. IMHO drm_hwc already uses DMA-buf, so there shouldn't be any
problem with imports on either side.

>
> The way this is currently worked around in production systems seems to be to
> disable drm master authentication. This is at least what ChromeOS & Intel
> are doing as far as I understand it.

We don't have such problem in Chrome OS, but we don't use drm_hwc
there either. Android-side uses render nodes only and our hwcomposer
defers composition to Chrome (by sharing DMA-buf FDs and metadata of
the layers), which uses master node, but it does so only in the
single, isolated GPU process, so there is no authentication needed.

Best regards,
Tomasz
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v6 1/2] gallium/winsys/kms: Fix possible leak in map/unmap.

[Tomasz Figa]

On Wed, Mar 21, 2018 at 12:58 AM, Emil Velikov <emil.l.veli...@gmail.com> wrote:
> On 20 March 2018 at 14:24, Tomasz Figa <tf...@chromium.org> wrote:
>> On Tue, Mar 20, 2018 at 10:44 PM, Emil Velikov <emil.l.veli...@gmail.com> 
>> wrote:
>>> On 20 March 2018 at 04:40, Tomasz Figa <tf...@chromium.org> wrote:
>>>> On Tue, Mar 20, 2018 at 2:55 AM, Emil Velikov <emil.l.veli...@gmail.com> 
>>>> wrote:
>>>>> Hi Lepton,
>>>>>
>>>>> On 19 March 2018 at 17:33, Lepton Wu <lep...@chromium.org> wrote:
>>>>>> If user calls map twice for kms_sw_displaytarget, the first mapped
>>>>>> buffer could get leaked. Instead of calling mmap every time, just
>>>>>> reuse previous mapping. Since user could map same displaytarget with
>>>>>> different flags, we have to keep two different pointers, one for rw
>>>>>> mapping and one for ro mapping. Also introduce reference count for
>>>>>> mapped buffer so we can unmap them at right time.
>>>>>>
>>>>>> Reviewed-by: Emil Velikov <emil.veli...@collabora.com>
>>>>>> Reviewed-by: Tomasz Figa <tf...@chromium.org>
>>>>>> Signed-off-by: Lepton Wu <lep...@chromium.org>
>>>>>
>>>>> Nit: normally it's a good idea to have brief revision log when sending
>>>>> new version:
>>>>> v2:
>>>>>  - split from larger patch (Emil)
>>>>> v3:
>>>>>  - remove munmap w/a from dt_destory(Emil)
>>>>> ...
>>>>>
>>>>>> @@ -170,6 +172,14 @@ kms_sw_displaytarget_destroy(struct sw_winsys *ws,
>>>>>> if (kms_sw_dt->ref_count > 0)
>>>>>>return;
>>>>>>
>>>>>> +   if (kms_sw_dt->map_count > 0) {
>>>>>> +  DEBUG_PRINT("KMS-DEBUG: fix leaked map buffer %u\n", 
>>>>>> kms_sw_dt->handle);
>>>>>> +  munmap(kms_sw_dt->mapped, kms_sw_dt->size);
>>>>>> +  kms_sw_dt->mapped = NULL;
>>>>>> +  munmap(kms_sw_dt->ro_mapped, kms_sw_dt->size);
>>>>>> +  kms_sw_dt->ro_mapped = NULL;
>>>>>> +   }
>>>>>> +
>>>>> I could swear this workaround was missing in earlier revisions. I
>>>>> don't see anything in Tomasz' reply that suggesting we should bring it
>>>>> back?
>>>>> AFAICT the added refcounting makes no difference - the driver isn't
>>>>> cleaning up after itself.
>>>>>
>>>>> Am I missing something?
>>>>
>>>> I think this is actually consistent with what other winsys
>>>> implementations do. They free the map (or shadow malloc/shm buffer) in
>>>> _destroy() callback, so we should probably do the same.
>>>>
>>> Looking at the SW winsys - none of them seem to unmap at destroy time.
>>> Perhaps you meant that the HW ones do?
>>
>> dri:
>> https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/winsys/sw/dri/dri_sw_winsys.c#n128
>>
>> gdi:
>> https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/winsys/sw/gdi/gdi_sw_winsys.c#n116
>>
>> hgl:
>> https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/winsys/sw/hgl/hgl_sw_winsys.c#n152
>>
>> xlib:
>> https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/winsys/sw/xlib/xlib_sw_winsys.c#n260
>> https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/winsys/sw/xlib/xlib_sw_winsys.c#n271
>>
>> The don't do real mapping - they all work on locally allocated memory.
>> However, after destroy, no resources are leaked and the pointers
>> returned from _map() are not valid anymore.
>>
> As mentioned before - zero objections against changing that, but keep
> it separate patch.
> Pretty please?

SGTM.

Best regards,
Tomasz
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v6 1/2] gallium/winsys/kms: Fix possible leak in map/unmap.

[Tomasz Figa]

On Tue, Mar 20, 2018 at 10:44 PM, Emil Velikov <emil.l.veli...@gmail.com> wrote:
> On 20 March 2018 at 04:40, Tomasz Figa <tf...@chromium.org> wrote:
>> On Tue, Mar 20, 2018 at 2:55 AM, Emil Velikov <emil.l.veli...@gmail.com> 
>> wrote:
>>> Hi Lepton,
>>>
>>> On 19 March 2018 at 17:33, Lepton Wu <lep...@chromium.org> wrote:
>>>> If user calls map twice for kms_sw_displaytarget, the first mapped
>>>> buffer could get leaked. Instead of calling mmap every time, just
>>>> reuse previous mapping. Since user could map same displaytarget with
>>>> different flags, we have to keep two different pointers, one for rw
>>>> mapping and one for ro mapping. Also introduce reference count for
>>>> mapped buffer so we can unmap them at right time.
>>>>
>>>> Reviewed-by: Emil Velikov <emil.veli...@collabora.com>
>>>> Reviewed-by: Tomasz Figa <tf...@chromium.org>
>>>> Signed-off-by: Lepton Wu <lep...@chromium.org>
>>>
>>> Nit: normally it's a good idea to have brief revision log when sending
>>> new version:
>>> v2:
>>>  - split from larger patch (Emil)
>>> v3:
>>>  - remove munmap w/a from dt_destory(Emil)
>>> ...
>>>
>>>> @@ -170,6 +172,14 @@ kms_sw_displaytarget_destroy(struct sw_winsys *ws,
>>>> if (kms_sw_dt->ref_count > 0)
>>>>return;
>>>>
>>>> +   if (kms_sw_dt->map_count > 0) {
>>>> +  DEBUG_PRINT("KMS-DEBUG: fix leaked map buffer %u\n", 
>>>> kms_sw_dt->handle);
>>>> +  munmap(kms_sw_dt->mapped, kms_sw_dt->size);
>>>> +  kms_sw_dt->mapped = NULL;
>>>> +  munmap(kms_sw_dt->ro_mapped, kms_sw_dt->size);
>>>> +  kms_sw_dt->ro_mapped = NULL;
>>>> +   }
>>>> +
>>> I could swear this workaround was missing in earlier revisions. I
>>> don't see anything in Tomasz' reply that suggesting we should bring it
>>> back?
>>> AFAICT the added refcounting makes no difference - the driver isn't
>>> cleaning up after itself.
>>>
>>> Am I missing something?
>>
>> I think this is actually consistent with what other winsys
>> implementations do. They free the map (or shadow malloc/shm buffer) in
>> _destroy() callback, so we should probably do the same.
>>
> Looking at the SW winsys - none of them seem to unmap at destroy time.
> Perhaps you meant that the HW ones do?

dri:
https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/winsys/sw/dri/dri_sw_winsys.c#n128

gdi:
https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/winsys/sw/gdi/gdi_sw_winsys.c#n116

hgl:
https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/winsys/sw/hgl/hgl_sw_winsys.c#n152

xlib:
https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/winsys/sw/xlib/xlib_sw_winsys.c#n260
https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/winsys/sw/xlib/xlib_sw_winsys.c#n271

The don't do real mapping - they all work on locally allocated memory.
However, after destroy, no resources are leaked and the pointers
returned from _map() are not valid anymore.

On the other hand, wrapper only releases a reference to pipe_resource,
so the related transfer remains valid:
https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/winsys/sw/wrapper/wrapper_sw_winsys.c#n266

Best regards,
Tomasz
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v6 1/2] gallium/winsys/kms: Fix possible leak in map/unmap.

[Tomasz Figa]

On Tue, Mar 20, 2018 at 2:55 AM, Emil Velikov <emil.l.veli...@gmail.com> wrote:
> Hi Lepton,
>
> On 19 March 2018 at 17:33, Lepton Wu <lep...@chromium.org> wrote:
>> If user calls map twice for kms_sw_displaytarget, the first mapped
>> buffer could get leaked. Instead of calling mmap every time, just
>> reuse previous mapping. Since user could map same displaytarget with
>> different flags, we have to keep two different pointers, one for rw
>> mapping and one for ro mapping. Also introduce reference count for
>> mapped buffer so we can unmap them at right time.
>>
>> Reviewed-by: Emil Velikov <emil.veli...@collabora.com>
>> Reviewed-by: Tomasz Figa <tf...@chromium.org>
>> Signed-off-by: Lepton Wu <lep...@chromium.org>
>
> Nit: normally it's a good idea to have brief revision log when sending
> new version:
> v2:
>  - split from larger patch (Emil)
> v3:
>  - remove munmap w/a from dt_destory(Emil)
> ...
>
>> @@ -170,6 +172,14 @@ kms_sw_displaytarget_destroy(struct sw_winsys *ws,
>> if (kms_sw_dt->ref_count > 0)
>>return;
>>
>> +   if (kms_sw_dt->map_count > 0) {
>> +  DEBUG_PRINT("KMS-DEBUG: fix leaked map buffer %u\n", 
>> kms_sw_dt->handle);
>> +  munmap(kms_sw_dt->mapped, kms_sw_dt->size);
>> +  kms_sw_dt->mapped = NULL;
>> +  munmap(kms_sw_dt->ro_mapped, kms_sw_dt->size);
>> +  kms_sw_dt->ro_mapped = NULL;
>> +   }
>> +
> I could swear this workaround was missing in earlier revisions. I
> don't see anything in Tomasz' reply that suggesting we should bring it
> back?
> AFAICT the added refcounting makes no difference - the driver isn't
> cleaning up after itself.
>
> Am I missing something?

I think this is actually consistent with what other winsys
implementations do. They free the map (or shadow malloc/shm buffer) in
_destroy() callback, so we should probably do the same.

Best regards,
Tomasz
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v5 1/2] gallium/winsys/kms: Fix possible leak in map/unmap.

[Tomasz Figa]

Hi Lepton,

On Sat, Mar 17, 2018 at 3:09 AM, Lepton Wu <lep...@chromium.org> wrote:
> If user calls map twice for kms_sw_displaytarget, the first mapped
> buffer could get leaked. Instead of calling mmap every time, just
> reuse previous mapping. Since user could map same displaytarget with
> different flags, we have to keep two different pointers, one for rw
> mapping and one for ro mapping. Also introduce reference count for
> mapped buffer so we can unmap them at right time.
>
> Change-Id: I65308f0ff2640bd57b2577c6a3469540c9722859

Change-Id shouldn't be included in upstream patches.

> Signed-off-by: Lepton Wu <lep...@chromium.org>
> ---
>  .../winsys/sw/kms-dri/kms_dri_sw_winsys.c | 44 +++
>  1 file changed, 36 insertions(+), 8 deletions(-)

Other than that:

Reviewed-by: Tomasz Figa <tf...@chromium.org>

Thanks for addressing the comments.

Best regards,
Tomasz
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v3 2/2] gallium/winsys/kms: Add support for multi-planes

[Tomasz Figa]

On Wed, Mar 7, 2018 at 7:43 AM, Lepton Wu  wrote:
> Add a new struct kms_sw_plane which delegate a plane and use it
> in place of sw_displaytarget. Multiple planes share same underlying
> kms_sw_displaytarget.
>
> Change-Id: I0e9ca1d0ba0aa78c27dfdb50c30dc0c424fec172
> Signed-off-by: Lepton Wu 
> ---
>  .../winsys/sw/kms-dri/kms_dri_sw_winsys.c | 162 +-
>  1 file changed, 122 insertions(+), 40 deletions(-)
>
> diff --git a/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c 
> b/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c
> index 30343222470..d191d5c4987 100644
> --- a/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c
> +++ b/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c
> @@ -59,13 +59,22 @@
>  #define DEBUG_PRINT(msg, ...)
>  #endif
>
> +struct kms_sw_displaytarget;
>
> -struct kms_sw_displaytarget
> +struct kms_sw_plane
>  {
> -   enum pipe_format format;
> unsigned width;
> unsigned height;
> unsigned stride;
> +   unsigned offset;
> +   int mapped;
> +   struct kms_sw_displaytarget *dt;
> +   struct list_head link;
> +};
> +
> +struct kms_sw_displaytarget
> +{
> +   enum pipe_format format;
> unsigned size;
>
> uint32_t handle;
> @@ -74,6 +83,7 @@ struct kms_sw_displaytarget
>
> int ref_count;
> struct list_head link;
> +   struct list_head planes;
>  };
>
>  struct kms_sw_winsys
> @@ -84,10 +94,16 @@ struct kms_sw_winsys
> struct list_head bo_list;
>  };
>
> -static inline struct kms_sw_displaytarget *
> -kms_sw_displaytarget( struct sw_displaytarget *dt )
> +static inline struct kms_sw_plane *
> +kms_sw_plane( struct sw_displaytarget *dt )
>  {
> -   return (struct kms_sw_displaytarget *)dt;
> +   return (struct kms_sw_plane *)dt;
> +}
> +
> +static inline struct sw_displaytarget *
> +sw_displaytarget( struct kms_sw_plane *pl)
> +{
> +   return (struct sw_displaytarget *)pl;
>  }
>
>  static inline struct kms_sw_winsys *
> @@ -106,6 +122,39 @@ kms_sw_is_displaytarget_format_supported( struct 
> sw_winsys *ws,
> return TRUE;
>  }
>
> +static struct kms_sw_plane *get_plane(struct kms_sw_displaytarget *kms_sw_dt,
> +  enum pipe_format format,
> +  unsigned width, unsigned height,
> +  unsigned stride, unsigned offset)
> +{
> +   struct kms_sw_plane *plane = NULL;
> +
> +   if (offset + util_format_get_2d_size(format, stride, height) >
> +   kms_sw_dt->size) {
> +  DEBUG_PRINT("KMS-DEBUG: plane too big. format: %d stride: %d height: 
> %d "
> +  "offset: %d size:%d\n", format, stride, height, offset,
> +  kms_sw_dt->size);
> +  return NULL;
> +   }
> +
> +   LIST_FOR_EACH_ENTRY(plane, _sw_dt->planes, link) {
> +  if (plane->offset == offset)
> + return plane;
> +   }
> +
> +   plane = CALLOC_STRUCT(kms_sw_plane);
> +   if (!plane)
> +  return NULL;
> +
> +   plane->width = width;
> +   plane->height = height;
> +   plane->stride = stride;
> +   plane->offset = offset;
> +   plane->dt = kms_sw_dt;
> +   list_add(>link, _sw_dt->planes);
> +   return plane;
> +}
> +
>  static struct sw_displaytarget *
>  kms_sw_displaytarget_create(struct sw_winsys *ws,
>  unsigned tex_usage,
> @@ -125,11 +174,10 @@ kms_sw_displaytarget_create(struct sw_winsys *ws,
> if (!kms_sw_dt)
>goto no_dt;
>
> +   list_inithead(_sw_dt->planes);
> kms_sw_dt->ref_count = 1;
>
> kms_sw_dt->format = format;
> -   kms_sw_dt->width = width;
> -   kms_sw_dt->height = height;
>
> memset(_req, 0, sizeof(create_req));
> create_req.bpp = 32;
> @@ -139,16 +187,19 @@ kms_sw_displaytarget_create(struct sw_winsys *ws,
> if (ret)
>goto free_bo;
>
> -   kms_sw_dt->stride = create_req.pitch;
> kms_sw_dt->size = create_req.size;
> kms_sw_dt->handle = create_req.handle;
> +   struct kms_sw_plane *plane = get_plane(kms_sw_dt, format, width, height,
> +  create_req.pitch, 0);
> +   if (!plane)
> +  goto free_bo;
>
> list_add(_sw_dt->link, _sw->bo_list);
>
> DEBUG_PRINT("KMS-DEBUG: created buffer %u (size %u)\n", 
> kms_sw_dt->handle, kms_sw_dt->size);
>
> -   *stride = kms_sw_dt->stride;
> -   return (struct sw_displaytarget *)kms_sw_dt;
> +   *stride = create_req.pitch;
> +   return sw_displaytarget(plane);
>
>   free_bo:
> memset(_req, 0, sizeof destroy_req);
> @@ -164,7 +215,8 @@ kms_sw_displaytarget_destroy(struct sw_winsys *ws,
>   struct sw_displaytarget *dt)
>  {
> struct kms_sw_winsys *kms_sw = kms_sw_winsys(ws);
> -   struct kms_sw_displaytarget *kms_sw_dt = kms_sw_displaytarget(dt);
> +   struct kms_sw_plane *plane = kms_sw_plane(dt);
> +   struct kms_sw_displaytarget *kms_sw_dt = plane->dt;
> struct drm_mode_destroy_dumb destroy_req;
>
> kms_sw_dt->ref_count --;
> @@ -184,6 +236,11 @@ 

Re: [Mesa-dev] [PATCH v4 1/2] gallium/winsys/kms: Fix possible leak in map/unmap.

[Tomasz Figa]

Hi Lepton,

Please avoid top-posting in mailing lists in the future. It's against
the netiquette.

On Wed, Mar 14, 2018 at 10:20 AM, Lepton Wu <lep...@chromium.org> wrote:
[Message moved to bottom]
> On Tue, Mar 13, 2018 at 8:41 AM, Emil Velikov <emil.l.veli...@gmail.com> 
> wrote:
>> On 13 March 2018 at 11:46, Tomasz Figa <tf...@chromium.org> wrote:
>>> On Thu, Mar 8, 2018 at 7:39 AM, Lepton Wu <lep...@chromium.org> wrote:
>>>> If user calls map twice for kms_sw_displaytarget, the first mapped
>>>> buffer could get leaked. Instead of calling mmap every time, just
>>>> reuse previous mapping. Since user could map same displaytarget with
>>>> different flags, we have to keep two different pointers, one for rw
>>>> mapping and one for ro mapping.
>>>>
>>>> Change-Id: I65308f0ff2640bd57b2577c6a3469540c9722859
>>>> Signed-off-by: Lepton Wu <lep...@chromium.org>
>>>> ---
>>>>  .../winsys/sw/kms-dri/kms_dri_sw_winsys.c | 21 ---
>>>>  1 file changed, 14 insertions(+), 7 deletions(-)
>>>>
>>>> diff --git a/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c 
>>>> b/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c
>>>> index 22e1c936ac5..7fc40488c2e 100644
>>>> --- a/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c
>>>> +++ b/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c
>>>> @@ -70,6 +70,7 @@ struct kms_sw_displaytarget
>>>>
>>>> uint32_t handle;
>>>> void *mapped;
>>>> +   void *ro_mapped;
>>>>
>>>> int ref_count;
>>>> struct list_head link;
>>>> @@ -198,16 +199,19 @@ kms_sw_displaytarget_map(struct sw_winsys *ws,
>>>>return NULL;
>>>>
>>>> prot = (flags == PIPE_TRANSFER_READ) ? PROT_READ : (PROT_READ | 
>>>> PROT_WRITE);
>>>> -   kms_sw_dt->mapped = mmap(0, kms_sw_dt->size, prot, MAP_SHARED,
>>>> -kms_sw->fd, map_req.offset);
>>>> -
>>>> -   if (kms_sw_dt->mapped == MAP_FAILED)
>>>> -  return NULL;
>>>> +   void **ptr = (flags == PIPE_TRANSFER_READ) ? _sw_dt->ro_mapped : 
>>>> _sw_dt->mapped;
>>>> +   if (!*ptr) {
>>>> +  void *tmp = mmap(0, kms_sw_dt->size, prot, MAP_SHARED,
>>>> +   kms_sw->fd, map_req.offset);
>>>> +  if (tmp == MAP_FAILED)
>>>> + return NULL;
>>>> +  *ptr = tmp;
>>>> +   }
>>>>
>>>> DEBUG_PRINT("KMS-DEBUG: mapped buffer %u (size %u) at %p\n",
>>>> - kms_sw_dt->handle, kms_sw_dt->size, kms_sw_dt->mapped);
>>>> + kms_sw_dt->handle, kms_sw_dt->size, *ptr);
>>>>
>>>> -   return kms_sw_dt->mapped;
>>>> +   return *ptr;
>>>>  }
>>>>
>>>>  static struct kms_sw_displaytarget *
>>>> @@ -278,9 +282,12 @@ kms_sw_displaytarget_unmap(struct sw_winsys *ws,
>>>> struct kms_sw_displaytarget *kms_sw_dt = kms_sw_displaytarget(dt);
>>>>
>>>> DEBUG_PRINT("KMS-DEBUG: unmapped buffer %u (was %p)\n", 
>>>> kms_sw_dt->handle, kms_sw_dt->mapped);
>>>> +   DEBUG_PRINT("KMS-DEBUG: unmapped buffer %u (was %p)\n", 
>>>> kms_sw_dt->handle, kms_sw_dt->ro_mapped);
>>>>
>>>> munmap(kms_sw_dt->mapped, kms_sw_dt->size);
>>>> kms_sw_dt->mapped = NULL;
>>>> +   munmap(kms_sw_dt->ro_mapped, kms_sw_dt->size);
>>>> +   kms_sw_dt->ro_mapped = NULL;
>>>>  }
>>>
>>> If user calls map twice, wouldn't they also call unmap twice?
>>> Moreover, wouldn't the pointer be expected to be still valid between
>>> first and second unmap?
>>>
>>> The answer obviously depends on how the API is designed, but i feels
>>> really weird being asymmetrical like that. Typically the mapping would
>>> be refcounted and maps would have to be balanced with unmaps to free
>>> the mapping.
>>>
>> Valid points.
>>
>> If you guys prefer we could land 2/2 (multiplane support), since it
>> has no dependency of the mapping work.
>> And polish out ro/rw mappings (even the leaks) at later stage, as time 
>> permits?
>>
>> -Emil
>
> I am fine to add ref count for map pointer but then the code looks a
> little complex:
&

Re: [Mesa-dev] [PATCH v2] egl/android: Implement the eglSwapinterval for Android.

[Tomasz Figa]

On Thu, Jan 18, 2018 at 4:39 PM, Zhongmin Wu <zhongmin...@intel.com> wrote:
> Implement the eglSwapinterval for Android platform to
> enable the async mode for some GFX benchmarks such as
> Daimler C217, CityBench.
>
> Signed-off-by: Zhongmin Wu <zhongmin...@intel.com>
> ---
>  src/egl/drivers/dri2/platform_android.c | 21 +
>  1 file changed, 21 insertions(+)
>
> diff --git a/src/egl/drivers/dri2/platform_android.c 
> b/src/egl/drivers/dri2/platform_android.c
> index f6a24cd..3a64689 100644
> --- a/src/egl/drivers/dri2/platform_android.c
> +++ b/src/egl/drivers/dri2/platform_android.c
> @@ -476,6 +476,20 @@ droid_destroy_surface(_EGLDriver *drv, _EGLDisplay 
> *disp, _EGLSurface *surf)
> return EGL_TRUE;
>  }
>
> +static EGLBoolean
> +droid_swap_interval(_EGLDriver *drv, _EGLDisplay *dpy,
> +   _EGLSurface *surf, EGLint interval)
> +{
> +   struct dri2_egl_surface *dri2_surf = dri2_egl_surface(surf);
> +   struct ANativeWindow *window = dri2_surf->window;
> +
> +   if (window->setSwapInterval(window, interval))
> +  return EGL_FALSE;
> +
> +   surf->SwapInterval = interval;
> +   return EGL_TRUE;
> +}
> +
>  static int
>  update_buffers(struct dri2_egl_surface *dri2_surf)
>  {
> @@ -1300,6 +1314,7 @@ static const struct dri2_egl_display_vtbl 
> droid_display_vtbl = {
> .swap_buffers = droid_swap_buffers,
> .swap_buffers_with_damage = dri2_fallback_swap_buffers_with_damage, /* 
> Android implements the function */
> .swap_buffers_region = dri2_fallback_swap_buffers_region,
> +   .swap_interval = droid_swap_interval,
>  #if ANDROID_API_LEVEL >= 23
> .set_damage_region = droid_set_damage_region,
>  #else
> @@ -1443,6 +1458,12 @@ dri2_initialize_android(_EGLDriver *drv, _EGLDisplay 
> *dpy)
>
> dri2_setup_screen(dpy);
>
> +   /* we set the maximum swap interval as 1 for Android platform, Since
> +   it is the maximum value supported by Android according to the
> +   value of ANativeWindow::maxSwapInterval.
> +   */

nit: Please use comment style consistent with rest of the file. Also,
please fix up typography issues, as below:

/* We set the maximum swap interval as 1 for Android platform, since it is
 * the maximum value supported by Android according to the value of
 * ANativeWindow::maxSwapInterval.
 */

I guess whoever committing this patch could just fix this up without a resend.

With the above:

Reviewed-by: Tomasz Figa <tf...@chromium.org>

Best regards,
Tomasz
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v4 1/2] gallium/winsys/kms: Fix possible leak in map/unmap.

[Tomasz Figa]

On Thu, Mar 8, 2018 at 7:39 AM, Lepton Wu  wrote:
> If user calls map twice for kms_sw_displaytarget, the first mapped
> buffer could get leaked. Instead of calling mmap every time, just
> reuse previous mapping. Since user could map same displaytarget with
> different flags, we have to keep two different pointers, one for rw
> mapping and one for ro mapping.
>
> Change-Id: I65308f0ff2640bd57b2577c6a3469540c9722859
> Signed-off-by: Lepton Wu 
> ---
>  .../winsys/sw/kms-dri/kms_dri_sw_winsys.c | 21 ---
>  1 file changed, 14 insertions(+), 7 deletions(-)
>
> diff --git a/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c 
> b/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c
> index 22e1c936ac5..7fc40488c2e 100644
> --- a/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c
> +++ b/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c
> @@ -70,6 +70,7 @@ struct kms_sw_displaytarget
>
> uint32_t handle;
> void *mapped;
> +   void *ro_mapped;
>
> int ref_count;
> struct list_head link;
> @@ -198,16 +199,19 @@ kms_sw_displaytarget_map(struct sw_winsys *ws,
>return NULL;
>
> prot = (flags == PIPE_TRANSFER_READ) ? PROT_READ : (PROT_READ | 
> PROT_WRITE);
> -   kms_sw_dt->mapped = mmap(0, kms_sw_dt->size, prot, MAP_SHARED,
> -kms_sw->fd, map_req.offset);
> -
> -   if (kms_sw_dt->mapped == MAP_FAILED)
> -  return NULL;
> +   void **ptr = (flags == PIPE_TRANSFER_READ) ? _sw_dt->ro_mapped : 
> _sw_dt->mapped;
> +   if (!*ptr) {
> +  void *tmp = mmap(0, kms_sw_dt->size, prot, MAP_SHARED,
> +   kms_sw->fd, map_req.offset);
> +  if (tmp == MAP_FAILED)
> + return NULL;
> +  *ptr = tmp;
> +   }
>
> DEBUG_PRINT("KMS-DEBUG: mapped buffer %u (size %u) at %p\n",
> - kms_sw_dt->handle, kms_sw_dt->size, kms_sw_dt->mapped);
> + kms_sw_dt->handle, kms_sw_dt->size, *ptr);
>
> -   return kms_sw_dt->mapped;
> +   return *ptr;
>  }
>
>  static struct kms_sw_displaytarget *
> @@ -278,9 +282,12 @@ kms_sw_displaytarget_unmap(struct sw_winsys *ws,
> struct kms_sw_displaytarget *kms_sw_dt = kms_sw_displaytarget(dt);
>
> DEBUG_PRINT("KMS-DEBUG: unmapped buffer %u (was %p)\n", 
> kms_sw_dt->handle, kms_sw_dt->mapped);
> +   DEBUG_PRINT("KMS-DEBUG: unmapped buffer %u (was %p)\n", 
> kms_sw_dt->handle, kms_sw_dt->ro_mapped);
>
> munmap(kms_sw_dt->mapped, kms_sw_dt->size);
> kms_sw_dt->mapped = NULL;
> +   munmap(kms_sw_dt->ro_mapped, kms_sw_dt->size);
> +   kms_sw_dt->ro_mapped = NULL;
>  }

If user calls map twice, wouldn't they also call unmap twice?
Moreover, wouldn't the pointer be expected to be still valid between
first and second unmap?

The answer obviously depends on how the API is designed, but i feels
really weird being asymmetrical like that. Typically the mapping would
be refcounted and maps would have to be balanced with unmaps to free
the mapping.

Best regards,
Tomasz
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v4 1/2] gallium/winsys/kms: Fix possible leak in map/unmap.

[Tomasz Figa]

On Tue, Mar 13, 2018 at 3:10 AM, Emil Velikov  wrote:
> On 12 March 2018 at 17:45, Lepton Wu  wrote:
>> Ping.  Any more comments or missing stuff to get this commited into master?
>>
> As things have changed a bit (the original map/unmap behaviour is
> preserved) I was hoping that Tomasz will give it another look.
> If he prefers, I could add some revision summary and keep him as reviewer of 
> v1?

Thanks Emil. I'll take a look. Sorry for being late to the party.

Best regards,
Tomasz
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v1 0/7] Implement commont gralloc_handle_t in libdrm

[Tomasz Figa]

On Thu, Feb 22, 2018 at 7:23 AM, Rob Herring <r...@kernel.org> wrote:
>
> On Wed, Feb 21, 2018 at 1:22 PM, Emil Velikov <emil.l.veli...@gmail.com> 
> wrote:
> > On 21 February 2018 at 18:50, Rob Herring <r...@kernel.org> wrote:
> >> On Wed, Feb 21, 2018 at 10:01 AM, Emil Velikov <emil.l.veli...@gmail.com> 
> >> wrote:
> >>> Hi all,
> >>>
> >>> Pardon for dropping in late. I think you've got nearly everything
> >>> settled down, just sharing a couple of ideas.
> >>>
> >>> On 21 February 2018 at 04:19, Tomasz Figa <tf...@chromium.org> wrote:
> >>>> On Wed, Feb 21, 2018 at 4:03 AM, Rob Herring <r...@kernel.org> wrote:
> >>>>> On Tue, Feb 20, 2018 at 4:26 AM, Tomasz Figa <tf...@chromium.org> wrote:
> >>>
> >>>> It is actually incorrect to have the same device FD used for different
> >>>> screens, if PRIME is used, due to GEM namespace issues, e.g.
> >>>> - screen 0: drmPrimeFdToHandle(buffer A) -> 1,
> >>>> - screen 1: drmPrimeFdToHandle(buffer A) -> 1 (same handle in same
> >>>> namespace, due to semantics of PRIME import and same device FD used),
> >>>> - screen 0: GEM_CLOSE(handle = 1),
> >>>> - screen 1 still thinks handle 1 is valid...
> >>>>
> >>>> So this only works for control nodes using flink only. (Or if you
> >>>> always use libdrm_* for BO management and your particular
> >>>> implementation does its own GEM handle reference counting, but that's
> >>>> not guaranted.)
> >>>>
> >>> Had a sneaky feeling that that != 1 will be returned for screen 1's
> >>> drmPrimeFdToHandle call.
> >>> Regardless, moving to DRI3/dmabuf-only setups is the [really] long
> >>> term plan, I think.
> >>> I don't know if we can achieve it outside of CrOS - with all the
> >>> distros building and shipping things in subtly different manner.
> >>
> >> It's already possible for Android.
> >>
> > Great. Feel free to join me in pushing distributions forward ;-)
>
> I'll trade you Android for any thing else. :)
>
>
> >>>>> How would that work if you support different GPUs in one image?
> >>>>
> >>>> It wouldn't and that's why I prefer probing available devices.
> >>>>
> >>>> For Chrome OS, we don't include GPU bits in system image, but rather
> >>>> have vendor images built separately for each board (although sharing
> >>>> any possible contents across board family, chipset, GPU type and so
> >>>> on), so we can have a custom .rc script (which sets a property) as
> >>>> well. It would even be possible to have paths hardcoded, but that
> >>>> would be prone to probe ordering issues which, with software fallback,
> >>>> could be actually not obvious to notice, and so we'd rather not go
> >>>> this route.
> >>>>
> >>>> So I'd agree here that we should revisit probing.
> >>>>
> >>> As you pointed out the fallback is not a good idea.
> >>
> >> Software fallback is a desired feature. Basing it on the path is the bad 
> >> idea.
> >>
> > Even considering that a) the transition is not obvious and b) it will
> > cause serve performance degradation?
> > For development and prototyping purposes it's great. For production
> > ... very few users will like the abysmal performance :-\
>
> Better slow than not booting. There are also usecases such as running
> in the cloud for running tests where performance is not too important.
> AOSP has "devices" now that build images for GCE. CrOS does something
> similar from what Tomasz has said.
>
> Software rendering should be the easy case, but some reason is not.

I think software fallback can be done reasonably right. Perhaps it
could kick in by default only if there is no matching hardware driver?
If there is a matching driver, but initialization fails, perhaps it
could make sense to boil out.

>
> >>> Plus, as the drm
> >>> node vary, one can use an Android property and match it to the info.
> >>> from drmGetDevice2.
> >>> Say the HW bus location, (sub)device PCIID, other.
> >>
> >> That generally doesn't work for non-x86.
> >>
> > Errr... wrong. If PCI bus does not exist (some arm boards to have them
> > though), one can use usb, platform or host1x specifics.
> > If 

Re: [Mesa-dev] [PATCH v1 0/7] Implement commont gralloc_handle_t in libdrm

[Tomasz Figa]

On Wed, Feb 21, 2018 at 4:03 AM, Rob Herring <r...@kernel.org> wrote:
> On Tue, Feb 20, 2018 at 4:26 AM, Tomasz Figa <tf...@chromium.org> wrote:
>> On Tue, Feb 20, 2018 at 6:51 PM, Robert Foss <robert.f...@collabora.com> 
>> wrote:
>>> Hey Tomasz,
>>>
>>> On 02/20/2018 09:55 AM, Tomasz Figa wrote:
>>>>
>>>> Hi Rob,
>>>>
>>>> On Fri, Feb 16, 2018 at 11:48 PM, Tomasz Figa <tf...@chromium.org> wrote:
>>>>>
>>>>> On Fri, Feb 16, 2018 at 11:33 PM, Robert Foss <robert.f...@collabora.com>
>>>>> wrote:
>>>>>>
>>>>>> Hey Tomasz,
>>>>>>
>>>>>>
>>>>>> On 02/16/2018 05:10 AM, Tomaszzz Figa wrote:
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Feb 9, 2018 at 11:06 PM, Rob Herring <r...@kernel.org> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Feb 9, 2018 at 3:58 AM, Tomasz Figa <tfiga@chromi
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Feb 2, 2018 at 2:01 AM, Tomasz Figa <tf...@chromium.org>
>>>>>>>>>>>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Hi Rob,
>>>>>>>>>>>>
>>>>>>>>>>>> On Tue, Jan 30, 2018 at 9:36 PM, Robert Foss
>>>>>>>>>>>> <robert.f...@collabora.com> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> uint32_t (*get_fd)(buffer_handle_t handle, uint32_t
>>>>>>>>>>>>>>>>>> plane);
>>>>>>>>>>>>>>>>>> uint64_t (*get_modifier)(buffer_handle_t handle,
>>>>>>>>>>>>>>>>>> uint32_t
>>>>>>>>>>>>>>>>>> plane);
>>>>>>>>>>>>>>>>>> uint32_t (*get_offsets)(buffer_handle_t handle,
>>>>>>>>>>>>>>>>>> uint32_t
>>>>>>>>>>>>>>>>>> plane);
>>>>>>>>>>>>>>>>>> uint32_t (*get_stride)(buffer_handle_t handle,
>>>>>>>>>>>>>>>>>> uint32_t
>>>>>>>>>>>>>>>>>> plane);
>>>>>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>>>>>> } gralloc_funcs_t;
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> These ones? >
>>>>>>>>>>>>>> Yeah, if we could retrieve such function pointer struct using
>>>>>>>>>>>>>> perform
>>>>>>>>>>>>>> or any equivalent (like the implementation-specific methods in
>>>>>>>>>>>>>> gralloc1, but not sure if that's going to be used in practice
>>>>>>>>>>>>>> anywhere), it could work for us.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> So this is where you and Rob Herring lose me, I don't think I
>>>>>>>>>>>>> understand
>>>>>>>>>>>>> quite how the gralloc1 call would be used, and how it would tie
>>>>>>>>>>>>> into
>>>>>>>>>>>>> this
>>>>>>>>>>>>> handle struct. I think I could do with some guidance on this.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> This would be

Re: [Mesa-dev] [PATCH v1 0/7] Implement commont gralloc_handle_t in libdrm

[Tomasz Figa]

On Tue, Feb 20, 2018 at 6:51 PM, Robert Foss <robert.f...@collabora.com> wrote:
> Hey Tomasz,
>
> On 02/20/2018 09:55 AM, Tomasz Figa wrote:
>>
>> Hi Rob,
>>
>> On Fri, Feb 16, 2018 at 11:48 PM, Tomasz Figa <tf...@chromium.org> wrote:
>>>
>>> On Fri, Feb 16, 2018 at 11:33 PM, Robert Foss <robert.f...@collabora.com>
>>> wrote:
>>>>
>>>> Hey Tomasz,
>>>>
>>>>
>>>> On 02/16/2018 05:10 AM, Tomaszzz Figa wrote:
>>>>>
>>>>>
>>>>> On Fri, Feb 9, 2018 at 11:06 PM, Rob Herring <r...@kernel.org> wrote:
>>>>>>
>>>>>>
>>>>>> On Fri, Feb 9, 2018 at 3:58 AM, Tomasz Figa <tfiga@chromi
>>>>>>>>>
>>>>>>>>> On Fri, Feb 2, 2018 at 2:01 AM, Tomasz Figa <tf...@chromium.org>
>>>>>>>>>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Hi Rob,
>>>>>>>>>>
>>>>>>>>>> On Tue, Jan 30, 2018 at 9:36 PM, Robert Foss
>>>>>>>>>> <robert.f...@collabora.com> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> uint32_t (*get_fd)(buffer_handle_t handle, uint32_t
>>>>>>>>>>>>>>>> plane);
>>>>>>>>>>>>>>>> uint64_t (*get_modifier)(buffer_handle_t handle,
>>>>>>>>>>>>>>>> uint32_t
>>>>>>>>>>>>>>>> plane);
>>>>>>>>>>>>>>>> uint32_t (*get_offsets)(buffer_handle_t handle,
>>>>>>>>>>>>>>>> uint32_t
>>>>>>>>>>>>>>>> plane);
>>>>>>>>>>>>>>>> uint32_t (*get_stride)(buffer_handle_t handle,
>>>>>>>>>>>>>>>> uint32_t
>>>>>>>>>>>>>>>> plane);
>>>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>>>> } gralloc_funcs_t;
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> These ones? >
>>>>>>>>>>>> Yeah, if we could retrieve such function pointer struct using
>>>>>>>>>>>> perform
>>>>>>>>>>>> or any equivalent (like the implementation-specific methods in
>>>>>>>>>>>> gralloc1, but not sure if that's going to be used in practice
>>>>>>>>>>>> anywhere), it could work for us.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> So this is where you and Rob Herring lose me, I don't think I
>>>>>>>>>>> understand
>>>>>>>>>>> quite how the gralloc1 call would be used, and how it would tie
>>>>>>>>>>> into
>>>>>>>>>>> this
>>>>>>>>>>> handle struct. I think I could do with some guidance on this.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> This would be very similar to gralloc0 perform call. gralloc1
>>>>>>>>>> implementations need to provide getFunction() callback [1], which
>>>>>>>>>> returns a pointer to given function. The list of standard
>>>>>>>>>> functions
>>>>>>>>>> is
>>>>>>>>>> defined in the gralloc1.h header [2], but we could take some
>>>>>>>>>> random
>>>>>>>>>> big number and use it for our function that fills in provided
>>>>>>>>>> gralloc_funcs_t struct with necessary pointers.
>>>>>>>>>>
>>

Re: [Mesa-dev] [PATCH v1 0/7] Implement commont gralloc_handle_t in libdrm

[Tomasz Figa]

Hi Rob,

On Fri, Feb 16, 2018 at 11:48 PM, Tomasz Figa <tf...@chromium.org> wrote:
> On Fri, Feb 16, 2018 at 11:33 PM, Robert Foss <robert.f...@collabora.com> 
> wrote:
>> Hey Tomasz,
>>
>>
>> On 02/16/2018 05:10 AM, Tomasz Figa wrote:
>>>
>>> On Fri, Feb 9, 2018 at 11:06 PM, Rob Herring <r...@kernel.org> wrote:
>>>>
>>>> On Fri, Feb 9, 2018 at 3:58 AM, Tomasz Figa <tf...@chromium.org> wrote:
>>>>>
>>>>> On Fri, Feb 2, 2018 at 11:51 PM, Tomasz Figa <tf...@chromium.org> wrote:
>>>>>>
>>>>>> On Fri, Feb 2, 2018 at 11:00 PM, Rob Herring <r...@kernel.org> wrote:
>>>>>>>
>>>>>>> On Fri, Feb 2, 2018 at 2:01 AM, Tomasz Figa <tf...@chromium.org>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hi Rob,
>>>>>>>>
>>>>>>>> On Tue, Jan 30, 2018 at 9:36 PM, Robert Foss
>>>>>>>> <robert.f...@collabora.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>uint32_t (*get_fd)(buffer_handle_t handle, uint32_t
>>>>>>>>>>>>>> plane);
>>>>>>>>>>>>>>uint64_t (*get_modifier)(buffer_handle_t handle,
>>>>>>>>>>>>>> uint32_t
>>>>>>>>>>>>>> plane);
>>>>>>>>>>>>>>uint32_t (*get_offsets)(buffer_handle_t handle, uint32_t
>>>>>>>>>>>>>> plane);
>>>>>>>>>>>>>>uint32_t (*get_stride)(buffer_handle_t handle, uint32_t
>>>>>>>>>>>>>> plane);
>>>>>>>>>>>>>>...
>>>>>>>>>>>>>> } gralloc_funcs_t;
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> These ones? >
>>>>>>>>>> Yeah, if we could retrieve such function pointer struct using
>>>>>>>>>> perform
>>>>>>>>>> or any equivalent (like the implementation-specific methods in
>>>>>>>>>> gralloc1, but not sure if that's going to be used in practice
>>>>>>>>>> anywhere), it could work for us.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> So this is where you and Rob Herring lose me, I don't think I
>>>>>>>>> understand
>>>>>>>>> quite how the gralloc1 call would be used, and how it would tie into
>>>>>>>>> this
>>>>>>>>> handle struct. I think I could do with some guidance on this.
>>>>>>>>
>>>>>>>>
>>>>>>>> This would be very similar to gralloc0 perform call. gralloc1
>>>>>>>> implementations need to provide getFunction() callback [1], which
>>>>>>>> returns a pointer to given function. The list of standard functions
>>>>>>>> is
>>>>>>>> defined in the gralloc1.h header [2], but we could take some random
>>>>>>>> big number and use it for our function that fills in provided
>>>>>>>> gralloc_funcs_t struct with necessary pointers.
>>>>>>>>
>>>>>>>> [1]
>>>>>>>> https://android.googlesource.com/platform/hardware/libhardware/+/master/include/hardware/gralloc1.h#300
>>>>>>>> [2]
>>>>>>>> https://android.googlesource.com/platform/hardware/libhardware/+/master/include/hardware/gralloc1.h#134
>>>>>>>
>>>>>>>
>>>>>>> This is a deadend because it won't work with a HIDL based
>>>>>>> implementation (aka gralloc 2.0). You can't set function pointers (or
>>>>>>> any pointers) because gralloc runs in a different process. Yes,
>>>>>>> currently gralloc is a pass-thru HAL, but AIUI that will go away.
>>>>>>
>>>>>>
>>>>>> Part of it. I can't see IMapper being implemented by a separate
>>>>>> process. You can't map a buffer into one process from another proce

Re: [Mesa-dev] [PATCH v1 0/7] Implement commont gralloc_handle_t in libdrm

[Tomasz Figa]

On Fri, Feb 16, 2018 at 11:33 PM, Robert Foss <robert.f...@collabora.com> wrote:
> Hey Tomasz,
>
>
> On 02/16/2018 05:10 AM, Tomasz Figa wrote:
>>
>> On Fri, Feb 9, 2018 at 11:06 PM, Rob Herring <r...@kernel.org> wrote:
>>>
>>> On Fri, Feb 9, 2018 at 3:58 AM, Tomasz Figa <tf...@chromium.org> wrote:
>>>>
>>>> On Fri, Feb 2, 2018 at 11:51 PM, Tomasz Figa <tf...@chromium.org> wrote:
>>>>>
>>>>> On Fri, Feb 2, 2018 at 11:00 PM, Rob Herring <r...@kernel.org> wrote:
>>>>>>
>>>>>> On Fri, Feb 2, 2018 at 2:01 AM, Tomasz Figa <tf...@chromium.org>
>>>>>> wrote:
>>>>>>>
>>>>>>> Hi Rob,
>>>>>>>
>>>>>>> On Tue, Jan 30, 2018 at 9:36 PM, Robert Foss
>>>>>>> <robert.f...@collabora.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>uint32_t (*get_fd)(buffer_handle_t handle, uint32_t
>>>>>>>>>>>>> plane);
>>>>>>>>>>>>>uint64_t (*get_modifier)(buffer_handle_t handle,
>>>>>>>>>>>>> uint32_t
>>>>>>>>>>>>> plane);
>>>>>>>>>>>>>uint32_t (*get_offsets)(buffer_handle_t handle, uint32_t
>>>>>>>>>>>>> plane);
>>>>>>>>>>>>>uint32_t (*get_stride)(buffer_handle_t handle, uint32_t
>>>>>>>>>>>>> plane);
>>>>>>>>>>>>>...
>>>>>>>>>>>>> } gralloc_funcs_t;
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> These ones? >
>>>>>>>>> Yeah, if we could retrieve such function pointer struct using
>>>>>>>>> perform
>>>>>>>>> or any equivalent (like the implementation-specific methods in
>>>>>>>>> gralloc1, but not sure if that's going to be used in practice
>>>>>>>>> anywhere), it could work for us.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> So this is where you and Rob Herring lose me, I don't think I
>>>>>>>> understand
>>>>>>>> quite how the gralloc1 call would be used, and how it would tie into
>>>>>>>> this
>>>>>>>> handle struct. I think I could do with some guidance on this.
>>>>>>>
>>>>>>>
>>>>>>> This would be very similar to gralloc0 perform call. gralloc1
>>>>>>> implementations need to provide getFunction() callback [1], which
>>>>>>> returns a pointer to given function. The list of standard functions
>>>>>>> is
>>>>>>> defined in the gralloc1.h header [2], but we could take some random
>>>>>>> big number and use it for our function that fills in provided
>>>>>>> gralloc_funcs_t struct with necessary pointers.
>>>>>>>
>>>>>>> [1]
>>>>>>> https://android.googlesource.com/platform/hardware/libhardware/+/master/include/hardware/gralloc1.h#300
>>>>>>> [2]
>>>>>>> https://android.googlesource.com/platform/hardware/libhardware/+/master/include/hardware/gralloc1.h#134
>>>>>>
>>>>>>
>>>>>> This is a deadend because it won't work with a HIDL based
>>>>>> implementation (aka gralloc 2.0). You can't set function pointers (or
>>>>>> any pointers) because gralloc runs in a different process. Yes,
>>>>>> currently gralloc is a pass-thru HAL, but AIUI that will go away.
>>>>>
>>>>>
>>>>> Part of it. I can't see IMapper being implemented by a separate
>>>>> process. You can't map a buffer into one process from another process.
>>>>>
>>>>> But anyway, it's a good point, thanks, I almost forgot about its
>>>>> existence. I'll do further investigation.
>>>>
>>>>
>>>> Okay, so IMapper indeed breaks the approach I suggested. I'm not sure
>>>> at the moment what we could do about it. (The idea of a dynamic
>

Re: [Mesa-dev] [PATCH v1 0/7] Implement commont gralloc_handle_t in libdrm

[Tomasz Figa]

On Fri, Feb 9, 2018 at 11:06 PM, Rob Herring <r...@kernel.org> wrote:
> On Fri, Feb 9, 2018 at 3:58 AM, Tomasz Figa <tf...@chromium.org> wrote:
>> On Fri, Feb 2, 2018 at 11:51 PM, Tomasz Figa <tf...@chromium.org> wrote:
>>> On Fri, Feb 2, 2018 at 11:00 PM, Rob Herring <r...@kernel.org> wrote:
>>>> On Fri, Feb 2, 2018 at 2:01 AM, Tomasz Figa <tf...@chromium.org> wrote:
>>>>> Hi Rob,
>>>>>
>>>>> On Tue, Jan 30, 2018 at 9:36 PM, Robert Foss <robert.f...@collabora.com> 
>>>>> wrote:
>>>>>>>>>>>   uint32_t (*get_fd)(buffer_handle_t handle, uint32_t plane);
>>>>>>>>>>>   uint64_t (*get_modifier)(buffer_handle_t handle, uint32_t
>>>>>>>>>>> plane);
>>>>>>>>>>>   uint32_t (*get_offsets)(buffer_handle_t handle, uint32_t 
>>>>>>>>>>> plane);
>>>>>>>>>>>   uint32_t (*get_stride)(buffer_handle_t handle, uint32_t 
>>>>>>>>>>> plane);
>>>>>>>>>>>   ...
>>>>>>>>>>> } gralloc_funcs_t;
>>>>>>>
>>>>>>>
>>>>>>> These ones? >
>>>>>>> Yeah, if we could retrieve such function pointer struct using perform
>>>>>>> or any equivalent (like the implementation-specific methods in
>>>>>>> gralloc1, but not sure if that's going to be used in practice
>>>>>>> anywhere), it could work for us.
>>>>>>
>>>>>>
>>>>>> So this is where you and Rob Herring lose me, I don't think I understand
>>>>>> quite how the gralloc1 call would be used, and how it would tie into this
>>>>>> handle struct. I think I could do with some guidance on this.
>>>>>
>>>>> This would be very similar to gralloc0 perform call. gralloc1
>>>>> implementations need to provide getFunction() callback [1], which
>>>>> returns a pointer to given function. The list of standard functions is
>>>>> defined in the gralloc1.h header [2], but we could take some random
>>>>> big number and use it for our function that fills in provided
>>>>> gralloc_funcs_t struct with necessary pointers.
>>>>>
>>>>> [1] 
>>>>> https://android.googlesource.com/platform/hardware/libhardware/+/master/include/hardware/gralloc1.h#300
>>>>> [2] 
>>>>> https://android.googlesource.com/platform/hardware/libhardware/+/master/include/hardware/gralloc1.h#134
>>>>
>>>> This is a deadend because it won't work with a HIDL based
>>>> implementation (aka gralloc 2.0). You can't set function pointers (or
>>>> any pointers) because gralloc runs in a different process. Yes,
>>>> currently gralloc is a pass-thru HAL, but AIUI that will go away.
>>>
>>> Part of it. I can't see IMapper being implemented by a separate
>>> process. You can't map a buffer into one process from another process.
>>>
>>> But anyway, it's a good point, thanks, I almost forgot about its
>>> existence. I'll do further investigation.
>>
>> Okay, so IMapper indeed breaks the approach I suggested. I'm not sure
>> at the moment what we could do about it. (The idea of a dynamic
>> library of a pre-defined name, exporting functions we specify, might
>> still work, though.)
>>
>> Note that the DRM_GRALLOC_GET_FD used currently by Mesa will also be
>> impossible to implement with IAllocator/IMapper. (Although I still
>> think Mesa and Gralloc are free to have separate logic for choosing
>> the DRM device to use.)
>
> I think the need for GET_FD goes away when the render node is used. We
> may still need the card node for s/w rendering (if I can ever get that
> working) though. Of course, if we use the vgem approach like CrOS then
> we wouldn't.

Hmm, if so, then we probably wouldn't have any strict need for these
function pointers anymore. We already have a makeshift format resolve
in place and the only missing bits that we still need to patch up
downstream are removing GET_FD, dropping drm_gralloc.h and adding a
fallback to kms_swrast if hw driver loading fails.

Best regards,
Tomasz
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v1 0/7] Implement commont gralloc_handle_t in libdrm

[Tomasz Figa]

On Fri, Feb 2, 2018 at 11:51 PM, Tomasz Figa <tf...@chromium.org> wrote:
> On Fri, Feb 2, 2018 at 11:00 PM, Rob Herring <r...@kernel.org> wrote:
>> On Fri, Feb 2, 2018 at 2:01 AM, Tomasz Figa <tf...@chromium.org> wrote:
>>> Hi Rob,
>>>
>>> On Tue, Jan 30, 2018 at 9:36 PM, Robert Foss <robert.f...@collabora.com> 
>>> wrote:
>>>>>>>>>   uint32_t (*get_fd)(buffer_handle_t handle, uint32_t plane);
>>>>>>>>>   uint64_t (*get_modifier)(buffer_handle_t handle, uint32_t
>>>>>>>>> plane);
>>>>>>>>>   uint32_t (*get_offsets)(buffer_handle_t handle, uint32_t plane);
>>>>>>>>>   uint32_t (*get_stride)(buffer_handle_t handle, uint32_t plane);
>>>>>>>>>   ...
>>>>>>>>> } gralloc_funcs_t;
>>>>>
>>>>>
>>>>> These ones? >
>>>>> Yeah, if we could retrieve such function pointer struct using perform
>>>>> or any equivalent (like the implementation-specific methods in
>>>>> gralloc1, but not sure if that's going to be used in practice
>>>>> anywhere), it could work for us.
>>>>
>>>>
>>>> So this is where you and Rob Herring lose me, I don't think I understand
>>>> quite how the gralloc1 call would be used, and how it would tie into this
>>>> handle struct. I think I could do with some guidance on this.
>>>
>>> This would be very similar to gralloc0 perform call. gralloc1
>>> implementations need to provide getFunction() callback [1], which
>>> returns a pointer to given function. The list of standard functions is
>>> defined in the gralloc1.h header [2], but we could take some random
>>> big number and use it for our function that fills in provided
>>> gralloc_funcs_t struct with necessary pointers.
>>>
>>> [1] 
>>> https://android.googlesource.com/platform/hardware/libhardware/+/master/include/hardware/gralloc1.h#300
>>> [2] 
>>> https://android.googlesource.com/platform/hardware/libhardware/+/master/include/hardware/gralloc1.h#134
>>
>> This is a deadend because it won't work with a HIDL based
>> implementation (aka gralloc 2.0). You can't set function pointers (or
>> any pointers) because gralloc runs in a different process. Yes,
>> currently gralloc is a pass-thru HAL, but AIUI that will go away.
>
> Part of it. I can't see IMapper being implemented by a separate
> process. You can't map a buffer into one process from another process.
>
> But anyway, it's a good point, thanks, I almost forgot about its
> existence. I'll do further investigation.

Okay, so IMapper indeed breaks the approach I suggested. I'm not sure
at the moment what we could do about it. (The idea of a dynamic
library of a pre-defined name, exporting functions we specify, might
still work, though.)

Note that the DRM_GRALLOC_GET_FD used currently by Mesa will also be
impossible to implement with IAllocator/IMapper. (Although I still
think Mesa and Gralloc are free to have separate logic for choosing
the DRM device to use.)

Best regards,
Tomasz
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v1 0/7] Implement commont gralloc_handle_t in libdrm

[Tomasz Figa]

On Fri, Feb 2, 2018 at 11:00 PM, Rob Herring <r...@kernel.org> wrote:
> On Fri, Feb 2, 2018 at 2:01 AM, Tomasz Figa <tf...@chromium.org> wrote:
>> Hi Rob,
>>
>> On Tue, Jan 30, 2018 at 9:36 PM, Robert Foss <robert.f...@collabora.com> 
>> wrote:
>>>>>>>>   uint32_t (*get_fd)(buffer_handle_t handle, uint32_t plane);
>>>>>>>>   uint64_t (*get_modifier)(buffer_handle_t handle, uint32_t
>>>>>>>> plane);
>>>>>>>>   uint32_t (*get_offsets)(buffer_handle_t handle, uint32_t plane);
>>>>>>>>   uint32_t (*get_stride)(buffer_handle_t handle, uint32_t plane);
>>>>>>>>   ...
>>>>>>>> } gralloc_funcs_t;
>>>>
>>>>
>>>> These ones? >
>>>> Yeah, if we could retrieve such function pointer struct using perform
>>>> or any equivalent (like the implementation-specific methods in
>>>> gralloc1, but not sure if that's going to be used in practice
>>>> anywhere), it could work for us.
>>>
>>>
>>> So this is where you and Rob Herring lose me, I don't think I understand
>>> quite how the gralloc1 call would be used, and how it would tie into this
>>> handle struct. I think I could do with some guidance on this.
>>
>> This would be very similar to gralloc0 perform call. gralloc1
>> implementations need to provide getFunction() callback [1], which
>> returns a pointer to given function. The list of standard functions is
>> defined in the gralloc1.h header [2], but we could take some random
>> big number and use it for our function that fills in provided
>> gralloc_funcs_t struct with necessary pointers.
>>
>> [1] 
>> https://android.googlesource.com/platform/hardware/libhardware/+/master/include/hardware/gralloc1.h#300
>> [2] 
>> https://android.googlesource.com/platform/hardware/libhardware/+/master/include/hardware/gralloc1.h#134
>
> This is a deadend because it won't work with a HIDL based
> implementation (aka gralloc 2.0). You can't set function pointers (or
> any pointers) because gralloc runs in a different process. Yes,
> currently gralloc is a pass-thru HAL, but AIUI that will go away.

Part of it. I can't see IMapper being implemented by a separate
process. You can't map a buffer into one process from another process.

But anyway, it's a good point, thanks, I almost forgot about its
existence. I'll do further investigation.

Best regards,
Tomasz
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v1 0/7] Implement commont gralloc_handle_t in libdrm

[Tomasz Figa]

Hi Rob,

On Tue, Jan 30, 2018 at 9:36 PM, Robert Foss  wrote:
>>   uint32_t (*get_fd)(buffer_handle_t handle, uint32_t plane);
>>   uint64_t (*get_modifier)(buffer_handle_t handle, uint32_t
>> plane);
>>   uint32_t (*get_offsets)(buffer_handle_t handle, uint32_t plane);
>>   uint32_t (*get_stride)(buffer_handle_t handle, uint32_t plane);
>>   ...
>> } gralloc_funcs_t;
>>
>>
>> These ones? >
>> Yeah, if we could retrieve such function pointer struct using perform
>> or any equivalent (like the implementation-specific methods in
>> gralloc1, but not sure if that's going to be used in practice
>> anywhere), it could work for us.
>
>
> So this is where you and Rob Herring lose me, I don't think I understand
> quite how the gralloc1 call would be used, and how it would tie into this
> handle struct. I think I could do with some guidance on this.

This would be very similar to gralloc0 perform call. gralloc1
implementations need to provide getFunction() callback [1], which
returns a pointer to given function. The list of standard functions is
defined in the gralloc1.h header [2], but we could take some random
big number and use it for our function that fills in provided
gralloc_funcs_t struct with necessary pointers.

[1] 
https://android.googlesource.com/platform/hardware/libhardware/+/master/include/hardware/gralloc1.h#300
[2] 
https://android.googlesource.com/platform/hardware/libhardware/+/master/include/hardware/gralloc1.h#134

With this, the buffer consumers (e.g. Mesa) would look like this:

consume_buffer(priv, handle)
{
gralloc_funcs_t funcs;

if (priv->gralloc1) {
DRM_GRALLOC1_PFN_GET_GRALLOC_FUNCS get_gralloc_funcs;

get_gralloc_func = priv->gralloc1->getFunction(priv->gralloc1,
DRM_GRALLOC1_FUNCTION_GET_GRALLOC_FUNCS);
get_gralloc_func(priv->gralloc1, handle, ); // Not sure
if the handle is even necessary
} else /* gralloc0 */ {
priv->gralloc0->perform(priv->gralloc0,
DRM_GRALLOC_PERFORM_GET_GRALLOC_FUNCS, );
}

// funcs has everything that the consumer needs to deal with the buffer
}

Best regards,
Tomasz
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gallium/winsys/kms: Add support for multi-planes (v2)

[Tomasz Figa]

On Tue, Jan 9, 2018 at 6:15 PM, Tomasz Figa <tf...@chromium.org> wrote:
> Adding some folks on CC for broader distribution.
>
> On Tue, Jan 9, 2018 at 3:52 PM, Lepton Wu <lep...@chromium.org> wrote:
>> Gentle ping. Thanks.
>>
>> On Wed, Dec 27, 2017 at 11:35 PM, Lepton Wu <lep...@chromium.org> wrote:
>>> v2: address comments from Tomasz Figa
>>>a) Add more check for plane size.
>>>b) Avoid duplicated mapping and leaked mapping.
>>>c) Other minor changes.
>>>
>>> Signed-off-by: Lepton Wu <lep...@chromium.org>
>>>
>>> Change-Id: I0863f522976cc8863d6e95492d9346df35c066ec
>>> ---
>>>  src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c | 179 
>>> +++---
>>>  1 file changed, 126 insertions(+), 53 deletions(-)

Well, if it's worth anything:

Reviewed-by: Tomasz Figa <tf...@chromium.org>

Would appreciate if some other user of kms_swrast took a look as well. :)

Best regards,
Tomasz
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v1 0/7] Implement commont gralloc_handle_t in libdrm

[Tomasz Figa]

Hi Rob,

On Tue, Jan 30, 2018 at 1:17 AM, Robert Foss  wrote:
> Hey Tomasz,
>
> I'm tempted to split this work into two parts.
> 1) Move gbm gralloc struct

Alright, if we look at this only as an attempt to converge gbm_ and
drm_gralloc, it's out of my scope and no concern anymore.

> 2) Accessor functions
>
> I would like to get 1) out the door to support John Stultzs current HiKey
> 960 efforts. As for 2), it would seem that we have some more discussing to
> do. But I'll keep pushing that forward.
>
> Separately, I'd like to know if the below sketch of a func ptr solution is
> what you had in mind. From what I've gathered this is exactly what you've
> requested, but I would like to confirm it too.

I assume you mean the ones below?

>
> I'll send out a v2, that covers 1) later today.
>
>
> Rob.
>
>
> On 01/29/2018 01:03 PM, Robert Foss wrote:
[snip]
>>
>>>
  uint32_t (*get_fd)(buffer_handle_t handle, uint32_t plane);
  uint64_t (*get_modifier)(buffer_handle_t handle, uint32_t plane);
  uint32_t (*get_offsets)(buffer_handle_t handle, uint32_t plane);
  uint32_t (*get_stride)(buffer_handle_t handle, uint32_t plane);
  ...
 } gralloc_funcs_t;

These ones?

Yeah, if we could retrieve such function pointer struct using perform
or any equivalent (like the implementation-specific methods in
gralloc1, but not sure if that's going to be used in practice
anywhere), it could work for us.

I think we could also add .get_fourcc(handle) and
.get_num_planes(handle) callbacks, so that we could do away with the
whole sophisticated format guessing based on Android HAL format and
lock_ycbcr results.

Perhaps an integer version field would also be useful, in case we end
up adding some more callbacks.

Best regards,
Tomasz
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v1 0/7] Implement commont gralloc_handle_t in libdrm

[Tomasz Figa]

Hi Robert,

On Wed, Jan 17, 2018 at 2:36 AM, Robert Foss  wrote:
> This series moves {gbm,drm,cros}_gralloc_handle_t struct to libdrm,
> since at least 4 implementations exist, and share a lot of contents.
> The idea is to keep the common stuff defined in one place, and libdrm
> is the common codebase to all of these platforms.
>
>
> Additionally, having this struct defined in libdrm will make it
> easier for mesa and gralloc implementations to communicate.
>
> Robert Foss (7):
>   android: Move gralloc handle struct to libdrm
>   android: Add version variable to gralloc_handle_t
>   android: Mark gralloc_handle_t magic variable as const
>   android: Remove member name from gralloc_handle_t
>   android: Change gralloc_handle_t format from Android format to fourcc
>   android: Change gralloc_handle_t members to be fixed width
>   android: Add accessor functions for gralloc_handle_t variables

Again, thanks for working on this.

I looked through the series and it seems to be much different from
what I imagined when writing my previous reply. I must have
misunderstood your proposal back then.

Generally, current series doesn't solve Chromium OS main concern of
locking down the handle struct. Even though accessors are added, they
are implemented in libdrm and refer to the exact handle layout as per
the handle struct defined by libdrm.

What I had in my mind, would be creating a secondary struct,
consisting only of callbacks, which would be filled in by particular
gralloc implementation running in the system with its accessors. This
would completely eliminate any dependencies on the handle struct
itself from consumers of gralloc buffers.

Best regards,
Tomasz
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [egl/android: Implement the eglSwapinterval for Android] egl/android: Implement the eglSwapinterval for Android.

[Tomasz Figa]

Hi Zhongmin,

On Tue, Jan 16, 2018 at 4:07 PM, Wu, Zhongmin <zhongmin...@intel.com> wrote:
> Sorry, is there any comment about the below patch, Thanks very much! Or did I 
> miss something ?

I assumed this was sent by mistake. The subject doesn't look like a
patch for review - it should have [PATCH] prefix. There was even a
follow-up email (presumably generated by your mailing client) to
cancel sending it.

Also please remove internal annotations, such as gerrit Change-Id,
since they do not have any meaning for upstream purposes.

As for the change itself, it looks fine to me, +/- some style
nitpicks, which I listed inline. Have you checked if there are no dEQP
regressions (at least for the EGL suite)?

Best regards,
Tomasz

>
> -Original Message-
> From: Wu, Zhongmin
> Sent: Wednesday, January 3, 2018 10:11
> To: mesa-dev@lists.freedesktop.org
> Cc: Kondapally, Kalyan <kalyan.kondapa...@intel.com>; Palli, Tapani 
> <tapani.pa...@intel.com>; Xu, Randy <randy...@intel.com>; Long, Zhifang 
> <zhifang.l...@intel.com>; Wu, Zhongmin <zhongmin...@intel.com>; Rob Herring 
> <r...@kernel.org>; Tomasz Figa <tf...@chromium.org>; Eric Engestrom 
> <e...@engestrom.ch>; Emil Velikov <emil.l.veli...@gmail.com>; Bhardwaj, 
> MunishX <munishx.bhard...@intel.com>; Kps, Harish Krupo 
> <harish.krupo@intel.com>; Chad Versace <chadvers...@chromium.org>
> Subject: [egl/android: Implement the eglSwapinterval for Android] 
> egl/android: Implement the eglSwapinterval for Android.
>
> From: Zhongmin Wu <zhongmin...@intel.com>
>
> Implement the eglSwapinterval for Android platform to enable the async mode 
> for some GFX benchmarks.
>
> Change-Id: I3576d8b92862719dae11c31e2adc2d77cb5a0b64
> Signed-off-by: Zhongmin Wu <zhongmin...@intel.com>
> ---
>  src/egl/drivers/dri2/platform_android.c | 15 +++
>  1 file changed, 15 insertions(+)
>
> diff --git a/src/egl/drivers/dri2/platform_android.c 
> b/src/egl/drivers/dri2/platform_android.c
> index f6a24cd..f9c74ee 100644
> --- a/src/egl/drivers/dri2/platform_android.c
> +++ b/src/egl/drivers/dri2/platform_android.c
> @@ -476,6 +476,18 @@ droid_destroy_surface(_EGLDriver *drv, _EGLDisplay 
> *disp, _EGLSurface *surf)
> return EGL_TRUE;
>  }
>
> +static EGLBoolean droid_swap_interval(_EGLDriver *drv, _EGLDisplay *dpy,
> +_EGLSurface *surf, EGLint interval) {

Please move the function name to new line, align the arguments with
the top lines, if there is a need to wrap the lines and move the
opening brace to new line, to match the coding style already used in
the file.

> +

No need for this blank line.

Best regards,
Tomasz
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC libdrm 0/5] Move alloc_handle_t from gralloc impls.

[Tomasz Figa]

On Tue, Jan 16, 2018 at 12:00 AM, Rob Herring  wrote:
> On Mon, Jan 15, 2018 at 7:09 AM, Robert Foss  
> wrote:
>> Hey,
>>
>> On 01/13/2018 12:49 AM, Gurchetan Singh wrote:
>>>
>>> We can define accessor functions too (not ptrs), then the struct is
>>> opaque
>>> and you can do your own accessor implementation if aligning is not
>>> possible
>>> or desired.
>>>
>>>
>>> Accessor functions in libdrm sound good to me.
>>
>>
>> Alright, this seems straight forward enough. As for the accessor
>> implementations, does anyone mind if I start out with support for multiple
>> planes even if the buffer handle currently doesn't contain multi plane
>> support
>> in various fields (fds, strides, offsets, etc.).
>
> That would be good. Once we convert over to the accessors in users,
> then we can change the handle.

Sounds good to me. FYI the handle used by cros_gralloc can already
describe multiple planes.

Best regards,
Tomasz
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC libdrm 0/5] Move alloc_handle_t from gralloc impls.

[Tomasz Figa]

Hi Rob,

On Fri, Jan 12, 2018 at 5:26 AM, Robert Foss <robert.f...@collabora.com> wrote:
> Heya,
>
>
> On 12/22/17 1:09 PM, Tomasz Figa wrote:
>>
>> On Fri, Dec 22, 2017 at 10:09 AM, Gurchetan Singh
>> <gurchetansi...@chromium.org> wrote:
>>>
>>> So the plan is for alloc_handle_t to not be sub-classed by the
>>> implementations, but have all necessary information that an
>>> implementation
>>> would need?
>>>
>>> If so, how do we reconcile the implementation specific information that
>>> is
>>> often in the handle:
>>>
>>>
>>> https://github.com/intel/minigbm/blob/master/cros_gralloc/cros_gralloc_handle.h
>>> [consumer_usage, producer_usage, yuv_color_range, is_updated etc.]
>>>
>>>
>>> https://chromium.googlesource.com/chromiumos/platform/minigbm/+/master/cros_gralloc/cros_gralloc_handle.h
>>> [use_flags, pixel_stride]
>>>
>>> In our case, removing our minigbm specific use flags from the handle
>>> would
>>> add complexity to our (*registerBuffer) path.
>>>
>>> On Thu, Dec 21, 2017 at 10:14 AM, Rob Herring <r...@kernel.org> wrote:
>>>>
>>>>
>>>> On Wed, Dec 13, 2017 at 5:02 PM, Gurchetan Singh
>>>> <gurchetansi...@chromium.org> wrote:
>>>>>
>>>>> Hi Robert,
>>>>>
>>>>> Thanks for looking into this!  We need to decide if we want:
>>>>>
>>>>> (1) A common struct that implementations can subclass, i.e:
>>>>>
>>>>> struct blah_gralloc_handle {
>>>>>  alloc_handle_t alloc_handle;
>>>>>  int x, y, z;
>>>>>  
>>>>> }
>>>>>
>>>>> (2) An accessor library that vendors can implement, i.e:
>>>>>
>>>>> struct drmAndroidHandleInfo {
>>>>> uint32_t (*get_fourcc)(buffer_handle_t handle);
>>>>> uint32_t (*get_stride)(buffer_handle_t handle, uint32_t plane);
>>>>> uint32_t (*get_offsets)(buffer_handle_t handle, uint32_t plane);
>>>>> uint64_t (*get_modifier)(buffer_handle_t handle);
>>>>> };
>>>>>
>>>>>  From my perspective as someone who has to maintain the minigbm gralloc
>>>>> implementation, (2) is preferable since:
>>>>
>>>>
>>>> Yeah, I'd prefer not to encourage 1 as the default.
>>>>
>
> So I had a look into implementing this,

Thanks!

> and using function pointers is
> problematic due to this struct being passed between processes which would
> prevent mesa calling a function assigned in gbm_gralloc for example.

Why would be this struct passed between processes?

The only data being exchanged between processes using gralloc is the
handle and it isn't actually exchanged directly, but the exporting
process will flatten it and send through Binder, while the importing
one will have it unflattened and then the gralloc implementation
called on it (the register buffer operation), which could update any
per-process data in the handle. (But still, why would we need to
include the function pointers there?)

>
> It could be used to provide runtime support for multiple gralloc
> implementations, but that seems to about the only advantage to adding FPs.
>
> Am I missing a good usecase for FPs? If not I think the added
> complexity/cruft is more problematic than good.
>
> Any thoughts?
>

I guess it might not be a big deal whether FPs or structs are used, as
long as they are not directly embedded in the handle, which we don't
want constraints on.

Best regards,
Tomasz

>
> Rob.
>
>
>>>>> a) We really don't have a need for fields like data_owner, void *data,
>>>>> etc.
>>>>
>>>>
>>>> We should be able to get rid of this. It's just for tracking imports.
>>>>
>>>>> Also, minigbm puts per plane fds, strides, offsets into the handle.
>>>>> Separating the information for the first plane (for the alloc_handle_t)
>>>>> and
>>>>> then rest of the planes would be annoying.
>>>>
>>>>
>>>> The plan is to add those to alloc_handle_t.
>>>>
>>>>> b) we can avoid the struct within a struct that happens when we
>>>>> subclass,
>>>>> since alignment/padding issues often pop up during
>>>>> serialization/de-serialization.  Using __attribute__((aligned(xx))) is
>>>>> less
>>>>> portable 

Re: [Mesa-dev] [PATCH] gallium/winsys/kms: Add support for multi-planes (v2)

[Tomasz Figa]

Adding some folks on CC for broader distribution.

On Tue, Jan 9, 2018 at 3:52 PM, Lepton Wu <lep...@chromium.org> wrote:
> Gentle ping. Thanks.
>
> On Wed, Dec 27, 2017 at 11:35 PM, Lepton Wu <lep...@chromium.org> wrote:
>> v2: address comments from Tomasz Figa
>>a) Add more check for plane size.
>>b) Avoid duplicated mapping and leaked mapping.
>>c) Other minor changes.
>>
>> Signed-off-by: Lepton Wu <lep...@chromium.org>
>>
>> Change-Id: I0863f522976cc8863d6e95492d9346df35c066ec
>> ---
>>  src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c | 179 
>> +++---
>>  1 file changed, 126 insertions(+), 53 deletions(-)
>>
>> diff --git a/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c 
>> b/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c
>> index 22e1c936ac5..69c05197081 100644
>> --- a/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c
>> +++ b/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c
>> @@ -59,20 +59,29 @@
>>  #define DEBUG_PRINT(msg, ...)
>>  #endif
>>
>> +struct kms_sw_displaytarget;
>>
>> -struct kms_sw_displaytarget
>> -{
>> -   enum pipe_format format;
>> +struct kms_sw_plane {
>> unsigned width;
>> unsigned height;
>> unsigned stride;
>> +   unsigned offset;
>> +   struct kms_sw_displaytarget* dt;
>> +   struct list_head link;
>> +};
>> +
>> +struct kms_sw_displaytarget
>> +{
>> +   enum pipe_format format;
>> unsigned size;
>>
>> uint32_t handle;
>> void *mapped;
>> +   void *ro_mapped;
>>
>> int ref_count;
>> struct list_head link;
>> +   struct list_head planes;
>>  };
>>
>>  struct kms_sw_winsys
>> @@ -83,10 +92,10 @@ struct kms_sw_winsys
>> struct list_head bo_list;
>>  };
>>
>> -static inline struct kms_sw_displaytarget *
>> -kms_sw_displaytarget( struct sw_displaytarget *dt )
>> +static inline struct kms_sw_plane *
>> +kms_sw_plane( struct sw_displaytarget *dt )
>>  {
>> -   return (struct kms_sw_displaytarget *)dt;
>> +   return (struct kms_sw_plane *)dt;
>>  }
>>
>>  static inline struct kms_sw_winsys *
>> @@ -105,6 +114,42 @@ kms_sw_is_displaytarget_format_supported( struct 
>> sw_winsys *ws,
>> return TRUE;
>>  }
>>
>> +static struct kms_sw_plane *get_plane(struct kms_sw_displaytarget 
>> *kms_sw_dt,
>> +  enum pipe_format format,
>> +  unsigned width, unsigned height,
>> +  unsigned stride, unsigned offset) {
>> +   struct kms_sw_plane * tmp, * plane = NULL;
>> +   if (offset + util_format_get_2d_size(format, stride, height) >
>> +   kms_sw_dt->size) {
>> +  DEBUG_PRINT("KMS-DEBUG: plane too big. format: %d stride: %d height: 
>> %d "
>> +  "offset: %d size:%d\n", format, stride, height, offset,
>> +  kms_sw_dt->size);
>> +  return NULL;
>> +   }
>> +   LIST_FOR_EACH_ENTRY(tmp, _sw_dt->planes, link) {
>> +  if (tmp->offset == offset) {
>> + plane = tmp;
>> + break;
>> +  }
>> +   }
>> +   if (plane) {
>> +  assert(plane->width == width);
>> +  assert(plane->height == height);
>> +  assert(plane->stride == stride);
>> +  assert(plane->dt == kms_sw_dt);
>> +   } else {
>> +  plane = CALLOC_STRUCT(kms_sw_plane);
>> +  if (plane == NULL) return NULL;
>> +  plane->width = width;
>> +  plane->height = height;
>> +  plane->stride = stride;
>> +  plane->offset = offset;
>> +  plane->dt = kms_sw_dt;
>> +  list_add(>link, _sw_dt->planes);
>> +   }
>> +   return plane;
>> +}
>> +
>>  static struct sw_displaytarget *
>>  kms_sw_displaytarget_create(struct sw_winsys *ws,
>>  unsigned tex_usage,
>> @@ -124,11 +169,10 @@ kms_sw_displaytarget_create(struct sw_winsys *ws,
>> if (!kms_sw_dt)
>>goto no_dt;
>>
>> +   list_inithead(_sw_dt->planes);
>> kms_sw_dt->ref_count = 1;
>>
>> kms_sw_dt->format = format;
>> -   kms_sw_dt->width = width;
>> -   kms_sw_dt->height = height;
>>
>> memset(_req, 0, sizeof(create_req));
>> create_req.bpp = 32;
>> @@ -138,17 +182,19 @@ kms_sw_displaytarget_crea

Re: [Mesa-dev] [RFC libdrm 0/5] Move alloc_handle_t from gralloc impls.

[Tomasz Figa]

On Fri, Dec 22, 2017 at 10:09 AM, Gurchetan Singh
 wrote:
> So the plan is for alloc_handle_t to not be sub-classed by the
> implementations, but have all necessary information that an implementation
> would need?
>
> If so, how do we reconcile the implementation specific information that is
> often in the handle:
>
> https://github.com/intel/minigbm/blob/master/cros_gralloc/cros_gralloc_handle.h
> [consumer_usage, producer_usage, yuv_color_range, is_updated etc.]
>
> https://chromium.googlesource.com/chromiumos/platform/minigbm/+/master/cros_gralloc/cros_gralloc_handle.h
> [use_flags, pixel_stride]
>
> In our case, removing our minigbm specific use flags from the handle would
> add complexity to our (*registerBuffer) path.
>
> On Thu, Dec 21, 2017 at 10:14 AM, Rob Herring  wrote:
>>
>> On Wed, Dec 13, 2017 at 5:02 PM, Gurchetan Singh
>>  wrote:
>> > Hi Robert,
>> >
>> > Thanks for looking into this!  We need to decide if we want:
>> >
>> > (1) A common struct that implementations can subclass, i.e:
>> >
>> > struct blah_gralloc_handle {
>> > alloc_handle_t alloc_handle;
>> > int x, y, z;
>> > 
>> > }
>> >
>> > (2) An accessor library that vendors can implement, i.e:
>> >
>> > struct drmAndroidHandleInfo {
>> >uint32_t (*get_fourcc)(buffer_handle_t handle);
>> >uint32_t (*get_stride)(buffer_handle_t handle, uint32_t plane);
>> >uint32_t (*get_offsets)(buffer_handle_t handle, uint32_t plane);
>> >uint64_t (*get_modifier)(buffer_handle_t handle);
>> > };
>> >
>> > From my perspective as someone who has to maintain the minigbm gralloc
>> > implementation, (2) is preferable since:
>>
>> Yeah, I'd prefer not to encourage 1 as the default.
>>
>> > a) We really don't have a need for fields like data_owner, void *data,
>> > etc.
>>
>> We should be able to get rid of this. It's just for tracking imports.
>>
>> > Also, minigbm puts per plane fds, strides, offsets into the handle.
>> > Separating the information for the first plane (for the alloc_handle_t)
>> > and
>> > then rest of the planes would be annoying.
>>
>> The plan is to add those to alloc_handle_t.
>>
>> > b) we can avoid the struct within a struct that happens when we
>> > subclass,
>> > since alignment/padding issues often pop up during
>> > serialization/de-serialization.  Using __attribute__((aligned(xx))) is
>> > less
>> > portable than maintaining a POD struct.
>>
>> Yes. Even just between 32 and 64 bit it's problematic.
>>
>>
>> > c) IMO creating the handle should be left to the gralloc implementation.
>> > Having accessor functions clearly defines what we need from libdrm -- to
>> > make up for shortcomings of the gralloc API for DRM/KMS use cases.
>> >

I think there might be also d). Define a standard struct in libdrm
headers and add a custom call to gralloc that would fill in such
struct for given buffer. This would keep the libdrm handle independent
of gralloc's internal handle.

P.S. Top-posting is bad.

Best regards,
Tomasz

>> >
>> > On Wed, Dec 13, 2017 at 9:30 AM, Robert Foss 
>> > wrote:
>> >>
>> >> This series moves {gbm,drm,cros}_gralloc_handle_t struct to libdrm,
>> >> since at least 4 implementations exist, and share a lot of contents.
>> >> The idea is to keep the common stuff defined in one place, and libdrm
>> >> is the common codebase to all of these platforms.
>> >>
>> >> Additionally, having this struct defined in libdrm will make it
>> >> easier for mesa and grallocs to communicate.
>> >>
>> >> Curretly missing is:
>> >>  - Planar formats
>> >>  - Get/Set functions
>> >>
>> >>
>> >> Planar formats
>> >> --
>> >> Support for planar formats is needed, but has not been added
>> >> yet, mostly since this was not already implemented in {gbm,drm}_gralloc
>> >> and the fact the having at least initial backwards compatability would
>> >> be nice. Anonymous unions can of course be used later on to provide
>> >> backwards compatability if so desired.
>> >>
>> >>
>> >> Get/Set functions
>> >> -
>> >> During the previous discussion[1] one suggestion was to add accessor
>> >> functions. In this RFC I've only provided a alloc_handle_create()
>> >> function.
>> >>
>> >> The Get/Set functions have not been added yet, I was hoping for some
>> >> conclusive arguments for them being adeded.
>> >>
>> >> Lastly it was suggested by Rob Herring that having a fourcc<->android
>> >> pixel format conversion function would be useful.
>> >>
>> >>
>> >> [1]
>> >>
>> >> https://lists.freedesktop.org/archives/mesa-dev/2017-November/178199.html
>> >>
>> >> Robert Foss (5):
>> >>   android: Move gralloc handle struct to libdrm
>> >>   android: Add version variable to alloc_handle_t
>> >>   android: Mark alloc_handle_t magic variable as const
>> >>   android: Remove member name from alloc_handle_t
>> >>   android: Change alloc_handle_t format from Android format to fourcc
>> >>
>> >>  Android.mk 

Re: [Mesa-dev] [PATCH] egl/android: Partially handle HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED

[Tomasz Figa]

On Sat, Dec 2, 2017 at 4:43 AM, Rob Herring <r...@kernel.org> wrote:
> On Fri, Dec 1, 2017 at 8:44 AM, Tomasz Figa <tf...@chromium.org> wrote:
>> On Fri, Dec 1, 2017 at 11:20 PM, Rob Herring <r...@kernel.org> wrote:
>>> On Fri, Dec 1, 2017 at 7:30 AM, Robert Foss <robert.f...@collabora.com> 
>>> wrote:
>>>> On Thu, 2017-11-30 at 11:14 -0600, Rob Herring wrote:
>>>>> On Thu, Nov 30, 2017 at 12:11 AM, Tapani Pälli <tapani.pa...@intel.co
>>>>> m> wrote:
>>>>> >
>>>>> >
>>>>> > On 11/30/2017 06:13 AM, Tomasz Figa wrote:
>>>>> > >
>>>>> > > On Thu, Nov 30, 2017 at 3:43 AM, Robert Foss <robert.foss@collabo
>>>>> > > ra.com>
>>>>> > > wrote:
>
> [...]
>
>>>>> > > (As a side note, I had an idea to create a new interface,
>>>>> > > standardized
>>>>> > > by Mesa, let's say libdri_android, completely free of any
>>>>> > > gralloc-internals. It would have to be exposed additionally by
>>>>> > > any
>>>>> > > Android that intends to run Mesa. Given the need to deal with 3
>>>>> > > different gralloc versions already, it could be something easier
>>>>> > > to
>>>>> > > manage.)
>>>>> >
>>>>> >
>>>>> > Makes sense, it is a bit messy and we have bit too much patches on
>>>>> > our tree
>>>>> > because of these differences.
>>>>>
>>>>> Seems overly complicated to me. The information needed is within the
>>>>> ints in the native_handle in most/all implementations. I don't think
>>>>> there's another way to globally store dmabuf metadata unless you have
>>>>> a custom interface in your DRM driver. So standardizing to a common
>>>>> library implies a common handle struct here. I think the options are:
>>>>>
>>>>> - common struct definition (native_handle_t + dmabuf fd(s) + width,
>>>>> height, stride, format, usage, etc.)
>>>>> - common struct plus inline accessor functions
>>>>> - common opaque struct plus accessor library
>>>>
>>>> So these common parts would be much like what currently exists in
>>>> minigbm/cros_gralloc_handle.h and gbm_gralloc/gralloc_drm_handle.h
>>>> then, but extended with the above suggestions?
>>>
>>> Yes, but which part do you think needs to be extended?
>>>
>>> As we discussed on IRC, I think perhaps we just need to change the
>>> handle format field in gralloc_drm_handle.h to use fourcc (aka DRM and
>>> GBM formats) instead of the Android format. I think all the users just
>>> end up converting it to their own internal format anyway.
>>
>> We keep the handle opaque for consumers and even minigbm dereferences
>> it only when creating/registering the buffer, further using the handle
>> pointer only as a key to internal bookkeeping map.
>
> What you say implies that you don't need any metadata in the handle,
> but you do have pretty much all the same data. Whether you
>
>> Relying on the struct itself is not only error prone, as there is no
>> way to check if the struct on gralloc implementation side matches what
>> we expect, but also makes it difficult to change the handle struct at
>> our convenience.
>
> How does a library solve this?
>
> Everything in Android gets built together and the handle pretty much
> has to stay the same across components in any implementation I've
> seen. Maybe someday that will change and we'll need versioning and
> backwards compatibility, but for now that's unnecessary complexity.
> We'd have to get to a single, well controlled and defined handle first
> anyway before we start versioning.
>
> Anyone is still free to change things downstream however they want.
> We're only talking about what does mainline/upstream do.
>
>>>>> Also, I don't think whatever is standardized should live in Mesa.
>>>>> There's a need to support drm_hwcomposer (which has the same
>>>>> dependencies as mesa) with non-Mesa GL implementations (yes, vendor
>>>>> binaries).
>>>>
>>>> Excluding Mesa and the composer leaves us with the allocator or
>>>> creating a new library.
>>>> I would assume that creating a new library is the worse option.
>>>
>>> Why excluding the composer

Re: [Mesa-dev] [PATCH] egl/android: Partially handle HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED

[Tomasz Figa]

On Fri, Dec 1, 2017 at 11:20 PM, Rob Herring <r...@kernel.org> wrote:
> On Fri, Dec 1, 2017 at 7:30 AM, Robert Foss <robert.f...@collabora.com> wrote:
>> On Thu, 2017-11-30 at 11:14 -0600, Rob Herring wrote:
>>> On Thu, Nov 30, 2017 at 12:11 AM, Tapani Pälli <tapani.pa...@intel.co
>>> m> wrote:
>>> >
>>> >
>>> > On 11/30/2017 06:13 AM, Tomasz Figa wrote:
>>> > >
>>> > > On Thu, Nov 30, 2017 at 3:43 AM, Robert Foss <robert.foss@collabo
>>> > > ra.com>
>>> > > wrote:
>>> > > >
>>> > > > Hey,
>>> > > >
>>> > > > On Tue, 2017-11-28 at 11:49 +, Emil Velikov wrote:
>>> > > > >
>>> > > > > On 28 November 2017 at 10:45, Tapani Pälli <tapani.palli@inte
>>> > > > > l.com>
>>> > > > > wrote:
>>> > > > > >
>>> > > > > > Hi;
>>> > > > > >
>>> > > > > >
>>> > > > > > On 11/27/2017 04:14 PM, Robert Foss wrote:
>>> > > > > > >
>>> > > > > > >
>>> > > > > > > From: Tomasz Figa <tf...@chromium.org>
>>> > > > > > >
>>> > > > > > > There is no API available to properly query the
>>> > > > > > > IMPLEMENTATION_DEFINED
>>> > > > > > > format. As a workaround we rely here on gralloc
>>> > > > > > > allocating either
>>> > > > > > > an arbitrary YCbCr 4:2:0 or RGBX_, with the latter
>>> > > > > > > being
>>> > > > > > > recognized
>>> > > > > > > by lock_ycbcr failing.
>>> > > > > > >
>>> > > > > > > Reviewed-on: https://chromium-review.googlesource.com/566
>>> > > > > > > 793
>>> > > > > > >
>>> > > > > > > Signed-off-by: Tomasz Figa <tf...@chromium.org>
>>> > > > > > > Reviewed-by: Chad Versace <chadvers...@chromium.org>
>>> > > > > > > Signed-off-by: Robert Foss <robert.f...@collabora.com>
>>> > > > > > > ---
>>> > > > > > >src/egl/drivers/dri2/platform_android.c | 39
>>> > > > > > > +++--
>>> > > > > > >1 file changed, 37 insertions(+), 2 deletions(-)
>>> > > > > > >
>>> > > > > > > diff --git a/src/egl/drivers/dri2/platform_android.c
>>> > > > > > > b/src/egl/drivers/dri2/platform_android.c
>>> > > > > > > index 63223e9a69..ae914d79c1 100644
>>> > > > > > > --- a/src/egl/drivers/dri2/platform_android.c
>>> > > > > > > +++ b/src/egl/drivers/dri2/platform_android.c
>>> > > > > > > @@ -59,6 +59,10 @@ static const struct droid_yuv_format
>>> > > > > > > droid_yuv_formats[] = {
>>> > > > > > >   { HAL_PIXEL_FORMAT_YCbCr_420_888,   0, 1,
>>> > > > > > > __DRI_IMAGE_FOURCC_YUV420
>>> > > > > > > },
>>> > > > > > >   { HAL_PIXEL_FORMAT_YCbCr_420_888,   1, 1,
>>> > > > > > > __DRI_IMAGE_FOURCC_YVU420
>>> > > > > > > },
>>> > > > > > >   { HAL_PIXEL_FORMAT_YV12,1, 1,
>>> > > > > > > __DRI_IMAGE_FOURCC_YVU420
>>> > > > > > > },
>>> > > > > > > +   /* HACK: See droid_create_image_from_prime_fd() and
>>> > > > > > > b/32077885. */
>>> > > > > > > +   { HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED,   0, 2,
>>> > > > > > > __DRI_IMAGE_FOURCC_NV12 },
>>> > > > > > > +   { HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED,   0, 1,
>>> > > > > > > __DRI_IMAGE_FOURCC_YUV420 },
>>> > > > > > > +   { HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED,   1, 1,
>>> > > > > > > __DRI_IMAGE_FOURCC_YVU420 },
>>> > > > > >
>>> > > > > >
>>> > > > > >
>>> > > > > > On

Re: [Mesa-dev] [PATCH] egl/android: Partially handle HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED

[Tomasz Figa]

On Thu, Nov 30, 2017 at 3:43 AM, Robert Foss <robert.f...@collabora.com> wrote:
> Hey,
>
> On Tue, 2017-11-28 at 11:49 +, Emil Velikov wrote:
>> On 28 November 2017 at 10:45, Tapani Pälli <tapani.pa...@intel.com>
>> wrote:
>> > Hi;
>> >
>> >
>> > On 11/27/2017 04:14 PM, Robert Foss wrote:
>> > >
>> > > From: Tomasz Figa <tf...@chromium.org>
>> > >
>> > > There is no API available to properly query the
>> > > IMPLEMENTATION_DEFINED
>> > > format. As a workaround we rely here on gralloc allocating either
>> > > an arbitrary YCbCr 4:2:0 or RGBX_, with the latter being
>> > > recognized
>> > > by lock_ycbcr failing.
>> > >
>> > > Reviewed-on: https://chromium-review.googlesource.com/566793
>> > >
>> > > Signed-off-by: Tomasz Figa <tf...@chromium.org>
>> > > Reviewed-by: Chad Versace <chadvers...@chromium.org>
>> > > Signed-off-by: Robert Foss <robert.f...@collabora.com>
>> > > ---
>> > >   src/egl/drivers/dri2/platform_android.c | 39
>> > > +++--
>> > >   1 file changed, 37 insertions(+), 2 deletions(-)
>> > >
>> > > diff --git a/src/egl/drivers/dri2/platform_android.c
>> > > b/src/egl/drivers/dri2/platform_android.c
>> > > index 63223e9a69..ae914d79c1 100644
>> > > --- a/src/egl/drivers/dri2/platform_android.c
>> > > +++ b/src/egl/drivers/dri2/platform_android.c
>> > > @@ -59,6 +59,10 @@ static const struct droid_yuv_format
>> > > droid_yuv_formats[] = {
>> > >  { HAL_PIXEL_FORMAT_YCbCr_420_888,   0, 1,
>> > > __DRI_IMAGE_FOURCC_YUV420
>> > > },
>> > >  { HAL_PIXEL_FORMAT_YCbCr_420_888,   1, 1,
>> > > __DRI_IMAGE_FOURCC_YVU420
>> > > },
>> > >  { HAL_PIXEL_FORMAT_YV12,1, 1,
>> > > __DRI_IMAGE_FOURCC_YVU420
>> > > },
>> > > +   /* HACK: See droid_create_image_from_prime_fd() and
>> > > b/32077885. */
>> > > +   { HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED,   0, 2,
>> > > __DRI_IMAGE_FOURCC_NV12 },
>> > > +   { HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED,   0, 1,
>> > > __DRI_IMAGE_FOURCC_YUV420 },
>> > > +   { HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED,   1, 1,
>> > > __DRI_IMAGE_FOURCC_YVU420 },
>> >
>> >
>> > One alternative way would be to ask gralloc about these formats. On
>> > gralloc0
>> > this would need a perform() hook and gralloc1 has getFormat(). This
>> > is how
>> > it is done currently on Android-IA, see following commits:
>> >
>> > https://github.com/intel/external-mesa/commit/deb323eafa321c725805a
>> > 702ed19cb4983346b60
>> >
>> > https://github.com/intel/external-mesa/commit/7cc01beaf540e29862853
>> > 561ef93c6c4e86c4c1a
>> >
>> > Do you think this approach would work with Chromium as well?
>> >
>>
>> i think the Android-IA approach looks good, although it depends on
>> local gralloc0 changes. With gralloc1 on the horizon, I don't know
>> how
>> much sense it makes to extend the predecessor.
>> AFAICT the patch should not cause any issues and it's nicely
>> documented.
>
> I had a look at the chromiumos/minigbm implementation, and it does not
> contain a gralloc1 implementation as far as I can see. I assume that it
> is available somewhere, but maybe not on a public branch.
>
> Would it be possible to make the minigbm gralloc1 impl. public? That
> way I could submit a patch mirroring what intel/minigbm does.
>
> If you fine folks as at Google prefer to roll it yourselves, just give
> me a poke.

There is no gralloc1 implementation for ChromiumOS minigbm and AFAIK
we don't have any plans of adding one. AFAICT there is nothing we
would gain with it over gralloc0.

>
> Those are the two options I'm seeing.
>
> As for gralloc0 support, would it be needed?
>
>>
>> Perhaps someone from the Google/CrOS team can assist in making the
>> bug
>> public, although even then it might be better to focus on a 'perfect'
>> gralloc1?
>>
>> IMHO the patch looks perfectly reasonable and we could merge it even,
>> if we were to switch to gralloc1 in the not too distant future ;-)
>
> Maybe doing both is reasonable.

I believe there isn't much adoption of gralloc1 in the wild.
Android-IA is the first I saw (might have missed something, though).
Tapani, what was the reason for switching to gralloc1?

Could we just support gralloc0 for now in Mesa, make sure the next
generation IAllocator/IMapper stuff suites our needs and switch to it
later when it happens?

(As a side note, I had an idea to create a new interface, standardized
by Mesa, let's say libdri_android, completely free of any
gralloc-internals. It would have to be exposed additionally by any
Android that intends to run Mesa. Given the need to deal with 3
different gralloc versions already, it could be something easier to
manage.)

Best regards,
Tomasz
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] egl/android: Partially handle HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED

[Tomasz Figa]

On Tue, Nov 28, 2017 at 11:27 PM, Rob Herring  wrote:
> On Tue, Nov 28, 2017 at 5:49 AM, Emil Velikov  
> wrote:
>> On 28 November 2017 at 10:45, Tapani Pälli  wrote:
>>> Hi;
>>>
>>>
>>> On 11/27/2017 04:14 PM, Robert Foss wrote:
>
> [...]
>
 +   /* HACK: See droid_create_image_from_prime_fd() and b/32077885. */
 +   { HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED,   0, 2,
 __DRI_IMAGE_FOURCC_NV12 },
 +   { HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED,   0, 1,
 __DRI_IMAGE_FOURCC_YUV420 },
 +   { HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED,   1, 1,
 __DRI_IMAGE_FOURCC_YVU420 },
>>>
>>>
>>> One alternative way would be to ask gralloc about these formats. On gralloc0
>>> this would need a perform() hook and gralloc1 has getFormat(). This is how
>>> it is done currently on Android-IA, see following commits:
>>>
>>> https://github.com/intel/external-mesa/commit/deb323eafa321c725805a702ed19cb4983346b60
>>>
>>> https://github.com/intel/external-mesa/commit/7cc01beaf540e29862853561ef93c6c4e86c4c1a
>>>
>>> Do you think this approach would work with Chromium as well?
>>>
>> i think the Android-IA approach looks good, although it depends on
>> local gralloc0 changes. With gralloc1 on the horizon, I don't know how
>> much sense it makes to extend the predecessor.
>> AFAICT the patch should not cause any issues and it's nicely documented.
>>
>> Perhaps someone from the Google/CrOS team can assist in making the bug
>> public, although even then it might be better to focus on a 'perfect'
>> gralloc1?
>>
>> IMHO the patch looks perfectly reasonable and we could merge it even,
>> if we were to switch to gralloc1 in the not too distant future ;-)
>
> gralloc1 has already come and gone. The interface is now (in O+)
> IAllocator and IMapper aka gralloc 2.0.

Oh, that was a new one for me. Do you have any idea about real world
adoption of this interface? We're still using gralloc0 in Chrome OS
Android.

> There is neither perform nor
> getFormat(). Seemed to me gralloc1 was moving in the right direction,
> but I guess making cross process calls to retrieve buffer metadata was
> not a good design. Other than standardizing the native_handle_t
> fields, I'm not sure how one would solve this in a gralloc2 world.

Well, the ideal solution would be to extend IMapper in next version of
the interface to have a method that gives us the data we need.

If not, one could still do some hacks like a library exporting some
semi-standard functions which take a handle as an argument and provide
the data we need as a result.

Best regards,
Tomasz
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] egl/android: Partially handle HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED

[Tomasz Figa]

On Tue, Nov 28, 2017 at 7:12 PM, Eric Engestrom
<eric.engest...@imgtec.com> wrote:
> On Monday, 2017-11-27 22:00:43 +0100, Robert Foss wrote:
>> Hey Rob,
>>
>> On Mon, 2017-11-27 at 13:42 -0600, Rob Herring wrote:
>> > On Mon, Nov 27, 2017 at 8:14 AM, Robert Foss <robert.foss@collabora.c
>> > om> wrote:
>> > > From: Tomasz Figa <tf...@chromium.org>
>> > >
>> > > There is no API available to properly query the
>> > > IMPLEMENTATION_DEFINED
>> > > format. As a workaround we rely here on gralloc allocating either
>> > > an arbitrary YCbCr 4:2:0 or RGBX_, with the latter being
>> > > recognized
>> > > by lock_ycbcr failing.
>> > >
>> > > Reviewed-on: https://chromium-review.googlesource.com/566793
>> > >
>> > > Signed-off-by: Tomasz Figa <tf...@chromium.org>
>> > > Reviewed-by: Chad Versace <chadvers...@chromium.org>
>> > > Signed-off-by: Robert Foss <robert.f...@collabora.com>
>> > > ---
>> > >  src/egl/drivers/dri2/platform_android.c | 39
>> > > +++--
>> > >  1 file changed, 37 insertions(+), 2 deletions(-)
>> > >
>> > > diff --git a/src/egl/drivers/dri2/platform_android.c
>> > > b/src/egl/drivers/dri2/platform_android.c
>> > > index 63223e9a69..ae914d79c1 100644
>> > > --- a/src/egl/drivers/dri2/platform_android.c
>> > > +++ b/src/egl/drivers/dri2/platform_android.c
>> > > @@ -59,6 +59,10 @@ static const struct droid_yuv_format
>> > > droid_yuv_formats[] = {
>> > > { HAL_PIXEL_FORMAT_YCbCr_420_888,   0, 1,
>> > > __DRI_IMAGE_FOURCC_YUV420 },
>> > > { HAL_PIXEL_FORMAT_YCbCr_420_888,   1, 1,
>> > > __DRI_IMAGE_FOURCC_YVU420 },
>> > > { HAL_PIXEL_FORMAT_YV12,1, 1,
>> > > __DRI_IMAGE_FOURCC_YVU420 },
>> > > +   /* HACK: See droid_create_image_from_prime_fd() and b/32077885.
>> > > */
>> > > +   { HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED,   0, 2,
>> > > __DRI_IMAGE_FOURCC_NV12 },
>> > > +   { HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED,   0, 1,
>> > > __DRI_IMAGE_FOURCC_YUV420 },
>> > > +   { HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED,   1, 1,
>> > > __DRI_IMAGE_FOURCC_YVU420 },
>> > >  };
>> > >
>> > >  static int
>> > > @@ -90,6 +94,11 @@ get_format_bpp(int native)
>> > >
>> > > switch (native) {
>> > > case HAL_PIXEL_FORMAT_RGBA_:
>> > > +   case HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED:
>> > > +  /*
>> > > +   * HACK: Hardcode this to RGBX_ as per cros_gralloc
>> > > hack.
>> >
>> > Does this work with other grallocs?
>>
>> Not necessarily, it is implementation specific.
>> The implementation specific part is lock_ycbcr() failing for non YUV
>> formats, which allows the application to disambiguate between YCbCr
>> 4:2:0 or RGBX_.
>>
>> >
>> > > +   * TODO: Remove this once b/32077885 is fixed.
>> >
>> > Is that a public bug? A full url would be better if so.
>>
>> Unfortunately it isn't, I maintained the link since it is better than
>> nothing. And to be clear, I don't have access to that URL either at
>> this moment.
>
> Don't have access either, but I think the URL is
> https://issuetracker.google.com/32077885
>
> I just asked #dri-devel if someone has access and can confirm, so we can
> have the URL instead.

I'm afraid we can't open access to this bug, because it mentions
various things not released publicly yet. Let me summarize the problem
myself, since that would be the only useful information for this patch
anyway.

The HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED format is an opaque format
used currently by Android frameworks for virtual display and camera
use cases (when camera HAL v3 API is used). Buffers allocated for this
format are not supposed to be accessed by CPU and are expected to be
used only inside vendor-provided components, such as camera HAL,
hwcomposer HAL, EGL/GLES, etc.

What exactly the format means is up to gralloc implementation and
chosen format must satisfy usage flags given at allocation time. In
case of virtual display, the buffer must be renderable (for EGL/GLES)
and displayable (by hwcomposer HAL or SurfaceFlinger GLES fallback,
i.e. might be used as a texture by EGL/GLES). For camera use case, the
camera must be able to capture frames to the buffer and displayable.

Initially Chromium OS used to deal with this format with a very simple
hack - hardcoding to RGBX_ in all the parts of the stack. It
worked fine with our HAL v1-based camera, because it used legacy
formats. After we switched some platforms to HALv3, the format became
ambiguous, because the cameras typically produce some kind of YUV
pictures, which typically is not renderable by GPUs. That's why we
needed to allow our gralloc choose the real format depending on usage
flags and make other users use some interface to query it.

Best regards,
Tomasz
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] egl/android: Partially handle HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED

[Tomasz Figa]

On Tue, Nov 28, 2017 at 8:49 PM, Emil Velikov <emil.l.veli...@gmail.com> wrote:
> On 28 November 2017 at 10:45, Tapani Pälli <tapani.pa...@intel.com> wrote:
>> Hi;
>>
>>
>> On 11/27/2017 04:14 PM, Robert Foss wrote:
>>>
>>> From: Tomasz Figa <tf...@chromium.org>
>>>
>>> There is no API available to properly query the IMPLEMENTATION_DEFINED
>>> format. As a workaround we rely here on gralloc allocating either
>>> an arbitrary YCbCr 4:2:0 or RGBX_, with the latter being recognized
>>> by lock_ycbcr failing.
>>>
>>> Reviewed-on: https://chromium-review.googlesource.com/566793
>>>
>>> Signed-off-by: Tomasz Figa <tf...@chromium.org>
>>> Reviewed-by: Chad Versace <chadvers...@chromium.org>
>>> Signed-off-by: Robert Foss <robert.f...@collabora.com>
>>> ---
>>>   src/egl/drivers/dri2/platform_android.c | 39
>>> +++--
>>>   1 file changed, 37 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/src/egl/drivers/dri2/platform_android.c
>>> b/src/egl/drivers/dri2/platform_android.c
>>> index 63223e9a69..ae914d79c1 100644
>>> --- a/src/egl/drivers/dri2/platform_android.c
>>> +++ b/src/egl/drivers/dri2/platform_android.c
>>> @@ -59,6 +59,10 @@ static const struct droid_yuv_format
>>> droid_yuv_formats[] = {
>>>  { HAL_PIXEL_FORMAT_YCbCr_420_888,   0, 1, __DRI_IMAGE_FOURCC_YUV420
>>> },
>>>  { HAL_PIXEL_FORMAT_YCbCr_420_888,   1, 1, __DRI_IMAGE_FOURCC_YVU420
>>> },
>>>  { HAL_PIXEL_FORMAT_YV12,1, 1, __DRI_IMAGE_FOURCC_YVU420
>>> },
>>> +   /* HACK: See droid_create_image_from_prime_fd() and b/32077885. */
>>> +   { HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED,   0, 2,
>>> __DRI_IMAGE_FOURCC_NV12 },
>>> +   { HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED,   0, 1,
>>> __DRI_IMAGE_FOURCC_YUV420 },
>>> +   { HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED,   1, 1,
>>> __DRI_IMAGE_FOURCC_YVU420 },
>>
>>
>> One alternative way would be to ask gralloc about these formats. On gralloc0
>> this would need a perform() hook and gralloc1 has getFormat(). This is how
>> it is done currently on Android-IA, see following commits:
>>
>> https://github.com/intel/external-mesa/commit/deb323eafa321c725805a702ed19cb4983346b60
>>
>> https://github.com/intel/external-mesa/commit/7cc01beaf540e29862853561ef93c6c4e86c4c1a
>>
>> Do you think this approach would work with Chromium as well?
>>
> i think the Android-IA approach looks good, although it depends on
> local gralloc0 changes. With gralloc1 on the horizon, I don't know how
> much sense it makes to extend the predecessor.
> AFAICT the patch should not cause any issues and it's nicely documented.
>
> Perhaps someone from the Google/CrOS team can assist in making the bug
> public, although even then it might be better to focus on a 'perfect'
> gralloc1?
>
> IMHO the patch looks perfectly reasonable and we could merge it even,
> if we were to switch to gralloc1 in the not too distant future ;-)

Looks very similar to my earlier internal proposal and should work for
us to, but need to test to make sure.

Best regards,
Tomasz
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] egl: refactor color_buffers structure for deduplicating (v2)

[Tomasz Figa]

Hi Gwan-gyeong,

Thanks for the patch!

On Wed, Nov 15, 2017 at 11:27 PM, Gwan-gyeong Mun <elong...@gmail.com> wrote:
> This is added for preventing adding of new color buffers structure and back*
> when new platform backend is added.
> This refactoring separates out the common and platform specific bits.
> This makes odd casting in the platform_foo.c but it prevents adding of new
> ifdef magic.
> Because of color_buffers array size is different on android and wayland /drm,
> it adds COLOR_BUFFERS_SIZE macro.
>  - android's color buffers array size is 3.
>drm & wayland's color buffers array size is 4.
>
> Fixes from Rob's review:
>  - refactor to separate out the common and platform specific bits.
>
> Fixes from Emil's review:
>  - use suggested color buffers structure shape.
>it makes a buffer pointer of each platform to void pointer type.
>
> v2: Fixes from Emil's review
>   a) change ifdef macro of "HAVE_WAYLAND_PLATFORM or HAVE_DRM_PLATFORM" to
>  "HAVE_ANDROID_PLATFORM" for COLOR_BUFFERS_SIZE.
>   b) drop the unneeded indentation of comment.
>   c) drop ifdef macro of HAVE_WAYLAND_PLATFORM from color_buffers structure
>  for more generic and widespread helpers.
>   d) drop unneeded $native_type -> void * cast and viceversa.
>   e) create the local native_buffer of $native_type and cast on assignment.
>
> Signed-off-by: Mun Gwan-gyeong <elong...@gmail.com>

The Android part looks good to me:

Reviewed-by: Tomasz Figa <tf...@chromium.org>

I think this patch actually enables us to do some further cleanup in
Android part. I'll try to send follow up patches in near future.

Best regards,
Tomasz

> ---
>  src/egl/drivers/dri2/egl_dri2.h | 32 --
>  src/egl/drivers/dri2/platform_android.c | 10 +++---
>  src/egl/drivers/dri2/platform_drm.c | 60 
> ++---
>  src/egl/drivers/dri2/platform_wayland.c | 41 +++---
>  4 files changed, 73 insertions(+), 70 deletions(-)
>
> diff --git a/src/egl/drivers/dri2/egl_dri2.h b/src/egl/drivers/dri2/egl_dri2.h
> index 0ec8f44dce..cbeedadd4b 100644
> --- a/src/egl/drivers/dri2/egl_dri2.h
> +++ b/src/egl/drivers/dri2/egl_dri2.h
> @@ -65,6 +65,15 @@ struct zwp_linux_dmabuf_v1;
>
>  #endif /* HAVE_ANDROID_PLATFORM */
>
> +#ifdef HAVE_ANDROID_PLATFORM
> +/* Usually Android uses at most triple buffers in ANativeWindow so hardcode
> + * the number of color_buffers to 3.
> + */
> +#define COLOR_BUFFERS_SIZE 3
> +#else
> +#define COLOR_BUFFERS_SIZE 4
> +#endif
> +
>  #include "eglconfig.h"
>  #include "eglcontext.h"
>  #include "egldisplay.h"
> @@ -280,39 +289,26 @@ struct dri2_egl_surface
> /* EGL-owned buffers */
> __DRIbuffer   *local_buffers[__DRI_BUFFER_COUNT];
>
> -#if defined(HAVE_WAYLAND_PLATFORM) || defined(HAVE_DRM_PLATFORM)
> +   /* Used to record all the buffers created by each platform's native window
> +* and their ages.
> +*/
> struct {
> -#ifdef HAVE_WAYLAND_PLATFORM
> -  struct wl_buffer   *wl_buffer;
> +  void *native_buffer; // aka wl_buffer/gbm_bo/ANativeWindowBuffer
>__DRIimage *dri_image;
>/* for is_different_gpu case. NULL else */
>__DRIimage *linear_copy;
>/* for swrast */
>void *data;
>int data_size;
> -#endif
> -#ifdef HAVE_DRM_PLATFORM
> -  struct gbm_bo   *bo;
> -#endif
>boollocked;
>int age;
> -   } color_buffers[4], *back, *current;
> -#endif
> +   } color_buffers[COLOR_BUFFERS_SIZE], *back, *current;
>
>  #ifdef HAVE_ANDROID_PLATFORM
> struct ANativeWindow *window;
> struct ANativeWindowBuffer *buffer;
> __DRIimage *dri_image_back;
> __DRIimage *dri_image_front;
> -
> -   /* Used to record all the buffers created by ANativeWindow and their ages.
> -* Usually Android uses at most triple buffers in ANativeWindow
> -* so hardcode the number of color_buffers to 3.
> -*/
> -   struct {
> -  struct ANativeWindowBuffer *buffer;
> -  int age;
> -   } color_buffers[3], *back;
>  #endif
>
>  #if defined(HAVE_SURFACELESS_PLATFORM)
> diff --git a/src/egl/drivers/dri2/platform_android.c 
> b/src/egl/drivers/dri2/platform_android.c
> index 63223e9a69..24e5ddebf9 100644
> --- a/src/egl/drivers/dri2/platform_android.c
> +++ b/src/egl/drivers/dri2/platform_android.c
> @@ -193,10 +193,10 @@ droid_window_dequeue_buffer(struct dri2_egl_surface 
> *dri2_surf)
>  */
> EGLBoolean updated = EGL_FALSE;
> for (int i = 0; i < ARRAY_SIZE(dri2_surf->color_buffers); i++) {
&

Re: [Mesa-dev] [PATCH] glsl: Allow precision mismatch on dead uniform with GLSL ES 1.00 (v3)

[Tomasz Figa]

Hi Kenneth,

On Tue, Nov 7, 2017 at 8:18 AM, Kenneth Graunke <kenn...@whitecape.org> wrote:
> On Thursday, October 19, 2017 9:02:20 PM PST Tomasz Figa wrote:
>> Hi Ian, Kenneth,
>>
>> On Wed, Sep 27, 2017 at 2:57 AM, Tomasz Figa <tf...@chromium.org> wrote:
>> > Commit 259fc505454ea6a67aeacf6cdebf1398d9947759 added linker error for
>> > mismatching uniform precision, as required by GLES 3.0 specification and
>> > conformance test-suite.
>> >
>> > Several Android applications, including Forge of Empires, have shaders
>> > which violate this rule, on uniforms that are declared but not used
>> > further in shader code. The problem affects a big number of Android
>> > games, including ones built on top of one of the common 2D graphics
>> > engines and other GLES implementations accept this, which poses a serious
>> > application compatibility issue.
>> >
>> > Starting from GLSL ES 3.0, declarations with conflicting precision
>> > qualifiers are explicitly prohibited. However GLSL ES 1.00 does not
>> > clearly specify the behavior, except that
>> >
>> >   "Uniforms are defined to behave as if they are using the same storage in
>> >   the vertex and fragment processors and may be implemented this way.
>> >   If uniforms are used in both the vertex and fragment shaders, developers
>> >   should be warned if the precisions are different. Conversion of
>> >   precision should never be implicit."
>> >
>> > The word "used" is not clear in this context and might refer to
>> >  1) declared (same as GLES 3.x)
>> >  2) referred after post-processing, or
>> >  3) linked after all optimizations are done.
>> >
>> > Looking at existing applications, 2) or 3) seems to be widely adopted.
>> > To avoid compatibility issues, turn the error into a warning if GLSL ES
>> > version is lower than 3.0 and the data is dead in at least one of the
>> > shaders.
>> >
>> > v3:
>> >  - Add a comment explaining the behavior.
>> >  - Fix bad copy/paste in commit message (s/varyings/uniforms).
>>
>> Would you be able to take a look?
>>
>> Ian, I believe your previous NAK was due to the confusing erroneous
>> copy/paste from the freedesktop bug I made in commit message. Looking
>> at last comment from Kenneth there, we were going to go with my patch,
>> but things remained quiet after that.
>>
>> Thanks,
>> Tomasz
>
> Sorry, this completely fell off my radar.  I've gone ahead and pushed
> your patch.  Dylan also sent out Piglit tests for this case today, which
> I've reviewed.

No worries, thanks a lot!

Best regards,
Tomasz
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH mesa] meson: wire up egl/android

[Tomasz Figa]

Hi everyone,

On Sat, Oct 28, 2017 at 2:38 AM, Dylan Baker <dy...@pnwbakers.com> wrote:
> Whooo! Thanks for doing this!
>
> Quoting Eric Engestrom (2017-10-27 07:40:17)
>> Cc: Rob Herring <r...@kernel.org>
>> Cc: Tomasz Figa <tf...@chromium.org>
>> Signed-off-by: Eric Engestrom <eric.engest...@imgtec.com>
>> ---
>> Completely untested!
>> It's a step in the right direction though; doesn't hurt non-android,
>> and gets android closer to building on meson :)
>> ---
>>  meson.build | 13 +++--
>>  src/egl/meson.build |  5 -
>>  2 files changed, 15 insertions(+), 3 deletions(-)

Thanks for looking into this!

I think I'd be the right person to test this with Chrome OS Android
build, but need to figure out how to use Meson with our Gentoo-based
build system. Do we already have upstream Gentoo experimenting with
Meson?

Best regards,
Tomasz

>>
>> diff --git a/meson.build b/meson.build
>> index 875f9d4d294d1911f239..761c33f4651ab37ab7b6 100644
>> --- a/meson.build
>> +++ b/meson.build
>> @@ -152,7 +152,7 @@ endif
>>  # TODO: other OSes
>>  with_dri_platform = 'drm'
>>
>> -# TODO: android platform
>> +with_platform_android = false
>>  with_platform_wayland = false
>>  with_platform_x11 = false
>>  with_platform_drm = false
>> @@ -161,6 +161,7 @@ egl_native_platform = ''
>>  _platforms = get_option('platforms')
>>  if _platforms != ''
>>_split = _platforms.split(',')
>> +  with_platform_android = _split.contains('android')
>>with_platform_x11 = _split.contains('x11')
>>with_platform_wayland = _split.contains('wayland')
>>with_platform_drm = _split.contains('drm')
>> @@ -252,7 +253,7 @@ if _vulkan_drivers != ''
>>with_intel_vk = _split.contains('intel')
>>with_amd_vk = _split.contains('amd')
>>with_any_vk = with_amd_vk or with_intel_vk
>> -  if not (with_platform_x11 or with_platform_wayland)
>> +  if not (with_platform_x11 or with_platform_wayland or 
>> with_platform_android)
>>  error('Vulkan requires at least one platform (x11, wayland)')
>>endif
>>  endif
>> @@ -330,6 +331,14 @@ endif
>>  if with_platform_surfaceless
>>pre_args += '-DHAVE_SURFACELESS_PLATFORM'
>>  endif
>> +if with_platform_android
>> +  dep_android = [
>> +  dependency('cutils'),
>> +  dependency('hardware'),
>> +  dependency('sync'),
>> +  ]
>
> The indent looks off here, it looks like 4 space instead of 2, and the closing
> brace should be dedented.
>
> Otherwise this looks good to me, though it would be great if one of the
> ChromeOS guys could look at it (since I think that android builds are always
> done with android.mk, and this would only be for the ChromeOS ARC++ container)
>
> Reviewed-by: Dylan Baker <dy...@pnwbakers.com>
>
>> +  pre_args += '-DHAVE_ANDROID_PLATFORM'
>> +endif
>>
>>  prog_python2 = find_program('python2')
>>  has_mako = run_command(prog_python2, '-c', 'import mako')
>> diff --git a/src/egl/meson.build b/src/egl/meson.build
>> index ea7ae06761f75c00a40c..cc51671f9d8f24708405 100644
>> --- a/src/egl/meson.build
>> +++ b/src/egl/meson.build
>> @@ -129,7 +129,10 @@ if with_platform_wayland
>>  'wayland/wayland-egl', 'wayland/wayland-drm',
>>)
>>  endif
>> -# TODO: android
>> +if with_platform_android
>> +  deps_for_egl += dep_android
>> +  files_egl += files('drivers/dri2/platform_android.c')
>> +endif
>>
>>  # TODO: glvnd
>>
>> --
>> Cheers,
>>   Eric
>>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] glsl: Allow precision mismatch on dead uniform with GLSL ES 1.00 (v3)

[Tomasz Figa]

Hi Ian, Kenneth,

On Wed, Sep 27, 2017 at 2:57 AM, Tomasz Figa <tf...@chromium.org> wrote:
> Commit 259fc505454ea6a67aeacf6cdebf1398d9947759 added linker error for
> mismatching uniform precision, as required by GLES 3.0 specification and
> conformance test-suite.
>
> Several Android applications, including Forge of Empires, have shaders
> which violate this rule, on uniforms that are declared but not used
> further in shader code. The problem affects a big number of Android
> games, including ones built on top of one of the common 2D graphics
> engines and other GLES implementations accept this, which poses a serious
> application compatibility issue.
>
> Starting from GLSL ES 3.0, declarations with conflicting precision
> qualifiers are explicitly prohibited. However GLSL ES 1.00 does not
> clearly specify the behavior, except that
>
>   "Uniforms are defined to behave as if they are using the same storage in
>   the vertex and fragment processors and may be implemented this way.
>   If uniforms are used in both the vertex and fragment shaders, developers
>   should be warned if the precisions are different. Conversion of
>   precision should never be implicit."
>
> The word "used" is not clear in this context and might refer to
>  1) declared (same as GLES 3.x)
>  2) referred after post-processing, or
>  3) linked after all optimizations are done.
>
> Looking at existing applications, 2) or 3) seems to be widely adopted.
> To avoid compatibility issues, turn the error into a warning if GLSL ES
> version is lower than 3.0 and the data is dead in at least one of the
> shaders.
>
> v3:
>  - Add a comment explaining the behavior.
>  - Fix bad copy/paste in commit message (s/varyings/uniforms).

Would you be able to take a look?

Ian, I believe your previous NAK was due to the confusing erroneous
copy/paste from the freedesktop bug I made in commit message. Looking
at last comment from Kenneth there, we were going to go with my patch,
but things remained quiet after that.

Thanks,
Tomasz

> v2:
>  - Change the behavior only for GLSL ES 1.00 shaders.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97532
> Signed-off-by: Tomasz Figa <tf...@chromium.org>
> ---
>  src/compiler/glsl/linker.cpp | 32 
>  1 file changed, 28 insertions(+), 4 deletions(-)
>
> diff --git a/src/compiler/glsl/linker.cpp b/src/compiler/glsl/linker.cpp
> index f352c5385ca..693c5ae3664 100644
> --- a/src/compiler/glsl/linker.cpp
> +++ b/src/compiler/glsl/linker.cpp
> @@ -1121,10 +1121,34 @@ cross_validate_globals(struct gl_shader_program *prog,
>   if (prog->IsES && (prog->data->Version != 310 ||
>  !var->get_interface_type()) &&
>   existing->data.precision != var->data.precision) {
> -linker_error(prog, "declarations for %s `%s` have "
> - "mismatching precision qualifiers\n",
> - mode_string(var), var->name);
> -return;
> +/*
> + * GLSL ES 3.00 is the first version that explicitly requires
> + * that uniform declarations have matching precision qualifiers.
> + *
> + * The only relevant part of GLSL ES 1.00 spec,
> + *
> + *  "If uniforms are used in both the vertex and fragment 
> shaders,
> + *   developers should be warned if the precisions are different.
> + *   Conversion of precision should never be implicit."
> + *
> + * leaves too wide field for intepretation. However, judging by
> + * applications and implementations existing in the wild, it 
> seems
> + * to be widely assumed that declarations alone are not enough to
> + * fail the link.
> + *
> + * Thus, in case of GLSL ES < 3.00, trigger an error only if the
> + * uniform is actually referenced in the code of both shaders.
> + */
> +if ((existing->data.used && var->data.used) || 
> prog->data->Version >= 300) {
> +   linker_error(prog, "declarations for %s `%s` have "
> +"mismatching precision qualifiers\n",
> +mode_string(var), var->name);
> +   return;
> +} else {
> +   linker_warning(prog, "declarations for %s `%s` have "
> +  "mismatching precision qualifiers\n",
> +  mode_string(var), var->name);
> +}
>   }
>} else
>   variables->add_variable(var);
> --
> 2.14.1.992.g2c7b836f3a-goog
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] egl/dri2: Implement swapInterval fallback in a conformant way (v2)

[Tomasz Figa]

On Wed, Sep 27, 2017 at 11:06 PM, Emil Velikov <emil.l.veli...@gmail.com> wrote:
> On 25 September 2017 at 08:25, Tomasz Figa <tf...@chromium.org> wrote:
>
>> Gentle ping. :)
>>
>
> I forgot that you don't have commit access. Can you please apply for one?

Yep, I have it on my list, sorry for being slow. Thanks for useful
links. (Need to dig out my PGP key.)

Best regards,
Tomasz

>
> Thanks
> Emil
>
> [1] https://www.freedesktop.org/wiki/AccountRequests/
> [2] https://bugs.freedesktop.org/show_bug.cgi?id=99601
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] glsl: Allow precision mismatch on dead uniform with GLSL ES 1.00 (v3)

[Tomasz Figa]

Commit 259fc505454ea6a67aeacf6cdebf1398d9947759 added linker error for
mismatching uniform precision, as required by GLES 3.0 specification and
conformance test-suite.

Several Android applications, including Forge of Empires, have shaders
which violate this rule, on uniforms that are declared but not used
further in shader code. The problem affects a big number of Android
games, including ones built on top of one of the common 2D graphics
engines and other GLES implementations accept this, which poses a serious
application compatibility issue.

Starting from GLSL ES 3.0, declarations with conflicting precision
qualifiers are explicitly prohibited. However GLSL ES 1.00 does not
clearly specify the behavior, except that

  "Uniforms are defined to behave as if they are using the same storage in
  the vertex and fragment processors and may be implemented this way.
  If uniforms are used in both the vertex and fragment shaders, developers
  should be warned if the precisions are different. Conversion of
  precision should never be implicit."

The word "used" is not clear in this context and might refer to
 1) declared (same as GLES 3.x)
 2) referred after post-processing, or
 3) linked after all optimizations are done.

Looking at existing applications, 2) or 3) seems to be widely adopted.
To avoid compatibility issues, turn the error into a warning if GLSL ES
version is lower than 3.0 and the data is dead in at least one of the
shaders.

v3:
 - Add a comment explaining the behavior.
 - Fix bad copy/paste in commit message (s/varyings/uniforms).
v2:
 - Change the behavior only for GLSL ES 1.00 shaders.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97532
Signed-off-by: Tomasz Figa <tf...@chromium.org>
---
 src/compiler/glsl/linker.cpp | 32 
 1 file changed, 28 insertions(+), 4 deletions(-)

diff --git a/src/compiler/glsl/linker.cpp b/src/compiler/glsl/linker.cpp
index f352c5385ca..693c5ae3664 100644
--- a/src/compiler/glsl/linker.cpp
+++ b/src/compiler/glsl/linker.cpp
@@ -1121,10 +1121,34 @@ cross_validate_globals(struct gl_shader_program *prog,
  if (prog->IsES && (prog->data->Version != 310 ||
 !var->get_interface_type()) &&
  existing->data.precision != var->data.precision) {
-linker_error(prog, "declarations for %s `%s` have "
- "mismatching precision qualifiers\n",
- mode_string(var), var->name);
-return;
+/*
+ * GLSL ES 3.00 is the first version that explicitly requires
+ * that uniform declarations have matching precision qualifiers.
+ *
+ * The only relevant part of GLSL ES 1.00 spec,
+ *
+ *  "If uniforms are used in both the vertex and fragment shaders,
+ *   developers should be warned if the precisions are different.
+ *   Conversion of precision should never be implicit."
+ *
+ * leaves too wide field for intepretation. However, judging by
+ * applications and implementations existing in the wild, it seems
+ * to be widely assumed that declarations alone are not enough to
+ * fail the link.
+ *
+ * Thus, in case of GLSL ES < 3.00, trigger an error only if the
+ * uniform is actually referenced in the code of both shaders.
+ */
+if ((existing->data.used && var->data.used) || prog->data->Version 
>= 300) {
+   linker_error(prog, "declarations for %s `%s` have "
+"mismatching precision qualifiers\n",
+mode_string(var), var->name);
+   return;
+} else {
+   linker_warning(prog, "declarations for %s `%s` have "
+  "mismatching precision qualifiers\n",
+  mode_string(var), var->name);
+}
  }
   } else
  variables->add_variable(var);
-- 
2.14.1.992.g2c7b836f3a-goog

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] glsl: Allow precision mismatch on dead data with GLSL ES 1.00

[Tomasz Figa]

On Wed, Sep 27, 2017 at 9:29 AM, Ian Romanick <i...@freedesktop.org> wrote:
> NAK.
>
> You mention varyings in the commit message, but then you quote spec text
> about uniforms.

Sorry, the part about varyings was a bad copy paste from the old
workaround patch on the bugzilla. The problem here is about uniforms.

> This bugged me, so I actually went and looked at the
> GLSL ES 1.00 specification.
>
> Section 4.3.5 (Varying) of the GLSL ES 1.00 specification says:
>
> The precision of varying variables does not need to match.
>
> SO... for GLSL ES 1.00 we should not even emit a warning for varyings
> with mismatched precision.  The above spec quotation should appear in
> the patch that does this.  We should also add a piglit test and,
> frankly, a CTS test!  We've been rejecting completely valid shaders for
> over a year now, and the CTS should have caught that.
>
> If there are actually shaders in the wild that expect mismatched
> precision on uniforms in GLSL ES 1.00 shaders, we should deal with that
> in a separate patch.

Given the commit message corrected to refer to "uniforms" instead,
would it remove your NAK?

Best regards,
Tomasz

>
> On 09/26/2017 01:35 AM, Tomasz Figa wrote:
>> Commit 259fc505454ea6a67aeacf6cdebf1398d9947759 added linker error for
>> mismatching uniform precision, as required by GLES 3.0 specification and
>> conformance test-suite.
>>
>> Several Android applications, including Forge of Empires, have shaders
>> which violate this rule, on a dead varying that will be eliminated.
>> The problem affects a big number of applications using Cocos2D engine
>> and other GLES implementations accept this, this poses a serious
>> application compatibility issue.
>>
>> Starting from GLSL ES 3.0, declarations with conflicting precision
>> qualifiers are explicitly prohibited. However GLSL ES 1.00 does not
>> clearly specify the behavior, except that
>>
>>   "Uniforms are defined to behave as if they are using the same storage in
>>   the vertex and fragment processors and may be implemented this way.
>>   If uniforms are used in both the vertex and fragment shaders, developers
>>   should be warned if the precisions are different. Conversion of
>>   precision should never be implicit."
>>
>> The word "used" is not clear in this context and might refer to
>>  1) declared (same as GLES 3.x)
>>  2) referred after post-processing, or
>>  3) linked after all optimizations are done.
>>
>> Looking at existing applications, 2) or 3) seems to be widely adopted.
>> To avoid compatibility issues, turn the error into a warning if GLSL ES
>> version is lower than 3.0 and the data is dead in at least one of the
>> shaders.
>>
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97532
>> Signed-off-by: Tomasz Figa <tf...@chromium.org>
>> ---
>>  src/compiler/glsl/linker.cpp | 14 ++
>>  1 file changed, 10 insertions(+), 4 deletions(-)
>>
>> diff --git a/src/compiler/glsl/linker.cpp b/src/compiler/glsl/linker.cpp
>> index f352c5385ca..ff2e6b7a0d3 100644
>> --- a/src/compiler/glsl/linker.cpp
>> +++ b/src/compiler/glsl/linker.cpp
>> @@ -1121,10 +1121,16 @@ cross_validate_globals(struct gl_shader_program 
>> *prog,
>>   if (prog->IsES && (prog->data->Version != 310 ||
>>  !var->get_interface_type()) &&
>>   existing->data.precision != var->data.precision) {
>> -linker_error(prog, "declarations for %s `%s` have "
>> - "mismatching precision qualifiers\n",
>> - mode_string(var), var->name);
>> -return;
>> +if ((existing->data.used && var->data.used) || 
>> prog->data->Version >= 300) {
>> +   linker_error(prog, "declarations for %s `%s` have "
>> +"mismatching precision qualifiers\n",
>> +mode_string(var), var->name);
>> +   return;
>> +} else {
>> +   linker_warning(prog, "declarations for %s `%s` have "
>> +  "mismatching precision qualifiers\n",
>> +  mode_string(var), var->name);
>> +}
>>   }
>>} else
>>   variables->add_variable(var);
>>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev