On Thu, 14 Oct 2021, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We don't have hpd support on i8xx/i915 which means hotplug_funcs==NULL.
> Let's not oops when loading the driver on one those machines.
D'oh!
Lemme guess, CI just casually dropped the machines from the results
because they
On Thu, Oct 14, 2021 at 01:28:56PM +0300, Jani Nikula wrote:
> Split out the sbi and pcode code to separate files.
>
> There's potential for follow-up work that's not included here:
>
> - vlv_sideband, intel_sbi and intel_pcode all use
> i915->sb_lock. Technically it's fine, but the appearance
On 13/10/2021 17:17, Daniel Vetter wrote:
On Wed, Oct 13, 2021 at 04:37:03PM +0100, Tvrtko Ursulin wrote:
On 13/10/2021 15:00, Daniel Vetter wrote:
On Wed, Oct 13, 2021 at 02:32:03PM +0200, Maarten Lankhorst wrote:
No memory should be allocated when calling i915_gem_object_wait,
because it
On 13/10/2021 23:43, john.c.harri...@intel.com wrote:
From: John Harrison
The gem_exec_fair test is specifically testing scheduler algorithm
performance. However, GuC does not implement the same algorithm as
execlist mode and this test is not applicable. So, until sw arch
approves a new
On Thu, 14 Oct 2021, Ville Syrjälä wrote:
> On Tue, Oct 12, 2021 at 05:43:20PM +0300, Jani Nikula wrote:
>> The link training delays are different and/or available in different
>> DPCD offsets depending on:
>>
>> - Clock recovery vs. channel equalization
>> - DPRX vs. LTTPR
>> - 128b/132b vs.
On Thu, Oct 14, 2021 at 12:18:23PM +0300, Jani Nikula wrote:
> On Thu, 14 Oct 2021, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > We don't have hpd support on i8xx/i915 which means hotplug_funcs==NULL.
> > Let's not oops when loading the driver on one those machines.
>
> D'oh!
>
> Lemme
On Wed, Oct 13, 2021 at 11:40:11PM +0300, Ville Syrjälä wrote:
> On Fri, Oct 08, 2021 at 03:19:08AM +0300, Imre Deak wrote:
> > bool is_ccs_plane(const struct drm_framebuffer *fb, int plane);
> > bool is_gen12_ccs_plane(const struct drm_framebuffer *fb, int plane);
> > bool
== Series Details ==
Series: drm/i915: Make the driver not oops on load on old machines
URL : https://patchwork.freedesktop.org/series/95815/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10732 -> Patchwork_21336
Summary
CONFIG_INTEL_MEI_PXP:
MEI Support for PXP Services on Intel platforms.
Enables the ME FW services required for PXP support through
I915 display driver of Intel.
That's ... very useless help text. According to
https://www.phoronix.com/scan.php?page=news_item=Intel-PXP-Protected-Xe-Path
this is
== Series Details ==
Series: drm/i915: Make the driver not oops on load on old machines
URL : https://patchwork.freedesktop.org/series/95815/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10732_full -> Patchwork_21336_full
Hi, Dave,
On 10/14/21 03:50, Dave Airlie wrote:
On Fri, 8 Oct 2021 at 23:36, Thomas Hellström
wrote:
This patch series introduces failsafe migration blits.
The reason for this seemingly strange concept is that if the initial
clearing or readback of LMEM fails for some reason, and we then set
From: Ville Syrjälä
Fix a pile of regression on older machines which just oops the driver
on load.
Cc: Dave Airlie
Cc: Jani Nikula
Cc: Maarten Lankhorst
Cc: Thomas Hellström
Cc: Chris Wilson
Cc: Mika Kuoppala
Ville Syrjälä (4):
drm/i915: Replace the unconditional clflush with
From: Ville Syrjälä
Not all machines have clflush, so don't go assuming they do.
Not really sure why the clflush is even here since hwsp
is supposed to get snooped I thought.
Although in my case we're talking about a i830 machine where
render/blitter snooping is definitely busted. But it might
From: Ville Syrjälä
This one is apparently a "clflush for good measure", so bit more
justification (if you can call it that) than some of the others.
Convert to drm_clflush_virt_range() again so that machines without
clflush will survive the ordeal.
Cc: sta...@vger.kernel.org
Cc: Maarten
From: Ville Syrjälä
We don't have hpd support on i8xx/i915 which means hotplug_funcs==NULL.
Let's not oops when loading the driver on one those machines.
Cc: Dave Airlie
Cc: Jani Nikula
Fixes: cd030c7c11a4 ("drm/i915: constify hotplug function vtable.")
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
Replace the unconditional clflush() with drm_clflush_virt_range()
which does the wbinvd() fallback when clflush is not available.
This time no justification is given for the clflush in the
offending commit.
Cc: sta...@vger.kernel.org
Cc: Maarten Lankhorst
Cc: Thomas
> From: Ville Syrjälä
> On Thu, Oct 14, 2021 at 09:31:40AM +, Sarvela, Tomi P wrote:
> > > From: Ville Syrjälä
> > > On Thu, Oct 14, 2021 at 12:18:23PM +0300, Jani Nikula wrote:
> > > > On Thu, 14 Oct 2021, Ville Syrjala
> > > > wrote:
> > > > > From: Ville Syrjälä
> > > > >
> > > > > We
== Series Details ==
Series: drm/i915: intel sbi/pcode cleanup
URL : https://patchwork.freedesktop.org/series/95818/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10733 -> Patchwork_21337
Summary
---
**SUCCESS**
On Thu, Oct 14, 2021 at 12:20:24PM +0300, Jani Nikula wrote:
> On Thu, 14 Oct 2021, Jani Nikula wrote:
> > On Thu, 14 Oct 2021, Ville Syrjala wrote:
> >> From: Ville Syrjälä
> >>
> >> We don't have hpd support on i8xx/i915 which means hotplug_funcs==NULL.
> >> Let's not oops when loading the
== Series Details ==
Series: drm/i915: intel sbi/pcode cleanup
URL : https://patchwork.freedesktop.org/series/95818/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
c1d1988d9662 drm/i915: split out intel_pcode.[ch] to separate file
-:200: WARNING:FILE_PATH_CHANGES: added, moved
On Thu, Oct 14, 2021 at 11:33:03AM +0200, Vlastimil Babka wrote:
> On 10/14/21 10:54, kernel test robot wrote:
> >
> >
> > Greeting,
> >
> > FYI, we noticed the following commit (built with gcc-9):
> >
> > commit: 1cd8ce52c520c26c513899fb5aee42b8e5f60d0d ("[PATCH v2]
> > lib/stackdepot: allow
Hi,
I review the code.
It seems I forget to delete the definition of the variable "inst",I'm sry for
that.: (
I'll submit another patch soon.
> Hi all,> > After merging the drm-misc tree, today's linux-next build (x86_64>
> allmodconfig) failed like this:> >
>
On 10/14/21 10:54, kernel test robot wrote:
>
>
> Greeting,
>
> FYI, we noticed the following commit (built with gcc-9):
>
> commit: 1cd8ce52c520c26c513899fb5aee42b8e5f60d0d ("[PATCH v2] lib/stackdepot:
> allow optional init and stack_table allocation by kvmalloc()")
> url:
>
The snb+ pcode mailbox code is not sideband, so split it out to a
separate file. As can be seen from the #include changes, very few places
use both sideband and pcode.
Code movement only.
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/Makefile | 1 +
Now that intel_sideband.[ch] has been decluttered, it's pure lpt/wpt
iosf sideband. Let's call it intel_sbi, following the function naming.
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/Makefile | 2 +-
drivers/gpu/drm/i915/display/intel_display.c | 2
Split out the sbi and pcode code to separate files.
There's potential for follow-up work that's not included here:
- vlv_sideband, intel_sbi and intel_pcode all use
i915->sb_lock. Technically it's fine, but the appearance is confusing.
- The pcode function naming could use some cleanup.
-
On 10/13/2021 8:49 PM, Imre Deak wrote:
On Thu, Oct 07, 2021 at 01:19:25PM +0530, Nautiyal, Ankit K wrote:
On 10/5/2021 9:01 PM, Imre Deak wrote:
On Tue, Oct 05, 2021 at 01:34:21PM +0300, Jani Nikula wrote:
Cc: Imre, I think you were involved in adding the checks.
About ADL-S the spec
drm-misc-fixes-2021-10-14:
drm-misc-fixes for v5.15-rc6:
- Respun clock fixes for vc4/hdmi.
- Cap connector_bad_edid()'s num_of_ext by num_blocks read.
- Clamp fbdev size to max available height.
- Hide hyper-v's hw pointer, to prevent double pointers.
- Use the correct engine bit in nouveau's
On Thu, Oct 14, 2021 at 05:02:46PM +0530, Nautiyal, Ankit K wrote:
>
> On 10/13/2021 8:49 PM, Imre Deak wrote:
> > On Thu, Oct 07, 2021 at 01:19:25PM +0530, Nautiyal, Ankit K wrote:
> > > On 10/5/2021 9:01 PM, Imre Deak wrote:
> > > > On Tue, Oct 05, 2021 at 01:34:21PM +0300, Jani Nikula wrote:
>
On 13/10/2021 11:41, Maarten Lankhorst wrote:
No memory should be allocated when calling i915_gem_object_wait,
because it may be called to idle a BO when evicting memory.
Fix this by using dma_resv_iter helpers to call
i915_gem_object_wait_fence() on each fence, which cleans up the code a
On Thu, 14 Oct 2021, Jani Nikula wrote:
> On Thu, 14 Oct 2021, Ville Syrjala wrote:
>> From: Ville Syrjälä
>>
>> We don't have hpd support on i8xx/i915 which means hotplug_funcs==NULL.
>> Let's not oops when loading the driver on one those machines.
>
> D'oh!
>
> Lemme guess, CI just casually
> From: Ville Syrjälä
> On Thu, Oct 14, 2021 at 12:18:23PM +0300, Jani Nikula wrote:
> > On Thu, 14 Oct 2021, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > We don't have hpd support on i8xx/i915 which means
> hotplug_funcs==NULL.
> > > Let's not oops when loading the driver on one
On Thu, Oct 14, 2021 at 01:38:14AM +0300, Ville Syrjälä wrote:
> On Thu, Oct 14, 2021 at 01:28:24AM +0300, Imre Deak wrote:
> > On Thu, Oct 14, 2021 at 12:54:58AM +0300, Ville Syrjälä wrote:
> > > On Thu, Oct 14, 2021 at 12:32:55AM +0300, Imre Deak wrote:
> > > > On Wed, Oct 13, 2021 at 11:45:33PM
On 13/10/2021 01:56, Umesh Nerlige Ramappa wrote:
With GuC handling scheduling, i915 is not aware of the time that a
context is scheduled in and out of the engine. Since i915 pmu relies on
this info to provide engine busyness to the user, GuC shares this info
with i915 for all engines using
On Thu, Oct 14, 2021 at 09:31:40AM +, Sarvela, Tomi P wrote:
> > From: Ville Syrjälä
> > On Thu, Oct 14, 2021 at 12:18:23PM +0300, Jani Nikula wrote:
> > > On Thu, 14 Oct 2021, Ville Syrjala wrote:
> > > > From: Ville Syrjälä
> > > >
> > > > We don't have hpd support on i8xx/i915 which
On 10/13/2021 9:05 PM, Jani Nikula wrote:
On Wed, 13 Oct 2021, Imre Deak wrote:
On Thu, Oct 07, 2021 at 01:19:25PM +0530, Nautiyal, Ankit K wrote:
On 10/5/2021 9:01 PM, Imre Deak wrote:
On Tue, Oct 05, 2021 at 01:34:21PM +0300, Jani Nikula wrote:
Cc: Imre, I think you were involved in
Hi Dave, Daniel,
Here's this week drm-misc-next PR
Maxime
drm-misc-next-2021-10-14:
drm-misc-next for 5.16:
UAPI Changes:
Cross-subsystem Changes:
Core Changes:
- fbdev: Fix double-free, Remove unused scrolling acceleration
- locking: improve logging for contented locks without backoff
Op 14-10-2021 om 10:37 schreef Tvrtko Ursulin:
>
> On 13/10/2021 11:41, Maarten Lankhorst wrote:
>> No memory should be allocated when calling i915_gem_object_wait,
>> because it may be called to idle a BO when evicting memory.
>>
>> Fix this by using dma_resv_iter helpers to call
>>
Op 05-10-2021 om 13:37 schreef Christian König:
> Simplifying the code a bit.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/i915/gem/i915_gem_wait.c | 51 +---
> 1 file changed, 9 insertions(+), 42 deletions(-)
>
> diff --git
On Thu, 14 Oct 2021, Jani Nikula wrote:
> On Thu, 07 Oct 2021, Imre Deak wrote:
>> +} intel_modifiers[] = {
>> +{
>> +.id = DRM_FORMAT_MOD_LINEAR,
>> +.display_versions = DISPLAY_VER_MASK_ALL,
>
> What is this going to look like when display version mask isn't fine
>
On 14/10/2021 13:05, Maarten Lankhorst wrote:
Op 14-10-2021 om 10:37 schreef Tvrtko Ursulin:
On 13/10/2021 11:41, Maarten Lankhorst wrote:
No memory should be allocated when calling i915_gem_object_wait,
because it may be called to idle a BO when evicting memory.
Fix this by using
On Thu, Oct 14, 2021 at 01:28:56PM +0300, Jani Nikula wrote:
Split out the sbi and pcode code to separate files.
There's potential for follow-up work that's not included here:
- vlv_sideband, intel_sbi and intel_pcode all use
i915->sb_lock. Technically it's fine, but the appearance is
On Wed, Oct 13, 2021 at 06:02:42PM -0700, John Harrison wrote:
> On 10/13/2021 13:42, Matthew Brost wrote:
> > Introduce 'set parallel submit' extension to connect UAPI to GuC
> > multi-lrc interface. Kernel doc in new uAPI should explain it all.
> >
> > IGT:
On Wed, Oct 13, 2021 at 11:00:35PM +0200, Fernando Ramos wrote:
> On 21/10/13 03:06PM, Ville Syrjälä wrote:
> > > And yes C is dangerous, but also C is verbose. I think one lesson from igt
> > > is that too many magic block constructs are bad, it's just not how C
> > > works. Definitely not in the
On Tue, 05 Oct 2021, "Souza, Jose" wrote:
> On Tue, 2021-10-05 at 23:38 +0300, Jani Nikula wrote:
>> On Tue, 05 Oct 2021, "Souza, Jose" wrote:
>> > On Tue, 2021-10-05 at 20:56 +0300, Jani Nikula wrote:
>> > > For the time being, neither the power sequencer nor the backlight code
>> > > properly
On 2021-10-14 15:21:22 [+0200], Daniel Vetter wrote:
> On Wed, Oct 13, 2021 at 07:35:48PM +0200, Sebastian Andrzej Siewior wrote:
> > c7fcbf2513973 -> does not boot
> > c7fcbf2513973 + 2f425cf5242a0 -> boots, 18 x DRM_OBJECT_MAX_PROPERTY
> > 6f11f37459d8f -> boots, 0 x DRM_OBJECT_MAX_PROPERTY
> >
Hi,
On 10/14/21 3:24 PM, Hans de Goede wrote:
> Hi,
>
> On 10/14/21 2:04 PM, Maxime Ripard wrote:
>> Hi Dave, Daniel,
>>
>> Here's this week drm-misc-next PR
>>
>> Maxime
>>
>> drm-misc-next-2021-10-14:
>> drm-misc-next for 5.16:
>
> Ugh, this just missed the drm-privacy-screen work which I
Hi,
On 10/14/21 2:04 PM, Maxime Ripard wrote:
> Hi Dave, Daniel,
>
> Here's this week drm-misc-next PR
>
> Maxime
>
> drm-misc-next-2021-10-14:
> drm-misc-next for 5.16:
Ugh, this just missed the drm-privacy-screen work which I just pushed
out to drm-misc-next (I was waiting for the last i915
On Thu, 07 Oct 2021, Imre Deak wrote:
> Add a table describing all the framebuffer modifiers used by i915 at one
> place. This has the benefit of deduplicating the listing of supported
> modifiers for each platform and checking the support of these modifiers
> on a given plane. This also
== Series Details ==
Series: drm/i915: intel sbi/pcode cleanup
URL : https://patchwork.freedesktop.org/series/95818/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10733_full -> Patchwork_21337_full
Summary
---
On Thu, Oct 14, 2021 at 06:00:58PM +0300, Jani Nikula wrote:
> Reuse the 8b/10b link training delay helpers. Functionally this skips
> the check for invalid values for DPCD 1.4 and later at clock recovery
> delay (as it's a fixed delay and bypasses the rd_interval) but the same
> value will be
On Thu, 14 Oct 2021, Imre Deak wrote:
> On Thu, Oct 14, 2021 at 05:07:16PM +0300, Jani Nikula wrote:
>> On Thu, 07 Oct 2021, Imre Deak wrote:
>> > Add a table describing all the framebuffer modifiers used by i915 at one
>> > place. This has the benefit of deduplicating the listing of supported
On 14/10/2021 14:33, Daniel Vetter wrote:
On Wed, Oct 13, 2021 at 03:13:33PM +0100, Matthew Auld wrote:
On 13/10/2021 14:38, Daniel Vetter wrote:
On Mon, Oct 11, 2021 at 09:41:44PM +0530, Ramalingam C wrote:
From: Matthew Auld
For local-memory objects we need to align the GTT addresses to
On Wed, Oct 13, 2021 at 03:13:33PM +0100, Matthew Auld wrote:
> On 13/10/2021 14:38, Daniel Vetter wrote:
> > On Mon, Oct 11, 2021 at 09:41:44PM +0530, Ramalingam C wrote:
> > > From: Matthew Auld
> > >
> > > For local-memory objects we need to align the GTT addresses to 64K, both
> > > for the
Hi Dave & Daniel -
drm-intel-fixes-2021-10-14:
drm/i915 fixes for v5.15-rc6:
- Fix ACPI object leak
- Fix context leak in user proto-context creation
- Fix missing i915_sw_fence_fini call
BR,
Jani.
The following changes since commit 64570fbc14f8d7cb3fe3995f20e26bc25ce4b2cc:
Linux 5.15-rc5
Reuse the 8b/10b link training delay helpers. Functionally this skips
the check for invalid values for DPCD 1.4 and later at clock recovery
delay (as it's a fixed delay and bypasses the rd_interval) but the same
value will be checked and invalid values reported at channel
equalization.
The link training delays are different and/or available in different
DPCD offsets depending on:
- Clock recovery vs. channel equalization
- DPRX vs. LTTPR
- 128b/132b vs. 8b/10b
- DPCD 1.4+ vs. earlier
Add helpers to get the correct delays in us, reading DPCD if
necessary. This is more
Use the new link training delay helpers, fixing the delays for
128b/132b.
For existing 8b/10b functionality, this will cause additional 1-byte
DPCD reads for LTTPR delays instead of using the cached values. It's
just too complicated to combine generic helpers with local caching in a
sensible way.
On Wed, Oct 13, 2021 at 07:35:48PM +0200, Sebastian Andrzej Siewior wrote:
> On 2021-10-13 14:57:34 [+0200], Daniel Vetter wrote:
> > Hm there's a pile of commits there, and nothing immediately jumps to
> > light. The thing is, 18 is likely way too much, since if e.g. we have a
> > single new
Op 14-10-2021 om 15:25 schreef Tvrtko Ursulin:
>
> On 14/10/2021 13:05, Maarten Lankhorst wrote:
>> Op 14-10-2021 om 10:37 schreef Tvrtko Ursulin:
>>>
>>> On 13/10/2021 11:41, Maarten Lankhorst wrote:
No memory should be allocated when calling i915_gem_object_wait,
because it may be
On 14/10/2021 14:45, Maarten Lankhorst wrote:
Op 14-10-2021 om 15:25 schreef Tvrtko Ursulin:
On 14/10/2021 13:05, Maarten Lankhorst wrote:
Op 14-10-2021 om 10:37 schreef Tvrtko Ursulin:
On 13/10/2021 11:41, Maarten Lankhorst wrote:
No memory should be allocated when calling
On Thu, Oct 14, 2021 at 05:07:16PM +0300, Jani Nikula wrote:
> On Thu, 07 Oct 2021, Imre Deak wrote:
> > Add a table describing all the framebuffer modifiers used by i915 at one
> > place. This has the benefit of deduplicating the listing of supported
> > modifiers for each platform and checking
On Wed, Oct 13, 2021 at 05:55:51PM -0700, John Harrison wrote:
> On 10/13/2021 13:42, Matthew Brost wrote:
> > Allow multiple batch buffers to be submitted in a single execbuf IOCTL
> > after a context has been configured with the 'set_parallel' extension.
> > The number batches is implicit based
patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Matthew-Brost/Parallel-submission-aka-multi-bb-execbuf/20211014-050217
On 10/13/2021 13:42, Matthew Brost wrote:
Parallel contexts are perma-pinned by the upper layers which makes the
backend implementation rather simple. The parent pins the guc_id and
children increment the parent's pin count on pin to ensure all the
contexts are unpinned before we disable
On 10/14/2021 09:41, Matthew Brost wrote:
On Thu, Oct 14, 2021 at 09:43:36AM -0700, John Harrison wrote:
On 10/14/2021 08:32, Matthew Brost wrote:
On Wed, Oct 13, 2021 at 06:02:42PM -0700, John Harrison wrote:
On 10/13/2021 13:42, Matthew Brost wrote:
Introduce 'set parallel submit'
In GuC parent-child contexts the parent context controls the scheduling,
ensure only the parent does the scheduling operations.
Signed-off-by: Matthew Brost
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 13 -
1 file changed, 12 insertions(+), 1
The GuC must receive requests in the order submitted for contexts in a
parent-child relationship to function correctly. To ensure this, insert
a submit fence between the current request and last request submitted
for requests / contexts in a parent child relationship. This is
conceptually similar
Update context and full GPU reset to work with multi-lrc. The idea is
parent context tracks all the active requests inflight for itself and
its children. The parent context owns the reset replaying / canceling
requests as needed.
v2:
(John Harrison)
- Simply loop in find active request
- Add
Add very basic (single submission) multi-lrc selftest.
Signed-off-by: Matthew Brost
Reviewed-by: John Harrison
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 1 +
.../drm/i915/gt/uc/selftest_guc_multi_lrc.c | 179 ++
.../drm/i915/selftests/i915_live_selftests.h | 1
Calling switch_to_kernel_context isn't needed if the engine PM reference
is taken while all user contexts are pinned as if don't have PM ref that
guarantees that all user contexts scheduling is disabled. By not calling
switch_to_kernel_context we save on issuing a request to the engine.
v2:
Implement multi-lrc submission via a single workqueue entry and single
H2G. The workqueue entry contains an updated tail value for each
request, of all the contexts in the multi-lrc submission, and updates
these values simultaneously. As such, the tasklet and bypass path have
been updated to
Introduce 'set parallel submit' extension to connect UAPI to GuC
multi-lrc interface. Kernel doc in new uAPI should explain it all.
IGT: https://patchwork.freedesktop.org/patch/447008/?series=93071=1
media UMD: https://github.com/intel/media-driver/pull/1252
v2:
(Daniel Vetter)
- Add IGT link
On 10/14/2021 10:19, Matthew Brost wrote:
Add multi-lrc context registration H2G. In addition a workqueue and
process descriptor are setup during multi-lrc context registration as
these data structures are needed for multi-lrc submission.
v2:
(John Harrison)
- Move GuC specific fields into
From: Ville Syrjälä
Turns out the DSB has trouble correctly loading the gamma LUT.
>From a cursory look maybe like some entries do not load
properly, or they get loaded with some gibberish. Unfortunately
our current kms_color/etc. tests do not seem to catch this.
I had a brief look at the
On Thu, Oct 14, 2021 at 11:42:41AM -0700, John Harrison wrote:
> On 10/14/2021 10:20, Matthew Brost wrote:
> > A weak implementation of parallel submission (multi-bb execbuf IOCTL) for
> > execlists. Doing as little as possible to support this interface for
> > execlists - basically just passing
On 10/14/2021 08:32, Matthew Brost wrote:
On Wed, Oct 13, 2021 at 06:02:42PM -0700, John Harrison wrote:
On 10/13/2021 13:42, Matthew Brost wrote:
Introduce 'set parallel submit' extension to connect UAPI to GuC
multi-lrc interface. Kernel doc in new uAPI should explain it all.
IGT:
Add logical engine mapping. This is required for split-frame, as
workloads need to be placed on engines in a logically contiguous manner.
v2:
(Daniel Vetter)
- Add kernel doc for new fields
v3:
(Tvrtko)
- Update comment for new logical_mask field
v4:
(John Harrison)
- Update comment for
Expose logical engine instance to user via query engine info IOCTL. This
is required for split-frame workloads as these needs to be placed on
engines in a logically contiguous order. The logical mapping can change
based on fusing. Rather than having user have knowledge of the fusing we
simply just
From: Ville Syrjälä
All interpolated gamma modes including the icl+ multi segment
mode require non-decreasing entries for the interpolation to
work correctly. For some reason we're forgetting to declare
that for icl+. Let us do so.
References:
On 10/14/2021 10:20, Matthew Brost wrote:
Allow multiple batch buffers to be submitted in a single execbuf IOCTL
after a context has been configured with the 'set_parallel' extension.
The number batches is implicit based on the contexts configuration.
This is implemented with a series of loops.
On 10/14/2021 10:20, Matthew Brost wrote:
Enable multi-bb execbuf by enabling the set_parallel extension.
Signed-off-by: Matthew Brost
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 3 ---
1 file changed, 3 deletions(-)
diff --git
Taking a PM reference to prevent intel_gt_wait_for_idle from short
circuiting while a deregister context H2G is in flight. To do this must
issue the deregister H2G from a worker as context can be destroyed from
an atomic context and taking GT PM ref blows up. Previously we took a
runtime PM from
Taking a PM reference to prevent intel_gt_wait_for_idle from short
circuiting while any user context has scheduling enabled. Returning GT
idle when it is not can cause all sorts of issues throughout the stack.
v2:
(Daniel Vetter)
- Add might_lock annotations to pin / unpin function
v3:
(CI)
As discussed in [1] we are introducing a new parallel submission uAPI
for the i915 which allows more than 1 BB to be submitted in an execbuf
IOCTL. This is the implemenation for both GuC and execlists.
In addition to selftests in the series, an IGT is available implemented
in the first 4 patches
Move guc_id allocation under submission state sub-struct as a future
patch will reuse the spin lock as a global submission state lock. Moving
this into sub-struct makes ownership of fields / lock clear.
v2:
(Docs)
- Add comment for submission_state sub-structure
v3:
(John Harrison)
- Fixup
On 10/14/2021 10:20, Matthew Brost wrote:
A weak implementation of parallel submission (multi-bb execbuf IOCTL) for
execlists. Doing as little as possible to support this interface for
execlists - basically just passing submit fences between each request
generated and virtual engines are not
From: John Harrison
The gem_exec_fair test is specifically testing scheduler algorithm
performance. However, GuC does not implement the same algorithm as
execlist mode and this test is not applicable. So, until sw arch
approves a new algorithm and it is implemented in GuC, stop running
the test.
On Thu, Oct 14, 2021 at 09:43:36AM -0700, John Harrison wrote:
> On 10/14/2021 08:32, Matthew Brost wrote:
> > On Wed, Oct 13, 2021 at 06:02:42PM -0700, John Harrison wrote:
> > > On 10/13/2021 13:42, Matthew Brost wrote:
> > > > Introduce 'set parallel submit' extension to connect UAPI to GuC
> >
Add multi-lrc context registration H2G. In addition a workqueue and
process descriptor are setup during multi-lrc context registration as
these data structures are needed for multi-lrc submission.
v2:
(John Harrison)
- Move GuC specific fields into sub-struct
- Clean up WQ defines
- Add
Display the workqueue status in debugfs for GuC contexts that are in
parent-child relationship.
v2:
(John Harrison)
- Output number children in debugfs
Signed-off-by: Matthew Brost
Reviewed-by: John Harrison
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 52 ++-
1 file
Assign contexts in parent-child relationship consecutive guc_ids. This
is accomplished by partitioning guc_id space between ones that need to
be consecutive (1/16 available guc_ids) and ones that do not (15/16 of
available guc_ids). The consecutive search is implemented via the bitmap
API.
This
Allow multiple batch buffers to be submitted in a single execbuf IOCTL
after a context has been configured with the 'set_parallel' extension.
The number batches is implicit based on the contexts configuration.
This is implemented with a series of loops. First a loop is used to find
all the
If an error occurs in the front end when multi-lrc requests are getting
generated we need to skip these in the backend but we still need to
emit the breadcrumbs seqno. An issues arises because with multi-lrc
breadcrumbs there is a handshake between the parent and children to make
forward progress.
Parallel submission create composite fences (dma_fence_array) for excl /
shared slots in objects. The I915_GEM_BUSY IOCTL checks these slots to
determine the busyness of the object. Prior to patch it only check if
the fence in the slot was a i915_request. Update the check to understand
composite
Enable multi-bb execbuf by enabling the set_parallel extension.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index
For some users of multi-lrc, e.g. split frame, it isn't safe to preempt
mid BB. To safely enable preemption at the BB boundary, a handshake
between parent and child is needed, syncing the set of BBs at the
beginning and end of each batch. This is implemented via custom
emit_bb_start &
If an object in the excl or shared slot is a composite fence from a
parallel submit and the current request in the conflict tracking is from
the same parallel context there is no need to enforce ordering as the
ordering is already implicit. Make the request conflict tracking
understand this by
A weak implementation of parallel submission (multi-bb execbuf IOCTL) for
execlists. Doing as little as possible to support this interface for
execlists - basically just passing submit fences between each request
generated and virtual engines are not allowed. This is on par with what
is there for
Parallel contexts are perma-pinned by the upper layers which makes the
backend implementation rather simple. The parent pins the guc_id and
children increment the parent's pin count on pin to ensure all the
contexts are unpinned before we disable scheduling with the GuC / or
deregister the
1 - 100 of 149 matches
Mail list logo
