On 10/09/2017 06:56 PM, Chad Versace wrote:
On Mon 25 Sep 2017, Tapani Pälli wrote:


On 09/22/2017 03:09 AM, Chad Versace wrote:
On Thu 21 Sep 2017, Tapani Pälli wrote:
Hi Chad;

The build works ok now on Android-IA. There is still something wrong with
'exec async' though. It behaves differently with small/big apps but
eventually I think it just starts to block .. somewhere. I still need the
big hammer to set device->has_exec_async false to fix that. Please don't
consider that to be a blocker though, we can easily carry such patch in
Android-IA and debug it further.

For this patch:
Reviewed-by: Tapani Pälli <tapani.pa...@intel.com>

Thanks for testing and review.

How long until you observe the lockup? And does the lockup happen
earlier or later for small apps vs big apps? And what apps do you use to
reproduce the lock? I'll try to reproduce the lock in my ARC++ setup
after returning to the office on Monday (I'm at XDC now).


Lockup happens very quickly on any app but some apps manage to do a bit of
work, here's 3 examples:

Triangle example from Sascha's demos clears background to blue but then does
not succeed in rendering triangle.

RayTracing example in Sascha's demos displays black background for long time
but then eventually gets VK_ERROR_DEVICE_LOST and crashes as after this it
still attempts to begin a new render pass.

VulkanParticleSystem from PowerVR SDK gets VK_ERROR_DEVICE_LOST very early
with texture uploads and submitting command buffers. Eventually
ActivityManager kills it because input dispatching timed out.

Tapani, I finally succeeded in building and installing the Sascha demos
onto ARC++ x86_64. I've tested 'triangle', 'gears', 'raytracing', and
'dynamicuniformbuffers', and see no issues. I run each app for about 10
minutes before closing it. Just in case you wanted to test my APKs on
your system, I've uploaded them to
http://kiwitree.net/~chadv/tmp/sascha-demos/.

Maybe the problem is due to triple-vs-double buffering? I believe
SurfaceFlinger in ARC++ uses triple-buffering (that is, the BufferQueue
is 3 deep), but default AOSP uses double-buffering.


Thanks Chad, I've grabbed the demos you shared. I'm currently busy investigating dEQP issues but will get back to this after those issues are resolved.

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

Reply via email to