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>
Add a flag to indicate that a buffer will be used for front-buffer (low-
latency) rendering. We need to avoid using framebuffer compression in
this case, as the compression data and pixel data can be transiently out
of sync, resulting in corrupted display.
BUG=b:168868719
TEST=None
Change-Id: I08e6444aba99a5f694d010372277de775bc56fd4
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/2450927
Tested-by: Rob Clark <robdclark@chromium.org>
Auto-Submit: Rob Clark <robdclark@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Commit-Queue: Rob Clark <robdclark@chromium.org>
Chrome needs to allocate a linear buffer that a hardware video encoder can read
and cpu can read and write. There is no use flag in gbm that specifies the
former. This CL introduces a new use flag for that.
BUG=b:138703716
TEST=None
Change-Id: Ied0321914a366294a47e4fc5c2a8f08ee0351bd8
Reviewed-on: https://chromium-review.googlesource.com/1728729
Tested-by: Hirokazu Honda <hiroh@chromium.org>
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Legacy-Commit-Queue: Commit Bot <commit-bot@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
This is a reland of 1bd7b04a3a
We've landed CL:1070995 which fixes the missing modifier that
caused tiling corruption on pre-KBL Intel devices and CL:1072638
which makes the failing vda unittests use SCANOUT_VDA_WRITE as
they were supposed to.
Original change's description:
> i915: Add GBM_BO_USE_HW_VIDEO_DECODER use flag
>
> This flag is used to indicate that the platform video decoder will be
> writing into this buffer and that it should be allocated
> accordingly. On Intel, this means that we have to allocate y-tiled
> NV12 for libva to be able to decode to the buffer.
>
> We force gralloc NV12 allocations to be linear for now, since ARC++
> doesn't properly pass modifiers to ChromeOS.
>
> BUG=822346
> TEST=test_that graphics_Gbm
>
> Change-Id: I840c30d22355d26816df718b49717407e2e4620f
> Reviewed-on: https://chromium-review.googlesource.com/996648
> Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
> Tested-by: Kristian H. Kristensen <hoegsberg@chromium.org>
> Reviewed-by: Kristian H. Kristensen <hoegsberg@chromium.org>
Bug: 822346
Change-Id: Icf0921dc91ac422da26371bffea34b26550b8234
Reviewed-on: https://chromium-review.googlesource.com/1073877
Commit-Ready: Kristian H. Kristensen <hoegsberg@chromium.org>
Tested-by: Kristian H. Kristensen <hoegsberg@chromium.org>
Reviewed-by: Kristian H. Kristensen <hoegsberg@chromium.org>
This reverts commit 1bd7b04a3a.
Reason for revert: Breaks video decoding on most intel platforms, e.g., caroline and samus
Original change's description:
> i915: Add GBM_BO_USE_HW_VIDEO_DECODER use flag
>
> This flag is used to indicate that the platform video decoder will be
> writing into this buffer and that it should be allocated
> accordingly. On Intel, this means that we have to allocate y-tiled
> NV12 for libva to be able to decode to the buffer.
>
> We force gralloc NV12 allocations to be linear for now, since ARC++
> doesn't properly pass modifiers to ChromeOS.
>
> BUG=822346
> TEST=test_that graphics_Gbm
>
> Change-Id: I840c30d22355d26816df718b49717407e2e4620f
> Reviewed-on: https://chromium-review.googlesource.com/996648
> Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
> Tested-by: Kristian H. Kristensen <hoegsberg@chromium.org>
> Reviewed-by: Kristian H. Kristensen <hoegsberg@chromium.org>
Bug: 822346, 845076
Change-Id: I7681ddb66e4789951e840821993fc5562a55d1af
Reviewed-on: https://chromium-review.googlesource.com/1066032
Tested-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Kuo Jen Wei <inker@chromium.org>
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
This flag is used to indicate that the platform video decoder will be
writing into this buffer and that it should be allocated
accordingly. On Intel, this means that we have to allocate y-tiled
NV12 for libva to be able to decode to the buffer.
We force gralloc NV12 allocations to be linear for now, since ARC++
doesn't properly pass modifiers to ChromeOS.
BUG=822346
TEST=test_that graphics_Gbm
Change-Id: I840c30d22355d26816df718b49717407e2e4620f
Reviewed-on: https://chromium-review.googlesource.com/996648
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Kristian H. Kristensen <hoegsberg@chromium.org>
Reviewed-by: Kristian H. Kristensen <hoegsberg@chromium.org>
Need for these flags has arisen because buffer's allocated
BO_USE_SCANOUT flag is not mmapable in amd, whereas going further
for ensuring atomictity related operations are functional, one
needs buffer to be mmap'd.
These flags shall be used to strike balance in enabling
AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED on amd and mmap X-tiled buffers
on Intel platforms.
BUG=b:65297611, chromium:777706
TEST=On Kahlee,
UI comes up.
GLMark2 & GLbench autotests show no performance regression
atomictest -t multiplanes passes
WebGL Aquarium
Change-Id: I582452d331f4a05106939447784a76eba06d13c2
Reviewed-on: https://chromium-review.googlesource.com/758618
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Allow allocations with BO_USE_PROTECTED.
Moreover, disallow mapping of such BOs, as for GBM/Gralloc API callers
it should not be mappable and considered as metadata alone, without
usable content.
BUG=b:64323695
TEST=emerge-eve arc-cros-gralloc
Change-Id: I1dd1846a2042f97eee2fcc7581a91a60854e62cc
Reviewed-on: https://chromium-review.googlesource.com/607808
Commit-Ready: Pawel Osciak <posciak@chromium.org>
Tested-by: Pawel Osciak <posciak@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
We use the terms "flags" and "usage" interchangeably in this repo,
since they essentally mean the same thing. However, let's be a
little more consistent since it's kind of confusing, especially
when buffer map flags come to play. Let's:
- refer to everything in the drv_* layer as use_flags
- refer to everything in the gbm/gralloc layers as
usages
BUG=chromium:764871
TEST=emerge-eve {arc-cros-gralloc, minigbm}
Change-Id: If987d72369b895f38cde87e50ce1080f78f2a084
Reviewed-on: https://chromium-review.googlesource.com/691423
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Add a new GBM usage flag for buffers used a output for camera subsystem.
It corresponds to Android GRALLOC_USAGE_HW_CAMERA_{READ,WRITE} flags and
translates to the same BO_USE_HW_CAMERA_{READ,WRITE} flags of drv.
BUG=b:62358788
TEST=compile
Change-Id: Ib7063437e39d1e08f643763c6ce383ce8657f5ce
Reviewed-on: https://chromium-review.googlesource.com/560935
Commit-Ready: Tomasz Figa <tfiga@chromium.org>
Tested-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-by: Ricky Liang <jcliang@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Chromium passes in no flags to gbm_bo_create() to indicate the buffer will be
used as a texture. This convention has caused confusion in the past.
CL:448251 introduced BO_USE_TEXTURE, so it makes sense to match the more
explicit internal semantics.
TEST=run mapped_texture_test -f NV12 of drm-tests package on amd64-generic
BUG=chromium:683347
Change-Id: I40782763d125e640b4bb6a157035b17ebc32cc8c
Reviewed-on: https://chromium-review.googlesource.com/546884
Commit-Ready: Dongseong Hwang <dongseong.hwang@intel.com>
Tested-by: Dongseong Hwang <dongseong.hwang@intel.com>
Reviewed-by: Dongseong Hwang <dongseong.hwang@intel.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
The pre-submit hook script checks that copyright messages don't
contain "(c)".
This CL removes "(c)" from all the copyrights header in minigbm
that still have it.
BUG=None
TEST=emerge-$BOARD minigbm.
Change-Id: I1922d9d29b78d124302d497310fe1c1cfd6fc695
Reviewed-on: https://chromium-review.googlesource.com/421588
Commit-Ready: David Reveman <reveman@chromium.org>
Commit-Ready: Daniele Castagna <dcastagna@chromium.org>
Tested-by: Daniele Castagna <dcastagna@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
We were duplicating formats. The original rationale behind this was
DRV_FORMAT_* would be a superset of Android and DRM formats. However,
there are only 2 HAL flexible formats not defined by DRM, and we can
deal with these easily. The DRM format namespace is large enough to
handle any additions we may need.
BUG=NONE
TEST=Ran graphics_Gbm,
arc-cros-gralloc still builds
Change-Id: Ie173eee6ac6926947a3b98c3ae809e38a0ea8014
Reviewed-on: https://chromium-review.googlesource.com/405790
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
We would like to reuse the same set of drivers for ChromeOS (with
a minigbm frontend) and Android (with a gralloc frontend). Since
we don't want to pollute the gbm API with gralloc formats and usages,
we can refactor minigbm on top a private API that will be a superset
of gbm and gralloc. This change redirects gbm calls to the
private API.
TEST=Ran graphics_Gbm on minnie and cyan, and checked if Chrome boots.
BUG=chromium:616275
CQ-DEPEND=CL:367791
Change-Id: I50d10f9d6c7ea936b0d76c5299a58d948939fdf9
Reviewed-on: https://chromium-review.googlesource.com/367780
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
