| Age | Commit message (Collapse) | Author |
|---|
|
16k*16k*16 == 1<<32, so 32bits isn't enough for the result when
we start to have big framebuffers.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
We're currently overallocating the shadow buffer stride by a
factor of 8. This didn't go down so well when I tried to use
a 16kx16k float framebuffer.
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Fixes: b0033d9310c1 ("lib/color_encoding: Prepare support for HDR modes, v2.")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Follow design of P01x conversion to support tests needing pixel data in fp16
(half float 64 bpp).
rfc2:
- Convert whole rows of pixels if possible (Maarten)
- Treat rgbx like rgba, let hardware ignore alpha (Maarten)
Signed-off-by: Kevin Strasser <kevin.strasser@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
|
The earlier approach of checking the higher tiled stride
limit has backfired. All out blits are between tiled and
linear, but we only ever check this for the tiled fb. Thus
we are taking the blitter path even though the linear fb
exceeds the blitter limits. So let's just check the limits
as if we are operating on linear fbs.
And let's toss in some width/height checks, and let's do
the checks for all the color planes as well.
v2: Reword the comment a bit to hopefully make it legible (Chris)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
The blit and rendercopy implementations are now identical.
Kill one.
v2: s/__blit/__gpu/ (Chris)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
We're currently leaking all the temporary bos we construct
for rendercopy. That doesn't go so well when trying to test
with 1GiB framebuffers.
v2: Add fini_buf() (Chris)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Remember to free the bufmgr and batch after the convert surface is
destroyed. We'll do that by sucking the relevant code into
free_linear_mapping(), and for the sake of symmetry we'll move
the setup code into setup_linear_mapping().
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
|
|
The blitter stride is limited to <32k. Fall back to gtt mmap or
rendercopy if we're about to exceed that.
Not quite sure why we're not just using gtt mmap for Y tiling
always. But let's keep it like that for now.
v2: Use rendercopy as the fallback for Yf
v3: Deal with gen4+ tiled stride correctly (Chris)
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
The kmstest_dumb_create API isn't suitable for creating multi-planar
buffers since it tries to calculate the size based on the first plane's
pitch only.
AMDGPU requires that the luma pitch be aligned to 256 for YUV buffers
which results in crashes on kms_plane@pixel-format-pipe-*-planes tests
when using kmstest_dumb_create since the buffer returned is smaller than
needed (16384 size returned, 24576 size required).
Create and map the buffer with the correct size by using the AMD helpers
introduced by this patch: igt_amd_create_bo and igt_amd_mmap_bo.
Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Leo Li <sunpeng.li@amd.com>
|
|
Y410 is packed with compressed a channel and only 32 bpp, like
10 bits RGB formats. Y416 is a packed 16 bits per component format.
Changes since v1:
- Rebase on top of upstream YUV changes.
Changes since v2:
- Discard alpha channel, not used upstream.
Changes since v3:
- Handle the XVYU formats and Y41x formats correctly.
Changes since v4:
- Fix YUV conversion routines. (Ville)
- Use memset64 to clear initial fb. (Ville)
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
[mlankhorst: Add missing ULL (Ville)
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
|
Those formats are packed like YUYV, but only 16 bits per component.
Changes since v1:
- Rebase on top of upstream YUV changes.
Changes since v2:
- Use drm_fourcc.h from upstream.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
|
The chroma address needs to be 256 byte aligned on amdgpu and the
easiest way to do so is to align the minimum stride for the luma.
v2: added this patch
Cc: Leo Li <sunpeng.li@amd.com>
Cc: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
|
|
A linear mapping setup for Y, Yf tiled and CCS modifiers. Instead of
checking against each CCS modifier, let's make use of this wrapper.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
|
Steal if from kms_plane.c and put it into igt_fb.h
Also tiny bikeshed to remove the space, so it fits more tidily into
the usual name1=value1, name2=value2 style printing.
v2: Rebase
v3: It better compile :-/
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v1)
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
|
|
In order to execute negative tests that validate fb creation, tests need to
be able to call the addfb ioctl themselves so that the arguments can be
manipulated. Add a library function to provide an initialized fb without
registering the fb with the kernel.
Cc: Clinton Taylor <clinton.a.taylor@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
|
Rename the igt_fb.tiling to igt_fb.modifier to better reflect
what information it carries. Now it's clear whether we're talking
about a modifier or a i915 tiling thing.
Cc: Clinton Taylor <clinton.a.taylor@intel.com>
>From DK:
Rebased on vc4 changes
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
|
|
Plug in rendercopy to the cairo surface stuff so that we can
generate compressed buffers with cairo.
v2: s/modifier_has_ccs/is_ccs_modifier/
v3: From DK
Set buf.bpp when initializing and rebase.
v4: From DK
Fix Yf-tiled BGR formats
Cc: Clinton Taylor <clinton.a.taylor@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com>
|
|
YVU420 and YVU422 will otherwise use offsets for P010 and pals.
Signed-off-by: Petri Latvala <petri.latvala@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> #irc
|
|
Move all mmap flavours and support function to separate file in i915
folder. This helps with moving i915 specific functions away from common
libraries.
v2:
- Autotools still exists. (Petri)
- Include gem_mman.h directly. (Chris)
v3:
- Keep includes explicit. (Chris)
Signed-off-by: Antonio Argenziano <antonio.argenziano@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Petri Latvala <petri.latvala@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
This pipes-in support for the VC4 modifiers that we have conversion
helpers for. A new temporary linear framebuffer is introduced, that
is either freed later or copied to the destination framebuffer
pointer.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Reviewed-by: Maxime Ripard <maxime.ripard@bootlin.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
|
|
The modifier is part of how a frame is represented, so add it as an
extra argument so that it can be specified when converting framebuffers.
For now, only a linear modifier is supported.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Reviewed-by: Maxime Ripard <maxime.ripard@bootlin.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
|
|
Introduce a helper to allocate and fill-in a list of available DRM
formats, which is useful for picking one at random in tests.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Maxime Ripard <maxime.ripard@bootlin.com>
|
|
The format bpp for a given plane is stored in the static format_desc
structure and is not accessible to tests, which is inconvenient to
get the minimum stride for a format when testing various strides.
Add a simple helper to expose the information.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Maxime Ripard <maxime.ripard@bootlin.com>
|
|
The current implementation of igt_fb_convert does not allow passing
the destination stride, which is something we want to change for tests.
Add a new fashion of this function that allocates the desintation buffer
with a given stride. Since the current function does the same thing with
an unspecified stride (set to zero, which will be filled later), make it
call our new fashion with the stride set to zero to avoid duplication.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Maxime Ripard <maxime.ripard@bootlin.com>
|
|
The VC4 SAND tiling modes are disposed in columns that follow each
other in memory. The column height defines the number of fixed-width
lines from the beginning of one column to the other, which may be
greater than the display height. In this case, the extra lines are
used as padding and the column height becomes a height-based stride
equivalent.
Support this when calculating the plane size by using the tile height
directly if it is greater than the plane height. This works better than
alignment for non-power-of-two cases (no space is wasted) and it is
equivalent to alignment for power-of-two tile heights.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Maxime Ripard <maxime.ripard@bootlin.com>
|
|
This introduces support for the VC4 SAND tiling modes, that take a
specific parameter indicating their column height. This parameter acts
as a height-based stride equivalent, that shall be equal or greater
than the displayed height.
The parameter is extracted and returned as tile height so that enough
memory can be reserved for column heights containing extra padding.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Reviewed-by: Maxime Ripard <maxime.ripard@bootlin.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
|
|
This introduces the required bits for allocating buffers with a T-tiled
disposition, that is specific to the VC4. It includes calculating the
top-tile width and creating a buffer object with the VC4-specific
helper. The tiling flag is set to the buffer object so that this can
be reused for GPU tests if needed later.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Maxime Ripard <maxime.ripard@bootlin.com>
|
|
The current create_bo_for_fb uses a device-specific BO instead of dumb
allocation when dumb allocation is not appropriate and the driver is
Intel. Then, it will assert that the parameters are appropriate for
dumb allocation.
The conditions related to tiling, size and stride are sufficient for
needing a device-specific BO and they are not specific to Intel.
However, a device-specific BO for YUV is only needed for Intel.
Change the conditions accordingly and set a device_bo variable. This
variable allows making fb->size calculation common between the
device-specific and dumb paths. Use the variable after that and
distinguish between the device types for allocating and error out if
it's not supported.
This makes the extra checks that dumb allocation is valid redundant,
since these cases will always fall under device-specific allocation
and potentially error out then.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Reviewed-by: Maxime Ripard <maxime.ripard@bootlin.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
|
|
The code path for allocating tiled buffers has a few i915-specific bits
without checks for the i915 driver. Add these missing checks.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Reviewed-by: Maxime Ripard <maxime.ripard@bootlin.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
|
|
The P01x formats are planar 16 bits per component, with the unused lower bits set to 0.
This means they can all be converted the same way. Only the range is slightly different,
and this is handled in the color_encoding implementation.
This requires cairo 1.17.2 and pixman 0.36. This works but doesn't give extra precision.
For more than 8 bits precision a few more patches are required to pixman, pending review:
https://lists.freedesktop.org/archives/pixman/2019-January/004815.html
https://lists.freedesktop.org/archives/pixman/2019-January/004809.html
Once those are merged, we will require the next pixman release for better precision.
Changes since v1:
- Add fallback color definitions when compiling on cairo version < 1.17.2.
- Skip when FB creation fails on HDR formats, instead of failing.
Changes since v2:
- Complain slightly harder when pixman/cairo are out of date.
- Create a fb with alpha when converting to pixman formats with alpha.
- Oops, s/pixman_format_code_t/cairo_format_t/
Changes since v3:
- Rebase on top of upstream YUV changes.
Changes since v4:
- Rebase again.
- Use drm_fourcc.h from drm-misc-next.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> #v4
|
|
We're starting to add support for 10, 12 and 16-bits formats that all have
different values for the Y offset and range. Some 10 bits formats
go from [0...1023], others go to [0...1023] shifted left by 6. To
accomodate all formats add a struct definition for all various formats,
this can be extended further when we add new formats.
Changes since v1:
- Rebase on top of added yuv changes.
- Add commit description (swatish)
- Add missing newline. (swatish)
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> #v1
|
|
Thanks to the previous reworks, we can now add new YUV formats pretty
easily. This patch adds support for the NV12, NV16, NV21, NV61, YUV420,
YVU420, YUV422 and YVU422 formats.
Reviewed-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
|
|
We only need to allocate a buffer using the GEM API when we're in the
condition that we currently test, and that we're running on i915.
All the other cases can be handled by a fallback to a dumb buffer
allocation. Let's simplify the code a bit to reflect that.
Reviewed-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Reviewed-by: Deepak Rawat <drawat@vmware.com>
|
|
YUV dumb buffers, just like i915 GEM buffers also need to be cleared once
allocated. Make sure it happens.
Reviewed-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
|
|
The dumb buffer allocation API only considers a single plane, and even
though allocating multi-planar buffers through it is allowed, the stride it
gives back is the the width times the bpp passed as an argument.
That doesn't work in our case, since the bpp is going to be the one we give
as an argument, but split over three planes so the stride doesn't match
anymore.
A proper fix for this would be to have a better dumb buffer allocation API,
but for the time being, let's do it that way.
Reviewed-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
|
|
When allocating a dumb buffer for a format with multiple plane, we need to
account for all plane's bpp in order to allocate the proper size.
Let's add all the planes bpp and use the result to allocate our buffer.
Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
|
|
Since we want to use the dumb buffers to store frames in formats with
multiple planes, we need to add checks for unsupported corner cases, and we
need to calculate the offsets and sizes of each planes. Let's use
calc_fb_size for that.
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
|
|
The else condition is not needed, since all the other conditions return
when they are done.
Move the KMS dumb buffer allocation outside of the outer else condition,
this will also allow to ease later changes.
Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Reviewed-by: Deepak Rawat <drawat@vmware.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
|
|
Preliminary patches for the YUV testing series were broken without
subsequent patches that fix them when moving things around.
The argument provided to clear_yuv_buffer should be the framebuffer,
not the DRM file descriptor (fb vs fd). Also, an assert was added to
clear_yuv_buffer to ensure that it's only called for YUV formats,
which has to be reflected in the calling function.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Reviewed-by: Maxime Ripard <maxime.ripard@bootlin.com>
|
|
The YUV buffer allocation path for the i915 driver also has some code to
clear a YUV buffer.
As that is going to be useful for all the other drivers, let's move it to
a separate function.
Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
|
|
The current way we work when we want to support a new YUV format to IGT, we
also need to add new function to convert to and from XRGB8888.
This doesn't really scale however, and creates a lot of code to maintain.
In order to work around this, create a generic function to convert to RGB
and one to convert from RGB.
The only thing that is needed now is to add new parameters, and that's it.
Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Acked-by: Lyude Paul <lyude@redhat.com>
|
|
Aligning the width on 64 pixels only make sense on intel platforms, make
sure to add a check against this.
Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
|
|
In order to improve the YUV support, let's add the horizontal and vertical
subsampling parameters to the IGT formats.
Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
|
|
A typo fix in 1x2 pixel block conversion code, revealed by GCC 9
Fixes: 1c7ef3890045 ("lib: Use igt_matrix for ycbcr<->rgb conversion")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109257
Reported-by: Martin Liska <mliska@suse.cz>
Signed-off-by: Petri Latvala <petri.latvala@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
|
|
Pixman requires buffer strides the be aligned to 32-bit words in order
to create internal representations of buffers. If this condition is not
met, it will fail and IGT will not be able to report the error cause,
making it hard to debug the issue.
Add an explicit check in our code prior to calling pixman when
converting buffer so that the error can be understood if it occurs.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Reviewed-by: Maxime Ripard <maxime.ripard@bootlin.com>
|
|
../lib/igt_fb.c: In function ‘convert_rgb24_to_yuv444’:
../lib/igt_fb.c:1720:16: warning: unused variable ‘v’ [-Wunused-variable]
float y, u, v;
^
../lib/igt_fb.c:1720:13: warning: unused variable ‘u’ [-Wunused-variable]
float y, u, v;
^
../lib/igt_fb.c:1720:10: warning: unused variable ‘y’ [-Wunused-variable]
float y, u, v;
^
Signed-off-by: Petri Latvala <petri.latvala@intel.com>
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
|
|
XYUV8888 format support has been added to DRM, modified
IGT to reflect those changes.
v2: Fixed merge conflict, started to use new yuv<=>rgb
conversion functions.
v3: Fixed kms_available_modes_crc test to support new XYUV
format. Fixed a problem, where test complains that two
outputs might use same pipe at the same time.
v4: Fixed convertion procedure in igt_fb to support XYUV
properly.
v5: Fixed a coding typo.
v6: Set depth equal to -1 for XYUV format in order to prevent
it to be used by igt_bpp_depth_to_drm_format, as we do not
want YUV formats to be used in that case.
v7: Fix "black" color initialization for create_bo_for_fb with
proper value. Changed naming "planar_stride" to "xyuv_stride".
v8: Change naming from DRM_FORMAT_XYUV to DRM_FORMAT_XYUV8888
v9: Fixed compilation errors by rebasing to recent master.
v10: Adding reference to correspondent kernel commit with the new format
in include/drm-uapi
v11: Removed unnecessary sizeof's in rgb <=> yuv444 convert functions.
v12: Rebased against master branch, fixed rebase conflict caused by
new fb_convert functions. Removed drm kernel commit reference
as it is still not merged, so doesn't make sense to use it.
v13: Resolved one more rebase conflict.
Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
|
|
Clang fails to compile with:
error: suggest braces around initialization of subobject [-Werror,-Wmissing-braces]
Make the initializer empty to fix this issue.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Petri Latvala <petri.latvala@intel.com> #irc
|
|
Make the handling of slow gtt mmap reads generic, and extend it to
the pixman converter. Makes the pixman path a bit faster.
With testing just XRGB8888 and XBGR8888 on KBL:
$ time kms_plane --r pixel-format-pipe-A-planes
- real 0m18,757s
+ real 0m2,635s
v2: Use the original src buffer if the malloc fails (Chris)
Drop the duplicated comment about things being slow
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Maxime Ripard <maxime.ripard@bootlin.com>
Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Maxime Ripard <maxime.ripard@bootlin.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
|
|
The converter operates between the linear and shadow fbs. When using
the blitter path there is no particular reason to assume that the
linear fb and actual fb have the same strides for instance. Thus
consulting the actual fb for metadata is not really correct.
We can also simplify the mmap() path by copying all the original
fb metadata into linear.fb as there we map the original fb directly.
We just have to keep clearing linear.fb.gem_handle so that the
dtor knows which kind of beast it's got.
Cc: Maxime Ripard <maxime.ripard@bootlin.com>
Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Maxime Ripard <maxime.ripard@bootlin.com>
|
