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
... 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. The for-each-[handle|buffer] methods support
dumpBuffers() where we need to iterate over all of the
buffers while holding a lock on the cros_gralloc_driver's
mutex.
BUG=b:207388558
TEST=cvd start
TEST=vts -m VtsHalGraphicsMapperV4_0Target
TEST=cvd start --gpu_mode=gfxstream
TEST=vts -m VtsHalGraphicsMapperV4_0Target
Change-Id: I674cab487d7446af722f94d796f504cf4f97de27
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/3433121
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>
... 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>
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>
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>
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 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>
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>
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>
