We need use_flags when we implement the dri interface on top of hbm.
Also, dri_bo_create_with_modifiers does not take use flags only because
gbm_bo_create_with_modifiers does not. That has changed with
gbm_bo_create_with_modifiers2 although minigbm does not reflect that.
BUG=b:292148713
TEST=CQ
Change-Id: I120358c843140a937fee1dd6183d1836ea622eec
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/5801181
Reviewed-by: Ryan Neph <ryanneph@google.com>
Commit-Queue: Chia-I Wu <olv@google.com>
Tested-by: Chia-I Wu <olv@google.com>
Reviewed-by: Dominik Behr <dbehr@chromium.org>
Make dri_driver a proper object that the backend can create, rather than
something that the backend must inherit from.
This makes dri_init return a dri_driver and make the rest dri_*
functions take a dri_driver. There is no functional change.
BUG=b:292148713
TEST=CQ
Change-Id: I3ef045d73b0015b5c6d926dec7bae69d35d94275
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/5801179
Reviewed-by: Dominik Behr <dbehr@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Commit-Queue: Chia-I Wu <olv@google.com>
Tested-by: Chia-I Wu <olv@google.com>
The multi-planar formats are being allocated into a single plane,
and the minigbm exynos backend is dropped. So we can use `handle` instead of handles as of now.
Remove some of the helper functions that calculate the number of planes.
There is no need to check if there is more than one kernel buffer per buffer object.
Added a new function `drv_gem_close` in `drv_helpers` that can be used by `drv_gem_bo_destroy` and `drv_prime_bo_import`. It can be used to clean the unused gem_handle.
Bug=b:266776512
TEST=camera and screenshot work fine after deploying the change #strongbad
TEST=camera and screenshot work fine after deploying the change #kukui-arc-r
TEST=camera and screenshot work fine after deploying the change, tested a couple of apps in the Google Play Store, and checked file `dma_buf/bufinfo` to see there's no object leaking. #guybrush
Change-Id: Ib63559504e4cb8f1a32ae90170925146613d694f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/4297873
Commit-Queue: Dawn Han <dawnhan@google.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Tested-by: Dawn Han <dawnhan@google.com>
The test requires the strides to be aligned consistently despite the use
flags. This is a test bug (b/167947334) before R.
BUG=b:265746435
TEST=android.hardware.camera2.cts.ImageWriterTest#testYuvImageWriterReaderOperation
Change-Id: I0f56b12f46c1a2d65ec7096d337c562459c35ee8
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/4351634
Tested-by: Chia-I Wu <olv@google.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Commit-Queue: Chia-I Wu <olv@google.com>
sommelier makes VIRTWL_IOCTL_NEW_DMABUF requests for 2D apps. crosvm's
virtio-wl allocates linear BOs in response and expects them to be
presentable.
BUG=b:273797429
TEST=xeyes and gedit in crostini
Change-Id: Id5a955e5c22342ee11e9e333720eb95ac08fd175
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/4343374
Tested-by: Chia-I Wu <olv@google.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Commit-Queue: Chia-I Wu <olv@google.com>
GFX10+ cannot support DRM_FORMAT_YVU420_ANDROID when the strides do not
meet hw requirement. When that happens, force the format to
DRM_FORMAT_YVU420 and log an error.
When the bo is used as a classic resource by virglrenderer, this is
hopefully fine because the guest only sees the guest storage (unless
there are bugs elsewhere). Otherwise, the logs can lead us to proper
fixes.
BUG=b:265746435
TEST=subset of CTS and CTS Verifier on grunt, guybrush and skyrim
Change-Id: I0fda9e2f09bec8c26e87748b9d58c4f8e186e34d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/4336266
Tested-by: Chia-I Wu <olv@google.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Commit-Queue: Chia-I Wu <olv@google.com>
drv_bo_from_format will apply stride_align to all planes. Since we
always pass 1 for stride_align, there is no change except when the
format is DRM_FORMAT_YVU420_ANDROID.
When the format is DRM_FORMAT_YVU420_ANDROID, and when stride_align is 0
or 1, drv_bo_from_format assumes there is no hw requirement and forces
stride_align to 16. But because we used to require stride to be aligned
to 32, there is no actual change either.
BUG=b:265746435
TEST=subset of CTS and CTS Verifier on grunt, guybrush and skyrim
Change-Id: Ia6ef89bb744c39d2baead07bc47f11b0eea96b97
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/4336265
Tested-by: Chia-I Wu <olv@google.com>
Commit-Queue: Chia-I Wu <olv@google.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Dawn Han <dawnhan@google.com>
Remove the parameter to align with upstream gbm.
For some places that use the number of planes. The number is 1. The
multi-planar formats are being allocated into a single plane, and
minigbm exynos backend is dropped. So we can just set the plane
index to 0 if needed.
Fixed the format in i915.c.
Bug=b:266776512
TEST=camera works after deploying the change #strongbad
TEST=camera works after deploying the change #corsola
Change-Id: I0880917754c01b9d0f27d21f3c42d87f00a09f50
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/4249501
Commit-Queue: Dawn Han <dawnhan@google.com>
Tested-by: Dawn Han <dawnhan@google.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olv@google.com>
It can be used to preload a backend, currently only used to preload
amdgpu.
BUG=b:269664560
TEST="grep radeonsi /proc/$(pidof zygote)/maps" on grunt
Change-Id: I30d9f701f1da3bc243a9c81326a1ba0c5e0562de
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/4262034
Commit-Queue: Chia-I Wu <olv@google.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Tested-by: Chia-I Wu <olv@google.com>
This is required for modern Android atop a gralloc with the cross_domain
backend or other native backend.
BUG=b:238609372
TEST=build and AHB cts
Change-Id: Id963eeec62c4400cc009384e127c93588c99346e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/3777566
Auto-Submit: Yiwei Zhang <zzyiwei@chromium.org>
Tested-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Jason Macnak <natsu@google.com>
Commit-Queue: Yiwei Zhang <zzyiwei@chromium.org>
crrev/c/3633249 compares libva and minigbm allocated Surfaces/BOs
for accelerated video decoding. Currently it fails on e.g. zork
because libva (mesa-amd backend) aligns those buffers to 256,
whereas minigbm aligns them to 512. This CL reduces the 512-align
provision in amdgpu to Android-originated buffers, where IIUC
from the bug there is such restriction.
BUG=b:200680176
BUG=b:171013552
TEST=vaapi_unittest on zork w/ crrev/c/3633249
Change-Id: I703037c70dded8596408c475518a29de3b59f039
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/3647157
Tested-by: Miguel Casas-Sanchez <mcasas@chromium.org>
Reviewed-by: Drew Davenport <ddavenport@chromium.org>
Commit-Queue: Miguel Casas-Sanchez <mcasas@chromium.org>
This is required for importing multi-plane modifiers where the
format plane count is lower (usually `1`). It will be used
by Exo for v3/4 of the `zwp_linux_dmabuf_v1` Wayland potocol,
allowing Wayland clients (and thus all clients that build on
the Wayland support) to use explicit modifiers which again
can increase performance on many GPUs.
Also add another fallback path to `dri_num_planes_from_modifier()`
for cases when `queryDmaBufFormatModifierAttribs()` fails and do
some refactoring there. Without this, some test apparently fail.
This includes the amdgpu part of
commit 1a733377e9, partially reverting
commit 853b8542fb.
Bug🅱️224580219
Change-Id: I93b64123420b39f3b83ff1bbbb9c59ddf4bc6105
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/3568489
Reviewed-by: Bas Nieuwenhuizen <basni@chromium.org>
Tested-by: Robert Mader <robert.mader@collabora.com>
Commit-Queue: Robert Mader <robert.mader@collabora.com>
This reverts commit 1a733377e9.
Reason for revert: Broke many ARC tests b/227807607 b/227830888
Original change's description:
> minigbm: i915/amdgpu: Update plane count in bo_import
>
> For format/modifier combination where the plane count does not
> match the `DRM_FORMAT_MOD_INVALID` case, importing BOs
> (via e.g. `gbm_bo_import`) currently fails as `bo->meta.num_planes`
> is not set correctly.
>
> Fix that by making the driver backends that support such
> format/modifier combinations update the plane count accordingly.
>
>
> minigbm: i915: Implement num_planes_from_modifier interface
>
> Some format/modifier combinations have different plane counts
> compared to the formats default (i.e. when the modifier is
> `DRM_FORMAT_MOD_INVALID`).
>
> Right now the supported cases are hardcoded in
> `i915_bo_compute_metadata()`, however this does not cover all
> use-cases. So implement the already existing backend interface,
> aligning i915 with e.g. amdgpu.
>
> Bug🅱️224580219
> Change-Id: If017997c70ab7da04ebf9d6cb9db775d9271ed05
> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/3516490
> Reviewed-by: Bas Nieuwenhuizen <basni@chromium.org>
> Tested-by: Bas Nieuwenhuizen <basni@chromium.org>
> Commit-Queue: Bas Nieuwenhuizen <basni@chromium.org>
Bug: b:224580219
Change-Id: I334f8cedb1d0414ecd0a38217afa4afc0df6ab47
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/3568890
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Tested-by: Kazuhiro Inaba <kinaba@chromium.org>
Auto-Submit: Kazuhiro Inaba <kinaba@chromium.org>
Reviewed-by: Tadashi G. Takaoka <takaoka@google.com>
Commit-Queue: Tadashi G. Takaoka <takaoka@google.com>
Owners-Override: Tadashi G. Takaoka <takaoka@google.com>
For format/modifier combination where the plane count does not
match the `DRM_FORMAT_MOD_INVALID` case, importing BOs
(via e.g. `gbm_bo_import`) currently fails as `bo->meta.num_planes`
is not set correctly.
Fix that by making the driver backends that support such
format/modifier combinations update the plane count accordingly.
minigbm: i915: Implement num_planes_from_modifier interface
Some format/modifier combinations have different plane counts
compared to the formats default (i.e. when the modifier is
`DRM_FORMAT_MOD_INVALID`).
Right now the supported cases are hardcoded in
`i915_bo_compute_metadata()`, however this does not cover all
use-cases. So implement the already existing backend interface,
aligning i915 with e.g. amdgpu.
Bug🅱️224580219
Change-Id: If017997c70ab7da04ebf9d6cb9db775d9271ed05
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/3516490
Reviewed-by: Bas Nieuwenhuizen <basni@chromium.org>
Tested-by: Bas Nieuwenhuizen <basni@chromium.org>
Commit-Queue: Bas Nieuwenhuizen <basni@chromium.org>
Previously these would get leaked if we had multiple bo structs
pointing to the same image/GEM BO as each has their own DRI image,
but bo_destroy only gets called on the last struct.
To mitigate this we have a new callback for every struct where we
can free the DRI image.
BUG=b:185869479
TEST=Repeatedly open/close camera app on Grunt.
Change-Id: I6188346b5bf9e5cbbbbf32a3db621a3fe0276d4f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/3270684
Tested-by: Bas Nieuwenhuizen <basni@chromium.org>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Commit-Queue: Bas Nieuwenhuizen <basni@chromium.org>
It makes more sense to resovle the format and use_flags together to
avoid duplicates.
Add the helper to vc4 and dumb_driver backends since that's missed
from prior frontend refactoring.
Split the resolve helper in virtgpu_virgl for the 3d and 2d paths to
make code logic cleaner.
BUG=b:199524294
TEST=CQ
Change-Id: I89b633ea484f0fc5bb9b4e0548cad017b9970cc6
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/3200143
Tested-by: Yiwei Zhang <zzyiwei@chromium.org>
Tested-by: Jason Macnak <natsu@google.com>
Reviewed-by: Chia-I Wu <olv@google.com>
Reviewed-by: Jason Macnak <natsu@google.com>
Reviewed-by: Dominik Behr <dbehr@chromium.org>
Commit-Queue: Yiwei Zhang <zzyiwei@chromium.org>
1. frontends access the driver via drv.h only
2. the renamed drv_helpers and drv_array_helpers are for driver only
3. remove extern "C" from drv_helpers.h given not exposed to gralloc
4. remove all redundant includes for those helpers
BUG=b:199524294
TEST=CQ and gralloc builds on aosp
Change-Id: I3f4d33076a6a8161804f1b7c26950ff5496507e9
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/3195651
Tested-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olv@google.com>
Commit-Queue: Yiwei Zhang <zzyiwei@chromium.org>
Only 2d virtgpu backend needs to fallback here because virtio primary
plane only allows DRM_FORMAT_XRGB8888.
Most our platforms cannot display YV12 (except msm), thus the fallback
is required for the converted DRM_FORMAT_YVU420_ANDROID. For virgl
backend, additionally append a BO_USE_LINEAR as a replacement for the
hack inside compute_virgl_bind_flags.
BUG=b:199524294
TEST=CQ
TEST=gralloctest alloc_combinations
TEST=android.media.cts.VideoDecoderRotationTest
Change-Id: Ic87838ea2aae2b0abf87ed898ad75a3d7e556471
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/3166775
Tested-by: Yiwei Zhang <zzyiwei@chromium.org>
Auto-Submit: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Commit-Queue: Yiwei Zhang <zzyiwei@chromium.org>
rgb565 is a common default pixel format for a native window on Android
when app or the platform doesn't override the pixel format. So it's a
must support format for scanout.
BUG=b:198669698
BUG=b:198098339
BUG=b:198098005
TEST=ASurfaceControlTest
TEST=SurfaceViewTests
Change-Id: Ie7199a3e7b181660497566c4a51d413e73ac4540
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/3140733
Reviewed-by: Lepton Wu <lepton@chromium.org>
Tested-by: Yiwei Zhang <zzyiwei@chromium.org>
Commit-Queue: Yiwei Zhang <zzyiwei@chromium.org>
For virtualization purposes we always want to have a modifier. With
radeonsi that means allocating with modifiers. This has the
complication that the structure of modifiers isn't trivial.
Three implementation options:
1) Add dri-flag to create bo with valid modifier
2) Figure out scanout capable modifiers in minigbm
3) Take scanout capable modifiers from kernel.
3 is an issue because the card node is often behind a video group
on desktop linux and we don't want to create something that won't
work on desktop linux.
For 2 I figured out that the structure is actually fairly simple if
we assume that the DRI driver doesn't provide useless modifiers.
For 1 we'd end up having to do the same work as 2 + define the
DRI interface + maybe have to deal with older somewhat buggy kernels.
So I ended up selecting 2.
Note that this also removes CURSOR usage in the old path with DRI
On AMD we only allow linear for the cursor so this gets handled
in the linear path.
BUG=b:192390822
TEST=Run vkcube on zork-arc-r.
Change-Id: Ibde0e2ec761e293486c8ee71cfd88d9846ba09da
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/3086527
Commit-Queue: Bas Nieuwenhuizen <basni@chromium.org>
Tested-by: Bas Nieuwenhuizen <basni@chromium.org>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Aligning the stride to 512 for multiplane images seems to be problematic
for VCE, resulting in protection faults and kernel hangs.
To avoid this situation, don't apply the 512 stride alignment workaround
for bos that will be used for encoding on Stoney.
BUG=b:195623914, b:195676997, b:195025184
TEST=camera.CCAUISmoke.video_fake and camera.CCAUISmoke.video_fake pass on grunt
CtsMediaTestCases android.media.cts.EncodeDecodeTest passes on grunt
Change-Id: I233391105c4fe1bc56d684676eb0e5813ccda9dc
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/3097148
Tested-by: Drew Davenport <ddavenport@chromium.org>
Reviewed-by: Bas Nieuwenhuizen <basni@chromium.org>
Commit-Queue: Drew Davenport <ddavenport@chromium.org>
This was restricted to Raven. Modify that restriction so that this
happens for Stoney as well. It seems that Stoney is also affected by
this same issue, but it just didn't cause any CTS or other errors until
the mesa-amd uprev added some additional correctness checks.
TEST=android.media.cts.EncodeDecodeTest passes on grunt
BUG=b:190484589
Change-Id: Ieebbffb0d711d08c24c071e79c0b3224663c8369
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/3060894
Reviewed-by: Bas Nieuwenhuizen <basni@chromium.org>
Tested-by: Drew Davenport <ddavenport@chromium.org>
Commit-Queue: Drew Davenport <ddavenport@chromium.org>
Tiled buffers do not need 256 alignment, and doing so leads to failing
new sanity checks added in a more recent mesa version [1].
The underlying problem for android (different map-time and allocation-time
strides for tiled buffers) is worked around in another way.
[1] https://chromium.googlesource.com/chromiumos/third_party/mesa/+/f7a4051b836/src/amd/common/ac_surface.c#2791
BUG=b:190028349
TEST=Pass CtsNativeHardwareTestCases on zork and grunt
Change-Id: I72f67f1bc089a27b187024df64280efbd8465217
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/2952005
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Drew Davenport <ddavenport@chromium.org>
Commit-Queue: Drew Davenport <ddavenport@chromium.org>
Some CTS tests allocate buffers with
AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE or
AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT along with
AHARDWAREBUFFER_USAGE_CPU_READ_RARELY, which is not a common usage in
the real world.
On AMD platforms, this results in a tiled buffer being allocated which
ends up having a different stride when mapped for read, and the
different stride does not get propagated to the caller through the
gralloc API. This results in CTS test failures when checking buffer
contents.
Removing support for READ_RARELY and WRITE_RARELY usage for tiled buffers
in Android works around this by ensuring that any buffers that need to be
mapped for read/write are linear buffers.
BUG=b:190028349
TEST=CtsNativeHardwareTestCases passes on grunt and zork
Change-Id: I9d595ea980b352610b2379330935505d92e8a555
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/2952004
Tested-by: Drew Davenport <ddavenport@chromium.org>
Reviewed-by: Jason Macnak <natsu@google.com>
Reviewed-by: Bas Nieuwenhuizen <basni@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Commit-Queue: Drew Davenport <ddavenport@chromium.org>
This workaround addresses instability on grunt devices, but is a much
larger alignment than should be required. On zork, the larger alignment
ends up triggering a check that was added in mesa 21.1, causing an
allocation failure for some use cases.
Restrict the workaround to grunt devices, which are not affected by the
new check in mesa 21.1
BUG=b:180755705
TEST=start crostini on zork
Change-Id: I15855e06edb784fbca6b1128ed260450c2c82e27
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/2879313
Tested-by: Drew Davenport <ddavenport@chromium.org>
Reviewed-by: Bas Nieuwenhuizen <basni@chromium.org>
Commit-Queue: Drew Davenport <ddavenport@chromium.org>
Am I the only one who does this????
BUG=none
TEST=none
Change-Id: Ie121703c631debd5e7eed1760334bb8ce5ebe115
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/2857885
Reviewed-by: Lingfeng Yang <lfy@google.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Auto-Submit: Gurchetan Singh <gurchetansingh@chromium.org>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Virgl are expecting host gpm can handle this format, so just
enable this for amdgpu.
BUG=b:177032502
TEST=manual - run CtsNativeHardwareTestCases on zork-arc-r
Change-Id: I574d3bfda5a86a6a42790cd02edc137f0e367471
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/2850989
Tested-by: Lepton Wu <lepton@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Commit-Queue: Lepton Wu <lepton@chromium.org>
- Sometimes were return -1 and sometimes -errno. Prefer -errno
wherever possible.
- No braces for single line if/else statements. This does not
apply gralloc3/gralloc4, since that directory follows AOSP
style.
BUG=b:178495907
TEST=Cuttlefish CFI
Change-Id: I4c35768e015109730772a972b4b18e8d2c3cbb9b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/2665001
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Jason Macnak <natsu@google.com>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
The early version of the modifier assumed per plane modifiers.
The current version is only one modifier per buffer object.
BUG=none
TEST=compile
Change-Id: Ic3899118d44cb172ee2e4eae346e98cdf8328cf9
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/2654590
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
It's good to do this every once and a while.
Change-Id: Ief71a50e07a51e2ac1b66daf1ed0c8b9129d9c1f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/2368212
Reviewed-by: Jason Macnak <natsu@google.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Should be fine for rendering and texturing.
AMDGPU only exposes this on the primary plane though, not on the
overlay or cursor. I strongly suspect the HW could also do this
on the overlay but I lack a proper testcase for now.
BUG=b:159011420
TEST=Run tast.video.Play.vp9_2_sw on Zork
Change-Id: Ie3a5356576a960985aac0ba16665425f45bd1541
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/2272566
Tested-by: Bas Nieuwenhuizen <basni@chromium.org>
Reviewed-by: Miguel Casas <mcasas@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Commit-Queue: Bas Nieuwenhuizen <basni@chromium.org>
Currently, allocator used by chrome aligns the height of Encoder/Decoder
buffer while allocator used by android(gralloc/minigbm) doesn't provide
any aligment.Aligned the height for video buffers in minigbm.
BUG=b:153130069
TEST=cheets_CTS_P.x86.CtsVideoTestCases
Signed-off-by: Ikshwaku Chauhan <ikshwaku.chauhan@amd.corp-partner.google.com>
Change-Id: I62a883ca55c07674fab7981af0974277fbd2c5b2
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/2273037
Reviewed-by: Bas Nieuwenhuizen <basni@chromium.org>
Reviewed-by: Drew Davenport <ddavenport@chromium.org>
Tested-by: Drew Davenport <ddavenport@chromium.org>
Commit-Queue: Drew Davenport <ddavenport@chromium.org>
This reverts commit 91d36976aa84abde87f0f56d235d57042ca3ea81.i
The previous changes should fix the mapping performance with USWC
memory.
original change:
amdgpu: Set USWC for SCANOUT images.
This is necessary for scanout from GTT. Without it, the kernel will
migrate it to the carveout. For large resolutions this would not be
feasible due to small carveout sizes and hence it is important that
we alloc scanout from GTT.
The original patch was on top of
4eebcea "amdgpu: make AMDGPU_GEM_CREATE_CPU_GTT_USWC flag default"
which set USWC unconditionally, but has since been reverted. The
main failure reason is being addressed in mesa-amd. This patch also
still disables USWC if we can and the image will be read often on
the CPU, to avoid staging textures during memory mapping.
TEST=Run android.hardware.camera2.cts.RecordingTest#testVideoPreviewSurfaceSharing on Grunt.
BUG=b:152378755
Change-Id: Ice0041de6676c057a2659986b962c2d54833e928
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/2246025
Tested-by: Bas Nieuwenhuizen <basni@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Commit-Queue: Bas Nieuwenhuizen <basni@chromium.org>
For SCANOUT images we need to use USWC memory. However USWC
memory is very slow to read from (~25 MiB/second).
At the same time for video decoding there are some images
that are allocated with SCANOUT but at the same time frequently
accessed from the CPU. Just mapping these is going to result
in non-satisfactory performance, so this patch adds a DMA step
to copy it to memory that is faster to acces from the CPU.
Benchmarked on Grunt with
android.hardware.camera2.cts.RecordingTest#testVideoPreviewSurfaceSharing
The time that an image (~500 KiB) is kept mapped for processing,
including the time for mapping and unmapping:
plain GTT (cachaeable): 1.5-2 ms
USWC: 45-50 ms
USWC w/ memcpy: 20-30 ms
USWC w/ SDMA copy: 3.5-5.5 ms
We can clearly see that the Android video processing code only gets
a throughput of ~10 MiB/s with USWC memory. memcpy is slightly more
efficient by getting 20-30 MiB/s, but neither of these are suitable
for 30+ fps video.
Furthermore, with SDMA copy, the timing is roughly as follows:
map:
- Allocate plain GTT BO: ~400-800 us
- map src & dst BO into GPU VM: ~25 us
- submit SDMA copy: ~80 us
- wait till SDMA copy finishes: ~400 us
- unmap src & dst BO from GPU: ~15 us
- map dst BO into CPU: ~30 us
unmap:
- unmapping dst BO from CPU: ~30 us
- Copy not benchmarked (avoided for RO map)
- delete BO: ~100 us
ideas for further improvement:
- BO cache
- rely on implicit sync and don't wait for the copy during
unmapping.
Alternatives that have been rejected:
- Use radeonsi + DRI interface: each plane gets mapped into
its own BO, which is an issue for gralloc.
- more persistently mapping each BO into GPU VM: this needs
proper address space management which adds complexity.
librm_amdgpu can do it for us but brings its own can of worms
with dedup of the drm fd. (which makes e.g. implicit sync not
work with any radeonsi instances in the same process)
- Use SDMA instead of DRI/Radeonsi for more images. This is an
issue because SDMA for images is a whole mess with lots of
corner cases and lots of changes per generation. Furthermore,
it wouldn't work for DCC compressed images.
TEST=Run android.hardware.camera2.cts.RecordingTest#testVideoPreviewSurfaceSharing on Grunt.
BUG=b:152378755
Change-Id: I8f5e00ff4b6d9e31f78fd4de7eb62d0d3aa66438
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/2256228
Tested-by: Bas Nieuwenhuizen <basni@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Commit-Queue: Bas Nieuwenhuizen <basni@chromium.org>
We use SCANOUT_VEA_READ_CAMERA_AND_CPU_READ_WRITE for camera
capture use scenario in Chrome. Therefore, NV12 format must be
allowed for all those usage masks. This CL modifies the usages on
all platforms.
BUG=chromium:982201
TEST=video.EncodeAccel.vp8_720p_i420 on eve
Change-Id: I7880e64049f3bbf9dd1c177619e41362baf641f7
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/2240995
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Hirokazu Honda <hiroh@chromium.org>
Commit-Queue: Hirokazu Honda <hiroh@chromium.org>
minigbm has allowed HW_VIDEO_ENCODER usage to YVU420 so that
chrome can allocate YVU420 with HW_VIDEO_ENCODER. But this
format is no longer allocated by chrome with the usage. Let's
delete the code.
BUG=chromium:982201
TEST=None
Change-Id: Ia6bbc24e7782e3e73c2eb00c00127af212ddf486
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/2245967
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Commit-Queue: Hirokazu Honda <hiroh@chromium.org>
Tested-by: Hirokazu Honda <hiroh@chromium.org>
Auto-Submit: Hirokazu Honda <hiroh@chromium.org>
ARCVM sets encoder/decoder usage on the blob output/input buffers, so
that virtio_gpu knows to perform transfers from/to the host where
appropriate. Recently, virtio_gpu started passing all bind flags to the
host, instead of reducing them in the guest. These factors combined
means that the host backends now need to support encoder/decoder usage
with R8 format.
Test: manually verify ARCVM YouTube
Bug: b:158957350
Change-Id: I58bf657496647f8002c693d17a1186f4cf527b01
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/2245540
Tested-by: David Stevens <stevensd@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Commit-Queue: David Stevens <stevensd@chromium.org>
This reverts commit d2c2843919.
Reason for revert: b/55018529: broke android.hardware.camera2.cts.RecordingTest#testVideoPreviewSurfaceSharing and fixing it is non-trivial
Original change's description:
> amdgpu: Set USWC for SCANOUT images.
>
> This is necessary for scanout from GTT. Without it, the kernel will
> migrate it to the carveout. For large resolutions this would not be
> feasible due to small carveout sizes and hence it is important that
> we alloc scanout from GTT.
>
> The original patch was on top of
> 4eebcea "amdgpu: make AMDGPU_GEM_CREATE_CPU_GTT_USWC flag default"
> which set USWC unconditionally, but has since been reverted. The
> main failure reason is being addressed in mesa-amd. This patch also
> still disables USWC if we can and the image will be read often on
> the CPU, to avoid staging textures during memory mapping.
>
> BUG=b:153247881
> TEST=Run CtsCameraTestCases on Grunt.
> 4k YouTube video p/b
>
> Change-Id: If6393e60cea5d2a98a052d7c46604e0012de0618
> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/2134451
> Tested-by: Bas Nieuwenhuizen <basni@chromium.org>
> Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
> Commit-Queue: Bas Nieuwenhuizen <basni@chromium.org>
Bug: b:153247881
Change-Id: I395798c637ab10a2cf2a2a65a3a418a18feb2310
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/2167399
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Bas Nieuwenhuizen <basni@chromium.org>
Commit-Queue: Bas Nieuwenhuizen <basni@chromium.org>
This is necessary for scanout from GTT. Without it, the kernel will
migrate it to the carveout. For large resolutions this would not be
feasible due to small carveout sizes and hence it is important that
we alloc scanout from GTT.
The original patch was on top of
4eebcea "amdgpu: make AMDGPU_GEM_CREATE_CPU_GTT_USWC flag default"
which set USWC unconditionally, but has since been reverted. The
main failure reason is being addressed in mesa-amd. This patch also
still disables USWC if we can and the image will be read often on
the CPU, to avoid staging textures during memory mapping.
BUG=b:153247881
TEST=Run CtsCameraTestCases on Grunt.
4k YouTube video p/b
Change-Id: If6393e60cea5d2a98a052d7c46604e0012de0618
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/2134451
Tested-by: Bas Nieuwenhuizen <basni@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Commit-Queue: Bas Nieuwenhuizen <basni@chromium.org>
This reverts commit 4eebcea0cc.
Reason for revert: Broke tast.video.DecodeAccel.*.h264_resolution_switch on grunt
Original change's description:
> amdgpu: make AMDGPU_GEM_CREATE_CPU_GTT_USWC flag default
>
> amdgpu kernel driver requires USWC flag for allowing bo
> allocation in GTT domain, hence enable it by default.
>
> BUG=b:152378755
> TEST=On Dali play 4k YouTube video
>
> Signed-off-by: Shirish S <shirish.s@amd.com>
> Change-Id: Ic509701f683d184d3fb85b7616dc9a7ed467cfe3
> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/2128147
> Tested-by: Bas Nieuwenhuizen <basni@chromium.org>
> Reviewed-by: Bas Nieuwenhuizen <basni@chromium.org>
> Reviewed-by: Drew Davenport <ddavenport@chromium.org>
Bug: b:152378755
Change-Id: If382833a741faa5462df841cc801e60fd9fca77a
Exempt-From-Owner-Approval: revert.
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/2145078
Tested-by: Ilja H. Friedel <ihf@chromium.org>
Reviewed-by: Jao-ke Chin-Lee <jchinlee@google.com>
