Add R8 and GR88 format for dma_bufs in amdgpu.
Required to support native GMB video playback.
If native GMB is enbaled,chrome transcodes NV12 to
RGB by importing Y plane as R8 EGLImage and the UV plane as GR88 EGLImage.
BUG=b:65302612
TEST=Boot Kahlee with --enable-native-gpu-memory-buffers and play youtube.
Change-Id: Ifa7e50959bb5417088357a0c0aa3ac874ecf6fc9
Signed-off-by: Deepak Sharma <deepak.sharma@amd.com>
Reviewed-on: https://chromium-review.googlesource.com/695850
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>
The Zero Latency Ink app is scanned out while the buffer is being
updated (by design). The buffer update is racy with the display,
leading to artifacts. Calling clflush on the buffer, even only on
the rectangle specified by gralloc (*lock), makes no difference. As
a result, let's map the buffer as uncached when it's being scanned
out (we do the same thing on ARM). Let's make sure not affect
renderscript buffers, since certain renderscript CTS tests require
caching.
BUG=chromium:762324
TEST=no overlay artifacts while using Zero Latency Ink app
on Eve.
Change-Id: I6f79dc8e48deee441790f737aba79c7f79ca4cb9
Reviewed-on: https://chromium-review.googlesource.com/665390
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: David Reveman <reveman@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>
Let's take the flush and writeback steps in the driver unmap
functions and move them to the (*bo_flush) callback.
BUG=chromium:764871
TEST=gbmtest, mmap_test -g on eve
Change-Id: Iecccafc25642b120bc84f2d1b8538303c8ce36eb
Reviewed-on: https://chromium-review.googlesource.com/668219
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, we would like to separate buffer flush/writeback
and unmap. This patch adds the appropriate entry point in our
internal driver API. Overall, the proposed flow is:
- drv_bo_map(..) creates a mapping and associated metadata
- drv_bo_flush(..) writes memory from any cache or temporary
buffer back to memory
- drv_bo_unmap(..) flushes, and frees the mapping and
associated metadata.
The drv_bo_flush function just does some sanity checks on
the map data at this point, but otherwise is a no-op.
BUG=chromium:764871
TEST=gbmtest, mmap_test -g on eve
Change-Id: If306f066a76bc5e0943c1170e2d6933fa5630eff
Reviewed-on: https://chromium-review.googlesource.com/668218
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Regardless of the allocator, we want to make sure any mappings
we create are eventually freed. This patch adds logic to
drv_bo_destroy to free any mappings before the GEM close
ioctl is called.
BUG=chromium:764871
TEST=gbmtest, mmap_test -g on eve
Change-Id: I8f4edb4bc01ff6e1d71a60e0309e77e9fc3840f4
Reviewed-on: https://chromium-review.googlesource.com/441916
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>
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
The (*bo_unmap) function is responsible for unmapping the buffer
and cleaning up any data allocated during (*bo_map). Previously,
we called munmap in drv_bo_unmap(), which caused some confusion.
This method is cleaner.
BUG=chromium:764871
TEST=emerge-betty minigbm
Change-Id: I4dc20cd6b15e79bce21d33f03ebc84480c582981
Reviewed-on: https://chromium-review.googlesource.com/671693
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Joe Kniss <djmk@google.com>
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
It's much the same as what we did for i915 in:
d30c0a5 (minigbm: i915: Add support for buffers required by new camera subsystem)
https://chromium-review.googlesource.com/559315
BUG=b:65390035
TEST=test arc_camera3_test on scarlet, no more this error:
[0905/104926:ERROR:camera3_test_gralloc.cc (76)] Can't detect flexible YUV 420 format
Change-Id: Ib99687ff2aaaca0233fa950abbe8581bc3572b74
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/670888
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
Due to USB flakiness issues, sometimes udl devices suddenly disconnect
then reconnect. In such cases, we see that drv_create runs before drv_destroy
can destroy the driver belonging to the disconnected udl device. Once
drv_destroy runs, it frees structs frequently used by the newly created
driver, most importantly drv->backend->combos->data which stores
format and usage combinations for creating BOs.
By nature, drv_destroy should not destroy data belonging to backend. Further,
BO format and usage combinations are hardcoded in driver _init, so there is
no point in it being freed in drv_destroy.
This fix moves the combos array to struct drv so a new combos array can be
created and destroyed in drv_create and drv_destroy. This eliminates the
race condition by avoiding using the shared resource.
BUG=crbug.com/766831
TEST=Boot up CfM, make sure ui and chrome logs are not complaining
about scanout and framebuffer failures. Play around with Mimo touchscreen
to make sure the display is not flickering.
Change-Id: I53d57693574daeb5486cd5daca71f660ada635ef
Reviewed-on: https://chromium-review.googlesource.com/674528
Commit-Ready: Ege Mihmanli <egemih@google.com>
Tested-by: Ege Mihmanli <egemih@google.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
While importing a foreign object, calculate each plane size according
to the offset of next plane or lseek result. Otherwise, an object that
has been created with aligned height will be mapped to a smaller
region and accessing the last bytes of last plane causes segmentation
faults.
BUG=b:65566935
TEST=checked that b:65566935 was not reproducible with this patch and
the size of mapped region is the same as allocated size
CQ-DEPEND=CL:669752
Change-Id: I294f6a816a3172df630c223fe8f338a9036e71bd
Reviewed-on: https://chromium-review.googlesource.com/662919
Commit-Ready: Hung-yu Wu <hywu@chromium.org>
Tested-by: Hung-yu Wu <hywu@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
libva 1.8.3 makes it a hard requirement that multi-planar surfaces are
vertically aligned to 16. Enforce this rule at allocation time.
BUG=b:65084476
TEST=checked that b:65084476 was not reproducible with this patch and
that all multi-planar surfaces are aligned to 16.
Change-Id: Id31055df81ba43130f3f45282db104753fb6e700
Reviewed-on: https://chromium-review.googlesource.com/642429
Commit-Ready: Alexandre Courbot <acourbot@chromium.org>
Tested-by: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
If we release the last reference and close the GEM handle, but we still
have an entry in the mapping map with such handle as the key, we can
experience a case when a new GEM is obtains the handle we just released
and next map attempt for the new GEM leads to the map entry for the old
buffer being used and wrong mappings being returned.
We ignore the nonsense gralloc API requirement to avoid crashing the
process in such case and simply assert() no mappings remaining when
last reference to the GEM is being dropped.
BUG=b:38250067
TEST=run cts -m CtsMediaTestCases on veyron_minnie without CL:*426529
Change-Id: Id36f55292bbded626af8cba56f4d8bf0603742fb
Reviewed-on: https://chromium-review.googlesource.com/605339
Commit-Ready: Tomasz Figa <tfiga@chromium.org>
Tested-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
There is a missing whitespace error in gralloc0.cc, which is
automatically corrected by some git hook, so let's fix it finally. Since
the original style issue seems to be caused by a bug in clang-format
used in ChromeOS chroot (and corrected by any other, not broken,
clang-format), just annotate the line to have clang-format bypassed.
BUG=none
TEST=compile
Change-Id: I6df1963eedc3b908d4a0abaffb2db9081eaba043
Reviewed-on: https://chromium-review.googlesource.com/597330
Commit-Ready: Tomasz Figa <tfiga@chromium.org>
Tested-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
All GEM mappings are write-combined by default. This leads to
performance issues with renderscript CTS tests on ARM boards.
Let's keep a local copy of the buffer in the hopes of improving
the test's performance.
BUG=b:38097499
TEST=run cts -m CtsViewTestCases -t android.view.cts.SurfaceViewSyncTests
passes on 9776.0.0 veyron_minnie
Change-Id: I74da770f42524e66ca643adfbe9475362ee397cc
Reviewed-on: https://chromium-review.googlesource.com/602736
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Previously, we mapped BO_USE_RENDERSCRIPT to BO_USE_LINEAR,
which made sense at the moment. However, we know have a case
where we need to special things with renderscript buffers on
ARM boards. Let's add back in the flag so we can differentiate
between normal linear buffers and renderscript buffers at map
and unmap time.
BUG=b:38097499
TEST=run cts -m CtsViewTestCases -t android.view.cts.SurfaceViewSyncTests
passes on 9776.0.0 veyron_minnie
Change-Id: I7f1ee76735280ab6495a2d4af332cce5bc1c1727
Reviewed-on: https://chromium-review.googlesource.com/602735
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Currently, minigbm only cares about the buffer use flags during buffer
creation. We would like to use cached renderscript buffers, so we need
knowledge about how the buffer was created at map time. Let's add this
to the buffer object struct.
BUG=b:38097499
TEST=run cts -m CtsViewTestCases -t android.view.cts.SurfaceViewSyncTests
passes on 9776.0.0 veyron_minnie
Change-Id: I73943dae309e60038affb78385aef4b6d3b678ed
Reviewed-on: https://chromium-review.googlesource.com/602734
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
On Android M, since we don't hold a lock during cros_gralloc_driver::init(),
another thread would sometimes access data before the driver was initialized.
This would lead to dEQP crashes. We don't experience this issue on Android
N since the framework has it's own layer of locks in the Gralloc1On0Adapter.
This patch makes the module initialization during (*registerBuffer) and
gralloc_open re-entrant.
BUG=b:63511976
TEST=run cts --package com.drawelements.deqp.gles2 on veyron_tiger has no
crashes
Change-Id: I2b72f2f8ed5e4a5afbacb291ed8cd928beb2a3b3
Reviewed-on: https://chromium-review.googlesource.com/597015
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>
All the regular formats are already aligned by current code, except
Android YV12, which requires height of planes to be unchanged. However
Mesa requires each plane to have at least certain required padding
between planes. Work around this by calculating total BO size with
aligned height to allow padding space to overlap with further planes
and making sure that padding of last plane fits in the buffer. This is
okay, since Mesa requirement seems to indicate that data of the padding
area should not be affected and padding is only needed to satisfy GPU
cache requests.
Fixes following CTS tests on Intel platforms:
android.media.cts.VideoEncoderTest#testGoogH264FlexArbitraryH
android.media.cts.VideoEncoderTest#testGoogH264FlexNearMaxMin
android.media.cts.VideoEncoderTest#testGoogH264SurfArbitraryH
android.media.cts.VideoEncoderTest#testGoogH264SurfNearMaxMin
BUG=b:63957026
TEST=./cts-tradefed run cts -m CtsMediaTestCases -t
android.media.cts.VideoEncoderTest
Change-Id: I46d44178ba983c0038b630b13b9b281251393f8f
Reviewed-on: https://chromium-review.googlesource.com/592990
Commit-Ready: Tomasz Figa <tfiga@chromium.org>
Tested-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Mesa handles planar formats with separate surface for each plane. Each
linear surface has certain width and height alignment restrictions.
However minigbm's i915 backend currently does not account for chroma plane
subsampling when calculating the alignments, so that only the luma plane
gets enough alignment. Fix this by multiplying luma plane alignment by
chroma subsampling factor, both horizonal and vertical for 3-plane
formats and only the latter for 2-plane formats.
Fixes following CTS tests on Intel platforms:
android.media.cts.VideoEncoderTest#testGoogVP8FlexArbitraryH
android.media.cts.VideoEncoderTest#testGoogVP8FlexArbitraryW
android.media.cts.VideoEncoderTest#testGoogVP8FlexNearMaxMin
android.media.cts.VideoEncoderTest#testGoogVP8SurfArbitraryH
android.media.cts.VideoEncoderTest#testGoogVP8SurfArbitraryW
android.media.cts.VideoEncoderTest#testGoogVP8SurfNearMaxMin
BUG=b:63957026
TEST=./cts-tradefed run cts -m CtsMediaTestCases
-t android.media.cts.VideoEncoderTest
Change-Id: I8459b0f5f22ba9f9936fa987a13dd99d6b245560
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/592989
Reviewed-by: Gurchetan Singh <gurchetansingh@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>
Let's support GRALLOC_MODULE_API_VERSION_0_3. This will more closely
mirror what gralloc1 and HIDL gralloc does.
We have the option to asychronously unlock with this version of the API,
but decided the added complexity wouldn't lead to any performance benefits.
We'll just set the release fence pointer to be -1, indicating the
the buffer is ready to use after the (*unlock_Async) call.
BUG=b:62069164
TEST=Android boots, play Youtube app, ./gralloctest all passes
Change-Id: Ia21a11b541796c4b36003c50cd8627d189b4bc56
Reviewed-on: https://chromium-review.googlesource.com/422661
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Tomasz Figa <tfiga@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>
This reverts commit 33cca93af6.
Reason for revert:
Many CTS tests are failed by the change, and video playback is corrupted on Youtube/Netflix app.
Original change's description:
> minigbm: rockchip: align NV12 planes to 64 bytes
>
> When running the mapped_texture_test with the Mali EGL implementation
> compiled with debug symbols, Mali complains that the NV12 planes are
> not sufficiently aligned (specifically, mali_cobj_surface.c line 1806).
> Fix this.
>
> BUG=b:63910596
> TEST=run Youtube App video on Kevin, at fullscreen and at normal size
>
> Change-Id: Ia204360c3aebe2bbd545ac7be0f6d095b0412f9d
> Reviewed-on: https://chromium-review.googlesource.com/556540
> Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
> Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
> Reviewed-by: Stphane Marchesin <marcheu@chromium.org>
Bug: b:63999659
Test: 1) run CTS on minnie: CtsVideoTestCases android.video.cts.VideoEncoderDecoderTest#testAvcGoog0Qual0720x0480, which fails on ToT and passes with the revert.
2) Play a video (size:426x240) on Youtube app. Video is corrupted on ToT and good with the revert.
Change-Id: I3418d0065733b4e0f99d1ab8c3cd416f7f454bc0
Reviewed-on: https://chromium-review.googlesource.com/583696
Commit-Ready: Pin-chih Lin <johnylin@chromium.org>
Tested-by: Pin-chih Lin <johnylin@chromium.org>
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
According to the ISL library used now by Mesa i965 driver to manage
surfaces, linear surfaces must have 64-byte padding added at the end,
due to the way how the GPU issues cache requests.
BUG=b:63957026
TEST=./cts-tradefed run cts --skip-preconditions --skip-device-info -m
CtsCameraTestCases -t
android.hardware.camera2.cts.MultiViewTest#testDualTextureViewAndImageReaderPreview
on Eve
Change-Id: I4887449a8e6e090b5ab7925b6f5c764cedd7589f
Reviewed-on: https://chromium-review.googlesource.com/582253
Commit-Ready: Tomasz Figa <tfiga@chromium.org>
Tested-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
When running the mapped_texture_test with the Mali EGL implementation
compiled with debug symbols, Mali complains that the NV12 planes are
not sufficiently aligned (specifically, mali_cobj_surface.c line 1806).
Fix this.
BUG=b:63910596
TEST=run Youtube App video on Kevin, at fullscreen and at normal size
Change-Id: Ia204360c3aebe2bbd545ac7be0f6d095b0412f9d
Reviewed-on: https://chromium-review.googlesource.com/556540
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>
Camera is supposed to mean camera hardware and the superfluous _HW_ does
not give us anything other than making the names longer.
BUG=b:62358788
TEST=compile
Change-Id: I3608470f17efe700fa43901167fa614ff9eac09c
Reviewed-on: https://chromium-review.googlesource.com/566774
Commit-Ready: Tomasz Figa <tfiga@chromium.org>
Tested-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
We should be casting a pointer to the fourcc to a char * pointer,
instead of casting the fourcc value itself (which unluckily happens to
be of the same size as pointer, so compilator fails to detect it).
BUG=b:62358788
TEST=Try to allocate with invalid usage
Change-Id: I2bb94d145dc3765d5193712aad7682c0fb383dd8
Reviewed-on: https://chromium-review.googlesource.com/566791
Commit-Ready: Tomasz Figa <tfiga@chromium.org>
Tested-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
In gralloc0, the flag GRALLOC_USAGE_HW_CAMERA_ZSL is defined to be a
bitwise OR of GRALLOC_USAGE_HW_CAMERA_WRITE and
GRALLOC_USAGE_HW_CAMERA_READ. So it is incorrect to treat it as a
separate usage flag, not even thinking about using it with the bitwise
AND operator for conditional tests.
Fix the current broken state by removing BO_USE_HW_CAMERA_ZSL, which
does not have any reason to exist.
BUG=b:62358788
TEST=Camera preview renders correctly on Poppy.
Change-Id: I883713f7e1c82c7747b20ac2000fb2edd5207616
Reviewed-on: https://chromium-review.googlesource.com/561034
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>
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 can use lock_ycbcr as a way to partially work around the format resolve
problem - with the assumption that if lock_ycbcr succeeds, the
android_ycbcr struct returned describes a YCbCr 4:2:0 image, we can
query gralloc for the format instead of hardcoding one statically.
BUG=b:32077885
TEST=Camera preview renders correctly on Poppy.
Change-Id: Ic20f5aa89809bf89941f3b4851c0d28965da54ac
Reviewed-on: https://chromium-review.googlesource.com/544487
Commit-Ready: Tomasz Figa <tfiga@chromium.org>
Tested-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
cros_gralloc_lock_ycbcr() obtains the mapping first and then fills in
the android_ycbcr struct. However the last step can fail if the backing
format is not included in the switch statement. In this case the function
returns without releasing the mapping.
Fix it by calling mod->drv->unlock() before returning, when the format
is unsupported. Also do not attempt to fill in the struct if the earlier
mod->drv->lock(() fails.
BUG=b:32077885
TEST=lock_ycbcr() fails properly for HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED
when it is backed by a RGBX_8888 buffer on Poppy.
Change-Id: I0b8cf91c578595a1b6ddc6e21009a8a84b8ac4de
Reviewed-on: https://chromium-review.googlesource.com/544486
Commit-Ready: Tomasz Figa <tfiga@chromium.org>
Tested-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
The new camera subsystem on ChromeOS (introduced with selected KBL
boards) requires following Android pixel formats to be supported:
- HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED,
- HAL_PIXEL_FORMAT_YCbCr_420_888,
- HAL_PIXEL_FORMAT_BLOB (JPEG binary data).
The first two need to map to DRM_FORMAT_NV12, if used with camera, so
adjust .resolve_format() callback to choose this format when camera
usage bits are specified. Also add respective combinations.
The last one is used specifically for JPEG binary data and the
cros_gralloc layer maps it into DRM_FORMAT_R8, so we need to add it to
the list of combinations for camera usage.
Note that the new usage flags are used only be the new camera subsystem
and do not affect existing boards. They will be migrated later, with the
initial objective to support NV12, so the combinations should remain
valid.
BUG=b:37615277
TEST=Camera preview renders correctly on Poppy.
Change-Id: Ib1081374ed82df9ae1cf543d85a2f5c50ff23371
Reviewed-on: https://chromium-review.googlesource.com/559315
Commit-Ready: Tomasz Figa <tfiga@chromium.org>
Tested-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
We already have the combinations infrastructure, which contains all the
information about supported tiling modes for given usage. Instead of
hardcoding this in i915_bo_create() one more time, let's just query for
the best available combination.
BUG=b:37615277
TEST=test_that reef graphics_Drm.bvt
Change-Id: I320da6419d001a41e965df00595de2fe17bd60f8
Reviewed-on: https://chromium-review.googlesource.com/544488
Commit-Ready: Tomasz Figa <tfiga@chromium.org>
Tested-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
As of today, drv_query_kms() does not report available format modifiers
and all returned items have DRM_FORMAT_MOD_NONE. The i915 backend has
a hack that adds KMS usage flags to X-tiled combinations even for items
without a modifier. However it is incorrect, as it adds cursor usage
flag, even though it isn't supported. On top of that, it is written in
a very convoluted way that hides the original problem.
Make i915_add_combinations() always set metadata.modifier (since we
already have the knowledge about mapping between I915 modifiers and
tiling modes) and use it to match combinations with KMS items. Add an
explicit special case for DRM_FORMAT_MOD_NONE and I915_TILING_X, which
adds KMS usage flags (other than cursor) to matched combinations.
BUG=b:37615277
TEST=test_that reef graphics_Drm.bvt
Change-Id: Ia7573a330ccc35c3d9868ba1aa45d73bda2f691b
Reviewed-on: https://chromium-review.googlesource.com/564187
Commit-Ready: Tomasz Figa <tfiga@chromium.org>
Tested-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
On certain platforms, depending on buffer usage, the preference for
implementation defined or flexible YUV formats might be different.
For example, the camera subsystem on Poppy (i915) requires NV12 for
HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED, but it can't be used in place
of RGBX as a render target.
Allow this by extending the .resolve_format driver callback to take BO
flags as argument and let the driver include this in the format
selection logic.
BUG=b:37615277
TEST=compile
Change-Id: Ieb44c294584ab25f106a92f406353212989d0724
Reviewed-on: https://chromium-review.googlesource.com/487553
Commit-Ready: Tomasz Figa <tfiga@chromium.org>
Tested-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
... when returning on error to close open gem handles.
BUG=chromium:738113
TEST=graphicsSanity on cyan
Change-Id: I19e30abc57349655b1f1c28d38aee67a39482cc6
Reviewed-on: https://chromium-review.googlesource.com/556402
Commit-Ready: Joe Kniss <djmk@google.com>
Tested-by: Joe Kniss <djmk@google.com>
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>
When a buffer is imported, knowledge of tiling is needed for later calls
to map. Add this functionality for tegra gpus.
The Tegra display engine only knows about 3 compression schemes, of
which we only use two (NV_MEM_KIND_C32_2CRA and NV_MEM_KIND_PITCH), these
are correlated to DRM_TEGRA_GEM_TILING_MODE_BLOCK and
DRM_TEGRA_GEM_TILING_MODE_PITCH respectively in the tegra drm driver.
BUG=chromium:653283, b:38152101
TEST=graphicsSanity on nyan_big
Change-Id: Ie28212494ad109bd8caa929a9271fc4c55c5c977
Reviewed-on: https://chromium-review.googlesource.com/553517
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>
