| Age | Commit message (Collapse) | Author |
|---|
|
We can't explicitly control the mmap caching type for discrete, but
using mmap_device_coherent should be good enough here on such devices.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4842
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Reviewed-by: Nirmoy Das <nirmoy.das@intel.com>
|
|
Add support for DG2 flat ccs framebuffers with tile-4.
Signed-off-by: Juha-Pekka Heikkilä <juha-pekka.heikkila@intel.com>
Signed-off-by: Jeevan B <jeevan.b@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
|
|
The spec is somewhat unclear about this and suggests a 4x4 tile layout
on the main surface of TGL+ CCS FBs. So far IGT ensured that the height
of the main surface is 4 tiles aligned accordingly. However, the layout
of tiles is just the usual Y-tiled one where consecutive tiles in memory
order fill one full tile-row at a time, continuing with the next
tile-row afterwards. Perhaps the spec referred to the layout where CCS
cachelines mapped to the main surface in the "vertical" cacheline-pair
mode. However up until ADLP the horizontal cacheline-pair mode is used,
where consecutive CCS cachelines in memory order map to consecutive main
surface tiles mapping one full tile-row first and then continuing with
the next tile-row.
Accordingly we don't need to align the surface height to 4 tiles, remove
this restriction.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
|
|
intel_buf is keeping its size which may differ to underlying gem bo size.
Introduce keeping bo_size field which is used along with softpin mode
- like in intel_bb.
Patch also should remove previous discrepancy where intel_buf_bo_size()
returned requested (not gem bo size).
From now on user has an access to:
1. raw buffer size - intel_buf_size() - function returns how buffer data
really takes in the memory
2. gem bo buffer size - intel_buf_bo_size() - function returns how big
underlying gem object is
Signed-off-by: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com>
Cc: Petri Latvala <petri.latvala@intel.com>
Cc: Ashutosh Dixit <ashutosh.dixit@intel.com>
Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
|
|
To avoid confusion with intel_buf_bo_size() which for some buffers
can return size not equal to underlying gem bo size rename it to
intel_buf_size().
Signed-off-by: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com>
Cc: Petri Latvala <petri.latvala@intel.com>
Cc: Ashutosh Dixit <ashutosh.dixit@intel.com>
Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
|
|
In 22643ce4014a ("Return allocated size in gem_create_in_memory_regions()
and friends") we modified __gem_create_in_memory_regions and
gem_create_in_memory_regions to return the allocated size for buffer
objects. However, this also unnecessarily complicates programming in the
majority of cases where the allocated size is not needed. For example in
several cases it requires tracking the requested and allocated sizes
separately, the size used must be strictly uint64_t etc.
In order to simplify things and provide greater flexibility, here we change
22643ce4014a to follow the same scheme followed in gem_create_ext (and in
gem_create) where __gem_create_ext returns the allocated size but
gem_create_ext doesn't. With this change, __gem_create_in_memory_regions
returns the allocated size for situations where it is needed but in the
majority of cases where the allocated size is not needed we can just use
gem_create_in_memory_regions for casual use as before.
v2: Store requested not allocated bo size in intel_buf->size (Zbigniew)
Reviewed-by: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com>
Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
|
|
Often the allocated size is of interest and is different from the
requested size. Therefore return allocated size for the object (by
__gem_create_ext()) in gem_create_in_memory_regions() and friends.
v2: Assign buf->size correctly in __intel_buf_init (Zbigniew)
Cc: Andrzej Turko <andrzej.turko@linux.intel.com>
Cc: Zbigniew Kempczynski <zbigniew.kempczynski@intel.com>
Cc: John Harrison <John.C.Harrison@intel.com>
Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
Reviewed-by: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com>
|
|
Starting commit 8759c4a3020ce4 "Add intel_buf_init_in_region"
__intel_buf_init uses gem_create_in_memory_regions instead of
gem_create. Older kernels like 5.4 still dont have support for
I915_GEM_CREATE_EXT_MEMORY_REGIONS (i915_gem_create_ext_ioctl)
from kernel commit (https://patchwork.freedesktop.org/patch/431581/?series=89648&rev=1)
Due to this, the flip-vs-fences tests are failing on kernel 5.4
Patch adds fall back to gem_create when __gem_create_in_memory_region_list fails.
v2 - Addressed review comments from Zbigniew and Mark
Added the fall back in __intel_buf_init
v3 - Fixed space issue - review comment from Zbigniew
v4 - Addressed review comments from Bhanu
Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com>
Reviewed-by: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com>
Acked-by: Bhanuprakash Modem <bhanuprakash.modem@intel.com>
|
|
Add intel_buf_init_in_region which allows memory region
to be specified for new BO being created.
Same as intel_buf_init with the additional region argument.
Signed-off-by: Apoorva Singh <apoorva1.singh@intel.com>
Cc: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Melkaveri, Arjun <arjun.melkaveri@intel.com>
Reviewed-by: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com>
|
|
On discrete we can no longer call get_caching or set_domain, and the
mmap mode must be FIXED.
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Ashutosh Dixit <ashutosh.dixit@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
|
|
Add a wrapper for gem_create_ext ioctl (a version of gem_create that
accepts extensions). In preparation for the driver change implementing it,
a local definition of its id and necessary structs have been added,
which are to be erased as soon as those definitions
appear in the i915_drm.h file.
The new ioctl wrapper is added to a separate file.
For consistency the wrapper of the old ioctl, gem_create
is moved from ioctl_wrappers to gem_create.
Signed-off-by: Andrzej Turko <andrzej.turko@linux.intel.com>
Cc: Zbigniew Kempczynski <zbigniew.kempczynski@intel.com>
Cc: Dominik Grzegorzek <dominik.grzegorzek@intel.com>
Cc: Petri Latvala <petri.latvala@intel.com>
Cc: Chris P Wilson <chris.p.wilson@intel.com>
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Acked-by: Petri Latvala <petri.latvala@intel.com>
|
|
When setting up an intel_buf for a render copy operation, the render
buffer stride has to match the framebuffer stride. Not ensuring this may
lead to a mismatch modeset error or an -EBUSY set_tiling IOCTL failure
when trying to change the stride for a framebuffer object.
Cc: Dominik Grzegorzek <dominik.grzegorzek@intel.com>
Cc: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com>
Reviewed-by: Juha-Pekka Heikkilä <juha-pekka.heikkila@intel.com>
|
|
From now on intel_bb starts tracking added/removed intel_bufs.
We're safe now regardless order of intel_buf close/destroy
or intel_bb destroy paths.
When intel_buf is closed/destroyed first and it was previously added
to intel_bb it calls the code which removes itself from intel_bb.
In destroy path we go over all tracked intel_bufs and clear tracking
information and buffer offset (it is set to INTEL_BUF_INVALID_ADDRESS).
Reset path is handled as follows:
- intel_bb_reset(ibb, false) - just clean objects array leaving
cache / allocator state intact.
- intel_bb_reset(ibb, true) - purge cache as well as detach intel_bufs
from intel_bb (release offsets from allocator).
Remove intel_bb_object_offset_to_buf() function as tracking intel_buf
updates (checks for allocator) their offsets after execbuf.
Alter api_intel_bb according to intel-bb changes.
Signed-off-by: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com>
Cc: Dominik Grzegorzek <dominik.grzegorzek@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Petri Latvala <petri.latvala@intel.com>
|
|
For some cases (fb with compression) fb size is bigger than calculated
intel_buf what lead to execbuf failure when allocator is used
along with EXEC_OBJECT_PINNED flag set for all objects.
We need to create intel_buf with size equal to fb so new function
in which we pass handle and size is required.
v2: add bo_size check to better protect input size (Jason)
Signed-off-by: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com>
Cc: Dominik Grzegorzek <dominik.grzegorzek@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Petri Latvala <petri.latvala@intel.com>
|
|
1. Buffer size from 32 -> 64 bit was changed to be consistent
with drm code.
2. Remember buffer creation size to avoid recalculation.
Signed-off-by: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com>
Cc: Dominik Grzegorzek <dominik.grzegorzek@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Petri Latvala <petri.latvala@intel.com>
|
|
In preparation for a variation on the exisiting GEM_CREATE API, split
the ioctl from out of the large ioctl_wrappers.c
Signed-off-by: Andrzej Turko <andrzej.turko@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Height alignment was not properly set to 32 which was to big for
x-tiling and linear surfaces and leads to overallocation.
Linear surfaces currently don't require any height alignment (just 1),
for x-tiling we use 8.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2491
Signed-off-by: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com>
Cc: Dominik Grzegorzek <dominik.grzegorzek@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
To avoid intel_buf handle leakage we need to clarify of buffer ownership
rules. So we currently have:
1. intel_buf_init(), intel_buf_create() which create handle and take
ownership of such handle.
2. intel_buf_init_using_handle(), intel_buf_create_using_handle() which
take bo handle from the caller and doesn't take ownership.
intel_buf_close()/intel_buf_destroy() will honour ownership and skip
closing handle if buffer is not owned.
To take/release buffer ownership intel_buf_set_ownership() can be used.
Signed-off-by: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com>
Cc: Dominik Grzegorzek <dominik.grzegorzek@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Previous assert checking was to narrow and it didn't support 64bpp.
Some kms tests use 64bpp so extend the assert.
Signed-off-by: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com>
Cc: Dominik Grzegorzek <dominik.grzegorzek@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Grantsdale requires 512 stride on Y tiling.
v2: Remove redundant code for getting the stride
Fix using not initialized buf->tiling field
(reported by Dominik)
Signed-off-by: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com>
Cc: Dominik Grzegorzek <dominik.grzegorzek@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Not all swizzling can be handled by the software (bit17) so detect
it properly during bufops creation time and disable if necessary.
Signed-off-by: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com>
Cc: Dominik Grzegorzek <dominik.grzegorzek@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Simplify mapping intel_buf. To be extended with ref counting.
Add intel_buf dump function for easy dump buffer to the file.
Fixing returned type of bo size function.
Idempotency selftest is now skipped for default buf_ops creation
to avoid time consuming comparison of HW and SW tiled buffers
(this can be the problem for forked tests). Additional function
buf_ops_create_with_selftest() was added to allow perform
verification step where it is required.
Changing alignment from 4->2 (required for 16bpp render).
Signed-off-by: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com>
Cc: Dominik Grzegorzek <dominik.grzegorzek@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Rendercopy for gen12+ requires additional aux pgtable. Alter bufops
and tests to use surface[] and ccs[] instead aux. This step is
required to properly rewrite handling aux pgtable to use with
intel_bb.
Signed-off-by: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
This is minor step toward removing libdrm from rendercopy. Lets
add new functions and structure fields to verify we don't introduce
regressions in already migrated code.
Some utility functions - write buf/aux (ccs) to png were added.
Signed-off-by: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Add bufops reference to intel_buf to allow acquire drm fd against which
buffer was created.
Change stride limitation for intel_buf for non-tiled buffers.
Signed-off-by: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Different GENs supports different tile surfaces. Older GENs
have HW fences to allow X / Y surface tiling / detiling.
Newer GENs have to tile / detile such surface in software.
To make test developer life easier this code adds buffer
operations (short buf_ops) to use appropriate functions allowing
copying linear buffer to BO and from BO to linear buffer
regardless GPU generation and tiling/swizzling within BO. For GENs
having fences support preference is to use them if they are available
(X / Y tiling is probed on buf_ops initialization).
Note: on Gen2 code supports only HW tiling at the moment.
Signed-off-by: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Katarzyna Dec <katarzyna.dec@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
