Along with the licensing files required by AOSP.
Bug: 77276633
Change-Id: I9b8d8d2f32658750696c453d439a168af2b7f7fb
Signed-off-by: Alistair Strachan <astrachan@google.com>
This patch does the below:
1. Adds DRM_FORMAT_NV12 & DRM_FORMAT_NV21
to the list of formats supported by amdgpu driver
2. bo_create() updates parameter's of video planes
appropriately.
3. add DRM_FORMAT_NV21 in drv.c & helpers.c
This patch is a step towards enabling overlay based video rendering
capability available in hardware.
BUG=b:37526302
TEST=emerge-kahlee media-libs/minigbm
TEST=Boots to UI on jadeite & kahlee
TEST=With all the changes in kernel(not upstreamed) execute below:
plane_test --format AR24 --size 500x50 -p --format NV12 --size 500x500
plane_test --format AR24 --size 500x50 -p --format NV12 --size 1280x720
plane_test --format AR24 --size 500x50 -p --format NV12 --size 1366x768
plane_test --format AR24 --size 500x50 -p --format NV21 --size 1366x768
TEST=displays same colored layers on video and RGB plane.
Change-Id: If75a4586b636b600a5b4b2d909f10bcf03613cc2
Signed-off-by: Shirish S <shirish.s@amd.com>
Reviewed-on: https://chromium-review.googlesource.com/479043
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
We were including native handle size in our numInts calculations.
Fix this.
BUG=b:62060380
TEST=gralloc related ASAN errors go away
Change-Id: I9ae66655f9e40d82a9cd3fe91ddca9f300fda911
Reviewed-on: https://chromium-review.googlesource.com/517279
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Dominik Behr <dbehr@chromium.org>
Reviewed-by: Luis Hector Chavez <lhchavez@chromium.org>
We can't use GR88, R8, YV12, NV12, UYVY, YUYV buffers as render
targets, so let's remove the BO_USE_RENDERING flag from these
formats. However, we can sample from these formats (though this
feature still needs to be enabled in our drivers), so the
BO_USE_TEXTURE flag remains set.
Also, change our interpretation of the GRALLOC_USAGE_HW_COMPOSER
flag such that it implies BO_USE_SCANOUT | BO_USE_TEXTURE. This
is because the OpenGL fallback textures from the buffer if
can't be scanned-out, not renders to it.
BUG=none
TEST=run Youtube app on Kevin
Change-Id: I9ea8452279e110bc1a9579f162abe1c72192eb40
Reviewed-on: https://chromium-review.googlesource.com/506812
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
cros_gralloc implements Gralloc Module API 0.2. Android framework's
libui uses a Gralloc1On0Adapter adapter on top of gralloc modules < 1.0.
The Gralloc1On0Adapter is a singleton object that calls gralloc_close in
its destructor. cros_gralloc implements gralloc_close() as
cros_gralloc_close().
In other words cros_gralloc_close() is called at process exit during
__cxa_finalize, which is not a safe place to do std::mutex operations.
In fact, the lock_guard() sometimes hangs while trying to aquire the
lock resulting in a non-responsive app.
Fix this by removing the lock_guard in cros_gralloc_close().
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=b/38016927
TEST=Use cherry to run 1 dEQP test.
=> No anr crash after 30 seconds in com.drawelements.deqp:testercore
Change-Id: I469516b8b3a7d8ac6b89e571f137935f097c9af9
Reviewed-on: https://chromium-review.googlesource.com/504429
Commit-Ready: Ilja H. Friedel <ihf@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Now clang-format will be run everytime a committer runs repo upload
with the --no-verify option. The committer will have to resolve
differences, i.e:
1) add clang-format off / clang-format on.
2) change files such that clang-format does not complain.
Since our version of clang-format was updated (in the LLVM ebuild), I had to
resolve a few conflicts in rockchip.c and tegra.c.
BUG=none
TEST=none
Change-Id: Ia32d3c47243957f2d674f142bda9daf7917aab0b
Reviewed-on: https://chromium-review.googlesource.com/506508
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
This changes the Makefile to use pkg-config to query for necessary
library paths and names instead of hardcoding -ldrm.
BUG=b:36540057
TEST=emerge-reef arc-cros-gralloc with multilib patches
CQ-DEPEND=CL:505794
Change-Id: Id223203506d71b3966e9730f92badb461eb6cb1b
Reviewed-on: https://chromium-review.googlesource.com/499971
Commit-Ready: Tomasz Figa <tfiga@chromium.org>
Tested-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-by: Luis Hector Chavez <lhchavez@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
This change uses pkg-config to find the libdrm headers instead of
relying on the arc-toolchain sysroot.
BUG=b:26864637
TEST=reef compiles, surfaceflinger is happy
CQ-DEPEND=CL:494886
Change-Id: Ic6142424ff5593ab5552dd61b8ae4b7dc38497fc
Reviewed-on: https://chromium-review.googlesource.com/495267
Commit-Ready: Luis Hector Chavez <lhchavez@chromium.org>
Tested-by: Luis Hector Chavez <lhchavez@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
We convert HAL_PIXEL_FORMAT_BLOB to DRM_FORMAT_R8 for camera picture
taking. Choose DRM_FORMAT_R8 because <system/graphics.h> requires the
buffers with a format HAL_PIXEL_FORMAT_BLOB have a height of 1, and
width equal to their size in bytes.
BUG=b:37692495
TEST=open camera app and take a picture.
Change-Id: I11a82b057b7c1174dd946e0b7d3cbde9c1d630d9
Reviewed-on: https://chromium-review.googlesource.com/487552
Commit-Ready: Heng-ruey Hsu <henryhsu@google.com>
Tested-by: Heng-ruey Hsu <henryhsu@google.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
The Intel last level cache (LLC) acts a coherency controller on
hardware that has it. Use I915_PARAM_HAS_LLC to determine if the
hardware has LLC.
We can maintain coherency by doing a clflush on non-LLC platforms, like the
Vulkan driver in Mesa does.
BUG=none
TEST=gbmtest on Cyan, Chrome boots, Android boots, mmap_test -g, 5-10 CTS
tests. No regressions.
CQ-DEPEND=CL:425716
Change-Id: I054e69c23016cd3336c2de1d07b49bb2c3709389
Reviewed-on: https://chromium-review.googlesource.com/454105
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
The following three CTS tests fail with an i915 backend:
EncodeVirtualDisplayWithCompositionTest#testRendering800x480Locally
EncodeVirtualDisplayWithCompositionTest#testRenderingMaxResolutionRemotely
EncodeVirtualDisplayWithCompositionTest#testVirtualDisplayRecycles
The reason for the failures is the bo_map() function calls
DRM_IOCTL_I915_GEM_MMAP_GTT with untiled buffers, leading to
Surface::dequeueBuffer not completing in time.
Note the final form of unmap will be a clfush.
BUG=none
TEST=The 3 CTS tests pass.
CQ-DEPEND=CL:454104
Change-Id: I60826d0006da345eceb89f26543e1cc436bbf312
Reviewed-on: https://chromium-review.googlesource.com/425716
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
As per offline discussion, libdrm_intel doesn't maintain cache coherency
correctly for a number of edge cases.
The plan is to:
1) Revert the libdrm CL.
2) Use simpler mmap/unmap logic to deal CTS failures.
3) Use explicit flush to deal with coherency.
CQ-DEPEND=CL:454105
This reverts commit 82a8eedaa5.
Conflicts: i915.c
Change-Id: I6c0bf746b71ea08f5cf4f1aa80d17d28b26ec4c6
Reviewed-on: https://chromium-review.googlesource.com/454104
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Dominik Behr <dbehr@chromium.org>
For some reason GCC does not like using %llu print format for uint64_t, which
maps to unsigned long on Linux x86_64. However on Linux i386 unsigned
long is a 32-bit type and uint64_t maps effectively to unsigned long
long and we need to use %llu. To work this around, simply cast the value
to unsigned long long.
BUG=b:36540057
TEST=emerge-reef arc-cros-gralloc with multilib patches applied
Change-Id: Ic585d40d690346babc280a04111fc8aedf8a30cd
Reviewed-on: https://chromium-review.googlesource.com/487766
Commit-Ready: Tomasz Figa <tfiga@chromium.org>
Tested-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
There is a desire to use virtio-gpu + Android with kernel v4.4. Let's
make it like the vgem backend, which aligns widths and heights to
64-pixel boundaries to support LLVM requirements.
BUG=chromium:616275
TEST=no crashes when running Android with amd64-generic-cheets
Change-Id: I5640a0f9cc84260d30eecddd84307170fa41d2ce
Reviewed-on: https://chromium-review.googlesource.com/471879
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Adding these hook overrides disables all of the default ChromiumOS
source style checks. This way repo upload . should just run
our presubmit script.
BUG=none
TEST=none
Change-Id: I18803f5a94ef4c17043dcb12c817e8cf78b64d66
Reviewed-on: https://chromium-review.googlesource.com/467646
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
The VM-tests in the Android PFQ require this now.
BUG=chromium:616275
TEST=-cheets_CTSHelper.smoke doesn't crash in a VM
Change-Id: Icd062210852810036ab349af10b350507e1b560b
Reviewed-on: https://chromium-review.googlesource.com/467626
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
We were only filling up the first five entries of the modifier array
in the handle, and we were doing it incorrectly. Fix this.
BUG=chromium:616275
TEST=compiles
Change-Id: I435f88db1b16af919081122a502cbe7d7fc9e3d9
Reviewed-on: https://chromium-review.googlesource.com/457289
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Haixia Shi <hshi@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
There's no reason to have these as functions. Also eliminate
sw_write() and sw_read(), the only reason I added them because
I was hitting the 80 column limit (we're 100 columns wide now).
BUG=chromium:616275
TEST=compiles
Change-Id: If0d406df64dc760f2c007eeecf79874c1deb3ec7
Reviewed-on: https://chromium-review.googlesource.com/457288
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
The C++ standard says value initialization results in
zero initialization for structs, so our memsets are
unecessary.
BUG=chromium:616275
TEST=compiles
Change-Id: I1744b237790cb79d2a8be92beffdb2ee9829f4e2
Reviewed-on: https://chromium-review.googlesource.com/457287
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
We have 100-lines to work with now.
BUG=none
TEST=compiles
Change-Id: I08f41a42d8841ac82c5a6defbcbc712722179fce
Reviewed-on: https://chromium-review.googlesource.com/457286
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Running the presubmit.sh script will apply our rules to every file in
the repo. Exclude gbm.h from the formatting requirements since this file
was taken from other open-source projects, and diffing will be easier
without our formatting rules.
In addition, special case drivers where the order of includes matters.
BUG=none
TEST=Verified the following commands succeed:
emerge-cyan minigbm/arc-cros-gralloc
emerge-oak minigbm/arc-cros-gralloc
emerge-veyron_minnie-cheets minigbm/arc-cros-gralloc
emerge-peach_pi minigbm
emerge-nyan_big minigbm
emerge-jadeite minigbm
Change-Id: I6ce93fb1930da254d13d5017766c17341870ccc9
Reviewed-on: https://chromium-review.googlesource.com/447319
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
cmemp_heap_partition in the mali driver checks if every plane is
64-byte aligned. Since we expose a fd for every plane in the
cros gralloc handle, we hit this case. We need to enforce this
alignment on our YV12 allocations.
BUG=chromium:616275
TEST=
android.media.cts.VideoEncoderTest#testGoogH264FlexArbitraryH
passes on veyron_minnie-cheets.
Change-Id: If6375eddd18fd216e7f07eb2cc47090d838f82ab
Reviewed-on: https://chromium-review.googlesource.com/459104
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
When doing alignment, many times we get the bytes per pixel, try
to align to a certain boundary, and then pass in the "aligned width"
to drv_bo_from_format. This back and forth is confusing and error
prone. Let's change our drivers and helpers to eliminate this, and
try to work in strides as soon as possible.
Additionally, let's make drv_bpp_from_format a static function. This
is because bits per pixel is ill-defined for YUV formats, and we should
work in strides whenever possible.
BUG=none
TEST=graphics_Gbm runs successfully on Cyan, ui boots
Change-Id: I207ce6fd5eaac472b7b82f0d952b46697e325498
Reviewed-on: https://chromium-review.googlesource.com/462479
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
We were using the drv_stride_from_format as a shorthand to calculate
bytes per pixel. This is incorrect with the addition of
DRM_FORMAT_YVU420_ANDROID, which always aligns to 16 bytes.
Let's have a separate bytes_per_pixel function to better express what
we want.
BUG=chromium:616275
TEST=android.media.cts.DecodeAccuracyTest
#testVP9GLViewLargerHeightVideoDecode
passes on veyron_minnie-cheets.
Change-Id: I2d740828d66031c3a032932c09d79dbce21b8986
Reviewed-on: https://chromium-review.googlesource.com/458978
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
We shouldn't round up to the nearest byte. This way we can represent
formats like Y41P. Makes no difference currently since
drv_bpp_from_format only returns numbers divisible by eight.
Change-Id: I57bcab383f1661ea11e9aa1d30e18750574143e2
Reviewed-on: https://chromium-review.googlesource.com/462478
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
drv_dumb_bo_create function only allocates single-plane formats at the
moment, even though the vgem driver has a resolve format hook that
leads to DRM_FORMAT_YVU420_ANDROID. Let's allocate a single buffer
that's big enough to support DRM_FORMAT_YVU420_ANDROID, as drm_gralloc
does. Note videos don't work with Android emulation, but they never
did with drm_gralloc and that's a separate problem.
BUG=chromium:616275
TEST=no regressions with gbmtest when running qemu + trybots
Change-Id: I9b081dbe553fe1159feaa7eed104ac340c59e41b
Reviewed-on: https://chromium-review.googlesource.com/456404
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
As per drm_gralloc we need to:
(1) align the Y plane to 128 bytes so the chroma planes would be
aligned to 64 bytes boundaries.
(2) Have no tiling with YV12.
BUG=chromium:616275
TEST=DecodeEditEncodeTest#testVideoEdit720p
passes on cyan. Run YT app.
Change-Id: I339163c94d4481991702b8bfd232a70f3a275506
Reviewed-on: https://chromium-review.googlesource.com/456403
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
YV12 in <system/graphics.h> in the Android tree defines the
HAL_PIXEL_FORMAT_YV12 as:
* y_size = stride * height
* c_stride = ALIGN(stride/2, 16)
* c_size = c_stride * height/2
* size = y_size + c_size * 2
* cr_offset = y_size
* cb_offset = y_size + c_size
Let's add a special format DRM_FORMAT_YVU420_ANDROID that adheres to these
requirements.
Previously, our y_size on Intel not adhere to the spec. We should
change drv_bo_from_format to calculate the size of plane not based on the
aligned height, but the height that outside world sees.
BUG=chromium:616275
TEST=
ImageReaderDecoderTest#testGoogH264ImageReader
passes on cyan. Run YT app.
Change-Id: I4906300a0775cf561c4b05bf6d973cf4e82470bc
Reviewed-on: https://chromium-review.googlesource.com/441913
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Let's keep a count of how many times a buffer has been locked, since
we have special lock_ycbcr() behavior that returns the offsets and
strides of a YUV buffer when an usage of zero is passed in. This behavior
is used by the ArcCodec. We have to take care not to call drv_bo_unmap
if we didn't map anything.
We also have to expose struct map_info so we can return the address if
we have mapped data, rather than incrementing the drv map count.
Additionally, the gralloc.h says:
"THREADING CONSIDERATIONS
It is legal for several different threads to lock a buffer from
read access, none of the threads are blocked."
This implies recursive locking, which this commit implements.
BUG=b:34419220
TEST=
android.video.cts.VideoEncoderDecoderTest#testAvcGoog0Qual0320x0240
Change-Id: Ibbe7dd5349594117aaaecca9647ad45264448575
Reviewed-on: https://chromium-review.googlesource.com/442835
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
A few CTS tests are failing due to incompatible usage flags.
Specifically, these combinations are passed in:
{ format: HAL_PIXEL_FORMAT_YCbCr_420_888,
HAL flags: GRALLOC_USAGE_RENDERSCRIPT |
GRALLOC_USAGE_SW_READ_OFTEN |
GRALLOC_USAGE_SW_WRITE_OFTEN }
Let's set the renderscript flag to BO_USE_LINEAR since in our
case renderscript code is executed on the CPU.
Change drivers to make sure linear flags are available.
BUG=b:34422476
TEST=
run cts --package android.security
run cts -m CtsRenderscriptTestCases --skip-device-info
run cts --package android.widget
don't crash due to createGraphicBuffer failures.
Change-Id: I47a97118ae5b6a732e6d5c1f090aa7c3a7cc95a5
Reviewed-on: https://chromium-review.googlesource.com/441915
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
GRALLOC_USAGE_HW_FB is a legacy flag, and doesn't make
sense in our setup.
BUG=chromium:616275
TEST=compiles
Change-Id: If39634a12ad325b4d28afbd3db335e6ee9e287f6
Reviewed-on: https://chromium-review.googlesource.com/455282
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
We've been back and forth on the semantics of the flag API many
times, and the current situation is confusing.
Change the drivers so every combination defines a distinct type of
buffer. That means if the same format is in the combination list three
times, the tiling or format modifiers of one of those combinations must
be different from the other two.
Let's add a priority variable in struct supported_combination that
breaks ties. For example, if a consumer specifies BO_USE_TEXTURE,
we of course can texture from both linear and tiled buffers, but
because a tiled buffer's priority is greater, it will be chosen.
If a consumer specifies BO_USE_TEXTURE | BO_USE_SW_WRITE_OFTEN, the
tiled combination won't have the BO_USE_SW_WRITE_OFTEN flag and the
linear combination will be chosen.
We expect drivers to modify the combinations after querying KMS.
This is clunky using linked lists, so get rid of list.h and use arrays.
BUG=chromium:616275
TEST=all the following compiles:
emerge-cyan minigbm/arc-cros-gralloc
emerge-oak minigbm/arc-cros-gralloc
emerge-veyron_minnie-cheets minigbm/arc-cros-gralloc
emerge-peach_pi minigbm
emerge-nyan_big minigbm
emerge-jadeite minigbm
Tested with gbmtest on cyan, checked if Chrome boots
Change-Id: Ib3fccf6f0cb86c8ded45924297df3c06f8e49271
Reviewed-on: https://chromium-review.googlesource.com/448252
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
We interpret the following flags as GRALLOC_USAGE_HW_COMPOSER
as BO_USE_SCANOUT | BO_USE_RENDERING:
If the combination is not supported by the driver, let's check if
the gralloc flag is present before we back out for clarity.
BUG=chromium:616275
TEST=compiles
Change-Id: If546ce653f1088cbb1d31cf2f90aba0621ed8b4a
Reviewed-on: https://chromium-review.googlesource.com/451978
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Many people have requested re-adding BO_USE_TEXTURE as a flag
since:
BO_USE_RENDERING means the buffer will be used as a render target.
BO_USE_TEXTURE means the buffer will be textured from.
BUG=chromium:616275
TEST=minigbm/arc-cros-gralloc compiles
Change-Id: I63be6682cf4e2415dc42c78b2cab3ad694bcd818
Reviewed-on: https://chromium-review.googlesource.com/448251
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
BUG=None
TEST=Able to build Minigbm in a pure Android environment
i.e. Android IA.
Change-Id: Ib12e8411b4ba42b8dd83974fc372bf4884ed6e41
Signed-off-by: Kalyan Kondapally <kalyan.kondapally@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/448841
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
The chroma stride of Android YV12 buffers is required to be
aligned to 16 bytes (see <system/graphics.h>).
Additionally, the size of the ARM L1 cache line is 64-bytes
(see chrome-os-partner:45777).
Let's always align the first plane to 64 bytes. The chroma strides
will be aligned to 32 bytes in that case.
BUG=chromium:616275
TEST=
ImageReaderDecoderTest#testGoogH264ImageReader
passes on veyron_minnie-cheets.
Change-Id: I87a309ce0612bf8c5be8f8e47dad3da10d61a081
Reviewed-on: https://chromium-review.googlesource.com/441912
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
The map_info data allocated drv_bo_map() should be added to the
map_table, not the buffer_table.
BUG=b:34580741, b:34528332
TEST=
android.uirendering.cts.testclasses.InfrastructureTests#testScreenshot
passes on Cyan.
Change-Id: I14a70df8fb174bc572ef3488f14c494808bab0e0
Reviewed-on: https://chromium-review.googlesource.com/441911
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
The block height should be calculated from the height,
not the width.
BUG=none
TEST=none
Change-Id: Ica4bca0831c12a2594e16c06c42074592a8fd560
Reviewed-on: https://chromium-review.googlesource.com/441910
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
BUG=chrome-os-partner:62585
TEST=Plug in monitor with native resolution over 2560 (eg 4k monitor)
and verify the output looks correct.
Change-Id: Iec925f54d74be19342d710313e5ac4ddca529e62
Signed-off-by: Kristian H. Kristensen <hoegsberg@google.com>
Reviewed-on: https://chromium-review.googlesource.com/438831
Commit-Ready: Douglas Anderson <dianders@chromium.org>
Tested-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Daniele Castagna <dcastagna@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
With cros_gralloc enabled, the following three CTS tests fail with an i915
backend:
EncodeVirtualDisplayWithCompositionTest#testRendering800x480Locally
EncodeVirtualDisplayWithCompositionTest#testRenderingMaxResolutionRemotely
EncodeVirtualDisplayWithCompositionTest#testVirtualDisplayRecycles
The reason for the failures is the bo_map() function calls
DRM_IOCTL_I915_GEM_MMAP_GTT with untiled buffers, leading to
Surface::dequeueBuffer not completing in time.
In addition, we never set the domain when we map, which can lead to
cache coherency issues.
libdrm already has functions for regular and GTT mapppings, so let's just
add it here rather than duplicating the logic.
TEST=Chrome boots and container boots
gbmtest, tiled_bo_test, all CTS tests specified in go/arc++gfx pass
BUG=chromium:616275
CQ-DEPEND=CL:424674
Change-Id: I68943367205abd3b470adb0597109fe30aa3e381
Reviewed-on: https://chromium-review.googlesource.com/424832
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
