This is needed for ARC-R container targets using arc-cros-gralloc.
Meanwhile, bump -std=c++14 to -std=c++17 for std::optional and others.
Bug: b/433317686
Test: chromium CI + android CI
Change-Id: Id9ed5f27f6788ca63d0bdb9566c54b3cd4030e16
Add build changes for mt8186.
Add ARM metadata types: compression, plane fds and data type.
Add mediatek_drm.h which is not available.
Bug: 388092228
Test: boot corsola with minigbm gralloc/mapper
Change-Id: I1f1e8a57f37e26694320c3ddee01fbad453f854b
* aosp/upstream-main: (27 commits)
minigbm: add some validation check in cros_gralloc
minigbm: update format of mediatek.c
Revert "i915: Vertical align video encode buffers to macroblock size"
minigbm: drv: Fix MINIGBM_DEBUG usage on Android
mediatek: Add BO_USE_PROTECTED use_flag for gpu and video decoder
i915: Vertical align video encode buffers to macroblock size
Don't print verbose messages by default
virgl: Store format modifier in blob's bo meta
Fix convertToFenceHandle()
minigbm: update drv_get_os_option() to try getenv() first
Update usage to 64-bit
virtgpu_cross_domain: fix prop query for mt8183 camera quirk
virtgpu_virgl: use blobs for ABGR8888
minigbm: move camera work-around
mediatek: Add BO_USE_PROTECTED use_flag to support secure buffer allocation
i915: prefer tile4 for non-linear scanout buffers
i915: allow linear mapping for P010 scanout
minigbm: remove `close_gem_handle`
mediatek: Exclude MT8173's FP16 and 10-bit ABGR support
minigbm: Use clflushopt if supported
...
Change-Id: I38fb3f2c699205f73633e07d1824c4fd48dac5f5
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
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>
... by reserving the first section in the shared memory
reserved region for a new CrosGralloc4Metadata struct.
BUG=b:207388558
TEST=cvd start
TEST=vts -m VtsHalGraphicsMapperV4_0Target
TEST=cvd start --gpu_mode=gfxstream
TEST=vts -m VtsHalGraphicsMapperV4_0Target
Change-Id: I7c59196ca747dc0fe854cdb4cbbcd21dd82e1401
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/3421048
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Dominik Behr <dbehr@chromium.org>
Tested-by: Jason Macnak <natsu@google.com>
Commit-Queue: Jason Macnak <natsu@google.com>
... to support upcoming change where CrosGralloc4Mapper's
get(<metadata>) will want to access metadata that may be
in either the buffer's handle or the buffer's reserved
region. Adding getter's will allow simplify
CrosGralloc4Mapper's get(<metadata>) method to just take
a cros_gralloc_buffer as an argument.
BUG=b:207388558
TEST=cvd start
TEST=vts -m VtsHalGraphicsMapperV4_0Target
TEST=cvd start --gpu_mode=gfxstream
TEST=vts -m VtsHalGraphicsMapperV4_0Target
Change-Id: I8048ef0e1af0ec8f42484d42a5eb88e69c003351
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/3433120
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Dominik Behr <dbehr@chromium.org>
Tested-by: Jason Macnak <natsu@google.com>
Commit-Queue: Jason Macnak <natsu@google.com>
... to make it easier handle ownership (no more conditional
ownership if the buffer was allocated versus imported).
This also helps avoid a deadlock in CrosGralloc4Mapper's
dumpBuffers() in an upcoming change where CrosGralloc4Mapper
wants to interact with both metadata in the handle and
metadata in the cros_gralloc_buffer's reserved region. By
having the cros_gralloc_buffer always have a handle, the
CrosGralloc4Mapper can have access to all metadata when it
has a cros_gralloc_buffer parameter.
BUG=b:207388558
TEST=cvd start
TEST=vts -m VtsHalGraphicsMapperV4_0Target
TEST=cvd start --gpu_mode=gfxstream
TEST=vts -m VtsHalGraphicsMapperV4_0Target
Change-Id: I56fffbbfacf8436db165a961bec8ce546b4acc6c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/3433118
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Roman Stratiienko <r.stratiienko@gmail.com>
Reviewed-by: Dominik Behr <dbehr@chromium.org>
Tested-by: Jason Macnak <natsu@google.com>
Commit-Queue: Jason Macnak <natsu@google.com>
Vulkan on Android relis on VkImageDrmFormatModifierExplicitCreateInfoEXT
to import the gralloc allocated buffer, which requires buffer info of
the host storage.
BUG=b:186679287
TEST=venus wsi on arcvm and egl/gles
TEST=CtsNativeHardwareTestCases and related CtsGraphicsTestCases
Change-Id: I7ab0e80ab67a2daae9ea547a8d5abe9417af17d8
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/2862161
Tested-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Commit-Queue: Yiwei Zhang <zzyiwei@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>
Implements the allocator 3.0 and mapper 3.0 interfaces
which:
- Implements HIDL interface directly (older versions
are wrapped in a passthrough HIDL interface)
- Adds isSupported() to allow checking for format and
usage combination support before allocating.
Adds emulated multi-planar buffer support to virtio
backend for non gbm enabled hosts.
Updates cros_gralloc_handle to use uint64_t instead of
two uint32_t for some members.
Updates cros_gralloc_handle to have a single format
modifier.
Replaces Android makefiles with Android bp files.
BUG=b:146515640
TEST=run Cuttlefish w/ gralloc3 and run CTS tests
Change-Id: I43ed9788a2413201bddce17ffb69b76006ef39fd
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/2273554
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Jason Macnak <natsu@google.com>
Commit-Queue: Jason Macnak <natsu@google.com>
In ARC++, the wayland sevice and the video stack rely on
GRALLOC_DRM_GET_STRIDE and (*lock_ycbcr) with zero flags to return
the metadata associated with the buffer.
In the past, we've simply returned the metadata that was calculated
during allocation.
Since the current virtio-gpu API relies on shadow buffers, there's
actually two different sets of metadata:
1) The metadata of the shadow buffer --> useful for mapping
2) The metadata of the host resource --> useful for passing to Chrome
For the wayland_service and video stack, we want to return (2).
For the Android framework, we want to return (1).
BUG=b:132939420
TEST=compile
Change-Id: I1134d651396ba68e064eaf2e3cad3cb3225d7c5c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/1681383
Reviewed-by: David Stevens <stevensd@chromium.org>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
This is a requirement of gralloc and the graphics.mapper HAL in Android.
BUG=b:143924619
TEST=Photo capture in GCA succeeds and most camera CTS tests pass
Change-Id: Ic34a49aa7175c1c3b9f6c0738b5ab848e002b93d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/2035207
Tested-by: Matthias Springer <springerm@chromium.org>
Commit-Queue: Matthias Springer <springerm@chromium.org>
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-by: David Stevens <stevensd@chromium.org>
Auto-Submit: Matthias Springer <springerm@chromium.org>
There's no flush or invalidate mechnaism with the DRI interface,
so we'll have to support mapping and unmapping.
BUG=b:72972511
TEST=gbmtest passes in CQ
Change-Id: If3aef651f8549544ed4ed499e17f7f99c597974c
Reviewed-on: https://chromium-review.googlesource.com/990892
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Satyajit Sahu <satyajit.sahu@amd.com>
Reviewed-by: Joe Kniss <djmk@google.com>
Reviewed-by: Satyajit Sahu <satyajit.sahu@amd.com>
This code might be loaded by a daemonized process now, so the existing
logging to stderr goes nowhere. It's better to use the Android logger.
Change-Id: I19f088b8f049f07c9c6839038d2971fad1a0e852
Reviewed-on: https://chromium-review.googlesource.com/971360
Commit-Ready: Alistair Strachan <astrachan@google.com>
Tested-by: Alistair Strachan <astrachan@google.com>
Reviewed-by: Alistair Strachan <astrachan@google.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
The reason the tests weren't passing is because DRM_IOCTL_I915_GEM_SET_DOMAIN
is required on x86 platforms when calling (*lock). A previous CLs added this.
BUG=b:67073097, b:67331142
TEST=
android.view.cts.SurfaceViewSyncTests
android.video.cts.VideoEncoderDecoderTest#testAvcGoog0Qual0720x0480
android.video.cts.VideoEncoderDecoderTest#testAvcGoog0Qual1280x0720
android.video.cts.VideoEncoderDecoderTest#testAvcGoog0Qual1920x1080
android.media.cts.EncodeDecodeTest#testVP8EncodeDecodeVideoFromSurfaceToSurface720p
android.media.cts.EncodeDecodeTest#testEncodeDecodeVideoFromPersistentSurfaceToSurface720p
android.media.cts.EncodeDecodeTest#testVP8EncodeDecodeVideoFromPersistentSurfaceToSurface720p
pass on Eve.
This reverts commit 14033e0013.
v2: Make lock_data[0] null after last (*unlock)(), because user may specify different
access regions in the next (*lock)().
Change-Id: Ia56ecd57acc4471b026c852b178d8bc0f189dec7
Reviewed-on: https://chromium-review.googlesource.com/710324
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
This will allow drivers to tile or detile only the regions requested
by the user. Note that the gralloc spec states that:
"This address will represent the top-left corner of the entire buffer,
even if accessRegion does not begin at the top-left corner."
(see hardware/interfaces/graphics/mapper/2.0/IMapper.hal in AOSP)
Also, the gralloc API makes it difficult to maintain two mappings of
the same buffer. For example, say you have two access regions:
module->lock(mod, handle1, 0, 0, 5, 5, &addr);
module->lock(mod, handle1, 5, 5, 10, 10, &addr);
module->unlock(mod, handle1); // which access region should be unlocked?
In practice, this scenario never happens on Android.
It's not exactly clear what gbm should return. Let's just return the
top left of the access region because that's what we where doing before.
BUG=chromium:764871
TEST=gbmtest, mmap_test -g, the following CTS tests:
android.view.cts.SurfaceViewSyncTests
android.media.cts.EncodeDecodeTest
android.video.cts.VideoEncoderDecoderTest
Change-Id: I7ca0713871e03928b1d4402aa161588990c7e775
Reviewed-on: https://chromium-review.googlesource.com/758147
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Since some drivers (AMDGPU, Tegra) may have to do expensive tiling
and detiling operations, we should try to take advantage of the
access regions passed in by gralloc and gbm. Let's refactor struct
map_data so we can separate the actual mapping and access region.
Here is the Coccinelle rule used in this change:
@@ struct map_info *M; @@
- (M)
+ M->vma
In addition, struct map_data was also renamed to struct mapping.
BUG=chromium:764871
TEST= mmap_test -g on Kevin
Change-Id: Idb094aa3b5f81e45ce3a2f4fb2d9bf8fba32bf29
Reviewed-on: https://chromium-review.googlesource.com/758144
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Joe Kniss <djmk@google.com>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
We may need to invalidate a buffer before reading it. Some use
cases are:
- DRM_IOCTL_I915_GEM_SET_DOMAIN
- DMA_BUF_IOCTL_SYNC with the SYNC_START option
- DRM_IOCTL_VIRTGPU_TRANSFER_FROM_HOST
This patch adds the function hook.
BUG=chromium:764871
TEST=compiles
Change-Id: I85811407252b859a12294381c65ff3545424636b
Reviewed-on: https://chromium-review.googlesource.com/710322
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
It looks like munmap is probably necessary for i915 and serves
some important function. Let's revert until we can figure
out what's going on.
BUG=b:67073097
TEST=android.view.cts.SurfaceViewSyncTests#testVideoSurfaceViewCornerCoverage
This reverts commit 254dbb19c4.
Change-Id: Idac50930f9f13b4867110a31fadb1a2547d05d07
Reviewed-on: https://chromium-review.googlesource.com/699802
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
It's helpful to differentiate map flags from normal buffer creation
flags. Note gralloc doesn't differentiate between map flags and buffer
creation flags. However, since flags are passed in with gralloc
(*lock)(), we can use a separate conversion function there.
BUG=chromium:764871
TEST=Boot Android and play games on Eve
Change-Id: Ic8aee84d9ac945abf93d9a9bda78fe3f77711cc3
Reviewed-on: https://chromium-review.googlesource.com/691424
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
As an optimization, let's call:
- drv_bo_flush when calling (*unlock).
- drv_bo_flush during gbm_bo_unmap()
CL:441916 makes sure that the buffer is unmapped before the
buffer destroy ioctl is called, so we will not be leaking
mappings in any case.
BUG=chromium:764871
TEST=Android boots, 8 CTS tests, and Youtube app works on Eve
gbmtest, mmap_test -g
Change-Id: I429739a8c6435a434dac41ad125761364a3775d0
Reviewed-on: https://chromium-review.googlesource.com/668220
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Even though it does not currently imply any technical issues, it is not
very elegant for the code to assign buffer map base to addr[0] first and
then modify it in a loop by adding a plan address. Let's just store the
map base in a local variable and use it in plane address calculation.
BUG=b:38250067
TEST=android.media.cts.DecoderTest on veyron_minnie
Change-Id: If2e95086385d96ced760cc94c8c747bffd0c6f55
Reviewed-on: https://chromium-review.googlesource.com/592988
Commit-Ready: Tomasz Figa <tfiga@chromium.org>
Tested-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Before we return to userspace, we should clear the output array of
pointer values, so that it doesn't contain some spurious data.
Furthermore, if zero flags are given, the lock method itself
dereferences addr[0] before assigning any value there.
BUG=b:38250067
TEST=android.media.cts.DecoderTest on veyron_minnie
Change-Id: I58284477b3813265188f1714f00b1fb7003ed2a3
Reviewed-on: https://chromium-review.googlesource.com/592987
Commit-Ready: Tomasz Figa <tfiga@chromium.org>
Tested-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Since we decided not to support gralloc1 and gralloc0 requires standard
errno-based error codes to be returned to callers, remove the custom
error code enumeration and use standard codes everywhere in
cros_gralloc.
BUG=b:63915090
TEST=Play store starts on Eve
Change-Id: I4f466e8cac6323554f29a7da5c2c00ab47b0abf2
Reviewed-on: https://chromium-review.googlesource.com/580735
Commit-Ready: Tomasz Figa <tfiga@chromium.org>
Tested-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Map read/write permissions were being ignored by minigbm. This can
cause segfaults or failed mappings if the device FD permissions are not
rw.
Also adds bounds checking in tegra.c for tile/untile transfers.
BUG=chromium:737328
TEST=cyan, nyan graphicsSanity with read only on device
Change-Id: I8fccaed4e908cda3ff7d7cf451d0ad75d65039e6
Reviewed-on: https://chromium-review.googlesource.com/556980
Commit-Ready: Joe Kniss <djmk@google.com>
Tested-by: Joe Kniss <djmk@google.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
We want the ability to support gralloc0, gralloc1 and HIDL
gralloc in this repo. This commit moves gralloc0 specific code
to the gralloc0 subdirectory, and refactors the rest of the code
so it can be eventually used by whichever APIs we choose to
implement.
In addition, all of the data by the module is now handled by
managed pointers instead of process data, since we get a number
of crash reports when we try to access data in gralloc_close().
BUG=b:62069164, b:62221166
TEST=gralloctest all, Android boots, Youtube videos, 5-10
CTS tests
Change-Id: Ic29a777573936216d99498d0b814ea50015fd435
Reviewed-on: https://chromium-review.googlesource.com/521794
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
