Re: [Mesa-dev] [RFC] mesa: drop current draw/read buffer when ctx is released

[Tapani Pälli]

On 11/04/2016 05:37 PM, Rob Clark wrote:

On Fri, Nov 4, 2016 at 11:31 AM, Emil Velikov  wrote:

On 1 November 2016 at 22:05, Rob Clark  wrote:

On Tue, Nov 1, 2016 at 5:42 PM, Mauro Rossi  wrote:

Mauro or Chih-Wei should be able to answer this (being do static
wallpapers work in i965?).

Rob


Hi, I've perfomed tests with mesa
https://github.com/maurossi/mesa/commits/13.0.0_nougat-x86
and the deafult pink wallpaper of nougat-x86 is working on i965

NOTE: I have cherry-picked android-ia "Add the RGBA and RGBX
back to Intel screen config",
which solved some black rendering issue in Basemark ES2 Taiji 3d
render and in OpenGL ES Examples (last two demos)
but Android wallpaper was working also without it.


fwiw, we have that patch as well..  the issue is not an egl/gl error,
but it happens by chance.  Ie. it requires the egl surface to be
destroyed, and then re-allocated as a different type (such as from
pbuffer to window), and get the idential pointer address as the
previous surface.

In other words, I think the cases where it is working is only by luck.


Can you flesh out the patch in a branch for Mark Janes to run through the CI ?
If it doesn't cause issues on their end it's worth merging it, even if
i965 is fortunate to work without it. Worth adding an inline comment
about the latter ?


For a test run, I guess applying the RFC as-is should be sufficient?
I was planning on sending a non-RFC version of this but haven't had
time/setup to do a piglit run on my end.

I *think* it should be a pretty safe change, but a CI run would be
much appreciated.



I applied this patch on top of cc49505 and did CI run, no regressions.

Acked-by: Tapani Pälli 

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

Re: [Mesa-dev] [RFC] mesa: drop current draw/read buffer when ctx is released

[Rob Clark]

On Fri, Nov 4, 2016 at 11:31 AM, Emil Velikov  wrote:
> On 1 November 2016 at 22:05, Rob Clark  wrote:
>> On Tue, Nov 1, 2016 at 5:42 PM, Mauro Rossi  wrote:
 Mauro or Chih-Wei should be able to answer this (being do static
 wallpapers work in i965?).

 Rob
>>>
>>> Hi, I've perfomed tests with mesa
>>> https://github.com/maurossi/mesa/commits/13.0.0_nougat-x86
>>> and the deafult pink wallpaper of nougat-x86 is working on i965
>>>
>>> NOTE: I have cherry-picked android-ia "Add the RGBA and RGBX
>>> back to Intel screen config",
>>> which solved some black rendering issue in Basemark ES2 Taiji 3d
>>> render and in OpenGL ES Examples (last two demos)
>>> but Android wallpaper was working also without it.
>>
>> fwiw, we have that patch as well..  the issue is not an egl/gl error,
>> but it happens by chance.  Ie. it requires the egl surface to be
>> destroyed, and then re-allocated as a different type (such as from
>> pbuffer to window), and get the idential pointer address as the
>> previous surface.
>>
>> In other words, I think the cases where it is working is only by luck.
>>
> Can you flesh out the patch in a branch for Mark Janes to run through the CI ?
> If it doesn't cause issues on their end it's worth merging it, even if
> i965 is fortunate to work without it. Worth adding an inline comment
> about the latter ?

For a test run, I guess applying the RFC as-is should be sufficient?
I was planning on sending a non-RFC version of this but haven't had
time/setup to do a piglit run on my end.

I *think* it should be a pretty safe change, but a CI run would be
much appreciated.

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

Re: [Mesa-dev] [RFC] mesa: drop current draw/read buffer when ctx is released

[Emil Velikov]

On 1 November 2016 at 22:05, Rob Clark  wrote:
> On Tue, Nov 1, 2016 at 5:42 PM, Mauro Rossi  wrote:
>>> Mauro or Chih-Wei should be able to answer this (being do static
>>> wallpapers work in i965?).
>>>
>>> Rob
>>
>> Hi, I've perfomed tests with mesa
>> https://github.com/maurossi/mesa/commits/13.0.0_nougat-x86
>> and the deafult pink wallpaper of nougat-x86 is working on i965
>>
>> NOTE: I have cherry-picked android-ia "Add the RGBA and RGBX
>> back to Intel screen config",
>> which solved some black rendering issue in Basemark ES2 Taiji 3d
>> render and in OpenGL ES Examples (last two demos)
>> but Android wallpaper was working also without it.
>
> fwiw, we have that patch as well..  the issue is not an egl/gl error,
> but it happens by chance.  Ie. it requires the egl surface to be
> destroyed, and then re-allocated as a different type (such as from
> pbuffer to window), and get the idential pointer address as the
> previous surface.
>
> In other words, I think the cases where it is working is only by luck.
>
Can you flesh out the patch in a branch for Mark Janes to run through the CI ?
If it doesn't cause issues on their end it's worth merging it, even if
i965 is fortunate to work without it. Worth adding an inline comment
about the latter ?

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

Re: [Mesa-dev] [RFC] mesa: drop current draw/read buffer when ctx is released

[Rob Clark]

On Tue, Nov 1, 2016 at 5:42 PM, Mauro Rossi  wrote:
>> Mauro or Chih-Wei should be able to answer this (being do static
>> wallpapers work in i965?).
>>
>> Rob
>
> Hi, I've perfomed tests with mesa
> https://github.com/maurossi/mesa/commits/13.0.0_nougat-x86
> and the deafult pink wallpaper of nougat-x86 is working on i965
>
> NOTE: I have cherry-picked android-ia "Add the RGBA and RGBX
> back to Intel screen config",
> which solved some black rendering issue in Basemark ES2 Taiji 3d
> render and in OpenGL ES Examples (last two demos)
> but Android wallpaper was working also without it.

fwiw, we have that patch as well..  the issue is not an egl/gl error,
but it happens by chance.  Ie. it requires the egl surface to be
destroyed, and then re-allocated as a different type (such as from
pbuffer to window), and get the idential pointer address as the
previous surface.

In other words, I think the cases where it is working is only by luck.

BR,
-R

> Androdi wallpapers are also working on gallium drivers and swrast
> llvmppipe (Wu Zhen implementation).
>
> I've also re-checked what is rendered black with gallium drivers as we speak
> and all cases (Rajawali app background, Basemark ES2 app background,
> Gears black surface)
> seem directly related to pixel format 2 (RGBX).
>
> There are no segfaults or other crash signals in dmesg,
> here are logcat traces of the common issue collected on Radeon RV630:
>
> 11-01 21:36:57.321  1498  1528 I ActivityManager: Displayed
> com.monyetmabuk.rajawali.tutorials/.RajawaliExamplesActivity: +159ms
> 11-01 21:36:57.324  1229  1229 E GLConsumer: error creating EGLImage: 0x3003
> 11-01 21:36:57.324  1229  1229 E GLConsumer: Failed to create image.
> size=1024x720 st=1024 usage=0x933 fmt=2
> 11-01 21:36:57.324  1229  1229 W GLConsumer:
> [com.monyetmabuk.rajawali.tutorials/com.monyetmabuk.rajawali.tutorials.RajawaliExamplesActivity]
> updateAndRelease: unable to createImage on display=0x1 slot=0
> ...
> 11-01 21:37:13.500  1498  2552 I ActivityManager: START u0
> {act=SPLASH_BASEMARK cmp=com.rightware.tdmm2v10jnifree/.SplashView}
> from uid 10070 on display 0
> 11-01 21:37:13.573  1229  1229 E GLConsumer: error creating EGLImage: 0x3003
> 11-01 21:37:13.573  1229  1229 E GLConsumer: Failed to create image.
> size=1024x720 st=1024 usage=0x933 fmt=2
> 11-01 21:37:13.573  1229  1229 W GLConsumer: [Starting
> com.rightware.tdmm2v10jnifree] updateAndRelease: unable to createImage
> on display=0x1 slot=0
> ...
> 11-01 21:58:37.205  1498  2051 I ActivityManager: Start proc
> 5579:com.jeffboody.GearsES2eclair/u0a74 for activity
> com.jeffboody.GearsES2eclair/.GearsES2eclair
> 11-01 21:58:28.508  1229  1229 E GLConsumer: error creating EGLImage: 0x3003
> 11-01 21:58:28.508  1229  1229 E GLConsumer: Failed to create image.
> size=1024x720 st=1024 usage=0x933 fmt=2
> 11-01 21:58:28.508  1229  1229 W GLConsumer: [Starting
> com.jeffboody.GearsES2eclair] updateAndRelease: unable to createImage
> on display=0x1 slot=0
>
> Mauro
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC] mesa: drop current draw/read buffer when ctx is released

[Mauro Rossi]

> Mauro or Chih-Wei should be able to answer this (being do static
> wallpapers work in i965?).
>
> Rob

Hi, I've perfomed tests with mesa
https://github.com/maurossi/mesa/commits/13.0.0_nougat-x86
and the deafult pink wallpaper of nougat-x86 is working on i965

NOTE: I have cherry-picked android-ia "Add the RGBA and RGBX
back to Intel screen config",
which solved some black rendering issue in Basemark ES2 Taiji 3d
render and in OpenGL ES Examples (last two demos)
but Android wallpaper was working also without it.

Androdi wallpapers are also working on gallium drivers and swrast
llvmppipe (Wu Zhen implementation).

I've also re-checked what is rendered black with gallium drivers as we speak
and all cases (Rajawali app background, Basemark ES2 app background,
Gears black surface)
seem directly related to pixel format 2 (RGBX).

There are no segfaults or other crash signals in dmesg,
here are logcat traces of the common issue collected on Radeon RV630:

11-01 21:36:57.321  1498  1528 I ActivityManager: Displayed
com.monyetmabuk.rajawali.tutorials/.RajawaliExamplesActivity: +159ms
11-01 21:36:57.324  1229  1229 E GLConsumer: error creating EGLImage: 0x3003
11-01 21:36:57.324  1229  1229 E GLConsumer: Failed to create image.
size=1024x720 st=1024 usage=0x933 fmt=2
11-01 21:36:57.324  1229  1229 W GLConsumer:
[com.monyetmabuk.rajawali.tutorials/com.monyetmabuk.rajawali.tutorials.RajawaliExamplesActivity]
updateAndRelease: unable to createImage on display=0x1 slot=0
...
11-01 21:37:13.500  1498  2552 I ActivityManager: START u0
{act=SPLASH_BASEMARK cmp=com.rightware.tdmm2v10jnifree/.SplashView}
from uid 10070 on display 0
11-01 21:37:13.573  1229  1229 E GLConsumer: error creating EGLImage: 0x3003
11-01 21:37:13.573  1229  1229 E GLConsumer: Failed to create image.
size=1024x720 st=1024 usage=0x933 fmt=2
11-01 21:37:13.573  1229  1229 W GLConsumer: [Starting
com.rightware.tdmm2v10jnifree] updateAndRelease: unable to createImage
on display=0x1 slot=0
...
11-01 21:58:37.205  1498  2051 I ActivityManager: Start proc
5579:com.jeffboody.GearsES2eclair/u0a74 for activity
com.jeffboody.GearsES2eclair/.GearsES2eclair
11-01 21:58:28.508  1229  1229 E GLConsumer: error creating EGLImage: 0x3003
11-01 21:58:28.508  1229  1229 E GLConsumer: Failed to create image.
size=1024x720 st=1024 usage=0x933 fmt=2
11-01 21:58:28.508  1229  1229 W GLConsumer: [Starting
com.jeffboody.GearsES2eclair] updateAndRelease: unable to createImage
on display=0x1 slot=0

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

Re: [Mesa-dev] [RFC] mesa: drop current draw/read buffer when ctx is released

[Chih-Wei Huang]

2016-10-28 22:09 GMT+08:00 Rob Herring :
> +Mauro, Chih-Wei
>
> On Fri, Oct 28, 2016 at 7:22 AM, Rob Clark  wrote:
>> On Fri, Oct 28, 2016 at 1:24 AM, Tapani Pälli  wrote:
>>> On 10/27/2016 01:48 PM, Rob Clark wrote:

 On Thu, Oct 27, 2016 at 2:59 AM, Tapani Pälli 
 wrote:
>
> On 10/27/2016 12:16 AM, Rob Clark wrote:
>>
>> So, not quite sure if this is the *correct* solution, but it is at least
>> *a* solution to a problem with android wallpaper vs mesa that I've been
>> debugging.  Basically, what happens is:
>
>
> Could you tell more how to trigger this, is this with some particular
> live
> wallpaper and has this been working before (regression)? For me at least
> these default wallpapers have been working ok.

 Actually, it is the default static wallpaper that is problematic.  And
 IIRC, it has never worked, at least not with any of the gallium
 drivers (freedreno, virgl, vc4, etc).  Live-wallpaper did work, but
 does not appear to exist in AOSP builds anymore.

 If this works with i965 on android, I'd be curious how.  Or if you're
 android build had some mesa patches that are not upstream?
>>>
>>>
>>> I can confirm that default wallpaper is working on i965. Our Mesa tree
>>> currently looks like this:
>>>
>>> https://github.com/android-ia/external-mesa
>>>
>>> It's now quite a bit behind though because we were dealing with some
>>> non-graphics issues and are planning to rebase soon.
>>
>> I suppose it is possible that it is triggered by something different
>> that mesa/st does vs dri/i965?  Although I find it odd that
>> dri2_make_current() would drop the reference to the EGLSurface when
>> unbinding ctx, but _mesa_make_current() would not drop the reference
>> to the corresponding gl_framebuffer.
>>
>> Maybe the classic driver is holding an extra reference to the
>> EGLSurface so the _eglPutSurface() call in dri2_make_current() does
>> not actually drop the last refcnt?  Which would ensure when the window
>> surface is created it ends up with a different address..
>>
>> but, I wonder if you could try w/ Rob Herring's tree.. this is what we
>> are using for the upstream kernel + AOSP builds[1]:
>>
>>   https://github.com/robherring/mesa/commits/android-m
>>
>> I guess in theory we should both need the same patches on top of
>> mesa..  although also I guess we should also just try to get to the
>> point where we can both use upstream mesa tree directly.
>
> Looks like we have some similar patches for gralloc headers and using
> render node (since I picked up Tomasz's patches).
>
>> [1] see: 
>> https://github.com/robherring/generic_device/wiki/KConfig-based-Multi-platform-Android-Device-(and-Mesa-graphics)
>>
>> Btw, I guess in theory the qemu/x86 build from rob's generic_device
>> stuff should also work on real hw, so I think we should be able to
>> test exact same build that is failing with gallium/virgl with i965.
>> But I don't have any real hw for that.
>
> Mauro or Chih-Wei should be able to answer this (being do static
> wallpapers work in i965?).

Yes, it works i i965.
But it does break on some gallium drivers sometimes.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC] mesa: drop current draw/read buffer when ctx is released

[Tomasz Figa]

On Fri, Oct 28, 2016 at 11:33 PM, Rob Herring  wrote:
> On Fri, Oct 28, 2016 at 9:14 AM, Emil Velikov  
> wrote:
>> On 28 October 2016 at 13:22, Rob Clark  wrote:
>>> On Fri, Oct 28, 2016 at 1:24 AM, Tapani Pälli  
>>> wrote:
 On 10/27/2016 01:48 PM, Rob Clark wrote:
>
> On Thu, Oct 27, 2016 at 2:59 AM, Tapani Pälli 
> wrote:
>>
>> On 10/27/2016 12:16 AM, Rob Clark wrote:
>>>
>>> So, not quite sure if this is the *correct* solution, but it is at least
>>> *a* solution to a problem with android wallpaper vs mesa that I've been
>>> debugging.  Basically, what happens is:
>>
>>
>> Could you tell more how to trigger this, is this with some particular
>> live
>> wallpaper and has this been working before (regression)? For me at least
>> these default wallpapers have been working ok.
>
> Actually, it is the default static wallpaper that is problematic.  And
> IIRC, it has never worked, at least not with any of the gallium
> drivers (freedreno, virgl, vc4, etc).  Live-wallpaper did work, but
> does not appear to exist in AOSP builds anymore.
>
> If this works with i965 on android, I'd be curious how.  Or if you're
> android build had some mesa patches that are not upstream?


 I can confirm that default wallpaper is working on i965. Our Mesa tree
 currently looks like this:

 https://github.com/android-ia/external-mesa

 It's now quite a bit behind though because we were dealing with some
 non-graphics issues and are planning to rebase soon.
>>>
>>> I suppose it is possible that it is triggered by something different
>>> that mesa/st does vs dri/i965?  Although I find it odd that
>>> dri2_make_current() would drop the reference to the EGLSurface when
>>> unbinding ctx, but _mesa_make_current() would not drop the reference
>>> to the corresponding gl_framebuffer.
>>>
>> Precisely my line of thinking as well. Both egl and glx drop the
>> reference to the objects on !newCtx.
>>
>> From a quick look the only place where we unref.
>> WinSysDrawBuffer/WinSysReadBuffer is in _mesa_free_context_data which
>> happens on ctx teardown. Which sounds incomplete -  so I'm a bit
>> curious why/how that i965 works fine.
>>
>>> Maybe the classic driver is holding an extra reference to the
>>> EGLSurface so the _eglPutSurface() call in dri2_make_current() does
>>> not actually drop the last refcnt?  Which would ensure when the window
>>> surface is created it ends up with a different address..
>>>
>>> but, I wonder if you could try w/ Rob Herring's tree.. this is what we
>>> are using for the upstream kernel + AOSP builds[1]:
>>>
>>>   https://github.com/robherring/mesa/commits/android-m
>>>
>>> I guess in theory we should both need the same patches on top of
>>> mesa..  although also I guess we should also just try to get to the
>>> point where we can both use upstream mesa tree directly.
>>>
>> Indeed. Skimming through the android-ia log - can borrow
>> ENABLE_FLINK_SUPPORT and let drm/gbm gralloc have a static inline
>> helpers gralloc_drm_get_gem_handle/gralloc_drm_get_prime_fd.
>> Thus everyone can polish their gralloc (if interested?) while still
>> having something that works across the board. With similar direction
>> on the GRALLOC_MODULE_PERFORM_GET_DRM_FD front ?
>
> It's all related. If we use dma-buf fds, then we use the render node
> instead of card node and don't need private gralloc access. We just
> assume if the buffer handle has an fd that the 1st fd is the dma-buf.
>
> I've been assuming that Tomasz would respin these patches.

Still working on it. Sorry for so long round trip. ;/

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

Re: [Mesa-dev] [RFC] mesa: drop current draw/read buffer when ctx is released

[Emil Velikov]

On 28 October 2016 at 15:33, Rob Herring  wrote:
> On Fri, Oct 28, 2016 at 9:14 AM, Emil Velikov  
> wrote:
>> On 28 October 2016 at 13:22, Rob Clark  wrote:
>>> On Fri, Oct 28, 2016 at 1:24 AM, Tapani Pälli  
>>> wrote:
 On 10/27/2016 01:48 PM, Rob Clark wrote:
>
> On Thu, Oct 27, 2016 at 2:59 AM, Tapani Pälli 
> wrote:
>>
>> On 10/27/2016 12:16 AM, Rob Clark wrote:
>>>
>>> So, not quite sure if this is the *correct* solution, but it is at least
>>> *a* solution to a problem with android wallpaper vs mesa that I've been
>>> debugging.  Basically, what happens is:
>>
>>
>> Could you tell more how to trigger this, is this with some particular
>> live
>> wallpaper and has this been working before (regression)? For me at least
>> these default wallpapers have been working ok.
>
> Actually, it is the default static wallpaper that is problematic.  And
> IIRC, it has never worked, at least not with any of the gallium
> drivers (freedreno, virgl, vc4, etc).  Live-wallpaper did work, but
> does not appear to exist in AOSP builds anymore.
>
> If this works with i965 on android, I'd be curious how.  Or if you're
> android build had some mesa patches that are not upstream?


 I can confirm that default wallpaper is working on i965. Our Mesa tree
 currently looks like this:

 https://github.com/android-ia/external-mesa

 It's now quite a bit behind though because we were dealing with some
 non-graphics issues and are planning to rebase soon.
>>>
>>> I suppose it is possible that it is triggered by something different
>>> that mesa/st does vs dri/i965?  Although I find it odd that
>>> dri2_make_current() would drop the reference to the EGLSurface when
>>> unbinding ctx, but _mesa_make_current() would not drop the reference
>>> to the corresponding gl_framebuffer.
>>>
>> Precisely my line of thinking as well. Both egl and glx drop the
>> reference to the objects on !newCtx.
>>
>> From a quick look the only place where we unref.
>> WinSysDrawBuffer/WinSysReadBuffer is in _mesa_free_context_data which
>> happens on ctx teardown. Which sounds incomplete -  so I'm a bit
>> curious why/how that i965 works fine.
>>
>>> Maybe the classic driver is holding an extra reference to the
>>> EGLSurface so the _eglPutSurface() call in dri2_make_current() does
>>> not actually drop the last refcnt?  Which would ensure when the window
>>> surface is created it ends up with a different address..
>>>
>>> but, I wonder if you could try w/ Rob Herring's tree.. this is what we
>>> are using for the upstream kernel + AOSP builds[1]:
>>>
>>>   https://github.com/robherring/mesa/commits/android-m
>>>
>>> I guess in theory we should both need the same patches on top of
>>> mesa..  although also I guess we should also just try to get to the
>>> point where we can both use upstream mesa tree directly.
>>>
>> Indeed. Skimming through the android-ia log - can borrow
>> ENABLE_FLINK_SUPPORT and let drm/gbm gralloc have a static inline
>> helpers gralloc_drm_get_gem_handle/gralloc_drm_get_prime_fd.
>> Thus everyone can polish their gralloc (if interested?) while still
>> having something that works across the board. With similar direction
>> on the GRALLOC_MODULE_PERFORM_GET_DRM_FD front ?
>
> It's all related. If we use dma-buf fds, then we use the render node
> instead of card node and don't need private gralloc access. We just
> assume if the buffer handle has an fd that the 1st fd is the dma-buf.
>
Point I was [trying to] make is that this is very iffy way to pick
render node device. Afaict every kernel nowadays has at least two -
vgem and the hw one (i915,nouveau).

Although far from ideal, the DRM_FD allows you to keep the heuristics
(shared device in drm_gralloc case and pick a random one* for
gbm_gralloc). That is, until liballoc comes about and we could nuke
most/all of that stuff into orbit ;-)

* Just do some basic probing/test on the device (/me is pitching for
drmDevice, but anything will do). Not to mention that one can override
the heuristics - be that device, drm module or the exact render node
name via the standard Android property_get().

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

Re: [Mesa-dev] [RFC] mesa: drop current draw/read buffer when ctx is released

[Rob Herring]

On Fri, Oct 28, 2016 at 9:14 AM, Emil Velikov  wrote:
> On 28 October 2016 at 13:22, Rob Clark  wrote:
>> On Fri, Oct 28, 2016 at 1:24 AM, Tapani Pälli  wrote:
>>> On 10/27/2016 01:48 PM, Rob Clark wrote:

 On Thu, Oct 27, 2016 at 2:59 AM, Tapani Pälli 
 wrote:
>
> On 10/27/2016 12:16 AM, Rob Clark wrote:
>>
>> So, not quite sure if this is the *correct* solution, but it is at least
>> *a* solution to a problem with android wallpaper vs mesa that I've been
>> debugging.  Basically, what happens is:
>
>
> Could you tell more how to trigger this, is this with some particular
> live
> wallpaper and has this been working before (regression)? For me at least
> these default wallpapers have been working ok.

 Actually, it is the default static wallpaper that is problematic.  And
 IIRC, it has never worked, at least not with any of the gallium
 drivers (freedreno, virgl, vc4, etc).  Live-wallpaper did work, but
 does not appear to exist in AOSP builds anymore.

 If this works with i965 on android, I'd be curious how.  Or if you're
 android build had some mesa patches that are not upstream?
>>>
>>>
>>> I can confirm that default wallpaper is working on i965. Our Mesa tree
>>> currently looks like this:
>>>
>>> https://github.com/android-ia/external-mesa
>>>
>>> It's now quite a bit behind though because we were dealing with some
>>> non-graphics issues and are planning to rebase soon.
>>
>> I suppose it is possible that it is triggered by something different
>> that mesa/st does vs dri/i965?  Although I find it odd that
>> dri2_make_current() would drop the reference to the EGLSurface when
>> unbinding ctx, but _mesa_make_current() would not drop the reference
>> to the corresponding gl_framebuffer.
>>
> Precisely my line of thinking as well. Both egl and glx drop the
> reference to the objects on !newCtx.
>
> From a quick look the only place where we unref.
> WinSysDrawBuffer/WinSysReadBuffer is in _mesa_free_context_data which
> happens on ctx teardown. Which sounds incomplete -  so I'm a bit
> curious why/how that i965 works fine.
>
>> Maybe the classic driver is holding an extra reference to the
>> EGLSurface so the _eglPutSurface() call in dri2_make_current() does
>> not actually drop the last refcnt?  Which would ensure when the window
>> surface is created it ends up with a different address..
>>
>> but, I wonder if you could try w/ Rob Herring's tree.. this is what we
>> are using for the upstream kernel + AOSP builds[1]:
>>
>>   https://github.com/robherring/mesa/commits/android-m
>>
>> I guess in theory we should both need the same patches on top of
>> mesa..  although also I guess we should also just try to get to the
>> point where we can both use upstream mesa tree directly.
>>
> Indeed. Skimming through the android-ia log - can borrow
> ENABLE_FLINK_SUPPORT and let drm/gbm gralloc have a static inline
> helpers gralloc_drm_get_gem_handle/gralloc_drm_get_prime_fd.
> Thus everyone can polish their gralloc (if interested?) while still
> having something that works across the board. With similar direction
> on the GRALLOC_MODULE_PERFORM_GET_DRM_FD front ?

It's all related. If we use dma-buf fds, then we use the render node
instead of card node and don't need private gralloc access. We just
assume if the buffer handle has an fd that the 1st fd is the dma-buf.

I've been assuming that Tomasz would respin these patches.

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

Re: [Mesa-dev] [RFC] mesa: drop current draw/read buffer when ctx is released

[Emil Velikov]

On 28 October 2016 at 13:22, Rob Clark  wrote:
> On Fri, Oct 28, 2016 at 1:24 AM, Tapani Pälli  wrote:
>> On 10/27/2016 01:48 PM, Rob Clark wrote:
>>>
>>> On Thu, Oct 27, 2016 at 2:59 AM, Tapani Pälli 
>>> wrote:

 On 10/27/2016 12:16 AM, Rob Clark wrote:
>
> So, not quite sure if this is the *correct* solution, but it is at least
> *a* solution to a problem with android wallpaper vs mesa that I've been
> debugging.  Basically, what happens is:


 Could you tell more how to trigger this, is this with some particular
 live
 wallpaper and has this been working before (regression)? For me at least
 these default wallpapers have been working ok.
>>>
>>> Actually, it is the default static wallpaper that is problematic.  And
>>> IIRC, it has never worked, at least not with any of the gallium
>>> drivers (freedreno, virgl, vc4, etc).  Live-wallpaper did work, but
>>> does not appear to exist in AOSP builds anymore.
>>>
>>> If this works with i965 on android, I'd be curious how.  Or if you're
>>> android build had some mesa patches that are not upstream?
>>
>>
>> I can confirm that default wallpaper is working on i965. Our Mesa tree
>> currently looks like this:
>>
>> https://github.com/android-ia/external-mesa
>>
>> It's now quite a bit behind though because we were dealing with some
>> non-graphics issues and are planning to rebase soon.
>
> I suppose it is possible that it is triggered by something different
> that mesa/st does vs dri/i965?  Although I find it odd that
> dri2_make_current() would drop the reference to the EGLSurface when
> unbinding ctx, but _mesa_make_current() would not drop the reference
> to the corresponding gl_framebuffer.
>
Precisely my line of thinking as well. Both egl and glx drop the
reference to the objects on !newCtx.

From a quick look the only place where we unref.
WinSysDrawBuffer/WinSysReadBuffer is in _mesa_free_context_data which
happens on ctx teardown. Which sounds incomplete -  so I'm a bit
curious why/how that i965 works fine.

> Maybe the classic driver is holding an extra reference to the
> EGLSurface so the _eglPutSurface() call in dri2_make_current() does
> not actually drop the last refcnt?  Which would ensure when the window
> surface is created it ends up with a different address..
>
> but, I wonder if you could try w/ Rob Herring's tree.. this is what we
> are using for the upstream kernel + AOSP builds[1]:
>
>   https://github.com/robherring/mesa/commits/android-m
>
> I guess in theory we should both need the same patches on top of
> mesa..  although also I guess we should also just try to get to the
> point where we can both use upstream mesa tree directly.
>
Indeed. Skimming through the android-ia log - can borrow
ENABLE_FLINK_SUPPORT and let drm/gbm gralloc have a static inline
helpers gralloc_drm_get_gem_handle/gralloc_drm_get_prime_fd.
Thus everyone can polish their gralloc (if interested?) while still
having something that works across the board. With similar direction
on the GRALLOC_MODULE_PERFORM_GET_DRM_FD front ?

Although admittedly i965 could/should use gbm_gralloc ;-)

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

Re: [Mesa-dev] [RFC] mesa: drop current draw/read buffer when ctx is released

[Tapani Pälli]

On 10/28/2016 03:22 PM, Rob Clark wrote:

On Fri, Oct 28, 2016 at 1:24 AM, Tapani Pälli  wrote:

On 10/27/2016 01:48 PM, Rob Clark wrote:

On Thu, Oct 27, 2016 at 2:59 AM, Tapani Pälli 
wrote:

On 10/27/2016 12:16 AM, Rob Clark wrote:

So, not quite sure if this is the *correct* solution, but it is at least
*a* solution to a problem with android wallpaper vs mesa that I've been
debugging.  Basically, what happens is:


Could you tell more how to trigger this, is this with some particular
live
wallpaper and has this been working before (regression)? For me at least
these default wallpapers have been working ok.

Actually, it is the default static wallpaper that is problematic.  And
IIRC, it has never worked, at least not with any of the gallium
drivers (freedreno, virgl, vc4, etc).  Live-wallpaper did work, but
does not appear to exist in AOSP builds anymore.

If this works with i965 on android, I'd be curious how.  Or if you're
android build had some mesa patches that are not upstream?


I can confirm that default wallpaper is working on i965. Our Mesa tree
currently looks like this:

https://github.com/android-ia/external-mesa

It's now quite a bit behind though because we were dealing with some
non-graphics issues and are planning to rebase soon.

I suppose it is possible that it is triggered by something different
that mesa/st does vs dri/i965?  Although I find it odd that
dri2_make_current() would drop the reference to the EGLSurface when
unbinding ctx, but _mesa_make_current() would not drop the reference
to the corresponding gl_framebuffer.

Maybe the classic driver is holding an extra reference to the
EGLSurface so the _eglPutSurface() call in dri2_make_current() does
not actually drop the last refcnt?  Which would ensure when the window
surface is created it ends up with a different address..

but, I wonder if you could try w/ Rob Herring's tree.. this is what we
are using for the upstream kernel + AOSP builds[1]:

   https://github.com/robherring/mesa/commits/android-m
I'll check if this tree works for me (only on Monday though ..) or what 
is required on top to make it work for our build. It looks like we have 
a bit of difference there but no big changes.



I guess in theory we should both need the same patches on top of
mesa..  although also I guess we should also just try to get to the
point where we can both use upstream mesa tree directly.
in theory ... we've been adopting (and upstreaming) some from the ARC++ 
tree:

https://chromium.googlesource.com/chromiumos/third_party/mesa/+log/arc-12.1.0-pre2/

I guess we always need to come a bit behind master to be stable enough 
to be 'usable' (especially because of the continuous build breaks) but 
hopefully not too much.




[1] see: 
https://github.com/robherring/generic_device/wiki/KConfig-based-Multi-platform-Android-Device-(and-Mesa-graphics)

Btw, I guess in theory the qemu/x86 build from rob's generic_device
stuff should also work on real hw, so I think we should be able to
test exact same build that is failing with gallium/virgl with i965.
But I don't have any real hw for that.

BR,
-R


BR,
-R


  EGLSurface tmpSurface = mEgl.eglCreatePbufferSurface(mEglDisplay,
mEglConfig, attribs);
  mEgl.eglMakeCurrent(mEglDisplay, tmpSurface, tmpSurface,
mEglContext);

  int[] maxSize = new int[1];
  Rect frame = surfaceHolder.getSurfaceFrame();
  glGetIntegerv(GL_MAX_TEXTURE_SIZE, maxSize, 0);

  mEgl.eglMakeCurrent(mEglDisplay, EGL_NO_SURFACE, EGL_NO_SURFACE,
EGL_NO_CONTEXT);
  mEgl.eglDestroySurface(mEglDisplay, tmpSurface);

  ... check maxSize vs frame size and bail if needed ...

  mEglSurface = mEgl.eglCreateWindowSurface(mEglDisplay, mEglConfig,
surfaceHolder, null);
  ... error checking ...
  mEgl.eglMakeCurrent(mEglDisplay, mEglSurface, mEglSurface,
mEglContext);

When the window-surface is created, it ends up with the same ptr address
as the recently freed tmpSurface pbuffer surface.  Which after many
levels of indirection, results in st_framebuffer_validate() ending up
with
the same/old framebuffer object, and in the end never calling the
DRIimageLoaderExtension::getBuffers().  Then in droid_swap_buffers(),
the
dri2_surf is still the old pbuffer surface (with dri2_surf->buffer being
NULL, obviously, so when wallpaper app calls eglSwapBuffers() nothing
gets enqueued to the compositor).

Maybe instead, eglDestroySurface() should clear any references the ctx
has to the surface.  Not sure how that would work.  Did I mention there
are many levels of indirection?
---
src/mesa/main/context.c | 4 
1 file changed, 4 insertions(+)

diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c
index 5e52065..83b8cc1 100644
--- a/src/mesa/main/context.c
+++ b/src/mesa/main/context.c
@@ -1646,6 +1646,10 @@ ALOGE("%s:%d, drawBuffer=%p, readBuffer=%p",
__func__, __LINE__, drawBuffer, rea
 if (!newCtx) {
  _glapi_set_dispatch(NULL);  

Re: [Mesa-dev] [RFC] mesa: drop current draw/read buffer when ctx is released

[Rob Clark]

On Fri, Oct 28, 2016 at 1:24 AM, Tapani Pälli  wrote:
> On 10/27/2016 01:48 PM, Rob Clark wrote:
>>
>> On Thu, Oct 27, 2016 at 2:59 AM, Tapani Pälli 
>> wrote:
>>>
>>> On 10/27/2016 12:16 AM, Rob Clark wrote:

 So, not quite sure if this is the *correct* solution, but it is at least
 *a* solution to a problem with android wallpaper vs mesa that I've been
 debugging.  Basically, what happens is:
>>>
>>>
>>> Could you tell more how to trigger this, is this with some particular
>>> live
>>> wallpaper and has this been working before (regression)? For me at least
>>> these default wallpapers have been working ok.
>>
>> Actually, it is the default static wallpaper that is problematic.  And
>> IIRC, it has never worked, at least not with any of the gallium
>> drivers (freedreno, virgl, vc4, etc).  Live-wallpaper did work, but
>> does not appear to exist in AOSP builds anymore.
>>
>> If this works with i965 on android, I'd be curious how.  Or if you're
>> android build had some mesa patches that are not upstream?
>
>
> I can confirm that default wallpaper is working on i965. Our Mesa tree
> currently looks like this:
>
> https://github.com/android-ia/external-mesa
>
> It's now quite a bit behind though because we were dealing with some
> non-graphics issues and are planning to rebase soon.

I suppose it is possible that it is triggered by something different
that mesa/st does vs dri/i965?  Although I find it odd that
dri2_make_current() would drop the reference to the EGLSurface when
unbinding ctx, but _mesa_make_current() would not drop the reference
to the corresponding gl_framebuffer.

Maybe the classic driver is holding an extra reference to the
EGLSurface so the _eglPutSurface() call in dri2_make_current() does
not actually drop the last refcnt?  Which would ensure when the window
surface is created it ends up with a different address..

but, I wonder if you could try w/ Rob Herring's tree.. this is what we
are using for the upstream kernel + AOSP builds[1]:

  https://github.com/robherring/mesa/commits/android-m

I guess in theory we should both need the same patches on top of
mesa..  although also I guess we should also just try to get to the
point where we can both use upstream mesa tree directly.

[1] see: 
https://github.com/robherring/generic_device/wiki/KConfig-based-Multi-platform-Android-Device-(and-Mesa-graphics)

Btw, I guess in theory the qemu/x86 build from rob's generic_device
stuff should also work on real hw, so I think we should be able to
test exact same build that is failing with gallium/virgl with i965.
But I don't have any real hw for that.

BR,
-R

>
>> BR,
>> -R
>>
  EGLSurface tmpSurface = mEgl.eglCreatePbufferSurface(mEglDisplay,
 mEglConfig, attribs);
  mEgl.eglMakeCurrent(mEglDisplay, tmpSurface, tmpSurface,
 mEglContext);

  int[] maxSize = new int[1];
  Rect frame = surfaceHolder.getSurfaceFrame();
  glGetIntegerv(GL_MAX_TEXTURE_SIZE, maxSize, 0);

  mEgl.eglMakeCurrent(mEglDisplay, EGL_NO_SURFACE, EGL_NO_SURFACE,
 EGL_NO_CONTEXT);
  mEgl.eglDestroySurface(mEglDisplay, tmpSurface);

  ... check maxSize vs frame size and bail if needed ...

  mEglSurface = mEgl.eglCreateWindowSurface(mEglDisplay, mEglConfig,
 surfaceHolder, null);
  ... error checking ...
  mEgl.eglMakeCurrent(mEglDisplay, mEglSurface, mEglSurface,
 mEglContext);

 When the window-surface is created, it ends up with the same ptr address
 as the recently freed tmpSurface pbuffer surface.  Which after many
 levels of indirection, results in st_framebuffer_validate() ending up
 with
 the same/old framebuffer object, and in the end never calling the
 DRIimageLoaderExtension::getBuffers().  Then in droid_swap_buffers(),
 the
 dri2_surf is still the old pbuffer surface (with dri2_surf->buffer being
 NULL, obviously, so when wallpaper app calls eglSwapBuffers() nothing
 gets enqueued to the compositor).

 Maybe instead, eglDestroySurface() should clear any references the ctx
 has to the surface.  Not sure how that would work.  Did I mention there
 are many levels of indirection?
 ---
src/mesa/main/context.c | 4 
1 file changed, 4 insertions(+)

 diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c
 index 5e52065..83b8cc1 100644
 --- a/src/mesa/main/context.c
 +++ b/src/mesa/main/context.c
 @@ -1646,6 +1646,10 @@ ALOGE("%s:%d, drawBuffer=%p, readBuffer=%p",
 __func__, __LINE__, drawBuffer, rea
 if (!newCtx) {
  _glapi_set_dispatch(NULL);  /* none current */
 +  if (curCtx) {
 + _mesa_reference_framebuffer(>WinSysDrawBuffer, NULL);
 + _mesa_reference_framebuffer(>WinSysReadBuffer, NULL);
 +  }
   }
   else {
  

Re: [Mesa-dev] [RFC] mesa: drop current draw/read buffer when ctx is released

[Tapani Pälli]

On 10/27/2016 01:48 PM, Rob Clark wrote:

On Thu, Oct 27, 2016 at 2:59 AM, Tapani Pälli  wrote:

On 10/27/2016 12:16 AM, Rob Clark wrote:

So, not quite sure if this is the *correct* solution, but it is at least
*a* solution to a problem with android wallpaper vs mesa that I've been
debugging.  Basically, what happens is:


Could you tell more how to trigger this, is this with some particular live
wallpaper and has this been working before (regression)? For me at least
these default wallpapers have been working ok.

Actually, it is the default static wallpaper that is problematic.  And
IIRC, it has never worked, at least not with any of the gallium
drivers (freedreno, virgl, vc4, etc).  Live-wallpaper did work, but
does not appear to exist in AOSP builds anymore.

If this works with i965 on android, I'd be curious how.  Or if you're
android build had some mesa patches that are not upstream?


I can confirm that default wallpaper is working on i965. Our Mesa tree 
currently looks like this:


https://github.com/android-ia/external-mesa

It's now quite a bit behind though because we were dealing with some 
non-graphics issues and are planning to rebase soon.



BR,
-R


 EGLSurface tmpSurface = mEgl.eglCreatePbufferSurface(mEglDisplay,
mEglConfig, attribs);
 mEgl.eglMakeCurrent(mEglDisplay, tmpSurface, tmpSurface, mEglContext);

 int[] maxSize = new int[1];
 Rect frame = surfaceHolder.getSurfaceFrame();
 glGetIntegerv(GL_MAX_TEXTURE_SIZE, maxSize, 0);

 mEgl.eglMakeCurrent(mEglDisplay, EGL_NO_SURFACE, EGL_NO_SURFACE,
EGL_NO_CONTEXT);
 mEgl.eglDestroySurface(mEglDisplay, tmpSurface);

 ... check maxSize vs frame size and bail if needed ...

 mEglSurface = mEgl.eglCreateWindowSurface(mEglDisplay, mEglConfig,
surfaceHolder, null);
 ... error checking ...
 mEgl.eglMakeCurrent(mEglDisplay, mEglSurface, mEglSurface,
mEglContext);

When the window-surface is created, it ends up with the same ptr address
as the recently freed tmpSurface pbuffer surface.  Which after many
levels of indirection, results in st_framebuffer_validate() ending up with
the same/old framebuffer object, and in the end never calling the
DRIimageLoaderExtension::getBuffers().  Then in droid_swap_buffers(), the
dri2_surf is still the old pbuffer surface (with dri2_surf->buffer being
NULL, obviously, so when wallpaper app calls eglSwapBuffers() nothing
gets enqueued to the compositor).

Maybe instead, eglDestroySurface() should clear any references the ctx
has to the surface.  Not sure how that would work.  Did I mention there
are many levels of indirection?
---
   src/mesa/main/context.c | 4 
   1 file changed, 4 insertions(+)

diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c
index 5e52065..83b8cc1 100644
--- a/src/mesa/main/context.c
+++ b/src/mesa/main/context.c
@@ -1646,6 +1646,10 @@ ALOGE("%s:%d, drawBuffer=%p, readBuffer=%p",
__func__, __LINE__, drawBuffer, rea
if (!newCtx) {
 _glapi_set_dispatch(NULL);  /* none current */
+  if (curCtx) {
+ _mesa_reference_framebuffer(>WinSysDrawBuffer, NULL);
+ _mesa_reference_framebuffer(>WinSysReadBuffer, NULL);
+  }
  }
  else {
 _glapi_set_dispatch(newCtx->CurrentDispatch);





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

Re: [Mesa-dev] [RFC] mesa: drop current draw/read buffer when ctx is released

[Robert Foss]

I gave this patch a spin on a Qemu+Virgl+AOSP setup, and it seems to 
work rather well.


Thanks Rob!

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

Re: [Mesa-dev] [RFC] mesa: drop current draw/read buffer when ctx is released

[Rob Clark]

On Thu, Oct 27, 2016 at 2:59 AM, Tapani Pälli  wrote:
> On 10/27/2016 12:16 AM, Rob Clark wrote:
>>
>> So, not quite sure if this is the *correct* solution, but it is at least
>> *a* solution to a problem with android wallpaper vs mesa that I've been
>> debugging.  Basically, what happens is:
>
>
> Could you tell more how to trigger this, is this with some particular live
> wallpaper and has this been working before (regression)? For me at least
> these default wallpapers have been working ok.

Actually, it is the default static wallpaper that is problematic.  And
IIRC, it has never worked, at least not with any of the gallium
drivers (freedreno, virgl, vc4, etc).  Live-wallpaper did work, but
does not appear to exist in AOSP builds anymore.

If this works with i965 on android, I'd be curious how.  Or if you're
android build had some mesa patches that are not upstream?

BR,
-R

>
>> EGLSurface tmpSurface = mEgl.eglCreatePbufferSurface(mEglDisplay,
>> mEglConfig, attribs);
>> mEgl.eglMakeCurrent(mEglDisplay, tmpSurface, tmpSurface, mEglContext);
>>
>> int[] maxSize = new int[1];
>> Rect frame = surfaceHolder.getSurfaceFrame();
>> glGetIntegerv(GL_MAX_TEXTURE_SIZE, maxSize, 0);
>>
>> mEgl.eglMakeCurrent(mEglDisplay, EGL_NO_SURFACE, EGL_NO_SURFACE,
>> EGL_NO_CONTEXT);
>> mEgl.eglDestroySurface(mEglDisplay, tmpSurface);
>>
>> ... check maxSize vs frame size and bail if needed ...
>>
>> mEglSurface = mEgl.eglCreateWindowSurface(mEglDisplay, mEglConfig,
>> surfaceHolder, null);
>> ... error checking ...
>> mEgl.eglMakeCurrent(mEglDisplay, mEglSurface, mEglSurface,
>> mEglContext);
>>
>> When the window-surface is created, it ends up with the same ptr address
>> as the recently freed tmpSurface pbuffer surface.  Which after many
>> levels of indirection, results in st_framebuffer_validate() ending up with
>> the same/old framebuffer object, and in the end never calling the
>> DRIimageLoaderExtension::getBuffers().  Then in droid_swap_buffers(), the
>> dri2_surf is still the old pbuffer surface (with dri2_surf->buffer being
>> NULL, obviously, so when wallpaper app calls eglSwapBuffers() nothing
>> gets enqueued to the compositor).
>>
>> Maybe instead, eglDestroySurface() should clear any references the ctx
>> has to the surface.  Not sure how that would work.  Did I mention there
>> are many levels of indirection?
>> ---
>>   src/mesa/main/context.c | 4 
>>   1 file changed, 4 insertions(+)
>>
>> diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c
>> index 5e52065..83b8cc1 100644
>> --- a/src/mesa/main/context.c
>> +++ b/src/mesa/main/context.c
>> @@ -1646,6 +1646,10 @@ ALOGE("%s:%d, drawBuffer=%p, readBuffer=%p",
>> __func__, __LINE__, drawBuffer, rea
>>if (!newCtx) {
>> _glapi_set_dispatch(NULL);  /* none current */
>> +  if (curCtx) {
>> + _mesa_reference_framebuffer(>WinSysDrawBuffer, NULL);
>> + _mesa_reference_framebuffer(>WinSysReadBuffer, NULL);
>> +  }
>>  }
>>  else {
>> _glapi_set_dispatch(newCtx->CurrentDispatch);
>
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC] mesa: drop current draw/read buffer when ctx is released

[Tapani Pälli]

On 10/27/2016 12:16 AM, Rob Clark wrote:

So, not quite sure if this is the *correct* solution, but it is at least
*a* solution to a problem with android wallpaper vs mesa that I've been
debugging.  Basically, what happens is:


Could you tell more how to trigger this, is this with some particular 
live wallpaper and has this been working before (regression)? For me at 
least these default wallpapers have been working ok.



EGLSurface tmpSurface = mEgl.eglCreatePbufferSurface(mEglDisplay, 
mEglConfig, attribs);
mEgl.eglMakeCurrent(mEglDisplay, tmpSurface, tmpSurface, mEglContext);

int[] maxSize = new int[1];
Rect frame = surfaceHolder.getSurfaceFrame();
glGetIntegerv(GL_MAX_TEXTURE_SIZE, maxSize, 0);

mEgl.eglMakeCurrent(mEglDisplay, EGL_NO_SURFACE, EGL_NO_SURFACE, 
EGL_NO_CONTEXT);
mEgl.eglDestroySurface(mEglDisplay, tmpSurface);

... check maxSize vs frame size and bail if needed ...

mEglSurface = mEgl.eglCreateWindowSurface(mEglDisplay, mEglConfig, 
surfaceHolder, null);
... error checking ...
mEgl.eglMakeCurrent(mEglDisplay, mEglSurface, mEglSurface, mEglContext);

When the window-surface is created, it ends up with the same ptr address
as the recently freed tmpSurface pbuffer surface.  Which after many
levels of indirection, results in st_framebuffer_validate() ending up with
the same/old framebuffer object, and in the end never calling the
DRIimageLoaderExtension::getBuffers().  Then in droid_swap_buffers(), the
dri2_surf is still the old pbuffer surface (with dri2_surf->buffer being
NULL, obviously, so when wallpaper app calls eglSwapBuffers() nothing
gets enqueued to the compositor).

Maybe instead, eglDestroySurface() should clear any references the ctx
has to the surface.  Not sure how that would work.  Did I mention there
are many levels of indirection?
---
  src/mesa/main/context.c | 4 
  1 file changed, 4 insertions(+)

diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c
index 5e52065..83b8cc1 100644
--- a/src/mesa/main/context.c
+++ b/src/mesa/main/context.c
@@ -1646,6 +1646,10 @@ ALOGE("%s:%d, drawBuffer=%p, readBuffer=%p", __func__, 
__LINE__, drawBuffer, rea
  
 if (!newCtx) {

_glapi_set_dispatch(NULL);  /* none current */
+  if (curCtx) {
+ _mesa_reference_framebuffer(>WinSysDrawBuffer, NULL);
+ _mesa_reference_framebuffer(>WinSysReadBuffer, NULL);
+  }
 }
 else {
_glapi_set_dispatch(newCtx->CurrentDispatch);



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

[Mesa-dev] [RFC] mesa: drop current draw/read buffer when ctx is released

[Rob Clark]

So, not quite sure if this is the *correct* solution, but it is at least
*a* solution to a problem with android wallpaper vs mesa that I've been
debugging.  Basically, what happens is:

   EGLSurface tmpSurface = mEgl.eglCreatePbufferSurface(mEglDisplay, 
mEglConfig, attribs);
   mEgl.eglMakeCurrent(mEglDisplay, tmpSurface, tmpSurface, mEglContext);

   int[] maxSize = new int[1];
   Rect frame = surfaceHolder.getSurfaceFrame();
   glGetIntegerv(GL_MAX_TEXTURE_SIZE, maxSize, 0);

   mEgl.eglMakeCurrent(mEglDisplay, EGL_NO_SURFACE, EGL_NO_SURFACE, 
EGL_NO_CONTEXT);
   mEgl.eglDestroySurface(mEglDisplay, tmpSurface);

   ... check maxSize vs frame size and bail if needed ...

   mEglSurface = mEgl.eglCreateWindowSurface(mEglDisplay, mEglConfig, 
surfaceHolder, null);
   ... error checking ...
   mEgl.eglMakeCurrent(mEglDisplay, mEglSurface, mEglSurface, mEglContext);

When the window-surface is created, it ends up with the same ptr address
as the recently freed tmpSurface pbuffer surface.  Which after many
levels of indirection, results in st_framebuffer_validate() ending up with
the same/old framebuffer object, and in the end never calling the
DRIimageLoaderExtension::getBuffers().  Then in droid_swap_buffers(), the
dri2_surf is still the old pbuffer surface (with dri2_surf->buffer being
NULL, obviously, so when wallpaper app calls eglSwapBuffers() nothing
gets enqueued to the compositor).

Maybe instead, eglDestroySurface() should clear any references the ctx
has to the surface.  Not sure how that would work.  Did I mention there
are many levels of indirection?
---
 src/mesa/main/context.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c
index 5e52065..83b8cc1 100644
--- a/src/mesa/main/context.c
+++ b/src/mesa/main/context.c
@@ -1646,6 +1646,10 @@ ALOGE("%s:%d, drawBuffer=%p, readBuffer=%p", __func__, 
__LINE__, drawBuffer, rea
 
if (!newCtx) {
   _glapi_set_dispatch(NULL);  /* none current */
+  if (curCtx) {
+ _mesa_reference_framebuffer(>WinSysDrawBuffer, NULL);
+ _mesa_reference_framebuffer(>WinSysReadBuffer, NULL);
+  }
}
else {
   _glapi_set_dispatch(newCtx->CurrentDispatch);
-- 
2.1.0

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