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>
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>
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>
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>
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>
This adds support for allocating AFBC (ARM FrameBuffer Compression)
buffers with minigbm for Rockchip SoCs. AFBC buffers are allocated
through the new gbm_bo_create_with_modifiers() entry point. Callers are
responsible for determining which modifiers are valid for the intended
use case and pass in that list. gbm will then pick the optimal modifier
and allocate a buffer with that layout. The chosen modifier can be
queries through gbm_bo_get_format_modifier().
Callers of the new entry point are expected to forward the modifier when
using the buffer with other APIs (EGL, KMS etc). The old gbm_bo_create()
entry point continues to work as before and won't allocate AFBC buffers.
BUG=chrome-os-partner:56407
TEST=drm-tests null_platform_test with AFBC support
Change-Id: I1aa345b0d79c4545b7bfc17e9699ef6ad57c68e2
Reviewed-on: https://chromium-review.googlesource.com/386318
Commit-Ready: Kristian H. Kristensen <hoegsberg@chromium.org>
Tested-by: Kristian H. Kristensen <hoegsberg@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
With CL:397941, hshi@ figured out how to detile blocklinear buffers
for tegra. Let's add that logic to our tegra map()/unmap() functions.
This can be useful for various tests.
BUG=chromium:673570
TEST=tiled_bo_test draws ellipse texture on Tegra (there are artifacts
due another bug though)
Change-Id: I7c2e7222ba67457ffd3641ba42a775ac4a667ec8
Reviewed-on: https://chromium-review.googlesource.com/421279
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Haixia Shi <hshi@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>
Adding a nouveau backend to minigbm can be useful to test ozone code
on our workstations.
This CL adds a nouveau backend that uses dumb buffers.
This is enough to run ozone_gl_unittests and ozone_demo on our
workstations.
BUG=None
TEST='Ran ozone_demo on my workstation.'
Change-Id: I4e690192c9d9944b9907e64253205a94605a76eb
Reviewed-on: https://chromium-review.googlesource.com/421606
Commit-Ready: David Reveman <reveman@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
We were incorrectly advertising the scanout and cursor flags in
the drivers.
Chrome never used the BO_USE_CURSOR flag (see chromium:666488), and we
set it for incorrect formats. Let's only advertise ARGB8888/XRGB8888
cursors if they were previously advertised, and prevent cursors from being
used as render targets.
For scanout, formats can vary from kernel version to kernel version.
For example, the v3.18 i915 driver can't scanout NV12, but the upstream v4.4
i915 driver can. Let's query the KMS API in those cases.
In addition, we would also like to move to a place where our backends can
determine if a specific {format, usage, format modifier} tuple is supported.
The plan is to add modifiers to the properties that are exposed in KMS, which
can help with optimization.
BUG=b:31942635, chromium:666488
TEST=Ran graphics_Gbm and checked if Chrome boots on cyan, minnie, and
nyan_big
CQ-DEPEND=CL:413325
Change-Id: Ifd3fd1c8063db97b3f1fe057ace82d22def76943
Reviewed-on: https://chromium-review.googlesource.com/405019
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Ilja H. Friedel <ihf@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>
This is helpful for importing multiplanar formats (see b/31999328)
and importing AFBC format modifiers.
BUG=chrome-os-partner:56407
TEST=drm-tests null_platform_test with AFBC support
test_that -b cyan $IP1 graphics_Gbm to check for regressions
Change-Id: If7ed9b54e18069ca69b2dbda2b01d59ce58ebeef
Reviewed-on: https://chromium-review.googlesource.com/401439
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Daniele Castagna <dcastagna@chromium.org>
When running x86 ARC++ images on a virtual machine, we use
the vgem driver. We should support it here too.
BUG=chromium:616275
TEST=container boots when running QEMU with cros_gralloc. Note
videos (i.e, YUV formats) don't work on QEMU, but they never did
with gralloc_drm either.
CQ-DEPEND=CL:392548
Change-Id: If9f6b8035f2a88068980bede5121ef4599b37272
Reviewed-on: https://chromium-review.googlesource.com/392549
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
It is desirable to have a gralloc implementation based on the same
drivers we use for minigbm. This will help synchronize the code between
CrOS and the Android container.
BUG=chromium:616275
TEST=Ran the gralloc unit test:
test_that -b veyron_minnie-cheets $IP1 graphics_Gralloc
Verified it succeeded.
CQ-DEPEND=CL:395066
Change-Id: Iff11eba3a92268327ef00eb12b4eabe6fc190cf3
Reviewed-on: https://chromium-review.googlesource.com/362062
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
We previously added the gbm_bo_map/gbm_bo_unmap (see CL:393927)
entry points since we wanted to do driver-specific detiling during
screenshot capture tests. We ignored most the parameters and mapped
the entire buffer. This CL adds the ability to:
1) Return the starting address within a byte given a specific x, y
in the buffer.
2) Handle the case where there are more than one kernel buffers
per buffer object. Currently, only the Exynos driver would use
this capability.
BUG=chromium:653284
TEST=Ran cros_gralloc with modified code
CQ-DEPEND=CL:393927
Change-Id: I19d75d2f16489c0184e96305fb643f18477e1cdb
Reviewed-on: https://chromium-review.googlesource.com/395066
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
This reverts commit bb19d6abec.
This was chumped w/out explanation, and the bots have all been
dead since due to graphics_Gbm check failures. Reverting in
the hope it'll fix things. It can reland via the CQ.
BUG=chromium:654245
Change-Id: I0d88f7731e9e90fffee1485056d787430eb0b850
Reviewed-on: https://chromium-review.googlesource.com/395727
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
BUG=chrome-os-partner:56407
TEST=drm-tests null_platform_test with AFBC support
Change-Id: If7ed9b54e18069ca69b2dbda2b01d59ce58ede0b
Reviewed-on: https://chromium-review.googlesource.com/387145
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Tested-by: Kristian H. Kristensen <hoegsberg@chromium.org>
Trybot-Ready: Kristian H. Kristensen <hoegsberg@chromium.org>
Added the drv analogues of the 2 flexible formats we need to support.
Added analogues of most of the gralloc use flags, except:
GRALLOC_USAGE_SW_READ_MASK
GRALLOC_USAGE_SW_WRITE_MASK
GRALLOC_USAGE_HW_MASK
GRALLOC_USAGE_FOREIGN_BUFFERS
GRALLOC_USAGE_ALLOC_MASK
These are used as masks and don't make sense as usage hints. In
addition, put the new flags in the drivers' supported lists and
added a flexible format query function.
BUG=chromium:616275
TEST=minigbm still builds
CQ-DEPEND=CL:371501
Change-Id: Idd2ecd6fde3e6c5caaaf3a8404d0d7db20b4ecf4
Reviewed-on: https://chromium-review.googlesource.com/372359
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>
Gralloc requires the ability to mmap a buffer into userspace. This
change adds the necessary entry points to our internal "drv"
interface.
BUG=chromium:616275
TEST=minigbm still builds. Also ran:
./gralloctest mapping
with CL:362062 applied on minnie and cyan (decided to split that CL
into smaller patches).
CQ-DEPEND=CL:366041
Change-Id: I7396b0c79702f24eb779984805bc679c237bd932
Reviewed-on: https://chromium-review.googlesource.com/370798
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
When a dmabuf is imported multiple times, further imports after the
first one are not refcounted, i.e. the first close() will lose the
dmabuf. To avoid this, user space needs to track the number of imports
and only close() the dmabuf once the last import is closed.
BUG=None
TEST=Ran graphics_Gbm on minnie. Still passes.
Change-Id: Iba63556ccc94ac5d49be2f827ceead85e0e22c9c
Reviewed-on: https://chromium-review.googlesource.com/366041
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>
