SEGV_MAPERR and graphical glitch with SW_WRITE_OFTEN flagged buffers about gbm_gralloc HOT 21 CLOSED

Very likely this bug is caused by wrong FORMAT_MODIFIER imported by EGL API and not related to gbm_gralloc itself.
GloDroid/glodroid_forks@512464b

from gbm_gralloc.

Just another info, Emil Velikov after having seen the apperarence of attached artifacts,
suggested to first check about stride errors, since there is no problem with i965 and iris I also suspected mesa implementation but I was never able to actually triage and pin-point the root cause

AMD Kaveri

AMD Raven

So you suggest that it is a problem in mesa happening with drivers r600, radeonsi and nouveau too,
because those drivers, which now support the modifiers, do not pass the modifiers info correctly throught egl/android?

But then why are i965, iris workung perfectly fine ?

Should I then open an issue in mesa?

from gbm_gralloc.

Hello @robherring @rsglobal

Just a few questions, to assess if there are two actual problems here, because there are some artifacts due to failed allocation/import and some others seem due to stride or alignment of the imported/mmap-ed memory regions used by Skia to paint SW_WRITE* buffers

Q1) Is the stride in the libdrm gralloc handle to be stored with metric in pixels or bytes? If it is in bytes is it correct that gralloc_gbm_bo_create() in gralloc_gmb.cpp stores the stride in pixels?

buffer_handle_t gralloc_gbm_bo_create(struct gbm_device *gbm,
		int width, int height, int format, int usage, int *stride)
{
...
	/* in pixels */
	*stride = gralloc_handle(handle)->stride / gralloc_gbm_get_bpp(format);

	return handle;
}

Q2) minigbm is not affected by any of the artifacts. Does the stride require some kind of aligment in general and it is not implemented in gbm_gralloc? In case it is needed is there a general rule applicable for all drivers?

Q3) in minigbm drv.c, which is the generic part of the single drivers backends, drv_bo_map() uses memcpy(). Is it correct that memcpy() is not required in mmap code paths in gbm_gralloc?

Q4) in minigbm gbm.c gbm_bo_map() an offset variable is used, is offset implementation required in gbm_gralloc too?

Thanks

from gbm_gralloc.

Hello @rsglobal and @evelikov

I followed your advise to log with ALOGD the stride and I found the following happenings

11-15 00:12:00.851  3026  3026 D GRALLOC-GBM: create BO, size=2006x1166, stride=129905000 fmt=1, usage=14
11-15 00:12:00.851  3026  3026 D GRALLOC-GBM: gbm_bo_get_stride(bo), size=2006x1166, stride=8192 fmt=1, usage=14
11-15 00:12:00.851  3026  3026 D GRALLOC-GBM: buffer usage = 00000933
...
11-15 00:12:02.753  8673  8673 D GRALLOC-GBM: lock bo 0x78d097f01630, cnt=0, usage=30 stride=8192
11-15 00:12:02.756  8673  8673 D GRALLOC-GBM: mapped bo 0x78d097f01630 (0, 0)-(2006, 1166) at 0x78cfe6f10000 stride=8192
...
11-15 00:12:02.757  8673  8673 D GRALLOC-GBM: lock bo 0x78d097f01630, cnt=0, usage=33 stride=8192
11-15 00:12:02.760  8673  8673 D GRALLOC-GBM: mapped bo 0x78d097f01630 (1317, 814)-(5, 150) at 0x78cfe83aa000 stride=5376

In the last two lines mapped bo stride differs from the allocation stride visible in the lock bo logged line

Based on suggestion by Roman, I have tried to disable GBM_BO_USE_SCANOUT for sw usage, as Emil did in drm_gralloc nouveau backend where sw_indicator would fully disable scanout, but this workaround did not work I am still seeing the artifacts in the ResolverActivity windows of launcher3 as depicted in previous images in both Athlon 200GE Vega3 APU and in dGPU AMD TURKS HD76xx with dedicated VRAM

I wanted to check with @evelikov if besides trying to port [1] you may suggest another option

[1] https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/1232673

from gbm_gralloc.

Must admit - I didn't follow all the details in the thread, but porting the minigbm patch [1] to gbm_gralloc sounds like a good addition. HTH o/

from gbm_gralloc.

Hi Emil, the doubt I have about [1] is that the stride of mmap-ed bo may turn out to be the same as per allocated bo stride and the problem is that when bo lock happens with L, T offsets due to cropped region locking for CPU write, we may end up with same problem.
I believe the actual problem may be related to [2]

[2] 640b8f1#diff-6f6fdb75f8a0ab48d08b9791f928af16b42257c10c82509337094f4dd4154894

from gbm_gralloc.

Knowing the correct L/T offset (considering varying stride et al) at mmap time might not be possible. So mapping the whole range makes sense.

from gbm_gralloc.

@maurossi did you resolve your issues? I'm not encounter this issue on Android 11, but on Android 12 / 13. I can reproduce this issue always on AMD GPU (report on Intel GPU either). seems related to DimLayer (such as Permission Grant Dialog). this issue is gone if setup virtio-gpu rendering.

mesa 22.0.0 / libdrm-2.4.109

from gbm_gralloc.

Hello @zhouziyang

In android-x86 Android 9, 10, 11, 12 we still have the problem, for Android 13 preview 2 /aosp master we have not yet achieved the build, but I'm sure the problem is there too.

Here are the attempts I made, which have failed to solve:

• attempt 1 was glodroid Roman patch for gbm_gralloc to import the correct modifiers, but it did not work

• attempt 2 was to align width to 64 pixels, i.e.256 bytes the usage GRALLOC_SW_{READ,WRITE}_OFTEN buffers, and it did not work with r600 parts nor with AMD GPU parts

• attempt 3 was to to move allocator to binderized, where allocation should happen in a single process as opposed to passthrough where it does not happen in a single process, this also failed. BTW in Android S it also failed when using gles renderer which is by definition single threaded.

One way to avoid the problem in ResolverActivity dialogues is to apply [1] as a Workaround, but it does not solve the problem for all Apps windows.

[1] boringdroid/platform_frameworks_base@eda1dde

It's interesting if with Android 11 you do confirm that you have no such issue with Resolver Activity dialogues on AMD GPU and Intel iGPU, please I need to know what branches are you using for frameworks/base and other gfx stack related projects e.g. kernel.
Please recheck because I see no clear reason motivating that Android 11 is not affected, because in my case it is affected as well on r600, AMD GPU (radeonsi), crocus, iris.

Another interesting fact is that i965 was never affected by the problem and iris/crocus are affected, that should ring a bell that the problem is most probably in mesa dri, where classic dri drivers were not affected and gallium dri targets for crocus, iris, nouveau, r600, radeonsi are all affected.

In case you work for Google, could you please help us to understand why and how the Workaround of minigbm [2] may also work for gbm_gralloc?

[2] https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/1232673

I never fully understood the actual problem, that's why we're still stuck with this only issue, otherwise gbm_gralloc would be perfect and with almost zero maintenances, as it has always been intended to be.

I other people agree like me, that this is indeed a mesa dri problem, please confirm and we will continue the thread in a mesa issue

from gbm_gralloc.

@maurossi thanks for your detailed info. I just tested on radeonsi (WX5100 / WX9100) platforms. I'm not encounter any rendering problems on Android 11 (arm64 / x86_64, ubuntu generic kernel 5.4 / 5.8 / 5.11 / 5.13...).
for code branches, please check https://github.com/remote-android/platform_manifests.
I' not work for Google currently, and I will look into the commit in minigbm you mentioned.

from gbm_gralloc.

as a workaround, just enable hardwareAccelerated (not sure why AOSP disable this in Android 12 / 13)

diff --git a/PermissionController/AndroidManifest.xml b/PermissionController/AndroidManifest.xml
index a6fee5833..144827872 100644
--- a/PermissionController/AndroidManifest.xml
+++ b/PermissionController/AndroidManifest.xml
@@ -111,7 +111,7 @@
                 android:theme="@style/GrantPermissions.FilterTouches"
                 android:visibleToInstantApps="true"
                 android:inheritShowWhenLocked="true"
-                android:hardwareAccelerated="false">
+                android:hardwareAccelerated="true">
             <intent-filter android:priority="1">
                 <action android:name="android.content.pm.action.REQUEST_PERMISSIONS" />
                 <category android:name="android.intent.category.DEFAULT" />

from gbm_gralloc.

Thanks @zhouziyang

A couple of questions, since you are a few steps ahead, is the hardwareAccelated="true" solving the problem also for Apps using Skia/SW rendering? Is this method applicable also to Android 11 and is it more effective than [1] ?

[1] boringdroid/platform_frameworks_base@eda1dde

Regarding redroid 11.0.0, in case you have not set hardwareAccelated="true", since you don't see the problem,
could it be that for you AMD GPU parts WX5100 / WX9100 the buffers are always allocated on GPU VRAM memory and may that may be avoiding the issue for your parts?

Are you using [hwcomposer.drm + gralloc.gbm] or [no hwc and gralloc.gbm + drm_framebuffer] ?
In my case I have the ResolverActivity artifacts with both the HALs combinations.

[hwcomposer.drm_minigbm + gralloc.minigbm] and [ no hwc and gralloc.minigbm + drm_framebuffer] are not affected

from gbm_gralloc.

@maurossi I confirmed all these issues (SW / Skia rendering issue) exists in gbm_gralloc. And I think it's due to partial locking just like logs you mentioned above.

hardwareAccelated="true" is same effective as changing in Java code directly. But I prefer to change in AndroidManifest.xml / some_themes.xml instead of Java code (may save some compilation time).

redroid is a headless solution (not show on physical display), and not depend on drm_framebuffer / hwcomposer.drm_minigbm etc. I chose to use gbm_gralloc because it's easy to support different GPUs...

from gbm_gralloc.

I chose to use gbm_gralloc because it's easy to support different GPUs...

Me too

I have tried to build Android S (s-x86 iso) with android:hardwareAccelerated="true" in PermissionController/AndroidManifest.xml, but the launcher3 still has some glitch in ResolverActivity window and the text and controls to select Home app do not show up

I will try to apply also the attached patch in frameworks/base

0001-ResolverActivity-use-hardware-rendering-for-Intent-R.zip

from gbm_gralloc.

I'm trying to run redroid12 on my raspberrypi (4b , 8G) , with the help of zhouziyang , i now can run it with a smooth display whit scrcpy .

but when i try to take screenshots with adb shell screencap -p /sdcard/screen.png , I get corrupted results

debug files from redroid (logcat , dumpsys ,etc included):
tmp.w81kt72k33.tar.gz

I'm just a student and I know nothing about this , but I'm willing to provide information about this running on raspberrypi.

from gbm_gralloc.

Hello @a279437145 ,

My issues with "screen wide" artifacts on AMD Kaveri, Kabini, Raven were solved by commit 2944928 submitted by aleasto

I was about to close this issue #22 but I'm waiting to see the outcome of this discussion. [edit] Issue #22 has been already closed.

There is indeed another artifact problem happening with iris and nouveau gallium drivers, correlated to stride, where mouse cursor using buffers "not aligned 2 pow X" (which is also using SW R/W OFTEN buffers) is showing artifact, maybe this problem with mouse cursor is correlated to your problem too.

Just a wild guess, no guarantees, if you are already using the updated branch of gbm_gralloc would you like to give a try to this "Hack" https://pastebin.com/raw/hrEGij38 which apparently avoids my artifacts problem on isis and nouveau?

Then we will see if the problem is completely defined and identified and if we may close this issue and how to treat my other artifact issue and yours.

from gbm_gralloc.

thank you
I'm not running with intel gpu or nvidia gpu , so I'm not using iris or nouveau .
but however , i'll give it try

from gbm_gralloc.

Hi @maurossi ,
Maybe a stupid question : After i synced code with

./repo init -u https://github.com/remote-android/platform_manifests.git -b redroid-12.0.0 --depth=1
./repo sync -c

I didn't know where to apply the patch , the only gralloc_gbm.cpp I found was device/linaro/dragonboard/gralloc/gralloc_gbm.cpp
Is this the one to be changed?

Sorry for disturbing.

from gbm_gralloc.

@a279437145 graphics related blobs are prebuilt (mesa3d, llvm, gralloc.gbm etc.) in redroid. I can provide you this patched gralloc.gbm if needed. And please move redroid discussion in redroid-doc.

from gbm_gralloc.

device/linaro/dragonboard/gralloc/gralloc_gbm.cpp
Is this the one to be changed?

Correct

from gbm_gralloc.

thanks everyone , i tried that but i still got corrupted screenshots like before .

from gbm_gralloc.