mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
synced 2026-07-16 17:57:38 -04:00
Merge tag 'drm-next-2021-08-31-1' of git://anongit.freedesktop.org/drm/drm
Pull drm updates from Dave Airlie:
"Highlights:
- i915 has seen a lot of refactoring and uAPI cleanups due to a
change in the upstream direction going forward
This has all been audited with known userspace, but there may be
some pitfalls that were missed.
- i915 now uses common TTM to enable discrete memory on DG1/2 GPUs
- i915 enables Jasper and Elkhart Lake by default and has preliminary
XeHP/DG2 support
- amdgpu adds support for Cyan Skillfish
- lots of implicit fencing rules documented and fixed up in drivers
- msm now uses the core scheduler
- the irq midlayer has been removed for non-legacy drivers
- the sysfb code now works on more than x86.
Otherwise the usual smattering of stuff everywhere, panels, bridges,
refactorings.
Detailed summary:
core:
- extract i915 eDP backlight into core
- DP aux bus support
- drm_device.irq_enabled removed
- port drivers to native irq interfaces
- export gem shadow plane handling for vgem
- print proper driver name in framebuffer registration
- driver fixes for implicit fencing rules
- ARM fixed rate compression modifier added
- updated fb damage handling
- rmfb ioctl logging/docs
- drop drm_gem_object_put_locked
- define DRM_FORMAT_MAX_PLANES
- add gem fb vmap/vunmap helpers
- add lockdep_assert(once) helpers
- mark drm irq midlayer as legacy
- use offset adjusted bo mapping conversion
vgaarb:
- cleanups
fbdev:
- extend efifb handling to all arches
- div by 0 fixes for multiple drivers
udmabuf:
- add hugepage mapping support
dma-buf:
- non-dynamic exporter fixups
- document implicit fencing rules
amdgpu:
- Initial Cyan Skillfish support
- switch virtual DCE over to vkms based atomic
- VCN/JPEG power down fixes
- NAVI PCIE link handling fixes
- AMD HDMI freesync fixes
- Yellow Carp + Beige Goby fixes
- Clockgating/S0ix/SMU/EEPROM fixes
- embed hw fence in job
- rework dma-resv handling
- ensure eviction to system ram
amdkfd:
- uapi: SVM address range query added
- sysfs leak fix
- GPUVM TLB optimizations
- vmfault/migration counters
i915:
- Enable JSL and EHL by default
- preliminary XeHP/DG2 support
- remove all CNL support (never shipped)
- move to TTM for discrete memory support
- allow mixed object mmap handling
- GEM uAPI spring cleaning
- add I915_MMAP_OBJECT_FIXED
- reinstate ADL-P mmap ioctls
- drop a bunch of unused by userspace features
- disable and remove GPU relocations
- revert some i915 misfeatures
- major refactoring of GuC for Gen11+
- execbuffer object locking separate step
- reject caching/set-domain on discrete
- Enable pipe DMC loading on XE-LPD and ADL-P
- add PSF GV point support
- Refactor and fix DDI buffer translations
- Clean up FBC CFB allocation code
- Finish INTEL_GEN() and friends macro conversions
nouveau:
- add eDP backlight support
- implicit fence fix
msm:
- a680/7c3 support
- drm/scheduler conversion
panfrost:
- rework GPU reset
virtio:
- fix fencing for planes
ast:
- add detect support
bochs:
- move to tiny GPU driver
vc4:
- use hotplug irqs
- HDMI codec support
vmwgfx:
- use internal vmware device headers
ingenic:
- demidlayering irq
rcar-du:
- shutdown fixes
- convert to bridge connector helpers
zynqmp-dsub:
- misc fixes
mgag200:
- convert PLL handling to atomic
mediatek:
- MT8133 AAL support
- gem mmap object support
- MT8167 support
etnaviv:
- NXP Layerscape LS1028A SoC support
- GEM mmap cleanups
tegra:
- new user API
exynos:
- missing unlock fix
- build warning fix
- use refcount_t"
* tag 'drm-next-2021-08-31-1' of git://anongit.freedesktop.org/drm/drm: (1318 commits)
drm/amd/display: Move AllowDRAMSelfRefreshOrDRAMClockChangeInVblank to bounding box
drm/amd/display: Remove duplicate dml init
drm/amd/display: Update bounding box states (v2)
drm/amd/display: Update number of DCN3 clock states
drm/amdgpu: disable GFX CGCG in aldebaran
drm/amdgpu: Clear RAS interrupt status on aldebaran
drm/amdgpu: Add support for RAS XGMI err query
drm/amdkfd: Account for SH/SE count when setting up cu masks.
drm/amdgpu: rename amdgpu_bo_get_preferred_pin_domain
drm/amdgpu: drop redundant cancel_delayed_work_sync call
drm/amdgpu: add missing cleanups for more ASICs on UVD/VCE suspend
drm/amdgpu: add missing cleanups for Polaris12 UVD/VCE on suspend
drm/amdkfd: map SVM range with correct access permission
drm/amdkfd: check access permisson to restore retry fault
drm/amdgpu: Update RAS XGMI Error Query
drm/amdgpu: Add driver infrastructure for MCA RAS
drm/amd/display: Add Logging for HDMI color depth information
drm/amd/amdgpu: consolidate PSP TA init shared buf functions
drm/amd/amdgpu: add name field back to ras_common_if
drm/amdgpu: Fix build with missing pm_suspend_target_state module export
...
This commit is contained in:
Linus Torvalds
@@ -159,6 +159,8 @@ KMS Core Structures and Functions
|
||||
.. kernel-doc:: drivers/gpu/drm/drm_mode_config.c
|
||||
:export:
|
||||
|
||||
.. _kms_base_object_abstraction:
|
||||
|
||||
Modeset Base Object Abstraction
|
||||
===============================
|
||||
|
||||
@@ -463,6 +465,35 @@ KMS Properties
|
||||
This section of the documentation is primarily aimed at user-space developers.
|
||||
For the driver APIs, see the other sections.
|
||||
|
||||
Requirements
|
||||
------------
|
||||
|
||||
KMS drivers might need to add extra properties to support new features. Each
|
||||
new property introduced in a driver needs to meet a few requirements, in
|
||||
addition to the one mentioned above:
|
||||
|
||||
* It must be standardized, documenting:
|
||||
|
||||
* The full, exact, name string;
|
||||
* If the property is an enum, all the valid value name strings;
|
||||
* What values are accepted, and what these values mean;
|
||||
* What the property does and how it can be used;
|
||||
* How the property might interact with other, existing properties.
|
||||
|
||||
* It must provide a generic helper in the core code to register that
|
||||
property on the object it attaches to.
|
||||
|
||||
* Its content must be decoded by the core and provided in the object's
|
||||
associated state structure. That includes anything drivers might want
|
||||
to precompute, like struct drm_clip_rect for planes.
|
||||
|
||||
* Its initial state must match the behavior prior to the property
|
||||
introduction. This might be a fixed value matching what the hardware
|
||||
does, or it may be inherited from the state the firmware left the
|
||||
system in during boot.
|
||||
|
||||
* An IGT test must be submitted where reasonable.
|
||||
|
||||
Property Types and Blob Property Support
|
||||
----------------------------------------
|
||||
|
||||
@@ -508,8 +539,8 @@ Plane Composition Properties
|
||||
Damage Tracking Properties
|
||||
--------------------------
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/drm_damage_helper.c
|
||||
:doc: overview
|
||||
.. kernel-doc:: drivers/gpu/drm/drm_plane.c
|
||||
:doc: damage tracking
|
||||
|
||||
Color Management Properties
|
||||
---------------------------
|
||||
|
||||
@@ -37,6 +37,15 @@ Primary Nodes, DRM Master and Authentication
|
||||
.. kernel-doc:: include/drm/drm_auth.h
|
||||
:internal:
|
||||
|
||||
|
||||
.. _drm_leasing:
|
||||
|
||||
DRM Display Resource Leasing
|
||||
============================
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/drm_lease.c
|
||||
:doc: drm leasing
|
||||
|
||||
Open-Source Userspace Requirements
|
||||
==================================
|
||||
|
||||
@@ -457,6 +466,19 @@ Userspace API Structures
|
||||
.. kernel-doc:: include/uapi/drm/drm_mode.h
|
||||
:doc: overview
|
||||
|
||||
.. _crtc_index:
|
||||
|
||||
CRTC index
|
||||
----------
|
||||
|
||||
CRTC's have both an object ID and an index, and they are not the same thing.
|
||||
The index is used in cases where a densely packed identifier for a CRTC is
|
||||
needed, for instance a bitmask of CRTC's. The member possible_crtcs of struct
|
||||
drm_mode_get_plane is an example.
|
||||
|
||||
DRM_IOCTL_MODE_GETRESOURCES populates a structure with an array of CRTC ID's,
|
||||
and the CRTC index is its position in this array.
|
||||
|
||||
.. kernel-doc:: include/uapi/drm/drm.h
|
||||
:internal:
|
||||
|
||||
|
||||
@@ -422,9 +422,16 @@ Batchbuffer Parsing
|
||||
User Batchbuffer Execution
|
||||
--------------------------
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_context_types.h
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
|
||||
:doc: User command execution
|
||||
|
||||
Scheduling
|
||||
----------
|
||||
.. kernel-doc:: drivers/gpu/drm/i915/i915_scheduler_types.h
|
||||
:functions: i915_sched_engine
|
||||
|
||||
Logical Rings, Logical Ring Contexts and Execlists
|
||||
--------------------------------------------------
|
||||
|
||||
@@ -518,6 +525,14 @@ GuC-based command submission
|
||||
.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
|
||||
:doc: GuC-based command submission
|
||||
|
||||
GuC ABI
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_messages_abi.h
|
||||
.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h
|
||||
.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
|
||||
.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
|
||||
|
||||
HuC
|
||||
---
|
||||
.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_huc.c
|
||||
|
||||
122
Documentation/gpu/rfc/i915_parallel_execbuf.h
Normal file
122
Documentation/gpu/rfc/i915_parallel_execbuf.h
Normal file
@@ -0,0 +1,122 @@
|
||||
/* SPDX-License-Identifier: MIT */
|
||||
/*
|
||||
* Copyright © 2021 Intel Corporation
|
||||
*/
|
||||
|
||||
#define I915_CONTEXT_ENGINES_EXT_PARALLEL_SUBMIT 2 /* see i915_context_engines_parallel_submit */
|
||||
|
||||
/**
|
||||
* struct drm_i915_context_engines_parallel_submit - Configure engine for
|
||||
* parallel submission.
|
||||
*
|
||||
* Setup a slot in the context engine map to allow multiple BBs to be submitted
|
||||
* in a single execbuf IOCTL. Those BBs will then be scheduled to run on the GPU
|
||||
* in parallel. Multiple hardware contexts are created internally in the i915
|
||||
* run these BBs. Once a slot is configured for N BBs only N BBs can be
|
||||
* submitted in each execbuf IOCTL and this is implicit behavior e.g. The user
|
||||
* doesn't tell the execbuf IOCTL there are N BBs, the execbuf IOCTL knows how
|
||||
* many BBs there are based on the slot's configuration. The N BBs are the last
|
||||
* N buffer objects or first N if I915_EXEC_BATCH_FIRST is set.
|
||||
*
|
||||
* The default placement behavior is to create implicit bonds between each
|
||||
* context if each context maps to more than 1 physical engine (e.g. context is
|
||||
* a virtual engine). Also we only allow contexts of same engine class and these
|
||||
* contexts must be in logically contiguous order. Examples of the placement
|
||||
* behavior described below. Lastly, the default is to not allow BBs to
|
||||
* preempted mid BB rather insert coordinated preemption on all hardware
|
||||
* contexts between each set of BBs. Flags may be added in the future to change
|
||||
* both of these default behaviors.
|
||||
*
|
||||
* Returns -EINVAL if hardware context placement configuration is invalid or if
|
||||
* the placement configuration isn't supported on the platform / submission
|
||||
* interface.
|
||||
* Returns -ENODEV if extension isn't supported on the platform / submission
|
||||
* interface.
|
||||
*
|
||||
* .. code-block:: none
|
||||
*
|
||||
* Example 1 pseudo code:
|
||||
* CS[X] = generic engine of same class, logical instance X
|
||||
* INVALID = I915_ENGINE_CLASS_INVALID, I915_ENGINE_CLASS_INVALID_NONE
|
||||
* set_engines(INVALID)
|
||||
* set_parallel(engine_index=0, width=2, num_siblings=1,
|
||||
* engines=CS[0],CS[1])
|
||||
*
|
||||
* Results in the following valid placement:
|
||||
* CS[0], CS[1]
|
||||
*
|
||||
* Example 2 pseudo code:
|
||||
* CS[X] = generic engine of same class, logical instance X
|
||||
* INVALID = I915_ENGINE_CLASS_INVALID, I915_ENGINE_CLASS_INVALID_NONE
|
||||
* set_engines(INVALID)
|
||||
* set_parallel(engine_index=0, width=2, num_siblings=2,
|
||||
* engines=CS[0],CS[2],CS[1],CS[3])
|
||||
*
|
||||
* Results in the following valid placements:
|
||||
* CS[0], CS[1]
|
||||
* CS[2], CS[3]
|
||||
*
|
||||
* This can also be thought of as 2 virtual engines described by 2-D array
|
||||
* in the engines the field with bonds placed between each index of the
|
||||
* virtual engines. e.g. CS[0] is bonded to CS[1], CS[2] is bonded to
|
||||
* CS[3].
|
||||
* VE[0] = CS[0], CS[2]
|
||||
* VE[1] = CS[1], CS[3]
|
||||
*
|
||||
* Example 3 pseudo code:
|
||||
* CS[X] = generic engine of same class, logical instance X
|
||||
* INVALID = I915_ENGINE_CLASS_INVALID, I915_ENGINE_CLASS_INVALID_NONE
|
||||
* set_engines(INVALID)
|
||||
* set_parallel(engine_index=0, width=2, num_siblings=2,
|
||||
* engines=CS[0],CS[1],CS[1],CS[3])
|
||||
*
|
||||
* Results in the following valid and invalid placements:
|
||||
* CS[0], CS[1]
|
||||
* CS[1], CS[3] - Not logical contiguous, return -EINVAL
|
||||
*/
|
||||
struct drm_i915_context_engines_parallel_submit {
|
||||
/**
|
||||
* @base: base user extension.
|
||||
*/
|
||||
struct i915_user_extension base;
|
||||
|
||||
/**
|
||||
* @engine_index: slot for parallel engine
|
||||
*/
|
||||
__u16 engine_index;
|
||||
|
||||
/**
|
||||
* @width: number of contexts per parallel engine
|
||||
*/
|
||||
__u16 width;
|
||||
|
||||
/**
|
||||
* @num_siblings: number of siblings per context
|
||||
*/
|
||||
__u16 num_siblings;
|
||||
|
||||
/**
|
||||
* @mbz16: reserved for future use; must be zero
|
||||
*/
|
||||
__u16 mbz16;
|
||||
|
||||
/**
|
||||
* @flags: all undefined flags must be zero, currently not defined flags
|
||||
*/
|
||||
__u64 flags;
|
||||
|
||||
/**
|
||||
* @mbz64: reserved for future use; must be zero
|
||||
*/
|
||||
__u64 mbz64[3];
|
||||
|
||||
/**
|
||||
* @engines: 2-d array of engine instances to configure parallel engine
|
||||
*
|
||||
* length = width (i) * num_siblings (j)
|
||||
* index = j + i * num_siblings
|
||||
*/
|
||||
struct i915_engine_class_instance engines[0];
|
||||
|
||||
} __packed;
|
||||
|
||||
148
Documentation/gpu/rfc/i915_scheduler.rst
Normal file
148
Documentation/gpu/rfc/i915_scheduler.rst
Normal file
@@ -0,0 +1,148 @@
|
||||
=========================================
|
||||
I915 GuC Submission/DRM Scheduler Section
|
||||
=========================================
|
||||
|
||||
Upstream plan
|
||||
=============
|
||||
For upstream the overall plan for landing GuC submission and integrating the
|
||||
i915 with the DRM scheduler is:
|
||||
|
||||
* Merge basic GuC submission
|
||||
* Basic submission support for all gen11+ platforms
|
||||
* Not enabled by default on any current platforms but can be enabled via
|
||||
modparam enable_guc
|
||||
* Lots of rework will need to be done to integrate with DRM scheduler so
|
||||
no need to nit pick everything in the code, it just should be
|
||||
functional, no major coding style / layering errors, and not regress
|
||||
execlists
|
||||
* Update IGTs / selftests as needed to work with GuC submission
|
||||
* Enable CI on supported platforms for a baseline
|
||||
* Rework / get CI heathly for GuC submission in place as needed
|
||||
* Merge new parallel submission uAPI
|
||||
* Bonding uAPI completely incompatible with GuC submission, plus it has
|
||||
severe design issues in general, which is why we want to retire it no
|
||||
matter what
|
||||
* New uAPI adds I915_CONTEXT_ENGINES_EXT_PARALLEL context setup step
|
||||
which configures a slot with N contexts
|
||||
* After I915_CONTEXT_ENGINES_EXT_PARALLEL a user can submit N batches to
|
||||
a slot in a single execbuf IOCTL and the batches run on the GPU in
|
||||
paralllel
|
||||
* Initially only for GuC submission but execlists can be supported if
|
||||
needed
|
||||
* Convert the i915 to use the DRM scheduler
|
||||
* GuC submission backend fully integrated with DRM scheduler
|
||||
* All request queues removed from backend (e.g. all backpressure
|
||||
handled in DRM scheduler)
|
||||
* Resets / cancels hook in DRM scheduler
|
||||
* Watchdog hooks into DRM scheduler
|
||||
* Lots of complexity of the GuC backend can be pulled out once
|
||||
integrated with DRM scheduler (e.g. state machine gets
|
||||
simplier, locking gets simplier, etc...)
|
||||
* Execlists backend will minimum required to hook in the DRM scheduler
|
||||
* Legacy interface
|
||||
* Features like timeslicing / preemption / virtual engines would
|
||||
be difficult to integrate with the DRM scheduler and these
|
||||
features are not required for GuC submission as the GuC does
|
||||
these things for us
|
||||
* ROI low on fully integrating into DRM scheduler
|
||||
* Fully integrating would add lots of complexity to DRM
|
||||
scheduler
|
||||
* Port i915 priority inheritance / boosting feature in DRM scheduler
|
||||
* Used for i915 page flip, may be useful to other DRM drivers as
|
||||
well
|
||||
* Will be an optional feature in the DRM scheduler
|
||||
* Remove in-order completion assumptions from DRM scheduler
|
||||
* Even when using the DRM scheduler the backends will handle
|
||||
preemption, timeslicing, etc... so it is possible for jobs to
|
||||
finish out of order
|
||||
* Pull out i915 priority levels and use DRM priority levels
|
||||
* Optimize DRM scheduler as needed
|
||||
|
||||
TODOs for GuC submission upstream
|
||||
=================================
|
||||
|
||||
* Need an update to GuC firmware / i915 to enable error state capture
|
||||
* Open source tool to decode GuC logs
|
||||
* Public GuC spec
|
||||
|
||||
New uAPI for basic GuC submission
|
||||
=================================
|
||||
No major changes are required to the uAPI for basic GuC submission. The only
|
||||
change is a new scheduler attribute: I915_SCHEDULER_CAP_STATIC_PRIORITY_MAP.
|
||||
This attribute indicates the 2k i915 user priority levels are statically mapped
|
||||
into 3 levels as follows:
|
||||
|
||||
* -1k to -1 Low priority
|
||||
* 0 Medium priority
|
||||
* 1 to 1k High priority
|
||||
|
||||
This is needed because the GuC only has 4 priority bands. The highest priority
|
||||
band is reserved with the kernel. This aligns with the DRM scheduler priority
|
||||
levels too.
|
||||
|
||||
Spec references:
|
||||
----------------
|
||||
* https://www.khronos.org/registry/EGL/extensions/IMG/EGL_IMG_context_priority.txt
|
||||
* https://www.khronos.org/registry/vulkan/specs/1.2-extensions/html/chap5.html#devsandqueues-priority
|
||||
* https://spec.oneapi.com/level-zero/latest/core/api.html#ze-command-queue-priority-t
|
||||
|
||||
New parallel submission uAPI
|
||||
============================
|
||||
The existing bonding uAPI is completely broken with GuC submission because
|
||||
whether a submission is a single context submit or parallel submit isn't known
|
||||
until execbuf time activated via the I915_SUBMIT_FENCE. To submit multiple
|
||||
contexts in parallel with the GuC the context must be explicitly registered with
|
||||
N contexts and all N contexts must be submitted in a single command to the GuC.
|
||||
The GuC interfaces do not support dynamically changing between N contexts as the
|
||||
bonding uAPI does. Hence the need for a new parallel submission interface. Also
|
||||
the legacy bonding uAPI is quite confusing and not intuitive at all. Furthermore
|
||||
I915_SUBMIT_FENCE is by design a future fence, so not really something we should
|
||||
continue to support.
|
||||
|
||||
The new parallel submission uAPI consists of 3 parts:
|
||||
|
||||
* Export engines logical mapping
|
||||
* A 'set_parallel' extension to configure contexts for parallel
|
||||
submission
|
||||
* Extend execbuf2 IOCTL to support submitting N BBs in a single IOCTL
|
||||
|
||||
Export engines logical mapping
|
||||
------------------------------
|
||||
Certain use cases require BBs to be placed on engine instances in logical order
|
||||
(e.g. split-frame on gen11+). The logical mapping of engine instances can change
|
||||
based on fusing. Rather than making UMDs be aware of fusing, simply expose the
|
||||
logical mapping with the existing query engine info IOCTL. Also the GuC
|
||||
submission interface currently only supports submitting multiple contexts to
|
||||
engines in logical order which is a new requirement compared to execlists.
|
||||
Lastly, all current platforms have at most 2 engine instances and the logical
|
||||
order is the same as uAPI order. This will change on platforms with more than 2
|
||||
engine instances.
|
||||
|
||||
A single bit will be added to drm_i915_engine_info.flags indicating that the
|
||||
logical instance has been returned and a new field,
|
||||
drm_i915_engine_info.logical_instance, returns the logical instance.
|
||||
|
||||
A 'set_parallel' extension to configure contexts for parallel submission
|
||||
------------------------------------------------------------------------
|
||||
The 'set_parallel' extension configures a slot for parallel submission of N BBs.
|
||||
It is a setup step that must be called before using any of the contexts. See
|
||||
I915_CONTEXT_ENGINES_EXT_LOAD_BALANCE or I915_CONTEXT_ENGINES_EXT_BOND for
|
||||
similar existing examples. Once a slot is configured for parallel submission the
|
||||
execbuf2 IOCTL can be called submitting N BBs in a single IOCTL. Initially only
|
||||
supports GuC submission. Execlists supports can be added later if needed.
|
||||
|
||||
Add I915_CONTEXT_ENGINES_EXT_PARALLEL_SUBMIT and
|
||||
drm_i915_context_engines_parallel_submit to the uAPI to implement this
|
||||
extension.
|
||||
|
||||
.. kernel-doc:: Documentation/gpu/rfc/i915_parallel_execbuf.h
|
||||
:functions: drm_i915_context_engines_parallel_submit
|
||||
|
||||
Extend execbuf2 IOCTL to support submitting N BBs in a single IOCTL
|
||||
-------------------------------------------------------------------
|
||||
Contexts that have been configured with the 'set_parallel' extension can only
|
||||
submit N BBs in a single execbuf2 IOCTL. The BBs are either the last N objects
|
||||
in the drm_i915_gem_exec_object2 list or the first N if I915_EXEC_BATCH_FIRST is
|
||||
set. The number of BBs is implicit based on the slot submitted and how it has
|
||||
been configured by 'set_parallel' or other extensions. No uAPI changes are
|
||||
required to the execbuf2 IOCTL.
|
||||
@@ -19,3 +19,7 @@ host such documentation:
|
||||
.. toctree::
|
||||
|
||||
i915_gem_lmem.rst
|
||||
|
||||
.. toctree::
|
||||
|
||||
i915_scheduler.rst
|
||||
|
||||
@@ -98,9 +98,17 @@ with VKMS maintainers.
|
||||
IGT better support
|
||||
------------------
|
||||
|
||||
- Investigate: (1) test cases on kms_plane that are failing due to timeout on
|
||||
capturing CRC; (2) when running kms_flip test cases in sequence, some
|
||||
successful individual test cases are failing randomly.
|
||||
Debugging:
|
||||
|
||||
- kms_plane: some test cases are failing due to timeout on capturing CRC;
|
||||
|
||||
- kms_flip: when running test cases in sequence, some successful individual
|
||||
test cases are failing randomly; when individually, some successful test
|
||||
cases display in the log the following error::
|
||||
|
||||
[drm:vkms_prepare_fb [vkms]] ERROR vmap failed: -4
|
||||
|
||||
Virtual hardware (vblank-less) mode:
|
||||
|
||||
- VKMS already has support for vblanks simulated via hrtimers, which can be
|
||||
tested with kms_flip test; in some way, we can say that VKMS already mimics
|
||||
@@ -116,7 +124,17 @@ Add Plane Features
|
||||
|
||||
There's lots of plane features we could add support for:
|
||||
|
||||
- Real overlay planes, not just cursor.
|
||||
- Multiple overlay planes. [Good to get started]
|
||||
|
||||
- Clearing primary plane: clear primary plane before plane composition (at the
|
||||
start) for correctness of pixel blend ops. It also guarantees alpha channel
|
||||
is cleared in the target buffer for stable crc. [Good to get started]
|
||||
|
||||
- ARGB format on primary plane: blend the primary plane into background with
|
||||
translucent alpha.
|
||||
|
||||
- Support when the primary plane isn't exactly matching the output size: blend
|
||||
the primary plane into the black background.
|
||||
|
||||
- Full alpha blending on all planes.
|
||||
|
||||
@@ -129,13 +147,8 @@ There's lots of plane features we could add support for:
|
||||
cursor api).
|
||||
|
||||
For all of these, we also want to review the igt test coverage and make sure
|
||||
all relevant igt testcases work on vkms.
|
||||
|
||||
Prime Buffer Sharing
|
||||
--------------------
|
||||
|
||||
- Syzbot report - WARNING in vkms_gem_free_object:
|
||||
https://syzkaller.appspot.com/bug?extid=e7ad70d406e74d8fc9d0
|
||||
all relevant igt testcases work on vkms. They are good options for internship
|
||||
project.
|
||||
|
||||
Runtime Configuration
|
||||
---------------------
|
||||
@@ -153,7 +166,7 @@ module. Use/Test-cases:
|
||||
the refresh rate.
|
||||
|
||||
The currently proposed solution is to expose vkms configuration through
|
||||
configfs. All existing module options should be supported through configfs
|
||||
configfs. All existing module options should be supported through configfs
|
||||
too.
|
||||
|
||||
Writeback support
|
||||
@@ -162,6 +175,7 @@ Writeback support
|
||||
- The writeback and CRC capture operations share the use of composer_enabled
|
||||
boolean to ensure vblanks. Probably, when these operations work together,
|
||||
composer_enabled needs to refcounting the composer state to proper work.
|
||||
[Good to get started]
|
||||
|
||||
- Add support for cloned writeback outputs and related test cases using a
|
||||
cloned output in the IGT kms_writeback.
|
||||
|
||||
Reference in New Issue
Block a user