[PATCH] RFC: i915: Drop relocation support on Gen12+

[PATCH] RFC: i915: Drop relocation support on Gen12+

[Jason Ekstrand]

The Vulkan driver in Mesa for Intel hardware never uses relocations if
it's running on a version of i915 that supports at least softpin which
all versions of i915 supporting Gen12 do.  On the OpenGL side, Gen12 is
only supported by iris which never uses relocations.  The older i965
driver in Mesa does use relocations but it only supports Intel hardware
through Gen11 and has been deprecated for all hardware Gen9+. The entire
relocation UAPI and related infrastructure, therefore, doesn't have any
open-source userspace consumer starting with Gen12.

Rejecting relocations starting with Gen12 has the benefit that we don't
have to bother supporting it on platforms with local memory.  Given how
much CPU touching of memory is required for relocations, not having to
do so on platforms where not all memory is directly CPU-accessible
carries significant advantages.

Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
---
 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 4f9c1f5a4dedb..e10c93aff945d 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1533,7 +1533,8 @@ eb_relocate_vma_slow(struct i915_execbuffer *eb, struct i915_vma *vma)
 	return err;
 }
 
-static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
+static int check_relocations(const struct i915_execbuffer *eb,
+			     const struct drm_i915_gem_exec_object2 *entry)
 {
 	const char __user *addr, *end;
 	unsigned long size;
@@ -1543,6 +1544,9 @@ static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
 	if (size == 0)
 		return 0;
 
+	if (size && eb->reloc_cache.gen >= 12)
+		return -EINVAL;
+
 	if (size > N_RELOC(ULONG_MAX))
 		return -EINVAL;
 
@@ -1576,7 +1580,7 @@ static int eb_copy_relocations(const struct i915_execbuffer *eb)
 		if (nreloc == 0)
 			continue;
 
-		err = check_relocations(&eb->exec[i]);
+		err = check_relocations(eb, &eb->exec[i]);
 		if (err)
 			goto err;
 
-- 
2.26.2

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Intel-gfx] [PATCH] RFC: i915: Drop relocation support on Gen12+

[Jason Ekstrand]

The Vulkan driver in Mesa for Intel hardware never uses relocations if
it's running on a version of i915 that supports at least softpin which
all versions of i915 supporting Gen12 do.  On the OpenGL side, Gen12 is
only supported by iris which never uses relocations.  The older i965
driver in Mesa does use relocations but it only supports Intel hardware
through Gen11 and has been deprecated for all hardware Gen9+. The entire
relocation UAPI and related infrastructure, therefore, doesn't have any
open-source userspace consumer starting with Gen12.

Rejecting relocations starting with Gen12 has the benefit that we don't
have to bother supporting it on platforms with local memory.  Given how
much CPU touching of memory is required for relocations, not having to
do so on platforms where not all memory is directly CPU-accessible
carries significant advantages.

Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
---
 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 4f9c1f5a4dedb..e10c93aff945d 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1533,7 +1533,8 @@ eb_relocate_vma_slow(struct i915_execbuffer *eb, struct i915_vma *vma)
 	return err;
 }
 
-static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
+static int check_relocations(const struct i915_execbuffer *eb,
+			     const struct drm_i915_gem_exec_object2 *entry)
 {
 	const char __user *addr, *end;
 	unsigned long size;
@@ -1543,6 +1544,9 @@ static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
 	if (size == 0)
 		return 0;
 
+	if (size && eb->reloc_cache.gen >= 12)
+		return -EINVAL;
+
 	if (size > N_RELOC(ULONG_MAX))
 		return -EINVAL;
 
@@ -1576,7 +1580,7 @@ static int eb_copy_relocations(const struct i915_execbuffer *eb)
 		if (nreloc == 0)
 			continue;
 
-		err = check_relocations(&eb->exec[i]);
+		err = check_relocations(eb, &eb->exec[i]);
 		if (err)
 			goto err;
 
-- 
2.26.2

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] RFC: i915: Drop relocation support on Gen12+

[Chris Wilson]

Quoting Jason Ekstrand (2020-05-07 16:36:00)
> The Vulkan driver in Mesa for Intel hardware never uses relocations if
> it's running on a version of i915 that supports at least softpin which
> all versions of i915 supporting Gen12 do.  On the OpenGL side, Gen12 is
> only supported by iris which never uses relocations.  The older i965
> driver in Mesa does use relocations but it only supports Intel hardware
> through Gen11 and has been deprecated for all hardware Gen9+. The entire
> relocation UAPI and related infrastructure, therefore, doesn't have any
> open-source userspace consumer starting with Gen12.
> 
> Rejecting relocations starting with Gen12 has the benefit that we don't
> have to bother supporting it on platforms with local memory.  Given how
> much CPU touching of memory is required for relocations, not having to
> do so on platforms where not all memory is directly CPU-accessible
> carries significant advantages.

You are not supplying them, the kernel is not checking them [as they
don't exist], so there is no material benefit. The only question is
maintainability.

How confident are you that you will never use them and rewrite the
media-driver? The code exists, will be tested, and can just as easily
expire with the rest of execbuffer2.
-Chris
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH] RFC: i915: Drop relocation support on Gen12+

[Chris Wilson]

Quoting Jason Ekstrand (2020-05-07 16:36:00)
> The Vulkan driver in Mesa for Intel hardware never uses relocations if
> it's running on a version of i915 that supports at least softpin which
> all versions of i915 supporting Gen12 do.  On the OpenGL side, Gen12 is
> only supported by iris which never uses relocations.  The older i965
> driver in Mesa does use relocations but it only supports Intel hardware
> through Gen11 and has been deprecated for all hardware Gen9+. The entire
> relocation UAPI and related infrastructure, therefore, doesn't have any
> open-source userspace consumer starting with Gen12.
> 
> Rejecting relocations starting with Gen12 has the benefit that we don't
> have to bother supporting it on platforms with local memory.  Given how
> much CPU touching of memory is required for relocations, not having to
> do so on platforms where not all memory is directly CPU-accessible
> carries significant advantages.

You are not supplying them, the kernel is not checking them [as they
don't exist], so there is no material benefit. The only question is
maintainability.

How confident are you that you will never use them and rewrite the
media-driver? The code exists, will be tested, and can just as easily
expire with the rest of execbuffer2.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] RFC: i915: Drop relocation support on Gen12+

[Jason Ekstrand]

On Thu, May 7, 2020 at 10:44 AM Chris Wilson <chris@chris-wilson.co.uk> wrote:
>
> Quoting Jason Ekstrand (2020-05-07 16:36:00)
> > The Vulkan driver in Mesa for Intel hardware never uses relocations if
> > it's running on a version of i915 that supports at least softpin which
> > all versions of i915 supporting Gen12 do.  On the OpenGL side, Gen12 is
> > only supported by iris which never uses relocations.  The older i965
> > driver in Mesa does use relocations but it only supports Intel hardware
> > through Gen11 and has been deprecated for all hardware Gen9+. The entire
> > relocation UAPI and related infrastructure, therefore, doesn't have any
> > open-source userspace consumer starting with Gen12.
> >
> > Rejecting relocations starting with Gen12 has the benefit that we don't
> > have to bother supporting it on platforms with local memory.  Given how
> > much CPU touching of memory is required for relocations, not having to
> > do so on platforms where not all memory is directly CPU-accessible
> > carries significant advantages.
>
> You are not supplying them, the kernel is not checking them [as they
> don't exist], so there is no material benefit. The only question is
> maintainability.
>
> How confident are you that you will never use them

Confident enough to send this patch.  Especially in a Vulkan world
where it's very hard to tell which bits of memory are actually in-use
on the GPU, stalling to relocate is performance death.  With a 48-bit
GTT, there's no need to have the kernel involved in address space
assignment so relocations don't really serve much purpose.  We did
potentially have one use for them with VK_KHR_performance_query but
we're going out of our way to avoid them there.  If we desperately
need relocations, we can do them from userspace.

> and rewrite the media-driver?

I'm pretty sure they're working on getting rid of them.  I'm checking
on that right now.

> The code exists, will be tested, and can just as easily
> expire with the rest of execbuffer2.

Sure.  The question, again, is maintenance.  If we're spending piles
of time trying to figure out how to keep relocations going in a local
memory world, that's likely a waste.  Relocations can sit and rot on
Gen11 and below until we finally make execbuffer3 a reality and then
they can rot in the deprecated execbuffer2 ioct.

There is a bit of a question here about what to do with IGT.  I
suspect it uses relocations for a lot of stuff and the fallout there
could be significant.  (I explicitly made this patch so it won't
actually build because I don't hate our CI people.)

--Jason
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH] RFC: i915: Drop relocation support on Gen12+

[Jason Ekstrand]

On Thu, May 7, 2020 at 10:44 AM Chris Wilson <chris@chris-wilson.co.uk> wrote:
>
> Quoting Jason Ekstrand (2020-05-07 16:36:00)
> > The Vulkan driver in Mesa for Intel hardware never uses relocations if
> > it's running on a version of i915 that supports at least softpin which
> > all versions of i915 supporting Gen12 do.  On the OpenGL side, Gen12 is
> > only supported by iris which never uses relocations.  The older i965
> > driver in Mesa does use relocations but it only supports Intel hardware
> > through Gen11 and has been deprecated for all hardware Gen9+. The entire
> > relocation UAPI and related infrastructure, therefore, doesn't have any
> > open-source userspace consumer starting with Gen12.
> >
> > Rejecting relocations starting with Gen12 has the benefit that we don't
> > have to bother supporting it on platforms with local memory.  Given how
> > much CPU touching of memory is required for relocations, not having to
> > do so on platforms where not all memory is directly CPU-accessible
> > carries significant advantages.
>
> You are not supplying them, the kernel is not checking them [as they
> don't exist], so there is no material benefit. The only question is
> maintainability.
>
> How confident are you that you will never use them

Confident enough to send this patch.  Especially in a Vulkan world
where it's very hard to tell which bits of memory are actually in-use
on the GPU, stalling to relocate is performance death.  With a 48-bit
GTT, there's no need to have the kernel involved in address space
assignment so relocations don't really serve much purpose.  We did
potentially have one use for them with VK_KHR_performance_query but
we're going out of our way to avoid them there.  If we desperately
need relocations, we can do them from userspace.

> and rewrite the media-driver?

I'm pretty sure they're working on getting rid of them.  I'm checking
on that right now.

> The code exists, will be tested, and can just as easily
> expire with the rest of execbuffer2.

Sure.  The question, again, is maintenance.  If we're spending piles
of time trying to figure out how to keep relocations going in a local
memory world, that's likely a waste.  Relocations can sit and rot on
Gen11 and below until we finally make execbuffer3 a reality and then
they can rot in the deprecated execbuffer2 ioct.

There is a bit of a question here about what to do with IGT.  I
suspect it uses relocations for a lot of stuff and the fallout there
could be significant.  (I explicitly made this patch so it won't
actually build because I don't hate our CI people.)

--Jason
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BUILD: failure for RFC: i915: Drop relocation support on Gen12+

[Patchwork]

== Series Details ==

Series: RFC: i915: Drop relocation support on Gen12+
URL   : https://patchwork.freedesktop.org/series/77048/
State : failure

== Summary ==

Applying: RFC: i915: Drop relocation support on Gen12+
Using index info to reconstruct a base tree...
M	drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
Falling back to patching base and 3-way merge...
Auto-merging drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0001 RFC: i915: Drop relocation support on Gen12+
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] RFC: i915: Drop relocation support on Gen12+

[Dave Airlie]

On Fri, 8 May 2020 at 01:44, Chris Wilson <chris@chris-wilson.co.uk> wrote:
>
> Quoting Jason Ekstrand (2020-05-07 16:36:00)
> > The Vulkan driver in Mesa for Intel hardware never uses relocations if
> > it's running on a version of i915 that supports at least softpin which
> > all versions of i915 supporting Gen12 do.  On the OpenGL side, Gen12 is
> > only supported by iris which never uses relocations.  The older i965
> > driver in Mesa does use relocations but it only supports Intel hardware
> > through Gen11 and has been deprecated for all hardware Gen9+. The entire
> > relocation UAPI and related infrastructure, therefore, doesn't have any
> > open-source userspace consumer starting with Gen12.
> >
> > Rejecting relocations starting with Gen12 has the benefit that we don't
> > have to bother supporting it on platforms with local memory.  Given how
> > much CPU touching of memory is required for relocations, not having to
> > do so on platforms where not all memory is directly CPU-accessible
> > carries significant advantages.
>
> You are not supplying them, the kernel is not checking them [as they
> don't exist], so there is no material benefit. The only question is
> maintainability.
>
> How confident are you that you will never use them and rewrite the
> media-driver? The code exists, will be tested, and can just as easily
> expire with the rest of execbuffer2.

From an upstream POV I say hell yes, if the hw isn't generally available yet,
and the media-driver/intel-compute-runtime people are warned in advance,

I'm all in on ripping it out for new GENs.

Dave.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH] RFC: i915: Drop relocation support on Gen12+

[Dave Airlie]

On Fri, 8 May 2020 at 01:44, Chris Wilson <chris@chris-wilson.co.uk> wrote:
>
> Quoting Jason Ekstrand (2020-05-07 16:36:00)
> > The Vulkan driver in Mesa for Intel hardware never uses relocations if
> > it's running on a version of i915 that supports at least softpin which
> > all versions of i915 supporting Gen12 do.  On the OpenGL side, Gen12 is
> > only supported by iris which never uses relocations.  The older i965
> > driver in Mesa does use relocations but it only supports Intel hardware
> > through Gen11 and has been deprecated for all hardware Gen9+. The entire
> > relocation UAPI and related infrastructure, therefore, doesn't have any
> > open-source userspace consumer starting with Gen12.
> >
> > Rejecting relocations starting with Gen12 has the benefit that we don't
> > have to bother supporting it on platforms with local memory.  Given how
> > much CPU touching of memory is required for relocations, not having to
> > do so on platforms where not all memory is directly CPU-accessible
> > carries significant advantages.
>
> You are not supplying them, the kernel is not checking them [as they
> don't exist], so there is no material benefit. The only question is
> maintainability.
>
> How confident are you that you will never use them and rewrite the
> media-driver? The code exists, will be tested, and can just as easily
> expire with the rest of execbuffer2.

From an upstream POV I say hell yes, if the hw isn't generally available yet,
and the media-driver/intel-compute-runtime people are warned in advance,

I'm all in on ripping it out for new GENs.

Dave.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] RFC: i915: Drop relocation support on Gen12+

[Joonas Lahtinen]

Quoting Dave Airlie (2020-05-07 21:27:27)
> On Fri, 8 May 2020 at 01:44, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> >
> > Quoting Jason Ekstrand (2020-05-07 16:36:00)
> > > The Vulkan driver in Mesa for Intel hardware never uses relocations if
> > > it's running on a version of i915 that supports at least softpin which
> > > all versions of i915 supporting Gen12 do.  On the OpenGL side, Gen12 is
> > > only supported by iris which never uses relocations.  The older i965
> > > driver in Mesa does use relocations but it only supports Intel hardware
> > > through Gen11 and has been deprecated for all hardware Gen9+. The entire
> > > relocation UAPI and related infrastructure, therefore, doesn't have any
> > > open-source userspace consumer starting with Gen12.
> > >
> > > Rejecting relocations starting with Gen12 has the benefit that we don't
> > > have to bother supporting it on platforms with local memory.  Given how
> > > much CPU touching of memory is required for relocations, not having to
> > > do so on platforms where not all memory is directly CPU-accessible
> > > carries significant advantages.
> >
> > You are not supplying them, the kernel is not checking them [as they
> > don't exist], so there is no material benefit. The only question is
> > maintainability.
> >
> > How confident are you that you will never use them and rewrite the
> > media-driver? The code exists, will be tested, and can just as easily
> > expire with the rest of execbuffer2.
> 
> From an upstream POV I say hell yes, if the hw isn't generally available yet,
> and the media-driver/intel-compute-runtime people are warned in advance,
> 
> I'm all in on ripping it out for new GENs.

There have been discussions with our media driver team about eliminating
any relocations, but today they are still being used. They have started
partially using soft-pinning, which is a great first step to that
direction.

The compute driver does not rely on relocations, they use soft-pinning
everywhere and explicitly manage the address space.

Be assured that I'm also in favor of eliminating relocations (just like
execbuffer2, userptr and couple other things), just that we still need
to have a functional stack before they can be dropped for new hardware.

Like Chris mentioned, enough optimization have been put in the code so
that there is zero impact from the relocations to the exclusively
soft-pinning drivers. So the sole benefit would be being able to drop
the relocations code in the future when the Gen11 hardware has gone
exctinct and that is a worthy goal, too.

But for now the feature is still needed for Gen12, so forcefully
disabling it is untimely.

Regards, Joonas
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH] RFC: i915: Drop relocation support on Gen12+

[Joonas Lahtinen]

Quoting Dave Airlie (2020-05-07 21:27:27)
> On Fri, 8 May 2020 at 01:44, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> >
> > Quoting Jason Ekstrand (2020-05-07 16:36:00)
> > > The Vulkan driver in Mesa for Intel hardware never uses relocations if
> > > it's running on a version of i915 that supports at least softpin which
> > > all versions of i915 supporting Gen12 do.  On the OpenGL side, Gen12 is
> > > only supported by iris which never uses relocations.  The older i965
> > > driver in Mesa does use relocations but it only supports Intel hardware
> > > through Gen11 and has been deprecated for all hardware Gen9+. The entire
> > > relocation UAPI and related infrastructure, therefore, doesn't have any
> > > open-source userspace consumer starting with Gen12.
> > >
> > > Rejecting relocations starting with Gen12 has the benefit that we don't
> > > have to bother supporting it on platforms with local memory.  Given how
> > > much CPU touching of memory is required for relocations, not having to
> > > do so on platforms where not all memory is directly CPU-accessible
> > > carries significant advantages.
> >
> > You are not supplying them, the kernel is not checking them [as they
> > don't exist], so there is no material benefit. The only question is
> > maintainability.
> >
> > How confident are you that you will never use them and rewrite the
> > media-driver? The code exists, will be tested, and can just as easily
> > expire with the rest of execbuffer2.
> 
> From an upstream POV I say hell yes, if the hw isn't generally available yet,
> and the media-driver/intel-compute-runtime people are warned in advance,
> 
> I'm all in on ripping it out for new GENs.

There have been discussions with our media driver team about eliminating
any relocations, but today they are still being used. They have started
partially using soft-pinning, which is a great first step to that
direction.

The compute driver does not rely on relocations, they use soft-pinning
everywhere and explicitly manage the address space.

Be assured that I'm also in favor of eliminating relocations (just like
execbuffer2, userptr and couple other things), just that we still need
to have a functional stack before they can be dropped for new hardware.

Like Chris mentioned, enough optimization have been put in the code so
that there is zero impact from the relocations to the exclusively
soft-pinning drivers. So the sole benefit would be being able to drop
the relocations code in the future when the Gen11 hardware has gone
exctinct and that is a worthy goal, too.

But for now the feature is still needed for Gen12, so forcefully
disabling it is untimely.

Regards, Joonas
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] RFC: i915: Drop relocation support on Gen12+

[Dave Airlie]

On Fri, 8 May 2020 at 15:58, Joonas Lahtinen
<joonas.lahtinen@linux.intel.com> wrote:
>
> Quoting Dave Airlie (2020-05-07 21:27:27)
> > On Fri, 8 May 2020 at 01:44, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> > >
> > > Quoting Jason Ekstrand (2020-05-07 16:36:00)
> > > > The Vulkan driver in Mesa for Intel hardware never uses relocations if
> > > > it's running on a version of i915 that supports at least softpin which
> > > > all versions of i915 supporting Gen12 do.  On the OpenGL side, Gen12 is
> > > > only supported by iris which never uses relocations.  The older i965
> > > > driver in Mesa does use relocations but it only supports Intel hardware
> > > > through Gen11 and has been deprecated for all hardware Gen9+. The entire
> > > > relocation UAPI and related infrastructure, therefore, doesn't have any
> > > > open-source userspace consumer starting with Gen12.
> > > >
> > > > Rejecting relocations starting with Gen12 has the benefit that we don't
> > > > have to bother supporting it on platforms with local memory.  Given how
> > > > much CPU touching of memory is required for relocations, not having to
> > > > do so on platforms where not all memory is directly CPU-accessible
> > > > carries significant advantages.
> > >
> > > You are not supplying them, the kernel is not checking them [as they
> > > don't exist], so there is no material benefit. The only question is
> > > maintainability.
> > >
> > > How confident are you that you will never use them and rewrite the
> > > media-driver? The code exists, will be tested, and can just as easily
> > > expire with the rest of execbuffer2.
> >
> > From an upstream POV I say hell yes, if the hw isn't generally available yet,
> > and the media-driver/intel-compute-runtime people are warned in advance,
> >
> > I'm all in on ripping it out for new GENs.
>
> There have been discussions with our media driver team about eliminating
> any relocations, but today they are still being used. They have started
> partially using soft-pinning, which is a great first step to that
> direction.
>
> The compute driver does not rely on relocations, they use soft-pinning
> everywhere and explicitly manage the address space.
>
> Be assured that I'm also in favor of eliminating relocations (just like
> execbuffer2, userptr and couple other things), just that we still need
> to have a functional stack before they can be dropped for new hardware.
>
> Like Chris mentioned, enough optimization have been put in the code so
> that there is zero impact from the relocations to the exclusively
> soft-pinning drivers. So the sole benefit would be being able to drop
> the relocations code in the future when the Gen11 hardware has gone
> exctinct and that is a worthy goal, too.
>
> But for now the feature is still needed for Gen12, so forcefully
> disabling it is untimely.
>

I'm going to ask that this be revisited for DG1.

DG1 is a discrete GPU,a brand new thing that in no way requires
relocations. If relocations are required for legacy software, that
software is being updated to add local memory support, relocations
should be removed at the same time.

The main reason for this is I believe a lot of effort is being put
into making relocations faster and better that is impacting all over
the i915 driver. instead of just fixing userspace to not require them
anymore moving forward.

I'd rather DG1 support gets upstream in a sane fashion without having
to worry about how super-optimised the relocation paths are for some
corner case userspace code that if it was part of the mesa project
would have been updated by now.

Dave.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH] RFC: i915: Drop relocation support on Gen12+

[Dave Airlie]

On Fri, 8 May 2020 at 15:58, Joonas Lahtinen
<joonas.lahtinen@linux.intel.com> wrote:
>
> Quoting Dave Airlie (2020-05-07 21:27:27)
> > On Fri, 8 May 2020 at 01:44, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> > >
> > > Quoting Jason Ekstrand (2020-05-07 16:36:00)
> > > > The Vulkan driver in Mesa for Intel hardware never uses relocations if
> > > > it's running on a version of i915 that supports at least softpin which
> > > > all versions of i915 supporting Gen12 do.  On the OpenGL side, Gen12 is
> > > > only supported by iris which never uses relocations.  The older i965
> > > > driver in Mesa does use relocations but it only supports Intel hardware
> > > > through Gen11 and has been deprecated for all hardware Gen9+. The entire
> > > > relocation UAPI and related infrastructure, therefore, doesn't have any
> > > > open-source userspace consumer starting with Gen12.
> > > >
> > > > Rejecting relocations starting with Gen12 has the benefit that we don't
> > > > have to bother supporting it on platforms with local memory.  Given how
> > > > much CPU touching of memory is required for relocations, not having to
> > > > do so on platforms where not all memory is directly CPU-accessible
> > > > carries significant advantages.
> > >
> > > You are not supplying them, the kernel is not checking them [as they
> > > don't exist], so there is no material benefit. The only question is
> > > maintainability.
> > >
> > > How confident are you that you will never use them and rewrite the
> > > media-driver? The code exists, will be tested, and can just as easily
> > > expire with the rest of execbuffer2.
> >
> > From an upstream POV I say hell yes, if the hw isn't generally available yet,
> > and the media-driver/intel-compute-runtime people are warned in advance,
> >
> > I'm all in on ripping it out for new GENs.
>
> There have been discussions with our media driver team about eliminating
> any relocations, but today they are still being used. They have started
> partially using soft-pinning, which is a great first step to that
> direction.
>
> The compute driver does not rely on relocations, they use soft-pinning
> everywhere and explicitly manage the address space.
>
> Be assured that I'm also in favor of eliminating relocations (just like
> execbuffer2, userptr and couple other things), just that we still need
> to have a functional stack before they can be dropped for new hardware.
>
> Like Chris mentioned, enough optimization have been put in the code so
> that there is zero impact from the relocations to the exclusively
> soft-pinning drivers. So the sole benefit would be being able to drop
> the relocations code in the future when the Gen11 hardware has gone
> exctinct and that is a worthy goal, too.
>
> But for now the feature is still needed for Gen12, so forcefully
> disabling it is untimely.
>

I'm going to ask that this be revisited for DG1.

DG1 is a discrete GPU,a brand new thing that in no way requires
relocations. If relocations are required for legacy software, that
software is being updated to add local memory support, relocations
should be removed at the same time.

The main reason for this is I believe a lot of effort is being put
into making relocations faster and better that is impacting all over
the i915 driver. instead of just fixing userspace to not require them
anymore moving forward.

I'd rather DG1 support gets upstream in a sane fashion without having
to worry about how super-optimised the relocation paths are for some
corner case userspace code that if it was part of the mesa project
would have been updated by now.

Dave.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH] i915: Drop relocation support on all new hardware

[Jason Ekstrand]

The Vulkan driver in Mesa for Intel hardware never uses relocations if
it's running on a version of i915 that supports at least softpin which
all versions of i915 supporting Gen12 do.  On the OpenGL side, Gen12+ is
only supported by iris which never uses relocations.  The older i965
driver in Mesa does use relocations but it only supports Intel hardware
through Gen11 and has been deprecated for all hardware Gen9+.  The
compute driver also never uses relocations.  This only leaves the media
driver which is supposed to be switching to softpin going forward.
Making softpin a requirement for all future hardware seems reasonable.

Rejecting relocations starting with Gen12 has the benefit that we don't
have to bother supporting it on platforms with local memory.  Given how
much CPU touching of memory is required for relocations, not having to
do so on platforms where not all memory is directly CPU-accessible
carries significant advantages.

Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
---
 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 99772f37bff60..de093acb7721c 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1764,7 +1764,8 @@ eb_relocate_vma_slow(struct i915_execbuffer *eb, struct eb_vma *ev)
 	return err;
 }
 
-static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
+static int check_relocations(const struct i915_execbuffer *eb,
+			     const struct drm_i915_gem_exec_object2 *entry)
 {
 	const char __user *addr, *end;
 	unsigned long size;
@@ -1774,6 +1775,13 @@ static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
 	if (size == 0)
 		return 0;
 
+	/* Relocations are disallowed for all platforms after TGL-LP */
+	if (INTEL_GEN(eb->i915) >= 12 && !IS_TIGERLAKE(eb->i915))
+		return -EINVAL;
+
+	/* All discrete memory platforms are Gen12 or above */
+	BUG_ON(HAS_LMEM(eb->i915));
+
 	if (size > N_RELOC(ULONG_MAX))
 		return -EINVAL;
 
@@ -1807,7 +1815,7 @@ static int eb_copy_relocations(const struct i915_execbuffer *eb)
 		if (nreloc == 0)
 			continue;
 
-		err = check_relocations(&eb->exec[i]);
+		err = check_relocations(eb, &eb->exec[i]);
 		if (err)
 			goto err;
 
@@ -1880,7 +1888,7 @@ static int eb_prefault_relocations(const struct i915_execbuffer *eb)
 	for (i = 0; i < count; i++) {
 		int err;
 
-		err = check_relocations(&eb->exec[i]);
+		err = check_relocations(eb, &eb->exec[i]);
 		if (err)
 			return err;
 	}
-- 
2.29.2

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Intel-gfx] [PATCH] i915: Drop relocation support on all new hardware

[Jason Ekstrand]

The Vulkan driver in Mesa for Intel hardware never uses relocations if
it's running on a version of i915 that supports at least softpin which
all versions of i915 supporting Gen12 do.  On the OpenGL side, Gen12+ is
only supported by iris which never uses relocations.  The older i965
driver in Mesa does use relocations but it only supports Intel hardware
through Gen11 and has been deprecated for all hardware Gen9+.  The
compute driver also never uses relocations.  This only leaves the media
driver which is supposed to be switching to softpin going forward.
Making softpin a requirement for all future hardware seems reasonable.

Rejecting relocations starting with Gen12 has the benefit that we don't
have to bother supporting it on platforms with local memory.  Given how
much CPU touching of memory is required for relocations, not having to
do so on platforms where not all memory is directly CPU-accessible
carries significant advantages.

Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
---
 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 99772f37bff60..de093acb7721c 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1764,7 +1764,8 @@ eb_relocate_vma_slow(struct i915_execbuffer *eb, struct eb_vma *ev)
 	return err;
 }
 
-static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
+static int check_relocations(const struct i915_execbuffer *eb,
+			     const struct drm_i915_gem_exec_object2 *entry)
 {
 	const char __user *addr, *end;
 	unsigned long size;
@@ -1774,6 +1775,13 @@ static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
 	if (size == 0)
 		return 0;
 
+	/* Relocations are disallowed for all platforms after TGL-LP */
+	if (INTEL_GEN(eb->i915) >= 12 && !IS_TIGERLAKE(eb->i915))
+		return -EINVAL;
+
+	/* All discrete memory platforms are Gen12 or above */
+	BUG_ON(HAS_LMEM(eb->i915));
+
 	if (size > N_RELOC(ULONG_MAX))
 		return -EINVAL;
 
@@ -1807,7 +1815,7 @@ static int eb_copy_relocations(const struct i915_execbuffer *eb)
 		if (nreloc == 0)
 			continue;
 
-		err = check_relocations(&eb->exec[i]);
+		err = check_relocations(eb, &eb->exec[i]);
 		if (err)
 			goto err;
 
@@ -1880,7 +1888,7 @@ static int eb_prefault_relocations(const struct i915_execbuffer *eb)
 	for (i = 0; i < count; i++) {
 		int err;
 
-		err = check_relocations(&eb->exec[i]);
+		err = check_relocations(eb, &eb->exec[i]);
 		if (err)
 			return err;
 	}
-- 
2.29.2

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for RFC: i915: Drop relocation support on Gen12+ (rev2)

[Patchwork]

== Series Details ==

Series: RFC: i915: Drop relocation support on Gen12+ (rev2)
URL   : https://patchwork.freedesktop.org/series/77048/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
35a435752bf5 i915: Drop relocation support on all new hardware
-:49: WARNING:AVOID_BUG: Avoid crashing the kernel - try using WARN_ON & recovery code rather than BUG() or BUG_ON()
#49: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1783:
+	BUG_ON(HAS_LMEM(eb->i915));

total: 0 errors, 1 warnings, 0 checks, 38 lines checked


_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH] i915: Drop relocation support on all new hardware (v3)

[Jason Ekstrand]

The Vulkan driver in Mesa for Intel hardware never uses relocations if
it's running on a version of i915 that supports at least softpin which
all versions of i915 supporting Gen12 do.  On the OpenGL side, Gen12+ is
only supported by iris which never uses relocations.  The older i965
driver in Mesa does use relocations but it only supports Intel hardware
through Gen11 and has been deprecated for all hardware Gen9+.  The
compute driver also never uses relocations.  This only leaves the media
driver which is supposed to be switching to softpin going forward.
Making softpin a requirement for all future hardware seems reasonable.

Rejecting relocations starting with Gen12 has the benefit that we don't
have to bother supporting it on platforms with local memory.  Given how
much CPU touching of memory is required for relocations, not having to
do so on platforms where not all memory is directly CPU-accessible
carries significant advantages.

v2 (Jason Ekstrand):
 - Allow TGL-LP platforms as they've already shipped

v3 (Jason Ekstrand):
 - WARN_ON platforms with LMEM support in case the check is wrong

Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
---
 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 15 ++++++++++++---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 99772f37bff60..b02dbd16bfa03 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1764,7 +1764,8 @@ eb_relocate_vma_slow(struct i915_execbuffer *eb, struct eb_vma *ev)
 	return err;
 }
 
-static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
+static int check_relocations(const struct i915_execbuffer *eb,
+			     const struct drm_i915_gem_exec_object2 *entry)
 {
 	const char __user *addr, *end;
 	unsigned long size;
@@ -1774,6 +1775,14 @@ static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
 	if (size == 0)
 		return 0;
 
+	/* Relocations are disallowed for all platforms after TGL-LP */
+	if (INTEL_GEN(eb->i915) >= 12 && !IS_TIGERLAKE(eb->i915))
+		return -EINVAL;
+
+	/* All discrete memory platforms are Gen12 or above */
+	if (WARN_ON(HAS_LMEM(eb->i915)))
+		return -EINVAL;
+
 	if (size > N_RELOC(ULONG_MAX))
 		return -EINVAL;
 
@@ -1807,7 +1816,7 @@ static int eb_copy_relocations(const struct i915_execbuffer *eb)
 		if (nreloc == 0)
 			continue;
 
-		err = check_relocations(&eb->exec[i]);
+		err = check_relocations(eb, &eb->exec[i]);
 		if (err)
 			goto err;
 
@@ -1880,7 +1889,7 @@ static int eb_prefault_relocations(const struct i915_execbuffer *eb)
 	for (i = 0; i < count; i++) {
 		int err;
 
-		err = check_relocations(&eb->exec[i]);
+		err = check_relocations(eb, &eb->exec[i]);
 		if (err)
 			return err;
 	}
-- 
2.29.2

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Intel-gfx] [PATCH] i915: Drop relocation support on all new hardware (v3)

[Jason Ekstrand]

The Vulkan driver in Mesa for Intel hardware never uses relocations if
it's running on a version of i915 that supports at least softpin which
all versions of i915 supporting Gen12 do.  On the OpenGL side, Gen12+ is
only supported by iris which never uses relocations.  The older i965
driver in Mesa does use relocations but it only supports Intel hardware
through Gen11 and has been deprecated for all hardware Gen9+.  The
compute driver also never uses relocations.  This only leaves the media
driver which is supposed to be switching to softpin going forward.
Making softpin a requirement for all future hardware seems reasonable.

Rejecting relocations starting with Gen12 has the benefit that we don't
have to bother supporting it on platforms with local memory.  Given how
much CPU touching of memory is required for relocations, not having to
do so on platforms where not all memory is directly CPU-accessible
carries significant advantages.

v2 (Jason Ekstrand):
 - Allow TGL-LP platforms as they've already shipped

v3 (Jason Ekstrand):
 - WARN_ON platforms with LMEM support in case the check is wrong

Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
---
 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 15 ++++++++++++---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 99772f37bff60..b02dbd16bfa03 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1764,7 +1764,8 @@ eb_relocate_vma_slow(struct i915_execbuffer *eb, struct eb_vma *ev)
 	return err;
 }
 
-static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
+static int check_relocations(const struct i915_execbuffer *eb,
+			     const struct drm_i915_gem_exec_object2 *entry)
 {
 	const char __user *addr, *end;
 	unsigned long size;
@@ -1774,6 +1775,14 @@ static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
 	if (size == 0)
 		return 0;
 
+	/* Relocations are disallowed for all platforms after TGL-LP */
+	if (INTEL_GEN(eb->i915) >= 12 && !IS_TIGERLAKE(eb->i915))
+		return -EINVAL;
+
+	/* All discrete memory platforms are Gen12 or above */
+	if (WARN_ON(HAS_LMEM(eb->i915)))
+		return -EINVAL;
+
 	if (size > N_RELOC(ULONG_MAX))
 		return -EINVAL;
 
@@ -1807,7 +1816,7 @@ static int eb_copy_relocations(const struct i915_execbuffer *eb)
 		if (nreloc == 0)
 			continue;
 
-		err = check_relocations(&eb->exec[i]);
+		err = check_relocations(eb, &eb->exec[i]);
 		if (err)
 			goto err;
 
@@ -1880,7 +1889,7 @@ static int eb_prefault_relocations(const struct i915_execbuffer *eb)
 	for (i = 0; i < count; i++) {
 		int err;
 
-		err = check_relocations(&eb->exec[i]);
+		err = check_relocations(eb, &eb->exec[i]);
 		if (err)
 			return err;
 	}
-- 
2.29.2

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for RFC: i915: Drop relocation support on Gen12+ (rev2)

[Patchwork]

[-- Attachment #1.1: Type: text/plain, Size: 8693 bytes --]

== Series Details ==

Series: RFC: i915: Drop relocation support on Gen12+ (rev2)
URL   : https://patchwork.freedesktop.org/series/77048/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9845 -> Patchwork_19775
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19775/index.html

Possible new issues
-------------------

  Here are the unknown changes that may have been introduced in Patchwork_19775:

### IGT changes ###

#### Suppressed ####

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@i915_selftest@live@gt_timelines:
    - {fi-tgl-dsi}:       [PASS][1] -> [DMESG-WARN][2] +2 similar issues
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9845/fi-tgl-dsi/igt@i915_selftest@live@gt_timelines.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19775/fi-tgl-dsi/igt@i915_selftest@live@gt_timelines.html

  
Known issues
------------

  Here are the changes found in Patchwork_19775 that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@amdgpu/amd_basic@cs-gfx:
    - fi-kbl-soraka:      NOTRUN -> [SKIP][3] ([fdo#109271]) +20 similar issues
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19775/fi-kbl-soraka/igt@amdgpu/amd_basic@cs-gfx.html

  * igt@amdgpu/amd_basic@semaphore:
    - fi-icl-y:           NOTRUN -> [SKIP][4] ([fdo#109315]) +17 similar issues
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19775/fi-icl-y/igt@amdgpu/amd_basic@semaphore.html

  * igt@amdgpu/amd_cs_nop@fork-compute0:
    - fi-ivb-3770:        NOTRUN -> [SKIP][5] ([fdo#109271]) +28 similar issues
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19775/fi-ivb-3770/igt@amdgpu/amd_cs_nop@fork-compute0.html

  * igt@amdgpu/amd_cs_nop@sync-fork-compute0:
    - fi-snb-2600:        NOTRUN -> [SKIP][6] ([fdo#109271]) +17 similar issues
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19775/fi-snb-2600/igt@amdgpu/amd_cs_nop@sync-fork-compute0.html

  * igt@gem_huc_copy@huc-copy:
    - fi-kbl-soraka:      NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#2190])
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19775/fi-kbl-soraka/igt@gem_huc_copy@huc-copy.html
    - fi-icl-y:           NOTRUN -> [SKIP][8] ([i915#2190])
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19775/fi-icl-y/igt@gem_huc_copy@huc-copy.html

  * igt@gem_tiled_fence_blits@basic:
    - fi-kbl-8809g:       [PASS][9] -> [TIMEOUT][10] ([i915#3145])
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9845/fi-kbl-8809g/igt@gem_tiled_fence_blits@basic.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19775/fi-kbl-8809g/igt@gem_tiled_fence_blits@basic.html

  * igt@i915_selftest@live@gt_pm:
    - fi-kbl-soraka:      NOTRUN -> [DMESG-FAIL][11] ([i915#1886] / [i915#2291])
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19775/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html

  * igt@kms_chamelium@common-hpd-after-suspend:
    - fi-kbl-soraka:      NOTRUN -> [SKIP][12] ([fdo#109271] / [fdo#111827]) +8 similar issues
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19775/fi-kbl-soraka/igt@kms_chamelium@common-hpd-after-suspend.html

  * igt@kms_chamelium@dp-crc-fast:
    - fi-icl-y:           NOTRUN -> [SKIP][13] ([fdo#109284] / [fdo#111827]) +8 similar issues
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19775/fi-icl-y/igt@kms_chamelium@dp-crc-fast.html

  * igt@kms_chamelium@dp-hpd-fast:
    - fi-ivb-3770:        NOTRUN -> [SKIP][14] ([fdo#109271] / [fdo#111827]) +8 similar issues
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19775/fi-ivb-3770/igt@kms_chamelium@dp-hpd-fast.html

  * igt@kms_force_connector_basic@force-load-detect:
    - fi-icl-y:           NOTRUN -> [SKIP][15] ([fdo#109285])
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19775/fi-icl-y/igt@kms_force_connector_basic@force-load-detect.html

  * igt@kms_frontbuffer_tracking@basic:
    - fi-kbl-soraka:      NOTRUN -> [FAIL][16] ([i915#49])
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19775/fi-kbl-soraka/igt@kms_frontbuffer_tracking@basic.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
    - fi-kbl-soraka:      NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#533])
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19775/fi-kbl-soraka/igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d.html
    - fi-icl-y:           NOTRUN -> [SKIP][18] ([fdo#109278])
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19775/fi-icl-y/igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d.html

  * igt@kms_psr@primary_mmap_gtt:
    - fi-icl-y:           NOTRUN -> [SKIP][19] ([fdo#110189]) +3 similar issues
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19775/fi-icl-y/igt@kms_psr@primary_mmap_gtt.html

  * igt@runner@aborted:
    - fi-bdw-5557u:       NOTRUN -> [FAIL][20] ([i915#1602] / [i915#2029] / [i915#2369])
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19775/fi-bdw-5557u/igt@runner@aborted.html

  
#### Possible fixes ####

  * igt@gem_exec_suspend@basic-s0:
    - fi-kbl-soraka:      [INCOMPLETE][21] ([i915#155]) -> [PASS][22]
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9845/fi-kbl-soraka/igt@gem_exec_suspend@basic-s0.html
   [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19775/fi-kbl-soraka/igt@gem_exec_suspend@basic-s0.html

  * igt@gem_tiled_blits@basic:
    - fi-kbl-8809g:       [TIMEOUT][23] ([i915#2502] / [i915#3145]) -> [PASS][24]
   [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9845/fi-kbl-8809g/igt@gem_tiled_blits@basic.html
   [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19775/fi-kbl-8809g/igt@gem_tiled_blits@basic.html

  * igt@i915_selftest@live@hangcheck:
    - fi-snb-2600:        [INCOMPLETE][25] ([i915#2782]) -> [PASS][26]
   [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9845/fi-snb-2600/igt@i915_selftest@live@hangcheck.html
   [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19775/fi-snb-2600/igt@i915_selftest@live@hangcheck.html

  
  {name}: This element is suppressed. This means it is ignored when computing
          the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
  [fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284
  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
  [fdo#110189]: https://bugs.freedesktop.org/show_bug.cgi?id=110189
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1222]: https://gitlab.freedesktop.org/drm/intel/issues/1222
  [i915#155]: https://gitlab.freedesktop.org/drm/intel/issues/155
  [i915#1602]: https://gitlab.freedesktop.org/drm/intel/issues/1602
  [i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#2029]: https://gitlab.freedesktop.org/drm/intel/issues/2029
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#2291]: https://gitlab.freedesktop.org/drm/intel/issues/2291
  [i915#2369]: https://gitlab.freedesktop.org/drm/intel/issues/2369
  [i915#2502]: https://gitlab.freedesktop.org/drm/intel/issues/2502
  [i915#2782]: https://gitlab.freedesktop.org/drm/intel/issues/2782
  [i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
  [i915#3145]: https://gitlab.freedesktop.org/drm/intel/issues/3145
  [i915#49]: https://gitlab.freedesktop.org/drm/intel/issues/49
  [i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533


Participating hosts (45 -> 41)
------------------------------

  Additional (2): fi-icl-y fi-ivb-3770 
  Missing    (6): fi-ilk-m540 fi-hsw-4200u fi-bsw-n3050 fi-bsw-cyan fi-ctg-p8600 fi-bdw-samus 


Build changes
-------------

  * Linux: CI_DRM_9845 -> Patchwork_19775

  CI-20190529: 20190529
  CI_DRM_9845: 2532f22e558a98a8a6d8dca97cd34f7af2e68db1 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6028: f3109d1e3b554903df9109e1e4d10c881b3f811b @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_19775: 35a435752bf591a17c384f974fea6c2928646486 @ git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

35a435752bf5 i915: Drop relocation support on all new hardware

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19775/index.html

[-- Attachment #1.2: Type: text/html, Size: 10274 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] i915: Drop relocation support on all new hardware (v3)

[Jason Ekstrand]

+Zbigniew for review

On Wed, Mar 10, 2021 at 3:50 PM Jason Ekstrand <jason@jlekstrand.net> wrote:
>
> The Vulkan driver in Mesa for Intel hardware never uses relocations if
> it's running on a version of i915 that supports at least softpin which
> all versions of i915 supporting Gen12 do.  On the OpenGL side, Gen12+ is
> only supported by iris which never uses relocations.  The older i965
> driver in Mesa does use relocations but it only supports Intel hardware
> through Gen11 and has been deprecated for all hardware Gen9+.  The
> compute driver also never uses relocations.  This only leaves the media
> driver which is supposed to be switching to softpin going forward.
> Making softpin a requirement for all future hardware seems reasonable.
>
> Rejecting relocations starting with Gen12 has the benefit that we don't
> have to bother supporting it on platforms with local memory.  Given how
> much CPU touching of memory is required for relocations, not having to
> do so on platforms where not all memory is directly CPU-accessible
> carries significant advantages.
>
> v2 (Jason Ekstrand):
>  - Allow TGL-LP platforms as they've already shipped
>
> v3 (Jason Ekstrand):
>  - WARN_ON platforms with LMEM support in case the check is wrong
>
> Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
> Cc: Dave Airlie <airlied@redhat.com>
> Cc: Daniel Vetter <daniel.vetter@intel.com>
> ---
>  drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 15 ++++++++++++---
>  1 file changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index 99772f37bff60..b02dbd16bfa03 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -1764,7 +1764,8 @@ eb_relocate_vma_slow(struct i915_execbuffer *eb, struct eb_vma *ev)
>         return err;
>  }
>
> -static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
> +static int check_relocations(const struct i915_execbuffer *eb,
> +                            const struct drm_i915_gem_exec_object2 *entry)
>  {
>         const char __user *addr, *end;
>         unsigned long size;
> @@ -1774,6 +1775,14 @@ static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
>         if (size == 0)
>                 return 0;
>
> +       /* Relocations are disallowed for all platforms after TGL-LP */
> +       if (INTEL_GEN(eb->i915) >= 12 && !IS_TIGERLAKE(eb->i915))
> +               return -EINVAL;
> +
> +       /* All discrete memory platforms are Gen12 or above */
> +       if (WARN_ON(HAS_LMEM(eb->i915)))
> +               return -EINVAL;
> +
>         if (size > N_RELOC(ULONG_MAX))
>                 return -EINVAL;
>
> @@ -1807,7 +1816,7 @@ static int eb_copy_relocations(const struct i915_execbuffer *eb)
>                 if (nreloc == 0)
>                         continue;
>
> -               err = check_relocations(&eb->exec[i]);
> +               err = check_relocations(eb, &eb->exec[i]);
>                 if (err)
>                         goto err;
>
> @@ -1880,7 +1889,7 @@ static int eb_prefault_relocations(const struct i915_execbuffer *eb)
>         for (i = 0; i < count; i++) {
>                 int err;
>
> -               err = check_relocations(&eb->exec[i]);
> +               err = check_relocations(eb, &eb->exec[i]);
>                 if (err)
>                         return err;
>         }
> --
> 2.29.2
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH] i915: Drop relocation support on all new hardware (v3)

[Jason Ekstrand]

+Zbigniew for review

On Wed, Mar 10, 2021 at 3:50 PM Jason Ekstrand <jason@jlekstrand.net> wrote:
>
> The Vulkan driver in Mesa for Intel hardware never uses relocations if
> it's running on a version of i915 that supports at least softpin which
> all versions of i915 supporting Gen12 do.  On the OpenGL side, Gen12+ is
> only supported by iris which never uses relocations.  The older i965
> driver in Mesa does use relocations but it only supports Intel hardware
> through Gen11 and has been deprecated for all hardware Gen9+.  The
> compute driver also never uses relocations.  This only leaves the media
> driver which is supposed to be switching to softpin going forward.
> Making softpin a requirement for all future hardware seems reasonable.
>
> Rejecting relocations starting with Gen12 has the benefit that we don't
> have to bother supporting it on platforms with local memory.  Given how
> much CPU touching of memory is required for relocations, not having to
> do so on platforms where not all memory is directly CPU-accessible
> carries significant advantages.
>
> v2 (Jason Ekstrand):
>  - Allow TGL-LP platforms as they've already shipped
>
> v3 (Jason Ekstrand):
>  - WARN_ON platforms with LMEM support in case the check is wrong
>
> Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
> Cc: Dave Airlie <airlied@redhat.com>
> Cc: Daniel Vetter <daniel.vetter@intel.com>
> ---
>  drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 15 ++++++++++++---
>  1 file changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index 99772f37bff60..b02dbd16bfa03 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -1764,7 +1764,8 @@ eb_relocate_vma_slow(struct i915_execbuffer *eb, struct eb_vma *ev)
>         return err;
>  }
>
> -static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
> +static int check_relocations(const struct i915_execbuffer *eb,
> +                            const struct drm_i915_gem_exec_object2 *entry)
>  {
>         const char __user *addr, *end;
>         unsigned long size;
> @@ -1774,6 +1775,14 @@ static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
>         if (size == 0)
>                 return 0;
>
> +       /* Relocations are disallowed for all platforms after TGL-LP */
> +       if (INTEL_GEN(eb->i915) >= 12 && !IS_TIGERLAKE(eb->i915))
> +               return -EINVAL;
> +
> +       /* All discrete memory platforms are Gen12 or above */
> +       if (WARN_ON(HAS_LMEM(eb->i915)))
> +               return -EINVAL;
> +
>         if (size > N_RELOC(ULONG_MAX))
>                 return -EINVAL;
>
> @@ -1807,7 +1816,7 @@ static int eb_copy_relocations(const struct i915_execbuffer *eb)
>                 if (nreloc == 0)
>                         continue;
>
> -               err = check_relocations(&eb->exec[i]);
> +               err = check_relocations(eb, &eb->exec[i]);
>                 if (err)
>                         goto err;
>
> @@ -1880,7 +1889,7 @@ static int eb_prefault_relocations(const struct i915_execbuffer *eb)
>         for (i = 0; i < count; i++) {
>                 int err;
>
> -               err = check_relocations(&eb->exec[i]);
> +               err = check_relocations(eb, &eb->exec[i]);
>                 if (err)
>                         return err;
>         }
> --
> 2.29.2
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for RFC: i915: Drop relocation support on Gen12+ (rev3)

[Patchwork]

[-- Attachment #1.1: Type: text/plain, Size: 3038 bytes --]

== Series Details ==

Series: RFC: i915: Drop relocation support on Gen12+ (rev3)
URL   : https://patchwork.freedesktop.org/series/77048/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9846 -> Patchwork_19777
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/index.html

Known issues
------------

  Here are the changes found in Patchwork_19777 that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@gem_exec_gttfill@basic:
    - fi-kbl-8809g:       [PASS][1] -> [TIMEOUT][2] ([i915#3145])
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9846/fi-kbl-8809g/igt@gem_exec_gttfill@basic.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/fi-kbl-8809g/igt@gem_exec_gttfill@basic.html

  
#### Possible fixes ####

  * igt@gem_tiled_fence_blits@basic:
    - fi-kbl-8809g:       [TIMEOUT][3] ([i915#3145]) -> [PASS][4]
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9846/fi-kbl-8809g/igt@gem_tiled_fence_blits@basic.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/fi-kbl-8809g/igt@gem_tiled_fence_blits@basic.html

  * igt@i915_module_load@reload:
    - {fi-tgl-dsi}:       [DMESG-WARN][5] ([i915#1982] / [k.org#205379]) -> [PASS][6]
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9846/fi-tgl-dsi/igt@i915_module_load@reload.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/fi-tgl-dsi/igt@i915_module_load@reload.html

  * igt@kms_frontbuffer_tracking@basic:
    - {fi-rkl-11500t}:    [SKIP][7] -> [PASS][8]
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9846/fi-rkl-11500t/igt@kms_frontbuffer_tracking@basic.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/fi-rkl-11500t/igt@kms_frontbuffer_tracking@basic.html

  
  {name}: This element is suppressed. This means it is ignored when computing
          the status of the difference (SUCCESS, WARNING, or FAILURE).

  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#3145]: https://gitlab.freedesktop.org/drm/intel/issues/3145
  [k.org#205379]: https://bugzilla.kernel.org/show_bug.cgi?id=205379


Participating hosts (47 -> 40)
------------------------------

  Missing    (7): fi-ilk-m540 fi-hsw-4200u fi-bsw-n3050 fi-bsw-cyan fi-ctg-p8600 fi-icl-y fi-bdw-samus 


Build changes
-------------

  * Linux: CI_DRM_9846 -> Patchwork_19777

  CI-20190529: 20190529
  CI_DRM_9846: 5c27a442313682671bff079c5be5ed4a4d7ce0ae @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6028: f3109d1e3b554903df9109e1e4d10c881b3f811b @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_19777: 6457ddae450a27790a9c4417ba4fb7bb956ad800 @ git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

6457ddae450a i915: Drop relocation support on all new hardware (v3)

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/index.html

[-- Attachment #1.2: Type: text/html, Size: 3798 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.IGT: failure for RFC: i915: Drop relocation support on Gen12+ (rev3)

[Patchwork]

[-- Attachment #1.1: Type: text/plain, Size: 30274 bytes --]

== Series Details ==

Series: RFC: i915: Drop relocation support on Gen12+ (rev3)
URL   : https://patchwork.freedesktop.org/series/77048/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_9846_full -> Patchwork_19777_full
====================================================

Summary
-------

  **FAILURE**

  Serious unknown changes coming with Patchwork_19777_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_19777_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  

Possible new issues
-------------------

  Here are the unknown changes that may have been introduced in Patchwork_19777_full:

### IGT changes ###

#### Possible regressions ####

  * igt@kms_plane_scaling@scaler-with-clipping-clamping:
    - shard-apl:          NOTRUN -> [INCOMPLETE][1]
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-apl2/igt@kms_plane_scaling@scaler-with-clipping-clamping.html

  
Known issues
------------

  Here are the changes found in Patchwork_19777_full that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@api_intel_bb@render-ccs:
    - shard-skl:          [PASS][2] -> [INCOMPLETE][3] ([i915#2405])
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9846/shard-skl1/igt@api_intel_bb@render-ccs.html
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-skl10/igt@api_intel_bb@render-ccs.html

  * igt@gem_create@create-massive:
    - shard-snb:          NOTRUN -> [DMESG-WARN][4] ([i915#3002]) +1 similar issue
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-snb6/igt@gem_create@create-massive.html

  * igt@gem_ctx_isolation@preservation-s3@bcs0:
    - shard-apl:          NOTRUN -> [DMESG-WARN][5] ([i915#180]) +1 similar issue
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-apl7/igt@gem_ctx_isolation@preservation-s3@bcs0.html

  * igt@gem_ctx_persistence@idempotent:
    - shard-snb:          NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#1099]) +3 similar issues
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-snb6/igt@gem_ctx_persistence@idempotent.html

  * igt@gem_eio@unwedge-stress:
    - shard-tglb:         [PASS][7] -> [TIMEOUT][8] ([i915#2369] / [i915#3063])
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9846/shard-tglb3/igt@gem_eio@unwedge-stress.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-tglb2/igt@gem_eio@unwedge-stress.html

  * igt@gem_exec_fair@basic-deadline:
    - shard-apl:          NOTRUN -> [FAIL][9] ([i915#2846])
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-apl3/igt@gem_exec_fair@basic-deadline.html

  * igt@gem_exec_fair@basic-none@vcs1:
    - shard-iclb:         NOTRUN -> [FAIL][10] ([i915#2842])
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-iclb4/igt@gem_exec_fair@basic-none@vcs1.html

  * igt@gem_exec_fair@basic-pace@vcs1:
    - shard-kbl:          [PASS][11] -> [FAIL][12] ([i915#2842])
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9846/shard-kbl4/igt@gem_exec_fair@basic-pace@vcs1.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-kbl2/igt@gem_exec_fair@basic-pace@vcs1.html
    - shard-tglb:         [PASS][13] -> [FAIL][14] ([i915#2842]) +1 similar issue
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9846/shard-tglb3/igt@gem_exec_fair@basic-pace@vcs1.html
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-tglb2/igt@gem_exec_fair@basic-pace@vcs1.html

  * igt@gem_exec_fair@basic-throttle@rcs0:
    - shard-iclb:         [PASS][15] -> [FAIL][16] ([i915#2849])
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9846/shard-iclb4/igt@gem_exec_fair@basic-throttle@rcs0.html
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-iclb5/igt@gem_exec_fair@basic-throttle@rcs0.html

  * igt@gem_exec_reloc@basic-many-active@vcs1:
    - shard-iclb:         NOTRUN -> [FAIL][17] ([i915#2389])
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-iclb1/igt@gem_exec_reloc@basic-many-active@vcs1.html

  * igt@gem_exec_reloc@basic-parallel:
    - shard-kbl:          NOTRUN -> [TIMEOUT][18] ([i915#1729])
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-kbl3/igt@gem_exec_reloc@basic-parallel.html

  * igt@gem_exec_reloc@basic-wide-active@bcs0:
    - shard-apl:          NOTRUN -> [FAIL][19] ([i915#2389]) +3 similar issues
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-apl8/igt@gem_exec_reloc@basic-wide-active@bcs0.html

  * igt@gem_exec_schedule@u-fairslice@vecs0:
    - shard-skl:          NOTRUN -> [DMESG-WARN][20] ([i915#1610] / [i915#2803])
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-skl4/igt@gem_exec_schedule@u-fairslice@vecs0.html

  * igt@gem_mmap_gtt@cpuset-basic-small-copy-xy:
    - shard-iclb:         [PASS][21] -> [FAIL][22] ([i915#307])
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9846/shard-iclb6/igt@gem_mmap_gtt@cpuset-basic-small-copy-xy.html
   [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-iclb7/igt@gem_mmap_gtt@cpuset-basic-small-copy-xy.html

  * igt@gem_mmap_gtt@cpuset-big-copy-xy:
    - shard-glk:          [PASS][23] -> [FAIL][24] ([i915#307])
   [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9846/shard-glk8/igt@gem_mmap_gtt@cpuset-big-copy-xy.html
   [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-glk1/igt@gem_mmap_gtt@cpuset-big-copy-xy.html

  * igt@gem_userptr_blits@mmap-offset-invalidate-active@wb:
    - shard-snb:          NOTRUN -> [SKIP][25] ([fdo#109271]) +347 similar issues
   [25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-snb5/igt@gem_userptr_blits@mmap-offset-invalidate-active@wb.html

  * igt@gem_vm_create@destroy-race:
    - shard-tglb:         [PASS][26] -> [TIMEOUT][27] ([i915#2795])
   [26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9846/shard-tglb3/igt@gem_vm_create@destroy-race.html
   [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-tglb2/igt@gem_vm_create@destroy-race.html

  * igt@gen7_exec_parse@basic-offset:
    - shard-apl:          NOTRUN -> [SKIP][28] ([fdo#109271]) +129 similar issues
   [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-apl8/igt@gen7_exec_parse@basic-offset.html

  * igt@i915_pm_dc@dc6-dpms:
    - shard-skl:          NOTRUN -> [FAIL][29] ([i915#454])
   [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-skl4/igt@i915_pm_dc@dc6-dpms.html

  * igt@i915_suspend@fence-restore-tiled2untiled:
    - shard-apl:          [PASS][30] -> [DMESG-WARN][31] ([i915#180]) +2 similar issues
   [30]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9846/shard-apl8/igt@i915_suspend@fence-restore-tiled2untiled.html
   [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-apl8/igt@i915_suspend@fence-restore-tiled2untiled.html

  * igt@kms_big_joiner@basic:
    - shard-apl:          NOTRUN -> [SKIP][32] ([fdo#109271] / [i915#2705])
   [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-apl8/igt@kms_big_joiner@basic.html

  * igt@kms_ccs@pipe-c-ccs-on-another-bo:
    - shard-skl:          NOTRUN -> [SKIP][33] ([fdo#109271] / [fdo#111304])
   [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-skl6/igt@kms_ccs@pipe-c-ccs-on-another-bo.html

  * igt@kms_chamelium@hdmi-edid-change-during-suspend:
    - shard-apl:          NOTRUN -> [SKIP][34] ([fdo#109271] / [fdo#111827]) +13 similar issues
   [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-apl2/igt@kms_chamelium@hdmi-edid-change-during-suspend.html

  * igt@kms_color_chamelium@pipe-c-ctm-max:
    - shard-kbl:          NOTRUN -> [SKIP][35] ([fdo#109271] / [fdo#111827]) +1 similar issue
   [35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-kbl3/igt@kms_color_chamelium@pipe-c-ctm-max.html

  * igt@kms_color_chamelium@pipe-d-ctm-0-25:
    - shard-skl:          NOTRUN -> [SKIP][36] ([fdo#109271] / [fdo#111827]) +10 similar issues
   [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-skl7/igt@kms_color_chamelium@pipe-d-ctm-0-25.html

  * igt@kms_color_chamelium@pipe-invalid-ctm-matrix-sizes:
    - shard-snb:          NOTRUN -> [SKIP][37] ([fdo#109271] / [fdo#111827]) +20 similar issues
   [37]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-snb5/igt@kms_color_chamelium@pipe-invalid-ctm-matrix-sizes.html

  * igt@kms_content_protection@lic:
    - shard-apl:          NOTRUN -> [TIMEOUT][38] ([i915#1319])
   [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-apl2/igt@kms_content_protection@lic.html

  * igt@kms_content_protection@uevent:
    - shard-apl:          NOTRUN -> [FAIL][39] ([i915#2105])
   [39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-apl3/igt@kms_content_protection@uevent.html

  * igt@kms_cursor_crc@pipe-b-cursor-64x64-offscreen:
    - shard-skl:          [PASS][40] -> [FAIL][41] ([i915#54])
   [40]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9846/shard-skl4/igt@kms_cursor_crc@pipe-b-cursor-64x64-offscreen.html
   [41]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-skl10/igt@kms_cursor_crc@pipe-b-cursor-64x64-offscreen.html

  * igt@kms_cursor_crc@pipe-b-cursor-suspend:
    - shard-kbl:          [PASS][42] -> [DMESG-WARN][43] ([i915#180])
   [42]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9846/shard-kbl3/igt@kms_cursor_crc@pipe-b-cursor-suspend.html
   [43]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-kbl6/igt@kms_cursor_crc@pipe-b-cursor-suspend.html

  * igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions:
    - shard-skl:          NOTRUN -> [FAIL][44] ([i915#2346])
   [44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-skl4/igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions.html

  * igt@kms_cursor_legacy@flip-vs-cursor-busy-crc-legacy:
    - shard-apl:          NOTRUN -> [DMESG-FAIL][45] ([IGT#6])
   [45]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-apl8/igt@kms_cursor_legacy@flip-vs-cursor-busy-crc-legacy.html

  * igt@kms_cursor_legacy@pipe-d-torture-bo:
    - shard-apl:          NOTRUN -> [SKIP][46] ([fdo#109271] / [i915#533]) +1 similar issue
   [46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-apl8/igt@kms_cursor_legacy@pipe-d-torture-bo.html

  * igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-16bpp-ytile:
    - shard-apl:          NOTRUN -> [FAIL][47] ([i915#2641]) +1 similar issue
   [47]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-apl8/igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-16bpp-ytile.html

  * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-blt:
    - shard-kbl:          NOTRUN -> [SKIP][48] ([fdo#109271]) +22 similar issues
   [48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-kbl3/igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-blt.html

  * igt@kms_frontbuffer_tracking@fbcpsr-2p-primscrn-cur-indfb-draw-mmap-cpu:
    - shard-skl:          NOTRUN -> [SKIP][49] ([fdo#109271]) +108 similar issues
   [49]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-skl7/igt@kms_frontbuffer_tracking@fbcpsr-2p-primscrn-cur-indfb-draw-mmap-cpu.html

  * igt@kms_frontbuffer_tracking@psr-rgb101010-draw-mmap-gtt:
    - shard-skl:          [PASS][50] -> [FAIL][51] ([i915#49])
   [50]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9846/shard-skl4/igt@kms_frontbuffer_tracking@psr-rgb101010-draw-mmap-gtt.html
   [51]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-skl4/igt@kms_frontbuffer_tracking@psr-rgb101010-draw-mmap-gtt.html

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-d:
    - shard-skl:          NOTRUN -> [SKIP][52] ([fdo#109271] / [i915#533])
   [52]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-skl6/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-d.html

  * igt@kms_plane_alpha_blend@pipe-a-alpha-basic:
    - shard-apl:          NOTRUN -> [FAIL][53] ([fdo#108145] / [i915#265]) +1 similar issue
   [53]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-apl2/igt@kms_plane_alpha_blend@pipe-a-alpha-basic.html

  * igt@kms_plane_alpha_blend@pipe-a-alpha-transparent-fb:
    - shard-skl:          NOTRUN -> [FAIL][54] ([i915#265])
   [54]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-skl5/igt@kms_plane_alpha_blend@pipe-a-alpha-transparent-fb.html

  * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc:
    - shard-skl:          NOTRUN -> [FAIL][55] ([fdo#108145] / [i915#265]) +3 similar issues
   [55]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-skl9/igt@kms_plane_alpha_blend@pipe-b-coverage-7efc.html

  * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
    - shard-skl:          [PASS][56] -> [FAIL][57] ([fdo#108145] / [i915#265])
   [56]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9846/shard-skl9/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html
   [57]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-skl5/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html

  * igt@kms_psr2_sf@overlay-plane-update-sf-dmg-area-5:
    - shard-skl:          NOTRUN -> [SKIP][58] ([fdo#109271] / [i915#658]) +2 similar issues
   [58]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-skl5/igt@kms_psr2_sf@overlay-plane-update-sf-dmg-area-5.html

  * igt@kms_psr2_sf@overlay-primary-update-sf-dmg-area-3:
    - shard-apl:          NOTRUN -> [SKIP][59] ([fdo#109271] / [i915#658]) +4 similar issues
   [59]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-apl8/igt@kms_psr2_sf@overlay-primary-update-sf-dmg-area-3.html

  * igt@kms_psr2_su@page_flip:
    - shard-kbl:          NOTRUN -> [SKIP][60] ([fdo#109271] / [i915#658])
   [60]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-kbl3/igt@kms_psr2_su@page_flip.html

  * igt@kms_psr@psr2_cursor_render:
    - shard-iclb:         [PASS][61] -> [SKIP][62] ([fdo#109441]) +1 similar issue
   [61]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9846/shard-iclb2/igt@kms_psr@psr2_cursor_render.html
   [62]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-iclb7/igt@kms_psr@psr2_cursor_render.html

  * igt@kms_sysfs_edid_timing:
    - shard-skl:          NOTRUN -> [FAIL][63] ([IGT#2])
   [63]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-skl4/igt@kms_sysfs_edid_timing.html

  * igt@kms_writeback@writeback-invalid-parameters:
    - shard-apl:          NOTRUN -> [SKIP][64] ([fdo#109271] / [i915#2437])
   [64]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-apl2/igt@kms_writeback@writeback-invalid-parameters.html

  * igt@kms_writeback@writeback-pixel-formats:
    - shard-skl:          NOTRUN -> [SKIP][65] ([fdo#109271] / [i915#2437])
   [65]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-skl4/igt@kms_writeback@writeback-pixel-formats.html

  * igt@runner@aborted:
    - shard-snb:          NOTRUN -> ([FAIL][66], [FAIL][67]) ([i915#3002] / [i915#698])
   [66]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-snb6/igt@runner@aborted.html
   [67]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-snb6/igt@runner@aborted.html

  * igt@sysfs_clients@recycle:
    - shard-iclb:         [PASS][68] -> [FAIL][69] ([i915#3028])
   [68]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9846/shard-iclb2/igt@sysfs_clients@recycle.html
   [69]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-iclb7/igt@sysfs_clients@recycle.html
    - shard-glk:          [PASS][70] -> [FAIL][71] ([i915#3028])
   [70]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9846/shard-glk7/igt@sysfs_clients@recycle.html
   [71]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-glk4/igt@sysfs_clients@recycle.html

  * igt@sysfs_clients@recycle-many:
    - shard-apl:          [PASS][72] -> [FAIL][73] ([i915#3028])
   [72]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9846/shard-apl3/igt@sysfs_clients@recycle-many.html
   [73]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-apl1/igt@sysfs_clients@recycle-many.html
    - shard-kbl:          NOTRUN -> [FAIL][74] ([i915#3028])
   [74]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-kbl3/igt@sysfs_clients@recycle-many.html

  
#### Possible fixes ####

  * igt@feature_discovery@psr2:
    - shard-iclb:         [SKIP][75] ([i915#658]) -> [PASS][76]
   [75]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9846/shard-iclb4/igt@feature_discovery@psr2.html
   [76]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-iclb2/igt@feature_discovery@psr2.html

  * igt@gem_ctx_isolation@preservation-s3@bcs0:
    - shard-kbl:          [DMESG-WARN][77] ([i915#180]) -> [PASS][78] +2 similar issues
   [77]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9846/shard-kbl7/igt@gem_ctx_isolation@preservation-s3@bcs0.html
   [78]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-kbl3/igt@gem_ctx_isolation@preservation-s3@bcs0.html

  * igt@gem_eio@in-flight-contexts-10ms:
    - shard-tglb:         [TIMEOUT][79] ([i915#3063]) -> [PASS][80]
   [79]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9846/shard-tglb1/igt@gem_eio@in-flight-contexts-10ms.html
   [80]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-tglb8/igt@gem_eio@in-flight-contexts-10ms.html

  * igt@gem_exec_fair@basic-none@rcs0:
    - shard-kbl:          [FAIL][81] ([i915#2842]) -> [PASS][82] +1 similar issue
   [81]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9846/shard-kbl6/igt@gem_exec_fair@basic-none@rcs0.html
   [82]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-kbl1/igt@gem_exec_fair@basic-none@rcs0.html

  * igt@gem_exec_fair@basic-throttle@rcs0:
    - shard-glk:          [FAIL][83] ([i915#2842]) -> [PASS][84] +2 similar issues
   [83]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9846/shard-glk9/igt@gem_exec_fair@basic-throttle@rcs0.html
   [84]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-glk5/igt@gem_exec_fair@basic-throttle@rcs0.html

  * igt@gem_mmap_gtt@cpuset-big-copy-odd:
    - shard-iclb:         [FAIL][85] ([i915#2428]) -> [PASS][86] +1 similar issue
   [85]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9846/shard-iclb6/igt@gem_mmap_gtt@cpuset-big-copy-odd.html
   [86]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-iclb3/igt@gem_mmap_gtt@cpuset-big-copy-odd.html

  * igt@kms_color@pipe-c-ctm-0-5:
    - shard-skl:          [DMESG-WARN][87] ([i915#1982]) -> [PASS][88]
   [87]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9846/shard-skl3/igt@kms_color@pipe-c-ctm-0-5.html
   [88]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-skl9/igt@kms_color@pipe-c-ctm-0-5.html

  * igt@kms_flip@flip-vs-expired-vblank@a-edp1:
    - shard-tglb:         [FAIL][89] ([i915#2598]) -> [PASS][90]
   [89]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9846/shard-tglb2/igt@kms_flip@flip-vs-expired-vblank@a-edp1.html
   [90]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-tglb8/igt@kms_flip@flip-vs-expired-vblank@a-edp1.html

  * igt@kms_flip@plain-flip-ts-check@c-edp1:
    - shard-skl:          [FAIL][91] ([i915#2122]) -> [PASS][92]
   [91]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9846/shard-skl10/igt@kms_flip@plain-flip-ts-check@c-edp1.html
   [92]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-skl4/igt@kms_flip@plain-flip-ts-check@c-edp1.html

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
    - shard-skl:          [INCOMPLETE][93] ([i915#198] / [i915#2828]) -> [PASS][94]
   [93]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9846/shard-skl4/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c.html
   [94]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-skl4/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c.html

  * igt@perf@polling-parameterized:
    - shard-skl:          [FAIL][95] ([i915#1542]) -> [PASS][96]
   [95]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9846/shard-skl2/igt@perf@polling-parameterized.html
   [96]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-skl7/igt@perf@polling-parameterized.html

  * igt@sysfs_clients@busy@vcs1:
    - shard-kbl:          [FAIL][97] ([i915#3009]) -> [PASS][98]
   [97]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9846/shard-kbl1/igt@sysfs_clients@busy@vcs1.html
   [98]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-kbl7/igt@sysfs_clients@busy@vcs1.html

  * igt@sysfs_clients@recycle:
    - shard-skl:          [FAIL][99] ([i915#3028]) -> [PASS][100]
   [99]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9846/shard-skl5/igt@sysfs_clients@recycle.html
   [100]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-skl10/igt@sysfs_clients@recycle.html

  * igt@sysfs_clients@recycle-many:
    - shard-iclb:         [FAIL][101] ([i915#3028]) -> [PASS][102]
   [101]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9846/shard-iclb1/igt@sysfs_clients@recycle-many.html
   [102]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-iclb2/igt@sysfs_clients@recycle-many.html
    - shard-tglb:         [FAIL][103] ([i915#3028]) -> [PASS][104]
   [103]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9846/shard-tglb3/igt@sysfs_clients@recycle-many.html
   [104]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-tglb2/igt@sysfs_clients@recycle-many.html

  * igt@sysfs_clients@split-25@rcs0:
    - shard-skl:          [SKIP][105] ([fdo#109271]) -> [PASS][106]
   [105]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9846/shard-skl9/igt@sysfs_clients@split-25@rcs0.html
   [106]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-skl5/igt@sysfs_clients@split-25@rcs0.html

  
#### Warnings ####

  * igt@gem_exec_balancer@hang:
    - shard-iclb:         [INCOMPLETE][107] ([i915#1895]) -> [INCOMPLETE][108] ([i915#1895] / [i915#3031])
   [107]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9846/shard-iclb2/igt@gem_exec_balancer@hang.html
   [108]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-iclb1/igt@gem_exec_balancer@hang.html

  * igt@i915_pm_rc6_residency@rc6-fence:
    - shard-iclb:         [WARN][109] ([i915#2681] / [i915#2684]) -> [WARN][110] ([i915#1804] / [i915#2684])
   [109]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9846/shard-iclb8/igt@i915_pm_rc6_residency@rc6-fence.html
   [110]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-iclb7/igt@i915_pm_rc6_residency@rc6-fence.html

  * igt@i915_pm_rc6_residency@rc6-idle:
    - shard-iclb:         [WARN][111] ([i915#2681] / [i915#2684]) -> [WARN][112] ([i915#2684])
   [111]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9846/shard-iclb1/igt@i915_pm_rc6_residency@rc6-idle.html
   [112]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-iclb5/igt@i915_pm_rc6_residency@rc6-idle.html

  * igt@kms_content_protection@dp-mst-type-1:
    - shard-iclb:         [SKIP][113] ([i915#3116]) -> [FAIL][114] ([i915#3144])
   [113]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9846/shard-iclb4/igt@kms_content_protection@dp-mst-type-1.html
   [114]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-iclb1/igt@kms_content_protection@dp-mst-type-1.html

  * igt@kms_content_protection@type1:
    - shard-iclb:         [FAIL][115] ([i915#3137]) -> [SKIP][116] ([fdo#109300] / [fdo#111066])
   [115]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9846/shard-iclb1/igt@kms_content_protection@type1.html
   [116]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-iclb2/igt@kms_content_protection@type1.html

  * igt@kms_psr2_sf@plane-move-sf-dmg-area-3:
    - shard-iclb:         [SKIP][117] ([i915#2920]) -> [SKIP][118] ([i915#658]) +2 similar issues
   [117]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9846/shard-iclb2/igt@kms_psr2_sf@plane-move-sf-dmg-area-3.html
   [118]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-iclb4/igt@kms_psr2_sf@plane-move-sf-dmg-area-3.html

  * igt@kms_psr2_sf@primary-plane-update-sf-dmg-area-4:
    - shard-iclb:         [SKIP][119] ([i915#658]) -> [SKIP][120] ([i915#2920]) +3 similar issues
   [119]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9846/shard-iclb8/igt@kms_psr2_sf@primary-plane-update-sf-dmg-area-4.html
   [120]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-iclb2/igt@kms_psr2_sf@primary-plane-update-sf-dmg-area-4.html

  * igt@runner@aborted:
    - shard-kbl:          ([FAIL][121], [FAIL][122], [FAIL][123], [FAIL][124], [FAIL][125], [FAIL][126]) ([i915#1436] / [i915#180] / [i915#1814] / [i915#2426] / [i915#2505] / [i915#2724] / [i915#3002]) -> ([FAIL][127], [FAIL][128], [FAIL][129], [FAIL][130], [FAIL][131]) ([i915#1814] / [i915#2426] / [i915#2505] / [i915#2724] / [i915#3002])
   [121]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9846/shard-kbl6/igt@runner@aborted.html
   [122]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9846/shard-kbl4/igt@runner@aborted.html
   [123]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9846/shard-kbl2/igt@runner@aborted.html
   [124]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9846/shard-kbl7/igt@runner@aborted.html
   [125]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9846/shard-kbl6/igt@runner@aborted.html
   [126]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9846/shard-kbl6/igt@runner@aborted.html
   [127]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-kbl6/igt@runner@aborted.html
   [128]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-kbl2/igt@runner@aborted.html
   [129]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-kbl1/igt@runner@aborted.html
   [130]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-kbl6/igt@runner@aborted.html
   [131]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-kbl6/igt@runner@aborted.html
    - shard-apl:          ([FAIL][132], [FAIL][133], [FAIL][134]) ([fdo#109271] / [i915#1814] / [i915#2724] / [i915#3002]) -> ([FAIL][135], [FAIL][136], [FAIL][137], [FAIL][138], [FAIL][139], [FAIL][140], [FAIL][141]) ([fdo#109271] / [i915#180] / [i915#1814] / [i915#2724] / [i915#3002])
   [132]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9846/shard-apl7/igt@runner@aborted.html
   [133]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9846/shard-apl1/igt@runner@aborted.html
   [134]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9846/shard-apl2/igt@runner@aborted.html
   [135]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-apl6/igt@runner@aborted.html
   [136]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-apl2/igt@runner@aborted.html
   [137]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-apl7/igt@runner@aborted.html
   [138]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-apl8/igt@runner@aborted.html
   [139]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-apl7/igt@runner@aborted.html
   [140]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-apl8/igt@runner@aborted.html
   [141]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-apl7/igt@runner@aborted.html
    - shard-skl:          ([FAIL][142], [FAIL][143], [FAIL][144], [FAIL][145], [FAIL][146], [FAIL][147], [FAIL][148], [FAIL][149]) ([i915#1436] / [i915#1814] / [i915#2029] / [i915#2724] / [i915#3002]) -> ([FAIL][150], [FAIL][151], [FAIL][152], [FAIL][153], [FAIL][154], [FAIL][155], [FAIL][156]) ([i915#1814] / [i915#2029] / [i915#2426] / [i915#3002])
   [142]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9846/shard-skl6/igt@runner@aborted.html
   [143]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9846/shard-skl4/igt@runner@aborted.html
   [144]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9846/shard-skl9/igt@runner@aborted.html
   [145]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9846/shard-skl5/igt@runner@aborted.html
   [146]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9846/shard-skl3/igt@runner@aborted.html
   [147]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9846/shard-skl2/igt@runner@aborted.html
   [148]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9846/shard-skl3/igt@runner@aborted.html
   [149]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9846/shard-skl2/igt@runner@aborted.html
   [150]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-skl10/igt@runner@aborted.html
   [151]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-skl3/igt@runner@aborted.html
   [152]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-skl4/igt@runner@aborted.html
   [153]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-skl3/igt@runner@aborted.html
   [154]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-skl2/igt@runner@aborted.html
   [155]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-skl5/igt@runner@aborted.html
   [156]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/shard-skl3/igt@runner@aborted.html

  
  {name}: This element is suppressed. This means it is ignored when computing
          the status of the difference (SUCCESS, WARNING, or FAILURE).

  [IGT#2]: https://gitlab.freedesktop.org/drm/igt-gpu-tools/issues/2
  [IGT#6]: https://gitlab.freedesktop.org/drm/igt-gpu-tools/issues/6
  [fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109300]: https://bugs.freedesktop.org/show_bug.cgi?id=109300
  [fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441
  [fdo#111066]: https://bugs.freedesktop.org/show_bug.cgi?id=111066
  [fdo#111304]: https://bugs.freedesktop.org/show_bug.cgi?id=111304
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1099]: https://gitla

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19777/index.html

[-- Attachment #1.2: Type: text/html, Size: 35113 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] i915: Drop relocation support on all new hardware (v3)

[Lucas De Marchi]

On Wed, Mar 10, 2021 at 1:50 PM Jason Ekstrand <jason@jlekstrand.net> wrote:
>
> The Vulkan driver in Mesa for Intel hardware never uses relocations if
> it's running on a version of i915 that supports at least softpin which
> all versions of i915 supporting Gen12 do.  On the OpenGL side, Gen12+ is
> only supported by iris which never uses relocations.  The older i965
> driver in Mesa does use relocations but it only supports Intel hardware
> through Gen11 and has been deprecated for all hardware Gen9+.  The
> compute driver also never uses relocations.  This only leaves the media
> driver which is supposed to be switching to softpin going forward.
> Making softpin a requirement for all future hardware seems reasonable.
>
> Rejecting relocations starting with Gen12 has the benefit that we don't
> have to bother supporting it on platforms with local memory.  Given how
> much CPU touching of memory is required for relocations, not having to
> do so on platforms where not all memory is directly CPU-accessible
> carries significant advantages.
>
> v2 (Jason Ekstrand):
>  - Allow TGL-LP platforms as they've already shipped
>
> v3 (Jason Ekstrand):
>  - WARN_ON platforms with LMEM support in case the check is wrong
>
> Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
> Cc: Dave Airlie <airlied@redhat.com>
> Cc: Daniel Vetter <daniel.vetter@intel.com>
> ---
>  drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 15 ++++++++++++---
>  1 file changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index 99772f37bff60..b02dbd16bfa03 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -1764,7 +1764,8 @@ eb_relocate_vma_slow(struct i915_execbuffer *eb, struct eb_vma *ev)
>         return err;
>  }
>
> -static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
> +static int check_relocations(const struct i915_execbuffer *eb,
> +                            const struct drm_i915_gem_exec_object2 *entry)
>  {
>         const char __user *addr, *end;
>         unsigned long size;
> @@ -1774,6 +1775,14 @@ static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
>         if (size == 0)
>                 return 0;
>
> +       /* Relocations are disallowed for all platforms after TGL-LP */
> +       if (INTEL_GEN(eb->i915) >= 12 && !IS_TIGERLAKE(eb->i915))
> +               return -EINVAL;
> +
> +       /* All discrete memory platforms are Gen12 or above */
> +       if (WARN_ON(HAS_LMEM(eb->i915)))

HAS_LMEM() will return true for the fake lmem support, which may be < gen12.
Dropping the fake lmem would be a possibility.

Lucas De Marchi

> +               return -EINVAL;
> +
>         if (size > N_RELOC(ULONG_MAX))
>                 return -EINVAL;
>
> @@ -1807,7 +1816,7 @@ static int eb_copy_relocations(const struct i915_execbuffer *eb)
>                 if (nreloc == 0)
>                         continue;
>
> -               err = check_relocations(&eb->exec[i]);
> +               err = check_relocations(eb, &eb->exec[i]);
>                 if (err)
>                         goto err;
>
> @@ -1880,7 +1889,7 @@ static int eb_prefault_relocations(const struct i915_execbuffer *eb)
>         for (i = 0; i < count; i++) {
>                 int err;
>
> -               err = check_relocations(&eb->exec[i]);
> +               err = check_relocations(eb, &eb->exec[i]);
>                 if (err)
>                         return err;
>         }
> --
> 2.29.2
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH] i915: Drop relocation support on all new hardware (v3)

[Lucas De Marchi]

On Wed, Mar 10, 2021 at 1:50 PM Jason Ekstrand <jason@jlekstrand.net> wrote:
>
> The Vulkan driver in Mesa for Intel hardware never uses relocations if
> it's running on a version of i915 that supports at least softpin which
> all versions of i915 supporting Gen12 do.  On the OpenGL side, Gen12+ is
> only supported by iris which never uses relocations.  The older i965
> driver in Mesa does use relocations but it only supports Intel hardware
> through Gen11 and has been deprecated for all hardware Gen9+.  The
> compute driver also never uses relocations.  This only leaves the media
> driver which is supposed to be switching to softpin going forward.
> Making softpin a requirement for all future hardware seems reasonable.
>
> Rejecting relocations starting with Gen12 has the benefit that we don't
> have to bother supporting it on platforms with local memory.  Given how
> much CPU touching of memory is required for relocations, not having to
> do so on platforms where not all memory is directly CPU-accessible
> carries significant advantages.
>
> v2 (Jason Ekstrand):
>  - Allow TGL-LP platforms as they've already shipped
>
> v3 (Jason Ekstrand):
>  - WARN_ON platforms with LMEM support in case the check is wrong
>
> Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
> Cc: Dave Airlie <airlied@redhat.com>
> Cc: Daniel Vetter <daniel.vetter@intel.com>
> ---
>  drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 15 ++++++++++++---
>  1 file changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index 99772f37bff60..b02dbd16bfa03 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -1764,7 +1764,8 @@ eb_relocate_vma_slow(struct i915_execbuffer *eb, struct eb_vma *ev)
>         return err;
>  }
>
> -static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
> +static int check_relocations(const struct i915_execbuffer *eb,
> +                            const struct drm_i915_gem_exec_object2 *entry)
>  {
>         const char __user *addr, *end;
>         unsigned long size;
> @@ -1774,6 +1775,14 @@ static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
>         if (size == 0)
>                 return 0;
>
> +       /* Relocations are disallowed for all platforms after TGL-LP */
> +       if (INTEL_GEN(eb->i915) >= 12 && !IS_TIGERLAKE(eb->i915))
> +               return -EINVAL;
> +
> +       /* All discrete memory platforms are Gen12 or above */
> +       if (WARN_ON(HAS_LMEM(eb->i915)))

HAS_LMEM() will return true for the fake lmem support, which may be < gen12.
Dropping the fake lmem would be a possibility.

Lucas De Marchi

> +               return -EINVAL;
> +
>         if (size > N_RELOC(ULONG_MAX))
>                 return -EINVAL;
>
> @@ -1807,7 +1816,7 @@ static int eb_copy_relocations(const struct i915_execbuffer *eb)
>                 if (nreloc == 0)
>                         continue;
>
> -               err = check_relocations(&eb->exec[i]);
> +               err = check_relocations(eb, &eb->exec[i]);
>                 if (err)
>                         goto err;
>
> @@ -1880,7 +1889,7 @@ static int eb_prefault_relocations(const struct i915_execbuffer *eb)
>         for (i = 0; i < count; i++) {
>                 int err;
>
> -               err = check_relocations(&eb->exec[i]);
> +               err = check_relocations(eb, &eb->exec[i]);
>                 if (err)
>                         return err;
>         }
> --
> 2.29.2
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] i915: Drop relocation support on all new hardware (v3)

[Tvrtko Ursulin]

On 10/03/2021 21:50, Jason Ekstrand wrote:
> The Vulkan driver in Mesa for Intel hardware never uses relocations if
> it's running on a version of i915 that supports at least softpin which
> all versions of i915 supporting Gen12 do.  On the OpenGL side, Gen12+ is
> only supported by iris which never uses relocations.  The older i965
> driver in Mesa does use relocations but it only supports Intel hardware
> through Gen11 and has been deprecated for all hardware Gen9+.  The
> compute driver also never uses relocations.  This only leaves the media
> driver which is supposed to be switching to softpin going forward.

How does "supposed to be" translates to actually being ready? Cc someone 
from media so they can ack?

> Making softpin a requirement for all future hardware seems reasonable.
> 
> Rejecting relocations starting with Gen12 has the benefit that we don't
> have to bother supporting it on platforms with local memory.  Given how
> much CPU touching of memory is required for relocations, not having to
> do so on platforms where not all memory is directly CPU-accessible
> carries significant advantages.
> 
> v2 (Jason Ekstrand):
>   - Allow TGL-LP platforms as they've already shipped
> 
> v3 (Jason Ekstrand):
>   - WARN_ON platforms with LMEM support in case the check is wrong
> 
> Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
> Cc: Dave Airlie <airlied@redhat.com>
> Cc: Daniel Vetter <daniel.vetter@intel.com>
> ---
>   drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 15 ++++++++++++---
>   1 file changed, 12 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index 99772f37bff60..b02dbd16bfa03 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -1764,7 +1764,8 @@ eb_relocate_vma_slow(struct i915_execbuffer *eb, struct eb_vma *ev)
>   	return err;
>   }
>   
> -static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
> +static int check_relocations(const struct i915_execbuffer *eb,
> +			     const struct drm_i915_gem_exec_object2 *entry)
>   {
>   	const char __user *addr, *end;
>   	unsigned long size;
> @@ -1774,6 +1775,14 @@ static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
>   	if (size == 0)
>   		return 0;
>   
> +	/* Relocations are disallowed for all platforms after TGL-LP */
> +	if (INTEL_GEN(eb->i915) >= 12 && !IS_TIGERLAKE(eb->i915))
> +		return -EINVAL;
> +
> +	/* All discrete memory platforms are Gen12 or above */
> +	if (WARN_ON(HAS_LMEM(eb->i915)))
> +		return -EINVAL;

Maybe ENODEV as our more typical "this platform does not support this" 
instead of "you are using it wrong".

Regards,

Tvrtko

> +
>   	if (size > N_RELOC(ULONG_MAX))
>   		return -EINVAL;
>   
> @@ -1807,7 +1816,7 @@ static int eb_copy_relocations(const struct i915_execbuffer *eb)
>   		if (nreloc == 0)
>   			continue;
>   
> -		err = check_relocations(&eb->exec[i]);
> +		err = check_relocations(eb, &eb->exec[i]);
>   		if (err)
>   			goto err;
>   
> @@ -1880,7 +1889,7 @@ static int eb_prefault_relocations(const struct i915_execbuffer *eb)
>   	for (i = 0; i < count; i++) {
>   		int err;
>   
> -		err = check_relocations(&eb->exec[i]);
> +		err = check_relocations(eb, &eb->exec[i]);
>   		if (err)
>   			return err;
>   	}
> 
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH] i915: Drop relocation support on all new hardware (v3)

[Tvrtko Ursulin]

On 10/03/2021 21:50, Jason Ekstrand wrote:
> The Vulkan driver in Mesa for Intel hardware never uses relocations if
> it's running on a version of i915 that supports at least softpin which
> all versions of i915 supporting Gen12 do.  On the OpenGL side, Gen12+ is
> only supported by iris which never uses relocations.  The older i965
> driver in Mesa does use relocations but it only supports Intel hardware
> through Gen11 and has been deprecated for all hardware Gen9+.  The
> compute driver also never uses relocations.  This only leaves the media
> driver which is supposed to be switching to softpin going forward.

How does "supposed to be" translates to actually being ready? Cc someone 
from media so they can ack?

> Making softpin a requirement for all future hardware seems reasonable.
> 
> Rejecting relocations starting with Gen12 has the benefit that we don't
> have to bother supporting it on platforms with local memory.  Given how
> much CPU touching of memory is required for relocations, not having to
> do so on platforms where not all memory is directly CPU-accessible
> carries significant advantages.
> 
> v2 (Jason Ekstrand):
>   - Allow TGL-LP platforms as they've already shipped
> 
> v3 (Jason Ekstrand):
>   - WARN_ON platforms with LMEM support in case the check is wrong
> 
> Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
> Cc: Dave Airlie <airlied@redhat.com>
> Cc: Daniel Vetter <daniel.vetter@intel.com>
> ---
>   drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 15 ++++++++++++---
>   1 file changed, 12 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index 99772f37bff60..b02dbd16bfa03 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -1764,7 +1764,8 @@ eb_relocate_vma_slow(struct i915_execbuffer *eb, struct eb_vma *ev)
>   	return err;
>   }
>   
> -static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
> +static int check_relocations(const struct i915_execbuffer *eb,
> +			     const struct drm_i915_gem_exec_object2 *entry)
>   {
>   	const char __user *addr, *end;
>   	unsigned long size;
> @@ -1774,6 +1775,14 @@ static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
>   	if (size == 0)
>   		return 0;
>   
> +	/* Relocations are disallowed for all platforms after TGL-LP */
> +	if (INTEL_GEN(eb->i915) >= 12 && !IS_TIGERLAKE(eb->i915))
> +		return -EINVAL;
> +
> +	/* All discrete memory platforms are Gen12 or above */
> +	if (WARN_ON(HAS_LMEM(eb->i915)))
> +		return -EINVAL;

Maybe ENODEV as our more typical "this platform does not support this" 
instead of "you are using it wrong".

Regards,

Tvrtko

> +
>   	if (size > N_RELOC(ULONG_MAX))
>   		return -EINVAL;
>   
> @@ -1807,7 +1816,7 @@ static int eb_copy_relocations(const struct i915_execbuffer *eb)
>   		if (nreloc == 0)
>   			continue;
>   
> -		err = check_relocations(&eb->exec[i]);
> +		err = check_relocations(eb, &eb->exec[i]);
>   		if (err)
>   			goto err;
>   
> @@ -1880,7 +1889,7 @@ static int eb_prefault_relocations(const struct i915_execbuffer *eb)
>   	for (i = 0; i < count; i++) {
>   		int err;
>   
> -		err = check_relocations(&eb->exec[i]);
> +		err = check_relocations(eb, &eb->exec[i]);
>   		if (err)
>   			return err;
>   	}
> 
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] i915: Drop relocation support on all new hardware (v3)

[Matthew Auld]

On 11/03/2021 08:14, Lucas De Marchi wrote:
> On Wed, Mar 10, 2021 at 1:50 PM Jason Ekstrand <jason@jlekstrand.net> wrote:
>>
>> The Vulkan driver in Mesa for Intel hardware never uses relocations if
>> it's running on a version of i915 that supports at least softpin which
>> all versions of i915 supporting Gen12 do.  On the OpenGL side, Gen12+ is
>> only supported by iris which never uses relocations.  The older i965
>> driver in Mesa does use relocations but it only supports Intel hardware
>> through Gen11 and has been deprecated for all hardware Gen9+.  The
>> compute driver also never uses relocations.  This only leaves the media
>> driver which is supposed to be switching to softpin going forward.
>> Making softpin a requirement for all future hardware seems reasonable.
>>
>> Rejecting relocations starting with Gen12 has the benefit that we don't
>> have to bother supporting it on platforms with local memory.  Given how
>> much CPU touching of memory is required for relocations, not having to
>> do so on platforms where not all memory is directly CPU-accessible
>> carries significant advantages.
>>
>> v2 (Jason Ekstrand):
>>   - Allow TGL-LP platforms as they've already shipped
>>
>> v3 (Jason Ekstrand):
>>   - WARN_ON platforms with LMEM support in case the check is wrong
>>
>> Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
>> Cc: Dave Airlie <airlied@redhat.com>
>> Cc: Daniel Vetter <daniel.vetter@intel.com>
>> ---
>>   drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 15 ++++++++++++---
>>   1 file changed, 12 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
>> index 99772f37bff60..b02dbd16bfa03 100644
>> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
>> @@ -1764,7 +1764,8 @@ eb_relocate_vma_slow(struct i915_execbuffer *eb, struct eb_vma *ev)
>>          return err;
>>   }
>>
>> -static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
>> +static int check_relocations(const struct i915_execbuffer *eb,
>> +                            const struct drm_i915_gem_exec_object2 *entry)
>>   {
>>          const char __user *addr, *end;
>>          unsigned long size;
>> @@ -1774,6 +1775,14 @@ static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
>>          if (size == 0)
>>                  return 0;
>>
>> +       /* Relocations are disallowed for all platforms after TGL-LP */
>> +       if (INTEL_GEN(eb->i915) >= 12 && !IS_TIGERLAKE(eb->i915))
>> +               return -EINVAL;
>> +
>> +       /* All discrete memory platforms are Gen12 or above */
>> +       if (WARN_ON(HAS_LMEM(eb->i915)))
> 
> HAS_LMEM() will return true for the fake lmem support, which may be < gen12.
> Dropping the fake lmem would be a possibility.

Nothing in CI is currently using the fake-lmem configuration(for some 
months now I think), also its use was limited only to the selftests, 
which can't hit this path, so shouldn't matter here. Plan was to just 
drop it.

> 
> Lucas De Marchi
> 
>> +               return -EINVAL;
>> +
>>          if (size > N_RELOC(ULONG_MAX))
>>                  return -EINVAL;
>>
>> @@ -1807,7 +1816,7 @@ static int eb_copy_relocations(const struct i915_execbuffer *eb)
>>                  if (nreloc == 0)
>>                          continue;
>>
>> -               err = check_relocations(&eb->exec[i]);
>> +               err = check_relocations(eb, &eb->exec[i]);
>>                  if (err)
>>                          goto err;
>>
>> @@ -1880,7 +1889,7 @@ static int eb_prefault_relocations(const struct i915_execbuffer *eb)
>>          for (i = 0; i < count; i++) {
>>                  int err;
>>
>> -               err = check_relocations(&eb->exec[i]);
>> +               err = check_relocations(eb, &eb->exec[i]);
>>                  if (err)
>>                          return err;
>>          }
>> --
>> 2.29.2
>>
>> _______________________________________________
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH] i915: Drop relocation support on all new hardware (v3)

[Matthew Auld]

On 11/03/2021 08:14, Lucas De Marchi wrote:
> On Wed, Mar 10, 2021 at 1:50 PM Jason Ekstrand <jason@jlekstrand.net> wrote:
>>
>> The Vulkan driver in Mesa for Intel hardware never uses relocations if
>> it's running on a version of i915 that supports at least softpin which
>> all versions of i915 supporting Gen12 do.  On the OpenGL side, Gen12+ is
>> only supported by iris which never uses relocations.  The older i965
>> driver in Mesa does use relocations but it only supports Intel hardware
>> through Gen11 and has been deprecated for all hardware Gen9+.  The
>> compute driver also never uses relocations.  This only leaves the media
>> driver which is supposed to be switching to softpin going forward.
>> Making softpin a requirement for all future hardware seems reasonable.
>>
>> Rejecting relocations starting with Gen12 has the benefit that we don't
>> have to bother supporting it on platforms with local memory.  Given how
>> much CPU touching of memory is required for relocations, not having to
>> do so on platforms where not all memory is directly CPU-accessible
>> carries significant advantages.
>>
>> v2 (Jason Ekstrand):
>>   - Allow TGL-LP platforms as they've already shipped
>>
>> v3 (Jason Ekstrand):
>>   - WARN_ON platforms with LMEM support in case the check is wrong
>>
>> Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
>> Cc: Dave Airlie <airlied@redhat.com>
>> Cc: Daniel Vetter <daniel.vetter@intel.com>
>> ---
>>   drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 15 ++++++++++++---
>>   1 file changed, 12 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
>> index 99772f37bff60..b02dbd16bfa03 100644
>> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
>> @@ -1764,7 +1764,8 @@ eb_relocate_vma_slow(struct i915_execbuffer *eb, struct eb_vma *ev)
>>          return err;
>>   }
>>
>> -static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
>> +static int check_relocations(const struct i915_execbuffer *eb,
>> +                            const struct drm_i915_gem_exec_object2 *entry)
>>   {
>>          const char __user *addr, *end;
>>          unsigned long size;
>> @@ -1774,6 +1775,14 @@ static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
>>          if (size == 0)
>>                  return 0;
>>
>> +       /* Relocations are disallowed for all platforms after TGL-LP */
>> +       if (INTEL_GEN(eb->i915) >= 12 && !IS_TIGERLAKE(eb->i915))
>> +               return -EINVAL;
>> +
>> +       /* All discrete memory platforms are Gen12 or above */
>> +       if (WARN_ON(HAS_LMEM(eb->i915)))
> 
> HAS_LMEM() will return true for the fake lmem support, which may be < gen12.
> Dropping the fake lmem would be a possibility.

Nothing in CI is currently using the fake-lmem configuration(for some 
months now I think), also its use was limited only to the selftests, 
which can't hit this path, so shouldn't matter here. Plan was to just 
drop it.

> 
> Lucas De Marchi
> 
>> +               return -EINVAL;
>> +
>>          if (size > N_RELOC(ULONG_MAX))
>>                  return -EINVAL;
>>
>> @@ -1807,7 +1816,7 @@ static int eb_copy_relocations(const struct i915_execbuffer *eb)
>>                  if (nreloc == 0)
>>                          continue;
>>
>> -               err = check_relocations(&eb->exec[i]);
>> +               err = check_relocations(eb, &eb->exec[i]);
>>                  if (err)
>>                          goto err;
>>
>> @@ -1880,7 +1889,7 @@ static int eb_prefault_relocations(const struct i915_execbuffer *eb)
>>          for (i = 0; i < count; i++) {
>>                  int err;
>>
>> -               err = check_relocations(&eb->exec[i]);
>> +               err = check_relocations(eb, &eb->exec[i]);
>>                  if (err)
>>                          return err;
>>          }
>> --
>> 2.29.2
>>
>> _______________________________________________
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] i915: Drop relocation support on all new hardware (v3)

[Zbigniew Kempczyński]

On Wed, Mar 10, 2021 at 03:50:07PM -0600, Jason Ekstrand wrote:
> The Vulkan driver in Mesa for Intel hardware never uses relocations if
> it's running on a version of i915 that supports at least softpin which
> all versions of i915 supporting Gen12 do.  On the OpenGL side, Gen12+ is
> only supported by iris which never uses relocations.  The older i965
> driver in Mesa does use relocations but it only supports Intel hardware
> through Gen11 and has been deprecated for all hardware Gen9+.  The
> compute driver also never uses relocations.  This only leaves the media
> driver which is supposed to be switching to softpin going forward.
> Making softpin a requirement for all future hardware seems reasonable.
> 
> Rejecting relocations starting with Gen12 has the benefit that we don't
> have to bother supporting it on platforms with local memory.  Given how
> much CPU touching of memory is required for relocations, not having to
> do so on platforms where not all memory is directly CPU-accessible
> carries significant advantages.
> 
> v2 (Jason Ekstrand):
>  - Allow TGL-LP platforms as they've already shipped
> 
> v3 (Jason Ekstrand):
>  - WARN_ON platforms with LMEM support in case the check is wrong

I was asked to review of this patch. It works along with expected
IGT check https://patchwork.freedesktop.org/patch/423361/?series=82954&rev=25

Before I'll give you r-b - isn't i915_gem_execbuffer2_ioctl() better place
to do for loop just after copy_from_user() and check relocation_count?
We have an access to exec2_list there, we know the gen so we're able to say
relocations are not supported immediate, without entering i915_gem_do_execbuffer().

--
Zbigniew

> 
> Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
> Cc: Dave Airlie <airlied@redhat.com>
> Cc: Daniel Vetter <daniel.vetter@intel.com>
> ---
>  drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 15 ++++++++++++---
>  1 file changed, 12 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index 99772f37bff60..b02dbd16bfa03 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -1764,7 +1764,8 @@ eb_relocate_vma_slow(struct i915_execbuffer *eb, struct eb_vma *ev)
>  	return err;
>  }
>  
> -static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
> +static int check_relocations(const struct i915_execbuffer *eb,
> +			     const struct drm_i915_gem_exec_object2 *entry)
>  {
>  	const char __user *addr, *end;
>  	unsigned long size;
> @@ -1774,6 +1775,14 @@ static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
>  	if (size == 0)
>  		return 0;
>  
> +	/* Relocations are disallowed for all platforms after TGL-LP */
> +	if (INTEL_GEN(eb->i915) >= 12 && !IS_TIGERLAKE(eb->i915))
> +		return -EINVAL;
> +
> +	/* All discrete memory platforms are Gen12 or above */
> +	if (WARN_ON(HAS_LMEM(eb->i915)))
> +		return -EINVAL;
> +
>  	if (size > N_RELOC(ULONG_MAX))
>  		return -EINVAL;
>  
> @@ -1807,7 +1816,7 @@ static int eb_copy_relocations(const struct i915_execbuffer *eb)
>  		if (nreloc == 0)
>  			continue;
>  
> -		err = check_relocations(&eb->exec[i]);
> +		err = check_relocations(eb, &eb->exec[i]);
>  		if (err)
>  			goto err;
>  
> @@ -1880,7 +1889,7 @@ static int eb_prefault_relocations(const struct i915_execbuffer *eb)
>  	for (i = 0; i < count; i++) {
>  		int err;
>  
> -		err = check_relocations(&eb->exec[i]);
> +		err = check_relocations(eb, &eb->exec[i]);
>  		if (err)
>  			return err;
>  	}
> -- 
> 2.29.2
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH] i915: Drop relocation support on all new hardware (v3)

[Zbigniew Kempczyński]

On Wed, Mar 10, 2021 at 03:50:07PM -0600, Jason Ekstrand wrote:
> The Vulkan driver in Mesa for Intel hardware never uses relocations if
> it's running on a version of i915 that supports at least softpin which
> all versions of i915 supporting Gen12 do.  On the OpenGL side, Gen12+ is
> only supported by iris which never uses relocations.  The older i965
> driver in Mesa does use relocations but it only supports Intel hardware
> through Gen11 and has been deprecated for all hardware Gen9+.  The
> compute driver also never uses relocations.  This only leaves the media
> driver which is supposed to be switching to softpin going forward.
> Making softpin a requirement for all future hardware seems reasonable.
> 
> Rejecting relocations starting with Gen12 has the benefit that we don't
> have to bother supporting it on platforms with local memory.  Given how
> much CPU touching of memory is required for relocations, not having to
> do so on platforms where not all memory is directly CPU-accessible
> carries significant advantages.
> 
> v2 (Jason Ekstrand):
>  - Allow TGL-LP platforms as they've already shipped
> 
> v3 (Jason Ekstrand):
>  - WARN_ON platforms with LMEM support in case the check is wrong

I was asked to review of this patch. It works along with expected
IGT check https://patchwork.freedesktop.org/patch/423361/?series=82954&rev=25

Before I'll give you r-b - isn't i915_gem_execbuffer2_ioctl() better place
to do for loop just after copy_from_user() and check relocation_count?
We have an access to exec2_list there, we know the gen so we're able to say
relocations are not supported immediate, without entering i915_gem_do_execbuffer().

--
Zbigniew

> 
> Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
> Cc: Dave Airlie <airlied@redhat.com>
> Cc: Daniel Vetter <daniel.vetter@intel.com>
> ---
>  drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 15 ++++++++++++---
>  1 file changed, 12 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index 99772f37bff60..b02dbd16bfa03 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -1764,7 +1764,8 @@ eb_relocate_vma_slow(struct i915_execbuffer *eb, struct eb_vma *ev)
>  	return err;
>  }
>  
> -static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
> +static int check_relocations(const struct i915_execbuffer *eb,
> +			     const struct drm_i915_gem_exec_object2 *entry)
>  {
>  	const char __user *addr, *end;
>  	unsigned long size;
> @@ -1774,6 +1775,14 @@ static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
>  	if (size == 0)
>  		return 0;
>  
> +	/* Relocations are disallowed for all platforms after TGL-LP */
> +	if (INTEL_GEN(eb->i915) >= 12 && !IS_TIGERLAKE(eb->i915))
> +		return -EINVAL;
> +
> +	/* All discrete memory platforms are Gen12 or above */
> +	if (WARN_ON(HAS_LMEM(eb->i915)))
> +		return -EINVAL;
> +
>  	if (size > N_RELOC(ULONG_MAX))
>  		return -EINVAL;
>  
> @@ -1807,7 +1816,7 @@ static int eb_copy_relocations(const struct i915_execbuffer *eb)
>  		if (nreloc == 0)
>  			continue;
>  
> -		err = check_relocations(&eb->exec[i]);
> +		err = check_relocations(eb, &eb->exec[i]);
>  		if (err)
>  			goto err;
>  
> @@ -1880,7 +1889,7 @@ static int eb_prefault_relocations(const struct i915_execbuffer *eb)
>  	for (i = 0; i < count; i++) {
>  		int err;
>  
> -		err = check_relocations(&eb->exec[i]);
> +		err = check_relocations(eb, &eb->exec[i]);
>  		if (err)
>  			return err;
>  	}
> -- 
> 2.29.2
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] i915: Drop relocation support on all new hardware (v3)

[Jason Ekstrand]

On Thu, Mar 11, 2021 at 5:44 AM Zbigniew Kempczyński
<zbigniew.kempczynski@intel.com> wrote:
>
> On Wed, Mar 10, 2021 at 03:50:07PM -0600, Jason Ekstrand wrote:
> > The Vulkan driver in Mesa for Intel hardware never uses relocations if
> > it's running on a version of i915 that supports at least softpin which
> > all versions of i915 supporting Gen12 do.  On the OpenGL side, Gen12+ is
> > only supported by iris which never uses relocations.  The older i965
> > driver in Mesa does use relocations but it only supports Intel hardware
> > through Gen11 and has been deprecated for all hardware Gen9+.  The
> > compute driver also never uses relocations.  This only leaves the media
> > driver which is supposed to be switching to softpin going forward.
> > Making softpin a requirement for all future hardware seems reasonable.
> >
> > Rejecting relocations starting with Gen12 has the benefit that we don't
> > have to bother supporting it on platforms with local memory.  Given how
> > much CPU touching of memory is required for relocations, not having to
> > do so on platforms where not all memory is directly CPU-accessible
> > carries significant advantages.
> >
> > v2 (Jason Ekstrand):
> >  - Allow TGL-LP platforms as they've already shipped
> >
> > v3 (Jason Ekstrand):
> >  - WARN_ON platforms with LMEM support in case the check is wrong
>
> I was asked to review of this patch. It works along with expected
> IGT check https://patchwork.freedesktop.org/patch/423361/?series=82954&rev=25
>
> Before I'll give you r-b - isn't i915_gem_execbuffer2_ioctl() better place
> to do for loop just after copy_from_user() and check relocation_count?
> We have an access to exec2_list there, we know the gen so we're able to say
> relocations are not supported immediate, without entering i915_gem_do_execbuffer().

I considered that but it adds an extra object list walk for a case
which we expect to not happen.  I'm not sure how expensive the list
walk would be if all we do is check the number of relocations on each
object.  I guess, if it comes right after a copy_from_user, it's all
hot in the cache so it shouldn't matter.  Ok.  I've convinced myself.
I'll move it.

--Jason

> --
> Zbigniew
>
> >
> > Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
> > Cc: Dave Airlie <airlied@redhat.com>
> > Cc: Daniel Vetter <daniel.vetter@intel.com>
> > ---
> >  drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 15 ++++++++++++---
> >  1 file changed, 12 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > index 99772f37bff60..b02dbd16bfa03 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > @@ -1764,7 +1764,8 @@ eb_relocate_vma_slow(struct i915_execbuffer *eb, struct eb_vma *ev)
> >       return err;
> >  }
> >
> > -static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
> > +static int check_relocations(const struct i915_execbuffer *eb,
> > +                          const struct drm_i915_gem_exec_object2 *entry)
> >  {
> >       const char __user *addr, *end;
> >       unsigned long size;
> > @@ -1774,6 +1775,14 @@ static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
> >       if (size == 0)
> >               return 0;
> >
> > +     /* Relocations are disallowed for all platforms after TGL-LP */
> > +     if (INTEL_GEN(eb->i915) >= 12 && !IS_TIGERLAKE(eb->i915))
> > +             return -EINVAL;
> > +
> > +     /* All discrete memory platforms are Gen12 or above */
> > +     if (WARN_ON(HAS_LMEM(eb->i915)))
> > +             return -EINVAL;
> > +
> >       if (size > N_RELOC(ULONG_MAX))
> >               return -EINVAL;
> >
> > @@ -1807,7 +1816,7 @@ static int eb_copy_relocations(const struct i915_execbuffer *eb)
> >               if (nreloc == 0)
> >                       continue;
> >
> > -             err = check_relocations(&eb->exec[i]);
> > +             err = check_relocations(eb, &eb->exec[i]);
> >               if (err)
> >                       goto err;
> >
> > @@ -1880,7 +1889,7 @@ static int eb_prefault_relocations(const struct i915_execbuffer *eb)
> >       for (i = 0; i < count; i++) {
> >               int err;
> >
> > -             err = check_relocations(&eb->exec[i]);
> > +             err = check_relocations(eb, &eb->exec[i]);
> >               if (err)
> >                       return err;
> >       }
> > --
> > 2.29.2
> >
> > _______________________________________________
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH] i915: Drop relocation support on all new hardware (v3)

[Jason Ekstrand]

On Thu, Mar 11, 2021 at 5:44 AM Zbigniew Kempczyński
<zbigniew.kempczynski@intel.com> wrote:
>
> On Wed, Mar 10, 2021 at 03:50:07PM -0600, Jason Ekstrand wrote:
> > The Vulkan driver in Mesa for Intel hardware never uses relocations if
> > it's running on a version of i915 that supports at least softpin which
> > all versions of i915 supporting Gen12 do.  On the OpenGL side, Gen12+ is
> > only supported by iris which never uses relocations.  The older i965
> > driver in Mesa does use relocations but it only supports Intel hardware
> > through Gen11 and has been deprecated for all hardware Gen9+.  The
> > compute driver also never uses relocations.  This only leaves the media
> > driver which is supposed to be switching to softpin going forward.
> > Making softpin a requirement for all future hardware seems reasonable.
> >
> > Rejecting relocations starting with Gen12 has the benefit that we don't
> > have to bother supporting it on platforms with local memory.  Given how
> > much CPU touching of memory is required for relocations, not having to
> > do so on platforms where not all memory is directly CPU-accessible
> > carries significant advantages.
> >
> > v2 (Jason Ekstrand):
> >  - Allow TGL-LP platforms as they've already shipped
> >
> > v3 (Jason Ekstrand):
> >  - WARN_ON platforms with LMEM support in case the check is wrong
>
> I was asked to review of this patch. It works along with expected
> IGT check https://patchwork.freedesktop.org/patch/423361/?series=82954&rev=25
>
> Before I'll give you r-b - isn't i915_gem_execbuffer2_ioctl() better place
> to do for loop just after copy_from_user() and check relocation_count?
> We have an access to exec2_list there, we know the gen so we're able to say
> relocations are not supported immediate, without entering i915_gem_do_execbuffer().

I considered that but it adds an extra object list walk for a case
which we expect to not happen.  I'm not sure how expensive the list
walk would be if all we do is check the number of relocations on each
object.  I guess, if it comes right after a copy_from_user, it's all
hot in the cache so it shouldn't matter.  Ok.  I've convinced myself.
I'll move it.

--Jason

> --
> Zbigniew
>
> >
> > Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
> > Cc: Dave Airlie <airlied@redhat.com>
> > Cc: Daniel Vetter <daniel.vetter@intel.com>
> > ---
> >  drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 15 ++++++++++++---
> >  1 file changed, 12 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > index 99772f37bff60..b02dbd16bfa03 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > @@ -1764,7 +1764,8 @@ eb_relocate_vma_slow(struct i915_execbuffer *eb, struct eb_vma *ev)
> >       return err;
> >  }
> >
> > -static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
> > +static int check_relocations(const struct i915_execbuffer *eb,
> > +                          const struct drm_i915_gem_exec_object2 *entry)
> >  {
> >       const char __user *addr, *end;
> >       unsigned long size;
> > @@ -1774,6 +1775,14 @@ static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
> >       if (size == 0)
> >               return 0;
> >
> > +     /* Relocations are disallowed for all platforms after TGL-LP */
> > +     if (INTEL_GEN(eb->i915) >= 12 && !IS_TIGERLAKE(eb->i915))
> > +             return -EINVAL;
> > +
> > +     /* All discrete memory platforms are Gen12 or above */
> > +     if (WARN_ON(HAS_LMEM(eb->i915)))
> > +             return -EINVAL;
> > +
> >       if (size > N_RELOC(ULONG_MAX))
> >               return -EINVAL;
> >
> > @@ -1807,7 +1816,7 @@ static int eb_copy_relocations(const struct i915_execbuffer *eb)
> >               if (nreloc == 0)
> >                       continue;
> >
> > -             err = check_relocations(&eb->exec[i]);
> > +             err = check_relocations(eb, &eb->exec[i]);
> >               if (err)
> >                       goto err;
> >
> > @@ -1880,7 +1889,7 @@ static int eb_prefault_relocations(const struct i915_execbuffer *eb)
> >       for (i = 0; i < count; i++) {
> >               int err;
> >
> > -             err = check_relocations(&eb->exec[i]);
> > +             err = check_relocations(eb, &eb->exec[i]);
> >               if (err)
> >                       return err;
> >       }
> > --
> > 2.29.2
> >
> > _______________________________________________
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] i915: Drop relocation support on all new hardware (v3)

[Daniel Vetter]

On Thu, Mar 11, 2021 at 4:50 PM Jason Ekstrand <jason@jlekstrand.net> wrote:
>
> On Thu, Mar 11, 2021 at 5:44 AM Zbigniew Kempczyński
> <zbigniew.kempczynski@intel.com> wrote:
> >
> > On Wed, Mar 10, 2021 at 03:50:07PM -0600, Jason Ekstrand wrote:
> > > The Vulkan driver in Mesa for Intel hardware never uses relocations if
> > > it's running on a version of i915 that supports at least softpin which
> > > all versions of i915 supporting Gen12 do.  On the OpenGL side, Gen12+ is
> > > only supported by iris which never uses relocations.  The older i965
> > > driver in Mesa does use relocations but it only supports Intel hardware
> > > through Gen11 and has been deprecated for all hardware Gen9+.  The
> > > compute driver also never uses relocations.  This only leaves the media
> > > driver which is supposed to be switching to softpin going forward.
> > > Making softpin a requirement for all future hardware seems reasonable.
> > >
> > > Rejecting relocations starting with Gen12 has the benefit that we don't
> > > have to bother supporting it on platforms with local memory.  Given how
> > > much CPU touching of memory is required for relocations, not having to
> > > do so on platforms where not all memory is directly CPU-accessible
> > > carries significant advantages.
> > >
> > > v2 (Jason Ekstrand):
> > >  - Allow TGL-LP platforms as they've already shipped
> > >
> > > v3 (Jason Ekstrand):
> > >  - WARN_ON platforms with LMEM support in case the check is wrong
> >
> > I was asked to review of this patch. It works along with expected
> > IGT check https://patchwork.freedesktop.org/patch/423361/?series=82954&rev=25
> >
> > Before I'll give you r-b - isn't i915_gem_execbuffer2_ioctl() better place
> > to do for loop just after copy_from_user() and check relocation_count?
> > We have an access to exec2_list there, we know the gen so we're able to say
> > relocations are not supported immediate, without entering i915_gem_do_execbuffer().
>
> I considered that but it adds an extra object list walk for a case
> which we expect to not happen.  I'm not sure how expensive the list
> walk would be if all we do is check the number of relocations on each
> object.  I guess, if it comes right after a copy_from_user, it's all
> hot in the cache so it shouldn't matter.  Ok.  I've convinced myself.
> I'll move it.

I really wouldn't move it if it's another list walk. Execbuf has a lot
of fast-paths going on, and we have extensive tests to make sure it
unwinds correctly in all cases. It's not very intuitive, but execbuf
code isn't scoring very high on that.
-Daniel

>
> --Jason
>
> > --
> > Zbigniew
> >
> > >
> > > Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
> > > Cc: Dave Airlie <airlied@redhat.com>
> > > Cc: Daniel Vetter <daniel.vetter@intel.com>
> > > ---
> > >  drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 15 ++++++++++++---
> > >  1 file changed, 12 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > index 99772f37bff60..b02dbd16bfa03 100644
> > > --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > @@ -1764,7 +1764,8 @@ eb_relocate_vma_slow(struct i915_execbuffer *eb, struct eb_vma *ev)
> > >       return err;
> > >  }
> > >
> > > -static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
> > > +static int check_relocations(const struct i915_execbuffer *eb,
> > > +                          const struct drm_i915_gem_exec_object2 *entry)
> > >  {
> > >       const char __user *addr, *end;
> > >       unsigned long size;
> > > @@ -1774,6 +1775,14 @@ static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
> > >       if (size == 0)
> > >               return 0;
> > >
> > > +     /* Relocations are disallowed for all platforms after TGL-LP */
> > > +     if (INTEL_GEN(eb->i915) >= 12 && !IS_TIGERLAKE(eb->i915))
> > > +             return -EINVAL;
> > > +
> > > +     /* All discrete memory platforms are Gen12 or above */
> > > +     if (WARN_ON(HAS_LMEM(eb->i915)))
> > > +             return -EINVAL;
> > > +
> > >       if (size > N_RELOC(ULONG_MAX))
> > >               return -EINVAL;
> > >
> > > @@ -1807,7 +1816,7 @@ static int eb_copy_relocations(const struct i915_execbuffer *eb)
> > >               if (nreloc == 0)
> > >                       continue;
> > >
> > > -             err = check_relocations(&eb->exec[i]);
> > > +             err = check_relocations(eb, &eb->exec[i]);
> > >               if (err)
> > >                       goto err;
> > >
> > > @@ -1880,7 +1889,7 @@ static int eb_prefault_relocations(const struct i915_execbuffer *eb)
> > >       for (i = 0; i < count; i++) {
> > >               int err;
> > >
> > > -             err = check_relocations(&eb->exec[i]);
> > > +             err = check_relocations(eb, &eb->exec[i]);
> > >               if (err)
> > >                       return err;
> > >       }
> > > --
> > > 2.29.2
> > >
> > > _______________________________________________
> > > dri-devel mailing list
> > > dri-devel@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel



-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH] i915: Drop relocation support on all new hardware (v3)

[Daniel Vetter]

On Thu, Mar 11, 2021 at 4:50 PM Jason Ekstrand <jason@jlekstrand.net> wrote:
>
> On Thu, Mar 11, 2021 at 5:44 AM Zbigniew Kempczyński
> <zbigniew.kempczynski@intel.com> wrote:
> >
> > On Wed, Mar 10, 2021 at 03:50:07PM -0600, Jason Ekstrand wrote:
> > > The Vulkan driver in Mesa for Intel hardware never uses relocations if
> > > it's running on a version of i915 that supports at least softpin which
> > > all versions of i915 supporting Gen12 do.  On the OpenGL side, Gen12+ is
> > > only supported by iris which never uses relocations.  The older i965
> > > driver in Mesa does use relocations but it only supports Intel hardware
> > > through Gen11 and has been deprecated for all hardware Gen9+.  The
> > > compute driver also never uses relocations.  This only leaves the media
> > > driver which is supposed to be switching to softpin going forward.
> > > Making softpin a requirement for all future hardware seems reasonable.
> > >
> > > Rejecting relocations starting with Gen12 has the benefit that we don't
> > > have to bother supporting it on platforms with local memory.  Given how
> > > much CPU touching of memory is required for relocations, not having to
> > > do so on platforms where not all memory is directly CPU-accessible
> > > carries significant advantages.
> > >
> > > v2 (Jason Ekstrand):
> > >  - Allow TGL-LP platforms as they've already shipped
> > >
> > > v3 (Jason Ekstrand):
> > >  - WARN_ON platforms with LMEM support in case the check is wrong
> >
> > I was asked to review of this patch. It works along with expected
> > IGT check https://patchwork.freedesktop.org/patch/423361/?series=82954&rev=25
> >
> > Before I'll give you r-b - isn't i915_gem_execbuffer2_ioctl() better place
> > to do for loop just after copy_from_user() and check relocation_count?
> > We have an access to exec2_list there, we know the gen so we're able to say
> > relocations are not supported immediate, without entering i915_gem_do_execbuffer().
>
> I considered that but it adds an extra object list walk for a case
> which we expect to not happen.  I'm not sure how expensive the list
> walk would be if all we do is check the number of relocations on each
> object.  I guess, if it comes right after a copy_from_user, it's all
> hot in the cache so it shouldn't matter.  Ok.  I've convinced myself.
> I'll move it.

I really wouldn't move it if it's another list walk. Execbuf has a lot
of fast-paths going on, and we have extensive tests to make sure it
unwinds correctly in all cases. It's not very intuitive, but execbuf
code isn't scoring very high on that.
-Daniel

>
> --Jason
>
> > --
> > Zbigniew
> >
> > >
> > > Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
> > > Cc: Dave Airlie <airlied@redhat.com>
> > > Cc: Daniel Vetter <daniel.vetter@intel.com>
> > > ---
> > >  drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 15 ++++++++++++---
> > >  1 file changed, 12 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > index 99772f37bff60..b02dbd16bfa03 100644
> > > --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > @@ -1764,7 +1764,8 @@ eb_relocate_vma_slow(struct i915_execbuffer *eb, struct eb_vma *ev)
> > >       return err;
> > >  }
> > >
> > > -static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
> > > +static int check_relocations(const struct i915_execbuffer *eb,
> > > +                          const struct drm_i915_gem_exec_object2 *entry)
> > >  {
> > >       const char __user *addr, *end;
> > >       unsigned long size;
> > > @@ -1774,6 +1775,14 @@ static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
> > >       if (size == 0)
> > >               return 0;
> > >
> > > +     /* Relocations are disallowed for all platforms after TGL-LP */
> > > +     if (INTEL_GEN(eb->i915) >= 12 && !IS_TIGERLAKE(eb->i915))
> > > +             return -EINVAL;
> > > +
> > > +     /* All discrete memory platforms are Gen12 or above */
> > > +     if (WARN_ON(HAS_LMEM(eb->i915)))
> > > +             return -EINVAL;
> > > +
> > >       if (size > N_RELOC(ULONG_MAX))
> > >               return -EINVAL;
> > >
> > > @@ -1807,7 +1816,7 @@ static int eb_copy_relocations(const struct i915_execbuffer *eb)
> > >               if (nreloc == 0)
> > >                       continue;
> > >
> > > -             err = check_relocations(&eb->exec[i]);
> > > +             err = check_relocations(eb, &eb->exec[i]);
> > >               if (err)
> > >                       goto err;
> > >
> > > @@ -1880,7 +1889,7 @@ static int eb_prefault_relocations(const struct i915_execbuffer *eb)
> > >       for (i = 0; i < count; i++) {
> > >               int err;
> > >
> > > -             err = check_relocations(&eb->exec[i]);
> > > +             err = check_relocations(eb, &eb->exec[i]);
> > >               if (err)
> > >                       return err;
> > >       }
> > > --
> > > 2.29.2
> > >
> > > _______________________________________________
> > > dri-devel mailing list
> > > dri-devel@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel



-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] i915: Drop relocation support on all new hardware (v3)

[Jason Ekstrand]

On Thu, Mar 11, 2021 at 9:57 AM Daniel Vetter <daniel@ffwll.ch> wrote:
>
> On Thu, Mar 11, 2021 at 4:50 PM Jason Ekstrand <jason@jlekstrand.net> wrote:
> >
> > On Thu, Mar 11, 2021 at 5:44 AM Zbigniew Kempczyński
> > <zbigniew.kempczynski@intel.com> wrote:
> > >
> > > On Wed, Mar 10, 2021 at 03:50:07PM -0600, Jason Ekstrand wrote:
> > > > The Vulkan driver in Mesa for Intel hardware never uses relocations if
> > > > it's running on a version of i915 that supports at least softpin which
> > > > all versions of i915 supporting Gen12 do.  On the OpenGL side, Gen12+ is
> > > > only supported by iris which never uses relocations.  The older i965
> > > > driver in Mesa does use relocations but it only supports Intel hardware
> > > > through Gen11 and has been deprecated for all hardware Gen9+.  The
> > > > compute driver also never uses relocations.  This only leaves the media
> > > > driver which is supposed to be switching to softpin going forward.
> > > > Making softpin a requirement for all future hardware seems reasonable.
> > > >
> > > > Rejecting relocations starting with Gen12 has the benefit that we don't
> > > > have to bother supporting it on platforms with local memory.  Given how
> > > > much CPU touching of memory is required for relocations, not having to
> > > > do so on platforms where not all memory is directly CPU-accessible
> > > > carries significant advantages.
> > > >
> > > > v2 (Jason Ekstrand):
> > > >  - Allow TGL-LP platforms as they've already shipped
> > > >
> > > > v3 (Jason Ekstrand):
> > > >  - WARN_ON platforms with LMEM support in case the check is wrong
> > >
> > > I was asked to review of this patch. It works along with expected
> > > IGT check https://patchwork.freedesktop.org/patch/423361/?series=82954&rev=25
> > >
> > > Before I'll give you r-b - isn't i915_gem_execbuffer2_ioctl() better place
> > > to do for loop just after copy_from_user() and check relocation_count?
> > > We have an access to exec2_list there, we know the gen so we're able to say
> > > relocations are not supported immediate, without entering i915_gem_do_execbuffer().
> >
> > I considered that but it adds an extra object list walk for a case
> > which we expect to not happen.  I'm not sure how expensive the list
> > walk would be if all we do is check the number of relocations on each
> > object.  I guess, if it comes right after a copy_from_user, it's all
> > hot in the cache so it shouldn't matter.  Ok.  I've convinced myself.
> > I'll move it.
>
> I really wouldn't move it if it's another list walk. Execbuf has a lot
> of fast-paths going on, and we have extensive tests to make sure it
> unwinds correctly in all cases. It's not very intuitive, but execbuf
> code isn't scoring very high on that.

And here I'd just finished doing the typing to move it.  Good thing I
hadn't closed vim yet and it was still in my undo buffer. :-)

--Jason

> -Daniel
>
> >
> > --Jason
> >
> > > --
> > > Zbigniew
> > >
> > > >
> > > > Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
> > > > Cc: Dave Airlie <airlied@redhat.com>
> > > > Cc: Daniel Vetter <daniel.vetter@intel.com>
> > > > ---
> > > >  drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 15 ++++++++++++---
> > > >  1 file changed, 12 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > > index 99772f37bff60..b02dbd16bfa03 100644
> > > > --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > > @@ -1764,7 +1764,8 @@ eb_relocate_vma_slow(struct i915_execbuffer *eb, struct eb_vma *ev)
> > > >       return err;
> > > >  }
> > > >
> > > > -static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
> > > > +static int check_relocations(const struct i915_execbuffer *eb,
> > > > +                          const struct drm_i915_gem_exec_object2 *entry)
> > > >  {
> > > >       const char __user *addr, *end;
> > > >       unsigned long size;
> > > > @@ -1774,6 +1775,14 @@ static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
> > > >       if (size == 0)
> > > >               return 0;
> > > >
> > > > +     /* Relocations are disallowed for all platforms after TGL-LP */
> > > > +     if (INTEL_GEN(eb->i915) >= 12 && !IS_TIGERLAKE(eb->i915))
> > > > +             return -EINVAL;
> > > > +
> > > > +     /* All discrete memory platforms are Gen12 or above */
> > > > +     if (WARN_ON(HAS_LMEM(eb->i915)))
> > > > +             return -EINVAL;
> > > > +
> > > >       if (size > N_RELOC(ULONG_MAX))
> > > >               return -EINVAL;
> > > >
> > > > @@ -1807,7 +1816,7 @@ static int eb_copy_relocations(const struct i915_execbuffer *eb)
> > > >               if (nreloc == 0)
> > > >                       continue;
> > > >
> > > > -             err = check_relocations(&eb->exec[i]);
> > > > +             err = check_relocations(eb, &eb->exec[i]);
> > > >               if (err)
> > > >                       goto err;
> > > >
> > > > @@ -1880,7 +1889,7 @@ static int eb_prefault_relocations(const struct i915_execbuffer *eb)
> > > >       for (i = 0; i < count; i++) {
> > > >               int err;
> > > >
> > > > -             err = check_relocations(&eb->exec[i]);
> > > > +             err = check_relocations(eb, &eb->exec[i]);
> > > >               if (err)
> > > >                       return err;
> > > >       }
> > > > --
> > > > 2.29.2
> > > >
> > > > _______________________________________________
> > > > dri-devel mailing list
> > > > dri-devel@lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > _______________________________________________
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH] i915: Drop relocation support on all new hardware (v3)

[Jason Ekstrand]

On Thu, Mar 11, 2021 at 9:57 AM Daniel Vetter <daniel@ffwll.ch> wrote:
>
> On Thu, Mar 11, 2021 at 4:50 PM Jason Ekstrand <jason@jlekstrand.net> wrote:
> >
> > On Thu, Mar 11, 2021 at 5:44 AM Zbigniew Kempczyński
> > <zbigniew.kempczynski@intel.com> wrote:
> > >
> > > On Wed, Mar 10, 2021 at 03:50:07PM -0600, Jason Ekstrand wrote:
> > > > The Vulkan driver in Mesa for Intel hardware never uses relocations if
> > > > it's running on a version of i915 that supports at least softpin which
> > > > all versions of i915 supporting Gen12 do.  On the OpenGL side, Gen12+ is
> > > > only supported by iris which never uses relocations.  The older i965
> > > > driver in Mesa does use relocations but it only supports Intel hardware
> > > > through Gen11 and has been deprecated for all hardware Gen9+.  The
> > > > compute driver also never uses relocations.  This only leaves the media
> > > > driver which is supposed to be switching to softpin going forward.
> > > > Making softpin a requirement for all future hardware seems reasonable.
> > > >
> > > > Rejecting relocations starting with Gen12 has the benefit that we don't
> > > > have to bother supporting it on platforms with local memory.  Given how
> > > > much CPU touching of memory is required for relocations, not having to
> > > > do so on platforms where not all memory is directly CPU-accessible
> > > > carries significant advantages.
> > > >
> > > > v2 (Jason Ekstrand):
> > > >  - Allow TGL-LP platforms as they've already shipped
> > > >
> > > > v3 (Jason Ekstrand):
> > > >  - WARN_ON platforms with LMEM support in case the check is wrong
> > >
> > > I was asked to review of this patch. It works along with expected
> > > IGT check https://patchwork.freedesktop.org/patch/423361/?series=82954&rev=25
> > >
> > > Before I'll give you r-b - isn't i915_gem_execbuffer2_ioctl() better place
> > > to do for loop just after copy_from_user() and check relocation_count?
> > > We have an access to exec2_list there, we know the gen so we're able to say
> > > relocations are not supported immediate, without entering i915_gem_do_execbuffer().
> >
> > I considered that but it adds an extra object list walk for a case
> > which we expect to not happen.  I'm not sure how expensive the list
> > walk would be if all we do is check the number of relocations on each
> > object.  I guess, if it comes right after a copy_from_user, it's all
> > hot in the cache so it shouldn't matter.  Ok.  I've convinced myself.
> > I'll move it.
>
> I really wouldn't move it if it's another list walk. Execbuf has a lot
> of fast-paths going on, and we have extensive tests to make sure it
> unwinds correctly in all cases. It's not very intuitive, but execbuf
> code isn't scoring very high on that.

And here I'd just finished doing the typing to move it.  Good thing I
hadn't closed vim yet and it was still in my undo buffer. :-)

--Jason

> -Daniel
>
> >
> > --Jason
> >
> > > --
> > > Zbigniew
> > >
> > > >
> > > > Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
> > > > Cc: Dave Airlie <airlied@redhat.com>
> > > > Cc: Daniel Vetter <daniel.vetter@intel.com>
> > > > ---
> > > >  drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 15 ++++++++++++---
> > > >  1 file changed, 12 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > > index 99772f37bff60..b02dbd16bfa03 100644
> > > > --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > > @@ -1764,7 +1764,8 @@ eb_relocate_vma_slow(struct i915_execbuffer *eb, struct eb_vma *ev)
> > > >       return err;
> > > >  }
> > > >
> > > > -static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
> > > > +static int check_relocations(const struct i915_execbuffer *eb,
> > > > +                          const struct drm_i915_gem_exec_object2 *entry)
> > > >  {
> > > >       const char __user *addr, *end;
> > > >       unsigned long size;
> > > > @@ -1774,6 +1775,14 @@ static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
> > > >       if (size == 0)
> > > >               return 0;
> > > >
> > > > +     /* Relocations are disallowed for all platforms after TGL-LP */
> > > > +     if (INTEL_GEN(eb->i915) >= 12 && !IS_TIGERLAKE(eb->i915))
> > > > +             return -EINVAL;
> > > > +
> > > > +     /* All discrete memory platforms are Gen12 or above */
> > > > +     if (WARN_ON(HAS_LMEM(eb->i915)))
> > > > +             return -EINVAL;
> > > > +
> > > >       if (size > N_RELOC(ULONG_MAX))
> > > >               return -EINVAL;
> > > >
> > > > @@ -1807,7 +1816,7 @@ static int eb_copy_relocations(const struct i915_execbuffer *eb)
> > > >               if (nreloc == 0)
> > > >                       continue;
> > > >
> > > > -             err = check_relocations(&eb->exec[i]);
> > > > +             err = check_relocations(eb, &eb->exec[i]);
> > > >               if (err)
> > > >                       goto err;
> > > >
> > > > @@ -1880,7 +1889,7 @@ static int eb_prefault_relocations(const struct i915_execbuffer *eb)
> > > >       for (i = 0; i < count; i++) {
> > > >               int err;
> > > >
> > > > -             err = check_relocations(&eb->exec[i]);
> > > > +             err = check_relocations(eb, &eb->exec[i]);
> > > >               if (err)
> > > >                       return err;
> > > >       }
> > > > --
> > > > 2.29.2
> > > >
> > > > _______________________________________________
> > > > dri-devel mailing list
> > > > dri-devel@lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > _______________________________________________
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH] drm/i915/gem: Drop relocation support on all new hardware (v4)

[Jason Ekstrand]

The Vulkan driver in Mesa for Intel hardware never uses relocations if
it's running on a version of i915 that supports at least softpin which
all versions of i915 supporting Gen12 do.  On the OpenGL side, Gen12+ is
only supported by iris which never uses relocations.  The older i965
driver in Mesa does use relocations but it only supports Intel hardware
through Gen11 and has been deprecated for all hardware Gen9+.  The
compute driver also never uses relocations.  This only leaves the media
driver which is supposed to be switching to softpin going forward.
Making softpin a requirement for all future hardware seems reasonable.

There is one piece of hardware enabled by default in i915: RKL which was
enabled by e22fa6f0a976 which has not yet landed in drm-next so this
almost but not really a userspace API change for RKL.  If it becomes a
problem, we can always add !IS_ROCKETLAKE(eb->i915) to the condition.

Rejecting relocations starting with newer Gen12 platforms has the
benefit that we don't have to bother supporting it on platforms with
local memory.  Given how much CPU touching of memory is required for
relocations, not having to do so on platforms where not all memory is
directly CPU-accessible carries significant advantages.

v2 (Jason Ekstrand):
 - Allow TGL-LP platforms as they've already shipped

v3 (Jason Ekstrand):
 - WARN_ON platforms with LMEM support in case the check is wrong

v4 (Jason Ekstrand):
 - Call out Rocket Lake in the commit message

Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Acked-by: Keith Packard <keithp@keithp.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
---
 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 15 ++++++++++++---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 99772f37bff60..b02dbd16bfa03 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1764,7 +1764,8 @@ eb_relocate_vma_slow(struct i915_execbuffer *eb, struct eb_vma *ev)
 	return err;
 }
 
-static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
+static int check_relocations(const struct i915_execbuffer *eb,
+			     const struct drm_i915_gem_exec_object2 *entry)
 {
 	const char __user *addr, *end;
 	unsigned long size;
@@ -1774,6 +1775,14 @@ static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
 	if (size == 0)
 		return 0;
 
+	/* Relocations are disallowed for all platforms after TGL-LP */
+	if (INTEL_GEN(eb->i915) >= 12 && !IS_TIGERLAKE(eb->i915))
+		return -EINVAL;
+
+	/* All discrete memory platforms are Gen12 or above */
+	if (WARN_ON(HAS_LMEM(eb->i915)))
+		return -EINVAL;
+
 	if (size > N_RELOC(ULONG_MAX))
 		return -EINVAL;
 
@@ -1807,7 +1816,7 @@ static int eb_copy_relocations(const struct i915_execbuffer *eb)
 		if (nreloc == 0)
 			continue;
 
-		err = check_relocations(&eb->exec[i]);
+		err = check_relocations(eb, &eb->exec[i]);
 		if (err)
 			goto err;
 
@@ -1880,7 +1889,7 @@ static int eb_prefault_relocations(const struct i915_execbuffer *eb)
 	for (i = 0; i < count; i++) {
 		int err;
 
-		err = check_relocations(&eb->exec[i]);
+		err = check_relocations(eb, &eb->exec[i]);
 		if (err)
 			return err;
 	}
-- 
2.29.2

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] i915: Drop relocation support on all new hardware (v3)

[Chris Wilson]

Quoting Zbigniew Kempczyński (2021-03-11 11:44:32)
> On Wed, Mar 10, 2021 at 03:50:07PM -0600, Jason Ekstrand wrote:
> > The Vulkan driver in Mesa for Intel hardware never uses relocations if
> > it's running on a version of i915 that supports at least softpin which
> > all versions of i915 supporting Gen12 do.  On the OpenGL side, Gen12+ is
> > only supported by iris which never uses relocations.  The older i965
> > driver in Mesa does use relocations but it only supports Intel hardware
> > through Gen11 and has been deprecated for all hardware Gen9+.  The
> > compute driver also never uses relocations.  This only leaves the media
> > driver which is supposed to be switching to softpin going forward.
> > Making softpin a requirement for all future hardware seems reasonable.
> > 
> > Rejecting relocations starting with Gen12 has the benefit that we don't
> > have to bother supporting it on platforms with local memory.  Given how
> > much CPU touching of memory is required for relocations, not having to
> > do so on platforms where not all memory is directly CPU-accessible
> > carries significant advantages.
> > 
> > v2 (Jason Ekstrand):
> >  - Allow TGL-LP platforms as they've already shipped
> > 
> > v3 (Jason Ekstrand):
> >  - WARN_ON platforms with LMEM support in case the check is wrong
> 
> I was asked to review of this patch. It works along with expected
> IGT check https://patchwork.freedesktop.org/patch/423361/?series=82954&rev=25
> 
> Before I'll give you r-b - isn't i915_gem_execbuffer2_ioctl() better place
> to do for loop just after copy_from_user() and check relocation_count?
> We have an access to exec2_list there, we know the gen so we're able to say
> relocations are not supported immediate, without entering i915_gem_do_execbuffer().

There's a NORELOC flag you can enforce as mandatory. That's trivial for
userspace to set, really makes sure they are aware of the change afoot,
and i915_gem_ceck_execbuffer() will perform the validation upfront with
the other flag checks.
-Chris
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH] i915: Drop relocation support on all new hardware (v3)

[Chris Wilson]

Quoting Zbigniew Kempczyński (2021-03-11 11:44:32)
> On Wed, Mar 10, 2021 at 03:50:07PM -0600, Jason Ekstrand wrote:
> > The Vulkan driver in Mesa for Intel hardware never uses relocations if
> > it's running on a version of i915 that supports at least softpin which
> > all versions of i915 supporting Gen12 do.  On the OpenGL side, Gen12+ is
> > only supported by iris which never uses relocations.  The older i965
> > driver in Mesa does use relocations but it only supports Intel hardware
> > through Gen11 and has been deprecated for all hardware Gen9+.  The
> > compute driver also never uses relocations.  This only leaves the media
> > driver which is supposed to be switching to softpin going forward.
> > Making softpin a requirement for all future hardware seems reasonable.
> > 
> > Rejecting relocations starting with Gen12 has the benefit that we don't
> > have to bother supporting it on platforms with local memory.  Given how
> > much CPU touching of memory is required for relocations, not having to
> > do so on platforms where not all memory is directly CPU-accessible
> > carries significant advantages.
> > 
> > v2 (Jason Ekstrand):
> >  - Allow TGL-LP platforms as they've already shipped
> > 
> > v3 (Jason Ekstrand):
> >  - WARN_ON platforms with LMEM support in case the check is wrong
> 
> I was asked to review of this patch. It works along with expected
> IGT check https://patchwork.freedesktop.org/patch/423361/?series=82954&rev=25
> 
> Before I'll give you r-b - isn't i915_gem_execbuffer2_ioctl() better place
> to do for loop just after copy_from_user() and check relocation_count?
> We have an access to exec2_list there, we know the gen so we're able to say
> relocations are not supported immediate, without entering i915_gem_do_execbuffer().

There's a NORELOC flag you can enforce as mandatory. That's trivial for
userspace to set, really makes sure they are aware of the change afoot,
and i915_gem_ceck_execbuffer() will perform the validation upfront with
the other flag checks.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] i915: Drop relocation support on all new hardware (v3)

[Jason Ekstrand]

On Thu, Mar 11, 2021 at 10:31 AM Chris Wilson <chris@chris-wilson.co.uk> wrote:
>
> Quoting Zbigniew Kempczyński (2021-03-11 11:44:32)
> > On Wed, Mar 10, 2021 at 03:50:07PM -0600, Jason Ekstrand wrote:
> > > The Vulkan driver in Mesa for Intel hardware never uses relocations if
> > > it's running on a version of i915 that supports at least softpin which
> > > all versions of i915 supporting Gen12 do.  On the OpenGL side, Gen12+ is
> > > only supported by iris which never uses relocations.  The older i965
> > > driver in Mesa does use relocations but it only supports Intel hardware
> > > through Gen11 and has been deprecated for all hardware Gen9+.  The
> > > compute driver also never uses relocations.  This only leaves the media
> > > driver which is supposed to be switching to softpin going forward.
> > > Making softpin a requirement for all future hardware seems reasonable.
> > >
> > > Rejecting relocations starting with Gen12 has the benefit that we don't
> > > have to bother supporting it on platforms with local memory.  Given how
> > > much CPU touching of memory is required for relocations, not having to
> > > do so on platforms where not all memory is directly CPU-accessible
> > > carries significant advantages.
> > >
> > > v2 (Jason Ekstrand):
> > >  - Allow TGL-LP platforms as they've already shipped
> > >
> > > v3 (Jason Ekstrand):
> > >  - WARN_ON platforms with LMEM support in case the check is wrong
> >
> > I was asked to review of this patch. It works along with expected
> > IGT check https://patchwork.freedesktop.org/patch/423361/?series=82954&rev=25
> >
> > Before I'll give you r-b - isn't i915_gem_execbuffer2_ioctl() better place
> > to do for loop just after copy_from_user() and check relocation_count?
> > We have an access to exec2_list there, we know the gen so we're able to say
> > relocations are not supported immediate, without entering i915_gem_do_execbuffer().
>
> There's a NORELOC flag you can enforce as mandatory. That's trivial for
> userspace to set, really makes sure they are aware of the change afoot,
> and i915_gem_ceck_execbuffer() will perform the validation upfront with
> the other flag checks.

NORELOC doesn't quite ensure that there are no relocations; it just
makes things optional if the kernel hasn't moved anything.  I guess we
could require userspace to set it but it also doesn't do anything if
there are no relocations to begin with.  I think I'd personally err on
the side of not requiring pointless flags.

--Jason
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH] i915: Drop relocation support on all new hardware (v3)

[Jason Ekstrand]

On Thu, Mar 11, 2021 at 10:31 AM Chris Wilson <chris@chris-wilson.co.uk> wrote:
>
> Quoting Zbigniew Kempczyński (2021-03-11 11:44:32)
> > On Wed, Mar 10, 2021 at 03:50:07PM -0600, Jason Ekstrand wrote:
> > > The Vulkan driver in Mesa for Intel hardware never uses relocations if
> > > it's running on a version of i915 that supports at least softpin which
> > > all versions of i915 supporting Gen12 do.  On the OpenGL side, Gen12+ is
> > > only supported by iris which never uses relocations.  The older i965
> > > driver in Mesa does use relocations but it only supports Intel hardware
> > > through Gen11 and has been deprecated for all hardware Gen9+.  The
> > > compute driver also never uses relocations.  This only leaves the media
> > > driver which is supposed to be switching to softpin going forward.
> > > Making softpin a requirement for all future hardware seems reasonable.
> > >
> > > Rejecting relocations starting with Gen12 has the benefit that we don't
> > > have to bother supporting it on platforms with local memory.  Given how
> > > much CPU touching of memory is required for relocations, not having to
> > > do so on platforms where not all memory is directly CPU-accessible
> > > carries significant advantages.
> > >
> > > v2 (Jason Ekstrand):
> > >  - Allow TGL-LP platforms as they've already shipped
> > >
> > > v3 (Jason Ekstrand):
> > >  - WARN_ON platforms with LMEM support in case the check is wrong
> >
> > I was asked to review of this patch. It works along with expected
> > IGT check https://patchwork.freedesktop.org/patch/423361/?series=82954&rev=25
> >
> > Before I'll give you r-b - isn't i915_gem_execbuffer2_ioctl() better place
> > to do for loop just after copy_from_user() and check relocation_count?
> > We have an access to exec2_list there, we know the gen so we're able to say
> > relocations are not supported immediate, without entering i915_gem_do_execbuffer().
>
> There's a NORELOC flag you can enforce as mandatory. That's trivial for
> userspace to set, really makes sure they are aware of the change afoot,
> and i915_gem_ceck_execbuffer() will perform the validation upfront with
> the other flag checks.

NORELOC doesn't quite ensure that there are no relocations; it just
makes things optional if the kernel hasn't moved anything.  I guess we
could require userspace to set it but it also doesn't do anything if
there are no relocations to begin with.  I think I'd personally err on
the side of not requiring pointless flags.

--Jason
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] i915: Drop relocation support on all new hardware (v3)

[Zbigniew Kempczyński]

On Thu, Mar 11, 2021 at 10:24:38AM -0600, Jason Ekstrand wrote:
> On Thu, Mar 11, 2021 at 9:57 AM Daniel Vetter <daniel@ffwll.ch> wrote:
> >
> > On Thu, Mar 11, 2021 at 4:50 PM Jason Ekstrand <jason@jlekstrand.net> wrote:
> > >
> > > On Thu, Mar 11, 2021 at 5:44 AM Zbigniew Kempczyński
> > > <zbigniew.kempczynski@intel.com> wrote:
> > > >
> > > > On Wed, Mar 10, 2021 at 03:50:07PM -0600, Jason Ekstrand wrote:
> > > > > The Vulkan driver in Mesa for Intel hardware never uses relocations if
> > > > > it's running on a version of i915 that supports at least softpin which
> > > > > all versions of i915 supporting Gen12 do.  On the OpenGL side, Gen12+ is
> > > > > only supported by iris which never uses relocations.  The older i965
> > > > > driver in Mesa does use relocations but it only supports Intel hardware
> > > > > through Gen11 and has been deprecated for all hardware Gen9+.  The
> > > > > compute driver also never uses relocations.  This only leaves the media
> > > > > driver which is supposed to be switching to softpin going forward.
> > > > > Making softpin a requirement for all future hardware seems reasonable.
> > > > >
> > > > > Rejecting relocations starting with Gen12 has the benefit that we don't
> > > > > have to bother supporting it on platforms with local memory.  Given how
> > > > > much CPU touching of memory is required for relocations, not having to
> > > > > do so on platforms where not all memory is directly CPU-accessible
> > > > > carries significant advantages.
> > > > >
> > > > > v2 (Jason Ekstrand):
> > > > >  - Allow TGL-LP platforms as they've already shipped
> > > > >
> > > > > v3 (Jason Ekstrand):
> > > > >  - WARN_ON platforms with LMEM support in case the check is wrong
> > > >
> > > > I was asked to review of this patch. It works along with expected
> > > > IGT check https://patchwork.freedesktop.org/patch/423361/?series=82954&rev=25
> > > >
> > > > Before I'll give you r-b - isn't i915_gem_execbuffer2_ioctl() better place
> > > > to do for loop just after copy_from_user() and check relocation_count?
> > > > We have an access to exec2_list there, we know the gen so we're able to say
> > > > relocations are not supported immediate, without entering i915_gem_do_execbuffer().
> > >
> > > I considered that but it adds an extra object list walk for a case
> > > which we expect to not happen.  I'm not sure how expensive the list
> > > walk would be if all we do is check the number of relocations on each
> > > object.  I guess, if it comes right after a copy_from_user, it's all
> > > hot in the cache so it shouldn't matter.  Ok.  I've convinced myself.
> > > I'll move it.
> >
> > I really wouldn't move it if it's another list walk. Execbuf has a lot
> > of fast-paths going on, and we have extensive tests to make sure it
> > unwinds correctly in all cases. It's not very intuitive, but execbuf
> > code isn't scoring very high on that.
> 
> And here I'd just finished doing the typing to move it.  Good thing I
> hadn't closed vim yet and it was still in my undo buffer. :-)

Before entering "slower" path from my perspective I would just check
batch object at that place. We still would have single list walkthrough
and quick check on the very beginning.

--
Zbigniew

> 
> --Jason
> 
> > -Daniel
> >
> > >
> > > --Jason
> > >
> > > > --
> > > > Zbigniew
> > > >
> > > > >
> > > > > Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
> > > > > Cc: Dave Airlie <airlied@redhat.com>
> > > > > Cc: Daniel Vetter <daniel.vetter@intel.com>
> > > > > ---
> > > > >  drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 15 ++++++++++++---
> > > > >  1 file changed, 12 insertions(+), 3 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > > > index 99772f37bff60..b02dbd16bfa03 100644
> > > > > --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > > > @@ -1764,7 +1764,8 @@ eb_relocate_vma_slow(struct i915_execbuffer *eb, struct eb_vma *ev)
> > > > >       return err;
> > > > >  }
> > > > >
> > > > > -static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
> > > > > +static int check_relocations(const struct i915_execbuffer *eb,
> > > > > +                          const struct drm_i915_gem_exec_object2 *entry)
> > > > >  {
> > > > >       const char __user *addr, *end;
> > > > >       unsigned long size;
> > > > > @@ -1774,6 +1775,14 @@ static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
> > > > >       if (size == 0)
> > > > >               return 0;
> > > > >
> > > > > +     /* Relocations are disallowed for all platforms after TGL-LP */
> > > > > +     if (INTEL_GEN(eb->i915) >= 12 && !IS_TIGERLAKE(eb->i915))
> > > > > +             return -EINVAL;
> > > > > +
> > > > > +     /* All discrete memory platforms are Gen12 or above */
> > > > > +     if (WARN_ON(HAS_LMEM(eb->i915)))
> > > > > +             return -EINVAL;
> > > > > +
> > > > >       if (size > N_RELOC(ULONG_MAX))
> > > > >               return -EINVAL;
> > > > >
> > > > > @@ -1807,7 +1816,7 @@ static int eb_copy_relocations(const struct i915_execbuffer *eb)
> > > > >               if (nreloc == 0)
> > > > >                       continue;
> > > > >
> > > > > -             err = check_relocations(&eb->exec[i]);
> > > > > +             err = check_relocations(eb, &eb->exec[i]);
> > > > >               if (err)
> > > > >                       goto err;
> > > > >
> > > > > @@ -1880,7 +1889,7 @@ static int eb_prefault_relocations(const struct i915_execbuffer *eb)
> > > > >       for (i = 0; i < count; i++) {
> > > > >               int err;
> > > > >
> > > > > -             err = check_relocations(&eb->exec[i]);
> > > > > +             err = check_relocations(eb, &eb->exec[i]);
> > > > >               if (err)
> > > > >                       return err;
> > > > >       }
> > > > > --
> > > > > 2.29.2
> > > > >
> > > > > _______________________________________________
> > > > > dri-devel mailing list
> > > > > dri-devel@lists.freedesktop.org
> > > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > > _______________________________________________
> > > dri-devel mailing list
> > > dri-devel@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
> >
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH] i915: Drop relocation support on all new hardware (v3)

[Zbigniew Kempczyński]

On Thu, Mar 11, 2021 at 10:24:38AM -0600, Jason Ekstrand wrote:
> On Thu, Mar 11, 2021 at 9:57 AM Daniel Vetter <daniel@ffwll.ch> wrote:
> >
> > On Thu, Mar 11, 2021 at 4:50 PM Jason Ekstrand <jason@jlekstrand.net> wrote:
> > >
> > > On Thu, Mar 11, 2021 at 5:44 AM Zbigniew Kempczyński
> > > <zbigniew.kempczynski@intel.com> wrote:
> > > >
> > > > On Wed, Mar 10, 2021 at 03:50:07PM -0600, Jason Ekstrand wrote:
> > > > > The Vulkan driver in Mesa for Intel hardware never uses relocations if
> > > > > it's running on a version of i915 that supports at least softpin which
> > > > > all versions of i915 supporting Gen12 do.  On the OpenGL side, Gen12+ is
> > > > > only supported by iris which never uses relocations.  The older i965
> > > > > driver in Mesa does use relocations but it only supports Intel hardware
> > > > > through Gen11 and has been deprecated for all hardware Gen9+.  The
> > > > > compute driver also never uses relocations.  This only leaves the media
> > > > > driver which is supposed to be switching to softpin going forward.
> > > > > Making softpin a requirement for all future hardware seems reasonable.
> > > > >
> > > > > Rejecting relocations starting with Gen12 has the benefit that we don't
> > > > > have to bother supporting it on platforms with local memory.  Given how
> > > > > much CPU touching of memory is required for relocations, not having to
> > > > > do so on platforms where not all memory is directly CPU-accessible
> > > > > carries significant advantages.
> > > > >
> > > > > v2 (Jason Ekstrand):
> > > > >  - Allow TGL-LP platforms as they've already shipped
> > > > >
> > > > > v3 (Jason Ekstrand):
> > > > >  - WARN_ON platforms with LMEM support in case the check is wrong
> > > >
> > > > I was asked to review of this patch. It works along with expected
> > > > IGT check https://patchwork.freedesktop.org/patch/423361/?series=82954&rev=25
> > > >
> > > > Before I'll give you r-b - isn't i915_gem_execbuffer2_ioctl() better place
> > > > to do for loop just after copy_from_user() and check relocation_count?
> > > > We have an access to exec2_list there, we know the gen so we're able to say
> > > > relocations are not supported immediate, without entering i915_gem_do_execbuffer().
> > >
> > > I considered that but it adds an extra object list walk for a case
> > > which we expect to not happen.  I'm not sure how expensive the list
> > > walk would be if all we do is check the number of relocations on each
> > > object.  I guess, if it comes right after a copy_from_user, it's all
> > > hot in the cache so it shouldn't matter.  Ok.  I've convinced myself.
> > > I'll move it.
> >
> > I really wouldn't move it if it's another list walk. Execbuf has a lot
> > of fast-paths going on, and we have extensive tests to make sure it
> > unwinds correctly in all cases. It's not very intuitive, but execbuf
> > code isn't scoring very high on that.
> 
> And here I'd just finished doing the typing to move it.  Good thing I
> hadn't closed vim yet and it was still in my undo buffer. :-)

Before entering "slower" path from my perspective I would just check
batch object at that place. We still would have single list walkthrough
and quick check on the very beginning.

--
Zbigniew

> 
> --Jason
> 
> > -Daniel
> >
> > >
> > > --Jason
> > >
> > > > --
> > > > Zbigniew
> > > >
> > > > >
> > > > > Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
> > > > > Cc: Dave Airlie <airlied@redhat.com>
> > > > > Cc: Daniel Vetter <daniel.vetter@intel.com>
> > > > > ---
> > > > >  drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 15 ++++++++++++---
> > > > >  1 file changed, 12 insertions(+), 3 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > > > index 99772f37bff60..b02dbd16bfa03 100644
> > > > > --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > > > @@ -1764,7 +1764,8 @@ eb_relocate_vma_slow(struct i915_execbuffer *eb, struct eb_vma *ev)
> > > > >       return err;
> > > > >  }
> > > > >
> > > > > -static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
> > > > > +static int check_relocations(const struct i915_execbuffer *eb,
> > > > > +                          const struct drm_i915_gem_exec_object2 *entry)
> > > > >  {
> > > > >       const char __user *addr, *end;
> > > > >       unsigned long size;
> > > > > @@ -1774,6 +1775,14 @@ static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
> > > > >       if (size == 0)
> > > > >               return 0;
> > > > >
> > > > > +     /* Relocations are disallowed for all platforms after TGL-LP */
> > > > > +     if (INTEL_GEN(eb->i915) >= 12 && !IS_TIGERLAKE(eb->i915))
> > > > > +             return -EINVAL;
> > > > > +
> > > > > +     /* All discrete memory platforms are Gen12 or above */
> > > > > +     if (WARN_ON(HAS_LMEM(eb->i915)))
> > > > > +             return -EINVAL;
> > > > > +
> > > > >       if (size > N_RELOC(ULONG_MAX))
> > > > >               return -EINVAL;
> > > > >
> > > > > @@ -1807,7 +1816,7 @@ static int eb_copy_relocations(const struct i915_execbuffer *eb)
> > > > >               if (nreloc == 0)
> > > > >                       continue;
> > > > >
> > > > > -             err = check_relocations(&eb->exec[i]);
> > > > > +             err = check_relocations(eb, &eb->exec[i]);
> > > > >               if (err)
> > > > >                       goto err;
> > > > >
> > > > > @@ -1880,7 +1889,7 @@ static int eb_prefault_relocations(const struct i915_execbuffer *eb)
> > > > >       for (i = 0; i < count; i++) {
> > > > >               int err;
> > > > >
> > > > > -             err = check_relocations(&eb->exec[i]);
> > > > > +             err = check_relocations(eb, &eb->exec[i]);
> > > > >               if (err)
> > > > >                       return err;
> > > > >       }
> > > > > --
> > > > > 2.29.2
> > > > >
> > > > > _______________________________________________
> > > > > dri-devel mailing list
> > > > > dri-devel@lists.freedesktop.org
> > > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > > _______________________________________________
> > > dri-devel mailing list
> > > dri-devel@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
> >
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] i915: Drop relocation support on all new hardware (v3)

[Jason Ekstrand]

On Thu, Mar 11, 2021 at 10:51 AM Zbigniew Kempczyński
<zbigniew.kempczynski@intel.com> wrote:
>
> On Thu, Mar 11, 2021 at 10:24:38AM -0600, Jason Ekstrand wrote:
> > On Thu, Mar 11, 2021 at 9:57 AM Daniel Vetter <daniel@ffwll.ch> wrote:
> > >
> > > On Thu, Mar 11, 2021 at 4:50 PM Jason Ekstrand <jason@jlekstrand.net> wrote:
> > > >
> > > > On Thu, Mar 11, 2021 at 5:44 AM Zbigniew Kempczyński
> > > > <zbigniew.kempczynski@intel.com> wrote:
> > > > >
> > > > > On Wed, Mar 10, 2021 at 03:50:07PM -0600, Jason Ekstrand wrote:
> > > > > > The Vulkan driver in Mesa for Intel hardware never uses relocations if
> > > > > > it's running on a version of i915 that supports at least softpin which
> > > > > > all versions of i915 supporting Gen12 do.  On the OpenGL side, Gen12+ is
> > > > > > only supported by iris which never uses relocations.  The older i965
> > > > > > driver in Mesa does use relocations but it only supports Intel hardware
> > > > > > through Gen11 and has been deprecated for all hardware Gen9+.  The
> > > > > > compute driver also never uses relocations.  This only leaves the media
> > > > > > driver which is supposed to be switching to softpin going forward.
> > > > > > Making softpin a requirement for all future hardware seems reasonable.
> > > > > >
> > > > > > Rejecting relocations starting with Gen12 has the benefit that we don't
> > > > > > have to bother supporting it on platforms with local memory.  Given how
> > > > > > much CPU touching of memory is required for relocations, not having to
> > > > > > do so on platforms where not all memory is directly CPU-accessible
> > > > > > carries significant advantages.
> > > > > >
> > > > > > v2 (Jason Ekstrand):
> > > > > >  - Allow TGL-LP platforms as they've already shipped
> > > > > >
> > > > > > v3 (Jason Ekstrand):
> > > > > >  - WARN_ON platforms with LMEM support in case the check is wrong
> > > > >
> > > > > I was asked to review of this patch. It works along with expected
> > > > > IGT check https://patchwork.freedesktop.org/patch/423361/?series=82954&rev=25
> > > > >
> > > > > Before I'll give you r-b - isn't i915_gem_execbuffer2_ioctl() better place
> > > > > to do for loop just after copy_from_user() and check relocation_count?
> > > > > We have an access to exec2_list there, we know the gen so we're able to say
> > > > > relocations are not supported immediate, without entering i915_gem_do_execbuffer().
> > > >
> > > > I considered that but it adds an extra object list walk for a case
> > > > which we expect to not happen.  I'm not sure how expensive the list
> > > > walk would be if all we do is check the number of relocations on each
> > > > object.  I guess, if it comes right after a copy_from_user, it's all
> > > > hot in the cache so it shouldn't matter.  Ok.  I've convinced myself.
> > > > I'll move it.
> > >
> > > I really wouldn't move it if it's another list walk. Execbuf has a lot
> > > of fast-paths going on, and we have extensive tests to make sure it
> > > unwinds correctly in all cases. It's not very intuitive, but execbuf
> > > code isn't scoring very high on that.
> >
> > And here I'd just finished doing the typing to move it.  Good thing I
> > hadn't closed vim yet and it was still in my undo buffer. :-)
>
> Before entering "slower" path from my perspective I would just check
> batch object at that place. We still would have single list walkthrough
> and quick check on the very beginning.

Can you be more specific about what exactly you think we can check at
the beginning?  Either we add a flag that we can O(1) check at the
beginning or we have to check everything in exec2_list for
exec2_list[n].relocation_count == 0.  That's a list walk.  I'm not
seeing what up-front check you're thinking we can do without the list
walk.

--Jason

> --
> Zbigniew
>
> >
> > --Jason
> >
> > > -Daniel
> > >
> > > >
> > > > --Jason
> > > >
> > > > > --
> > > > > Zbigniew
> > > > >
> > > > > >
> > > > > > Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
> > > > > > Cc: Dave Airlie <airlied@redhat.com>
> > > > > > Cc: Daniel Vetter <daniel.vetter@intel.com>
> > > > > > ---
> > > > > >  drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 15 ++++++++++++---
> > > > > >  1 file changed, 12 insertions(+), 3 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > > > > index 99772f37bff60..b02dbd16bfa03 100644
> > > > > > --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > > > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > > > > @@ -1764,7 +1764,8 @@ eb_relocate_vma_slow(struct i915_execbuffer *eb, struct eb_vma *ev)
> > > > > >       return err;
> > > > > >  }
> > > > > >
> > > > > > -static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
> > > > > > +static int check_relocations(const struct i915_execbuffer *eb,
> > > > > > +                          const struct drm_i915_gem_exec_object2 *entry)
> > > > > >  {
> > > > > >       const char __user *addr, *end;
> > > > > >       unsigned long size;
> > > > > > @@ -1774,6 +1775,14 @@ static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
> > > > > >       if (size == 0)
> > > > > >               return 0;
> > > > > >
> > > > > > +     /* Relocations are disallowed for all platforms after TGL-LP */
> > > > > > +     if (INTEL_GEN(eb->i915) >= 12 && !IS_TIGERLAKE(eb->i915))
> > > > > > +             return -EINVAL;
> > > > > > +
> > > > > > +     /* All discrete memory platforms are Gen12 or above */
> > > > > > +     if (WARN_ON(HAS_LMEM(eb->i915)))
> > > > > > +             return -EINVAL;
> > > > > > +
> > > > > >       if (size > N_RELOC(ULONG_MAX))
> > > > > >               return -EINVAL;
> > > > > >
> > > > > > @@ -1807,7 +1816,7 @@ static int eb_copy_relocations(const struct i915_execbuffer *eb)
> > > > > >               if (nreloc == 0)
> > > > > >                       continue;
> > > > > >
> > > > > > -             err = check_relocations(&eb->exec[i]);
> > > > > > +             err = check_relocations(eb, &eb->exec[i]);
> > > > > >               if (err)
> > > > > >                       goto err;
> > > > > >
> > > > > > @@ -1880,7 +1889,7 @@ static int eb_prefault_relocations(const struct i915_execbuffer *eb)
> > > > > >       for (i = 0; i < count; i++) {
> > > > > >               int err;
> > > > > >
> > > > > > -             err = check_relocations(&eb->exec[i]);
> > > > > > +             err = check_relocations(eb, &eb->exec[i]);
> > > > > >               if (err)
> > > > > >                       return err;
> > > > > >       }
> > > > > > --
> > > > > > 2.29.2
> > > > > >
> > > > > > _______________________________________________
> > > > > > dri-devel mailing list
> > > > > > dri-devel@lists.freedesktop.org
> > > > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > > > _______________________________________________
> > > > dri-devel mailing list
> > > > dri-devel@lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > >
> > >
> > >
> > > --
> > > Daniel Vetter
> > > Software Engineer, Intel Corporation
> > > http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH] i915: Drop relocation support on all new hardware (v3)

[Jason Ekstrand]

On Thu, Mar 11, 2021 at 10:51 AM Zbigniew Kempczyński
<zbigniew.kempczynski@intel.com> wrote:
>
> On Thu, Mar 11, 2021 at 10:24:38AM -0600, Jason Ekstrand wrote:
> > On Thu, Mar 11, 2021 at 9:57 AM Daniel Vetter <daniel@ffwll.ch> wrote:
> > >
> > > On Thu, Mar 11, 2021 at 4:50 PM Jason Ekstrand <jason@jlekstrand.net> wrote:
> > > >
> > > > On Thu, Mar 11, 2021 at 5:44 AM Zbigniew Kempczyński
> > > > <zbigniew.kempczynski@intel.com> wrote:
> > > > >
> > > > > On Wed, Mar 10, 2021 at 03:50:07PM -0600, Jason Ekstrand wrote:
> > > > > > The Vulkan driver in Mesa for Intel hardware never uses relocations if
> > > > > > it's running on a version of i915 that supports at least softpin which
> > > > > > all versions of i915 supporting Gen12 do.  On the OpenGL side, Gen12+ is
> > > > > > only supported by iris which never uses relocations.  The older i965
> > > > > > driver in Mesa does use relocations but it only supports Intel hardware
> > > > > > through Gen11 and has been deprecated for all hardware Gen9+.  The
> > > > > > compute driver also never uses relocations.  This only leaves the media
> > > > > > driver which is supposed to be switching to softpin going forward.
> > > > > > Making softpin a requirement for all future hardware seems reasonable.
> > > > > >
> > > > > > Rejecting relocations starting with Gen12 has the benefit that we don't
> > > > > > have to bother supporting it on platforms with local memory.  Given how
> > > > > > much CPU touching of memory is required for relocations, not having to
> > > > > > do so on platforms where not all memory is directly CPU-accessible
> > > > > > carries significant advantages.
> > > > > >
> > > > > > v2 (Jason Ekstrand):
> > > > > >  - Allow TGL-LP platforms as they've already shipped
> > > > > >
> > > > > > v3 (Jason Ekstrand):
> > > > > >  - WARN_ON platforms with LMEM support in case the check is wrong
> > > > >
> > > > > I was asked to review of this patch. It works along with expected
> > > > > IGT check https://patchwork.freedesktop.org/patch/423361/?series=82954&rev=25
> > > > >
> > > > > Before I'll give you r-b - isn't i915_gem_execbuffer2_ioctl() better place
> > > > > to do for loop just after copy_from_user() and check relocation_count?
> > > > > We have an access to exec2_list there, we know the gen so we're able to say
> > > > > relocations are not supported immediate, without entering i915_gem_do_execbuffer().
> > > >
> > > > I considered that but it adds an extra object list walk for a case
> > > > which we expect to not happen.  I'm not sure how expensive the list
> > > > walk would be if all we do is check the number of relocations on each
> > > > object.  I guess, if it comes right after a copy_from_user, it's all
> > > > hot in the cache so it shouldn't matter.  Ok.  I've convinced myself.
> > > > I'll move it.
> > >
> > > I really wouldn't move it if it's another list walk. Execbuf has a lot
> > > of fast-paths going on, and we have extensive tests to make sure it
> > > unwinds correctly in all cases. It's not very intuitive, but execbuf
> > > code isn't scoring very high on that.
> >
> > And here I'd just finished doing the typing to move it.  Good thing I
> > hadn't closed vim yet and it was still in my undo buffer. :-)
>
> Before entering "slower" path from my perspective I would just check
> batch object at that place. We still would have single list walkthrough
> and quick check on the very beginning.

Can you be more specific about what exactly you think we can check at
the beginning?  Either we add a flag that we can O(1) check at the
beginning or we have to check everything in exec2_list for
exec2_list[n].relocation_count == 0.  That's a list walk.  I'm not
seeing what up-front check you're thinking we can do without the list
walk.

--Jason

> --
> Zbigniew
>
> >
> > --Jason
> >
> > > -Daniel
> > >
> > > >
> > > > --Jason
> > > >
> > > > > --
> > > > > Zbigniew
> > > > >
> > > > > >
> > > > > > Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
> > > > > > Cc: Dave Airlie <airlied@redhat.com>
> > > > > > Cc: Daniel Vetter <daniel.vetter@intel.com>
> > > > > > ---
> > > > > >  drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 15 ++++++++++++---
> > > > > >  1 file changed, 12 insertions(+), 3 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > > > > index 99772f37bff60..b02dbd16bfa03 100644
> > > > > > --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > > > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > > > > @@ -1764,7 +1764,8 @@ eb_relocate_vma_slow(struct i915_execbuffer *eb, struct eb_vma *ev)
> > > > > >       return err;
> > > > > >  }
> > > > > >
> > > > > > -static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
> > > > > > +static int check_relocations(const struct i915_execbuffer *eb,
> > > > > > +                          const struct drm_i915_gem_exec_object2 *entry)
> > > > > >  {
> > > > > >       const char __user *addr, *end;
> > > > > >       unsigned long size;
> > > > > > @@ -1774,6 +1775,14 @@ static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
> > > > > >       if (size == 0)
> > > > > >               return 0;
> > > > > >
> > > > > > +     /* Relocations are disallowed for all platforms after TGL-LP */
> > > > > > +     if (INTEL_GEN(eb->i915) >= 12 && !IS_TIGERLAKE(eb->i915))
> > > > > > +             return -EINVAL;
> > > > > > +
> > > > > > +     /* All discrete memory platforms are Gen12 or above */
> > > > > > +     if (WARN_ON(HAS_LMEM(eb->i915)))
> > > > > > +             return -EINVAL;
> > > > > > +
> > > > > >       if (size > N_RELOC(ULONG_MAX))
> > > > > >               return -EINVAL;
> > > > > >
> > > > > > @@ -1807,7 +1816,7 @@ static int eb_copy_relocations(const struct i915_execbuffer *eb)
> > > > > >               if (nreloc == 0)
> > > > > >                       continue;
> > > > > >
> > > > > > -             err = check_relocations(&eb->exec[i]);
> > > > > > +             err = check_relocations(eb, &eb->exec[i]);
> > > > > >               if (err)
> > > > > >                       goto err;
> > > > > >
> > > > > > @@ -1880,7 +1889,7 @@ static int eb_prefault_relocations(const struct i915_execbuffer *eb)
> > > > > >       for (i = 0; i < count; i++) {
> > > > > >               int err;
> > > > > >
> > > > > > -             err = check_relocations(&eb->exec[i]);
> > > > > > +             err = check_relocations(eb, &eb->exec[i]);
> > > > > >               if (err)
> > > > > >                       return err;
> > > > > >       }
> > > > > > --
> > > > > > 2.29.2
> > > > > >
> > > > > > _______________________________________________
> > > > > > dri-devel mailing list
> > > > > > dri-devel@lists.freedesktop.org
> > > > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > > > _______________________________________________
> > > > dri-devel mailing list
> > > > dri-devel@lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > >
> > >
> > >
> > > --
> > > Daniel Vetter
> > > Software Engineer, Intel Corporation
> > > http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915/gem: Drop relocation support on all new hardware (v4)

[Jason Ekstrand]

The Vulkan driver in Mesa for Intel hardware never uses relocations if
it's running on a version of i915 that supports at least softpin which
all versions of i915 supporting Gen12 do.  On the OpenGL side, Gen12+ is
only supported by iris which never uses relocations.  The older i965
driver in Mesa does use relocations but it only supports Intel hardware
through Gen11 and has been deprecated for all hardware Gen9+.  The
compute driver also never uses relocations.  This only leaves the media
driver which is supposed to be switching to softpin going forward.
Making softpin a requirement for all future hardware seems reasonable.

There is one piece of hardware enabled by default in i915: RKL which was
enabled by e22fa6f0a976 which has not yet landed in drm-next so this
almost but not really a userspace API change for RKL.  If it becomes a
problem, we can always add !IS_ROCKETLAKE(eb->i915) to the condition.

Rejecting relocations starting with newer Gen12 platforms has the
benefit that we don't have to bother supporting it on platforms with
local memory.  Given how much CPU touching of memory is required for
relocations, not having to do so on platforms where not all memory is
directly CPU-accessible carries significant advantages.

v2 (Jason Ekstrand):
 - Allow TGL-LP platforms as they've already shipped

v3 (Jason Ekstrand):
 - WARN_ON platforms with LMEM support in case the check is wrong

v4 (Jason Ekstrand):
 - Call out Rocket Lake in the commit message

Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Acked-by: Keith Packard <keithp@keithp.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
---
 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 15 ++++++++++++---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 99772f37bff60..b02dbd16bfa03 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1764,7 +1764,8 @@ eb_relocate_vma_slow(struct i915_execbuffer *eb, struct eb_vma *ev)
 	return err;
 }
 
-static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
+static int check_relocations(const struct i915_execbuffer *eb,
+			     const struct drm_i915_gem_exec_object2 *entry)
 {
 	const char __user *addr, *end;
 	unsigned long size;
@@ -1774,6 +1775,14 @@ static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
 	if (size == 0)
 		return 0;
 
+	/* Relocations are disallowed for all platforms after TGL-LP */
+	if (INTEL_GEN(eb->i915) >= 12 && !IS_TIGERLAKE(eb->i915))
+		return -EINVAL;
+
+	/* All discrete memory platforms are Gen12 or above */
+	if (WARN_ON(HAS_LMEM(eb->i915)))
+		return -EINVAL;
+
 	if (size > N_RELOC(ULONG_MAX))
 		return -EINVAL;
 
@@ -1807,7 +1816,7 @@ static int eb_copy_relocations(const struct i915_execbuffer *eb)
 		if (nreloc == 0)
 			continue;
 
-		err = check_relocations(&eb->exec[i]);
+		err = check_relocations(eb, &eb->exec[i]);
 		if (err)
 			goto err;
 
@@ -1880,7 +1889,7 @@ static int eb_prefault_relocations(const struct i915_execbuffer *eb)
 	for (i = 0; i < count; i++) {
 		int err;
 
-		err = check_relocations(&eb->exec[i]);
+		err = check_relocations(eb, &eb->exec[i]);
 		if (err)
 			return err;
 	}
-- 
2.29.2

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] i915: Drop relocation support on all new hardware (v3)

[Zbigniew Kempczyński]

On Thu, Mar 11, 2021 at 11:18:11AM -0600, Jason Ekstrand wrote:
> On Thu, Mar 11, 2021 at 10:51 AM Zbigniew Kempczyński
> <zbigniew.kempczynski@intel.com> wrote:
> >
> > On Thu, Mar 11, 2021 at 10:24:38AM -0600, Jason Ekstrand wrote:
> > > On Thu, Mar 11, 2021 at 9:57 AM Daniel Vetter <daniel@ffwll.ch> wrote:
> > > >
> > > > On Thu, Mar 11, 2021 at 4:50 PM Jason Ekstrand <jason@jlekstrand.net> wrote:
> > > > >
> > > > > On Thu, Mar 11, 2021 at 5:44 AM Zbigniew Kempczyński
> > > > > <zbigniew.kempczynski@intel.com> wrote:
> > > > > >
> > > > > > On Wed, Mar 10, 2021 at 03:50:07PM -0600, Jason Ekstrand wrote:
> > > > > > > The Vulkan driver in Mesa for Intel hardware never uses relocations if
> > > > > > > it's running on a version of i915 that supports at least softpin which
> > > > > > > all versions of i915 supporting Gen12 do.  On the OpenGL side, Gen12+ is
> > > > > > > only supported by iris which never uses relocations.  The older i965
> > > > > > > driver in Mesa does use relocations but it only supports Intel hardware
> > > > > > > through Gen11 and has been deprecated for all hardware Gen9+.  The
> > > > > > > compute driver also never uses relocations.  This only leaves the media
> > > > > > > driver which is supposed to be switching to softpin going forward.
> > > > > > > Making softpin a requirement for all future hardware seems reasonable.
> > > > > > >
> > > > > > > Rejecting relocations starting with Gen12 has the benefit that we don't
> > > > > > > have to bother supporting it on platforms with local memory.  Given how
> > > > > > > much CPU touching of memory is required for relocations, not having to
> > > > > > > do so on platforms where not all memory is directly CPU-accessible
> > > > > > > carries significant advantages.
> > > > > > >
> > > > > > > v2 (Jason Ekstrand):
> > > > > > >  - Allow TGL-LP platforms as they've already shipped
> > > > > > >
> > > > > > > v3 (Jason Ekstrand):
> > > > > > >  - WARN_ON platforms with LMEM support in case the check is wrong
> > > > > >
> > > > > > I was asked to review of this patch. It works along with expected
> > > > > > IGT check https://patchwork.freedesktop.org/patch/423361/?series=82954&rev=25
> > > > > >
> > > > > > Before I'll give you r-b - isn't i915_gem_execbuffer2_ioctl() better place
> > > > > > to do for loop just after copy_from_user() and check relocation_count?
> > > > > > We have an access to exec2_list there, we know the gen so we're able to say
> > > > > > relocations are not supported immediate, without entering i915_gem_do_execbuffer().
> > > > >
> > > > > I considered that but it adds an extra object list walk for a case
> > > > > which we expect to not happen.  I'm not sure how expensive the list
> > > > > walk would be if all we do is check the number of relocations on each
> > > > > object.  I guess, if it comes right after a copy_from_user, it's all
> > > > > hot in the cache so it shouldn't matter.  Ok.  I've convinced myself.
> > > > > I'll move it.
> > > >
> > > > I really wouldn't move it if it's another list walk. Execbuf has a lot
> > > > of fast-paths going on, and we have extensive tests to make sure it
> > > > unwinds correctly in all cases. It's not very intuitive, but execbuf
> > > > code isn't scoring very high on that.
> > >
> > > And here I'd just finished doing the typing to move it.  Good thing I
> > > hadn't closed vim yet and it was still in my undo buffer. :-)
> >
> > Before entering "slower" path from my perspective I would just check
> > batch object at that place. We still would have single list walkthrough
> > and quick check on the very beginning.
> 
> Can you be more specific about what exactly you think we can check at
> the beginning?  Either we add a flag that we can O(1) check at the
> beginning or we have to check everything in exec2_list for
> exec2_list[n].relocation_count == 0.  That's a list walk.  I'm not
> seeing what up-front check you're thinking we can do without the list
> walk.

I expect that last (default) or first (I915_EXEC_BATCH_FIRST) execobj
(batch) will likely has relocations. So we can check that single 
object without entering i915_gem_do_execbuffer(). If that check
is missed (relocation_count = 0) you'll catch relocations in other
objects in check_relocations() as you already did. This is simple
optimization but we can avoid two iterations over buffer list 
(first is in eb_lookup_vmas()).

--
Zbigniew

> 
> --Jason
> 
> > --
> > Zbigniew
> >
> > >
> > > --Jason
> > >
> > > > -Daniel
> > > >
> > > > >
> > > > > --Jason
> > > > >
> > > > > > --
> > > > > > Zbigniew
> > > > > >
> > > > > > >
> > > > > > > Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
> > > > > > > Cc: Dave Airlie <airlied@redhat.com>
> > > > > > > Cc: Daniel Vetter <daniel.vetter@intel.com>
> > > > > > > ---
> > > > > > >  drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 15 ++++++++++++---
> > > > > > >  1 file changed, 12 insertions(+), 3 deletions(-)
> > > > > > >
> > > > > > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > > > > > index 99772f37bff60..b02dbd16bfa03 100644
> > > > > > > --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > > > > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > > > > > @@ -1764,7 +1764,8 @@ eb_relocate_vma_slow(struct i915_execbuffer *eb, struct eb_vma *ev)
> > > > > > >       return err;
> > > > > > >  }
> > > > > > >
> > > > > > > -static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
> > > > > > > +static int check_relocations(const struct i915_execbuffer *eb,
> > > > > > > +                          const struct drm_i915_gem_exec_object2 *entry)
> > > > > > >  {
> > > > > > >       const char __user *addr, *end;
> > > > > > >       unsigned long size;
> > > > > > > @@ -1774,6 +1775,14 @@ static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
> > > > > > >       if (size == 0)
> > > > > > >               return 0;
> > > > > > >
> > > > > > > +     /* Relocations are disallowed for all platforms after TGL-LP */
> > > > > > > +     if (INTEL_GEN(eb->i915) >= 12 && !IS_TIGERLAKE(eb->i915))
> > > > > > > +             return -EINVAL;
> > > > > > > +
> > > > > > > +     /* All discrete memory platforms are Gen12 or above */
> > > > > > > +     if (WARN_ON(HAS_LMEM(eb->i915)))
> > > > > > > +             return -EINVAL;
> > > > > > > +
> > > > > > >       if (size > N_RELOC(ULONG_MAX))
> > > > > > >               return -EINVAL;
> > > > > > >
> > > > > > > @@ -1807,7 +1816,7 @@ static int eb_copy_relocations(const struct i915_execbuffer *eb)
> > > > > > >               if (nreloc == 0)
> > > > > > >                       continue;
> > > > > > >
> > > > > > > -             err = check_relocations(&eb->exec[i]);
> > > > > > > +             err = check_relocations(eb, &eb->exec[i]);
> > > > > > >               if (err)
> > > > > > >                       goto err;
> > > > > > >
> > > > > > > @@ -1880,7 +1889,7 @@ static int eb_prefault_relocations(const struct i915_execbuffer *eb)
> > > > > > >       for (i = 0; i < count; i++) {
> > > > > > >               int err;
> > > > > > >
> > > > > > > -             err = check_relocations(&eb->exec[i]);
> > > > > > > +             err = check_relocations(eb, &eb->exec[i]);
> > > > > > >               if (err)
> > > > > > >                       return err;
> > > > > > >       }
> > > > > > > --
> > > > > > > 2.29.2
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > dri-devel mailing list
> > > > > > > dri-devel@lists.freedesktop.org
> > > > > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > > > > _______________________________________________
> > > > > dri-devel mailing list
> > > > > dri-devel@lists.freedesktop.org
> > > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > > >
> > > >
> > > >
> > > > --
> > > > Daniel Vetter
> > > > Software Engineer, Intel Corporation
> > > > http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH] i915: Drop relocation support on all new hardware (v3)

[Zbigniew Kempczyński]

On Thu, Mar 11, 2021 at 11:18:11AM -0600, Jason Ekstrand wrote:
> On Thu, Mar 11, 2021 at 10:51 AM Zbigniew Kempczyński
> <zbigniew.kempczynski@intel.com> wrote:
> >
> > On Thu, Mar 11, 2021 at 10:24:38AM -0600, Jason Ekstrand wrote:
> > > On Thu, Mar 11, 2021 at 9:57 AM Daniel Vetter <daniel@ffwll.ch> wrote:
> > > >
> > > > On Thu, Mar 11, 2021 at 4:50 PM Jason Ekstrand <jason@jlekstrand.net> wrote:
> > > > >
> > > > > On Thu, Mar 11, 2021 at 5:44 AM Zbigniew Kempczyński
> > > > > <zbigniew.kempczynski@intel.com> wrote:
> > > > > >
> > > > > > On Wed, Mar 10, 2021 at 03:50:07PM -0600, Jason Ekstrand wrote:
> > > > > > > The Vulkan driver in Mesa for Intel hardware never uses relocations if
> > > > > > > it's running on a version of i915 that supports at least softpin which
> > > > > > > all versions of i915 supporting Gen12 do.  On the OpenGL side, Gen12+ is
> > > > > > > only supported by iris which never uses relocations.  The older i965
> > > > > > > driver in Mesa does use relocations but it only supports Intel hardware
> > > > > > > through Gen11 and has been deprecated for all hardware Gen9+.  The
> > > > > > > compute driver also never uses relocations.  This only leaves the media
> > > > > > > driver which is supposed to be switching to softpin going forward.
> > > > > > > Making softpin a requirement for all future hardware seems reasonable.
> > > > > > >
> > > > > > > Rejecting relocations starting with Gen12 has the benefit that we don't
> > > > > > > have to bother supporting it on platforms with local memory.  Given how
> > > > > > > much CPU touching of memory is required for relocations, not having to
> > > > > > > do so on platforms where not all memory is directly CPU-accessible
> > > > > > > carries significant advantages.
> > > > > > >
> > > > > > > v2 (Jason Ekstrand):
> > > > > > >  - Allow TGL-LP platforms as they've already shipped
> > > > > > >
> > > > > > > v3 (Jason Ekstrand):
> > > > > > >  - WARN_ON platforms with LMEM support in case the check is wrong
> > > > > >
> > > > > > I was asked to review of this patch. It works along with expected
> > > > > > IGT check https://patchwork.freedesktop.org/patch/423361/?series=82954&rev=25
> > > > > >
> > > > > > Before I'll give you r-b - isn't i915_gem_execbuffer2_ioctl() better place
> > > > > > to do for loop just after copy_from_user() and check relocation_count?
> > > > > > We have an access to exec2_list there, we know the gen so we're able to say
> > > > > > relocations are not supported immediate, without entering i915_gem_do_execbuffer().
> > > > >
> > > > > I considered that but it adds an extra object list walk for a case
> > > > > which we expect to not happen.  I'm not sure how expensive the list
> > > > > walk would be if all we do is check the number of relocations on each
> > > > > object.  I guess, if it comes right after a copy_from_user, it's all
> > > > > hot in the cache so it shouldn't matter.  Ok.  I've convinced myself.
> > > > > I'll move it.
> > > >
> > > > I really wouldn't move it if it's another list walk. Execbuf has a lot
> > > > of fast-paths going on, and we have extensive tests to make sure it
> > > > unwinds correctly in all cases. It's not very intuitive, but execbuf
> > > > code isn't scoring very high on that.
> > >
> > > And here I'd just finished doing the typing to move it.  Good thing I
> > > hadn't closed vim yet and it was still in my undo buffer. :-)
> >
> > Before entering "slower" path from my perspective I would just check
> > batch object at that place. We still would have single list walkthrough
> > and quick check on the very beginning.
> 
> Can you be more specific about what exactly you think we can check at
> the beginning?  Either we add a flag that we can O(1) check at the
> beginning or we have to check everything in exec2_list for
> exec2_list[n].relocation_count == 0.  That's a list walk.  I'm not
> seeing what up-front check you're thinking we can do without the list
> walk.

I expect that last (default) or first (I915_EXEC_BATCH_FIRST) execobj
(batch) will likely has relocations. So we can check that single 
object without entering i915_gem_do_execbuffer(). If that check
is missed (relocation_count = 0) you'll catch relocations in other
objects in check_relocations() as you already did. This is simple
optimization but we can avoid two iterations over buffer list 
(first is in eb_lookup_vmas()).

--
Zbigniew

> 
> --Jason
> 
> > --
> > Zbigniew
> >
> > >
> > > --Jason
> > >
> > > > -Daniel
> > > >
> > > > >
> > > > > --Jason
> > > > >
> > > > > > --
> > > > > > Zbigniew
> > > > > >
> > > > > > >
> > > > > > > Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
> > > > > > > Cc: Dave Airlie <airlied@redhat.com>
> > > > > > > Cc: Daniel Vetter <daniel.vetter@intel.com>
> > > > > > > ---
> > > > > > >  drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 15 ++++++++++++---
> > > > > > >  1 file changed, 12 insertions(+), 3 deletions(-)
> > > > > > >
> > > > > > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > > > > > index 99772f37bff60..b02dbd16bfa03 100644
> > > > > > > --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > > > > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > > > > > @@ -1764,7 +1764,8 @@ eb_relocate_vma_slow(struct i915_execbuffer *eb, struct eb_vma *ev)
> > > > > > >       return err;
> > > > > > >  }
> > > > > > >
> > > > > > > -static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
> > > > > > > +static int check_relocations(const struct i915_execbuffer *eb,
> > > > > > > +                          const struct drm_i915_gem_exec_object2 *entry)
> > > > > > >  {
> > > > > > >       const char __user *addr, *end;
> > > > > > >       unsigned long size;
> > > > > > > @@ -1774,6 +1775,14 @@ static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
> > > > > > >       if (size == 0)
> > > > > > >               return 0;
> > > > > > >
> > > > > > > +     /* Relocations are disallowed for all platforms after TGL-LP */
> > > > > > > +     if (INTEL_GEN(eb->i915) >= 12 && !IS_TIGERLAKE(eb->i915))
> > > > > > > +             return -EINVAL;
> > > > > > > +
> > > > > > > +     /* All discrete memory platforms are Gen12 or above */
> > > > > > > +     if (WARN_ON(HAS_LMEM(eb->i915)))
> > > > > > > +             return -EINVAL;
> > > > > > > +
> > > > > > >       if (size > N_RELOC(ULONG_MAX))
> > > > > > >               return -EINVAL;
> > > > > > >
> > > > > > > @@ -1807,7 +1816,7 @@ static int eb_copy_relocations(const struct i915_execbuffer *eb)
> > > > > > >               if (nreloc == 0)
> > > > > > >                       continue;
> > > > > > >
> > > > > > > -             err = check_relocations(&eb->exec[i]);
> > > > > > > +             err = check_relocations(eb, &eb->exec[i]);
> > > > > > >               if (err)
> > > > > > >                       goto err;
> > > > > > >
> > > > > > > @@ -1880,7 +1889,7 @@ static int eb_prefault_relocations(const struct i915_execbuffer *eb)
> > > > > > >       for (i = 0; i < count; i++) {
> > > > > > >               int err;
> > > > > > >
> > > > > > > -             err = check_relocations(&eb->exec[i]);
> > > > > > > +             err = check_relocations(eb, &eb->exec[i]);
> > > > > > >               if (err)
> > > > > > >                       return err;
> > > > > > >       }
> > > > > > > --
> > > > > > > 2.29.2
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > dri-devel mailing list
> > > > > > > dri-devel@lists.freedesktop.org
> > > > > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > > > > _______________________________________________
> > > > > dri-devel mailing list
> > > > > dri-devel@lists.freedesktop.org
> > > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > > >
> > > >
> > > >
> > > > --
> > > > Daniel Vetter
> > > > Software Engineer, Intel Corporation
> > > > http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for RFC: i915: Drop relocation support on Gen12+ (rev4)

[Patchwork]

== Series Details ==

Series: RFC: i915: Drop relocation support on Gen12+ (rev4)
URL   : https://patchwork.freedesktop.org/series/77048/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
a67282dccbf2 drm/i915/gem: Drop relocation support on all new hardware (v4)
-:18: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ chars of sha1> ("<title line>")' - ie: 'commit e22fa6f0a976 ("drm/i915/rkl: Remove require_force_probe protection")'
#18: 
enabled by e22fa6f0a976 which has not yet landed in drm-next so this

total: 1 errors, 0 warnings, 0 checks, 39 lines checked


_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] i915: Drop relocation support on all new hardware (v3)

[Jason Ekstrand]

On Thu, Mar 11, 2021 at 12:20 PM Zbigniew Kempczyński
<zbigniew.kempczynski@intel.com> wrote:
>
> On Thu, Mar 11, 2021 at 11:18:11AM -0600, Jason Ekstrand wrote:
> > On Thu, Mar 11, 2021 at 10:51 AM Zbigniew Kempczyński
> > <zbigniew.kempczynski@intel.com> wrote:
> > >
> > > On Thu, Mar 11, 2021 at 10:24:38AM -0600, Jason Ekstrand wrote:
> > > > On Thu, Mar 11, 2021 at 9:57 AM Daniel Vetter <daniel@ffwll.ch> wrote:
> > > > >
> > > > > On Thu, Mar 11, 2021 at 4:50 PM Jason Ekstrand <jason@jlekstrand.net> wrote:
> > > > > >
> > > > > > On Thu, Mar 11, 2021 at 5:44 AM Zbigniew Kempczyński
> > > > > > <zbigniew.kempczynski@intel.com> wrote:
> > > > > > >
> > > > > > > On Wed, Mar 10, 2021 at 03:50:07PM -0600, Jason Ekstrand wrote:
> > > > > > > > The Vulkan driver in Mesa for Intel hardware never uses relocations if
> > > > > > > > it's running on a version of i915 that supports at least softpin which
> > > > > > > > all versions of i915 supporting Gen12 do.  On the OpenGL side, Gen12+ is
> > > > > > > > only supported by iris which never uses relocations.  The older i965
> > > > > > > > driver in Mesa does use relocations but it only supports Intel hardware
> > > > > > > > through Gen11 and has been deprecated for all hardware Gen9+.  The
> > > > > > > > compute driver also never uses relocations.  This only leaves the media
> > > > > > > > driver which is supposed to be switching to softpin going forward.
> > > > > > > > Making softpin a requirement for all future hardware seems reasonable.
> > > > > > > >
> > > > > > > > Rejecting relocations starting with Gen12 has the benefit that we don't
> > > > > > > > have to bother supporting it on platforms with local memory.  Given how
> > > > > > > > much CPU touching of memory is required for relocations, not having to
> > > > > > > > do so on platforms where not all memory is directly CPU-accessible
> > > > > > > > carries significant advantages.
> > > > > > > >
> > > > > > > > v2 (Jason Ekstrand):
> > > > > > > >  - Allow TGL-LP platforms as they've already shipped
> > > > > > > >
> > > > > > > > v3 (Jason Ekstrand):
> > > > > > > >  - WARN_ON platforms with LMEM support in case the check is wrong
> > > > > > >
> > > > > > > I was asked to review of this patch. It works along with expected
> > > > > > > IGT check https://patchwork.freedesktop.org/patch/423361/?series=82954&rev=25
> > > > > > >
> > > > > > > Before I'll give you r-b - isn't i915_gem_execbuffer2_ioctl() better place
> > > > > > > to do for loop just after copy_from_user() and check relocation_count?
> > > > > > > We have an access to exec2_list there, we know the gen so we're able to say
> > > > > > > relocations are not supported immediate, without entering i915_gem_do_execbuffer().
> > > > > >
> > > > > > I considered that but it adds an extra object list walk for a case
> > > > > > which we expect to not happen.  I'm not sure how expensive the list
> > > > > > walk would be if all we do is check the number of relocations on each
> > > > > > object.  I guess, if it comes right after a copy_from_user, it's all
> > > > > > hot in the cache so it shouldn't matter.  Ok.  I've convinced myself.
> > > > > > I'll move it.
> > > > >
> > > > > I really wouldn't move it if it's another list walk. Execbuf has a lot
> > > > > of fast-paths going on, and we have extensive tests to make sure it
> > > > > unwinds correctly in all cases. It's not very intuitive, but execbuf
> > > > > code isn't scoring very high on that.
> > > >
> > > > And here I'd just finished doing the typing to move it.  Good thing I
> > > > hadn't closed vim yet and it was still in my undo buffer. :-)
> > >
> > > Before entering "slower" path from my perspective I would just check
> > > batch object at that place. We still would have single list walkthrough
> > > and quick check on the very beginning.
> >
> > Can you be more specific about what exactly you think we can check at
> > the beginning?  Either we add a flag that we can O(1) check at the
> > beginning or we have to check everything in exec2_list for
> > exec2_list[n].relocation_count == 0.  That's a list walk.  I'm not
> > seeing what up-front check you're thinking we can do without the list
> > walk.
>
> I expect that last (default) or first (I915_EXEC_BATCH_FIRST) execobj
> (batch) will likely has relocations. So we can check that single
> object without entering i915_gem_do_execbuffer(). If that check
> is missed (relocation_count = 0) you'll catch relocations in other
> objects in check_relocations() as you already did. This is simple
> optimization but we can avoid two iterations over buffer list
> (first is in eb_lookup_vmas()).

Sure, we can do an early-exit check of the first and last objects.
I'm just not seeing what that saves us given that we still have to do
the full list-walk check anyway.  Especially since this is an error
path which shouldn't be hit by real userspace drivers.

--Jason

> --
> Zbigniew
>
> >
> > --Jason
> >
> > > --
> > > Zbigniew
> > >
> > > >
> > > > --Jason
> > > >
> > > > > -Daniel
> > > > >
> > > > > >
> > > > > > --Jason
> > > > > >
> > > > > > > --
> > > > > > > Zbigniew
> > > > > > >
> > > > > > > >
> > > > > > > > Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
> > > > > > > > Cc: Dave Airlie <airlied@redhat.com>
> > > > > > > > Cc: Daniel Vetter <daniel.vetter@intel.com>
> > > > > > > > ---
> > > > > > > >  drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 15 ++++++++++++---
> > > > > > > >  1 file changed, 12 insertions(+), 3 deletions(-)
> > > > > > > >
> > > > > > > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > > > > > > index 99772f37bff60..b02dbd16bfa03 100644
> > > > > > > > --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > > > > > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > > > > > > @@ -1764,7 +1764,8 @@ eb_relocate_vma_slow(struct i915_execbuffer *eb, struct eb_vma *ev)
> > > > > > > >       return err;
> > > > > > > >  }
> > > > > > > >
> > > > > > > > -static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
> > > > > > > > +static int check_relocations(const struct i915_execbuffer *eb,
> > > > > > > > +                          const struct drm_i915_gem_exec_object2 *entry)
> > > > > > > >  {
> > > > > > > >       const char __user *addr, *end;
> > > > > > > >       unsigned long size;
> > > > > > > > @@ -1774,6 +1775,14 @@ static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
> > > > > > > >       if (size == 0)
> > > > > > > >               return 0;
> > > > > > > >
> > > > > > > > +     /* Relocations are disallowed for all platforms after TGL-LP */
> > > > > > > > +     if (INTEL_GEN(eb->i915) >= 12 && !IS_TIGERLAKE(eb->i915))
> > > > > > > > +             return -EINVAL;
> > > > > > > > +
> > > > > > > > +     /* All discrete memory platforms are Gen12 or above */
> > > > > > > > +     if (WARN_ON(HAS_LMEM(eb->i915)))
> > > > > > > > +             return -EINVAL;
> > > > > > > > +
> > > > > > > >       if (size > N_RELOC(ULONG_MAX))
> > > > > > > >               return -EINVAL;
> > > > > > > >
> > > > > > > > @@ -1807,7 +1816,7 @@ static int eb_copy_relocations(const struct i915_execbuffer *eb)
> > > > > > > >               if (nreloc == 0)
> > > > > > > >                       continue;
> > > > > > > >
> > > > > > > > -             err = check_relocations(&eb->exec[i]);
> > > > > > > > +             err = check_relocations(eb, &eb->exec[i]);
> > > > > > > >               if (err)
> > > > > > > >                       goto err;
> > > > > > > >
> > > > > > > > @@ -1880,7 +1889,7 @@ static int eb_prefault_relocations(const struct i915_execbuffer *eb)
> > > > > > > >       for (i = 0; i < count; i++) {
> > > > > > > >               int err;
> > > > > > > >
> > > > > > > > -             err = check_relocations(&eb->exec[i]);
> > > > > > > > +             err = check_relocations(eb, &eb->exec[i]);
> > > > > > > >               if (err)
> > > > > > > >                       return err;
> > > > > > > >       }
> > > > > > > > --
> > > > > > > > 2.29.2
> > > > > > > >
> > > > > > > > _______________________________________________
> > > > > > > > dri-devel mailing list
> > > > > > > > dri-devel@lists.freedesktop.org
> > > > > > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > > > > > _______________________________________________
> > > > > > dri-devel mailing list
> > > > > > dri-devel@lists.freedesktop.org
> > > > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Daniel Vetter
> > > > > Software Engineer, Intel Corporation
> > > > > http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH] i915: Drop relocation support on all new hardware (v3)

[Jason Ekstrand]

On Thu, Mar 11, 2021 at 12:20 PM Zbigniew Kempczyński
<zbigniew.kempczynski@intel.com> wrote:
>
> On Thu, Mar 11, 2021 at 11:18:11AM -0600, Jason Ekstrand wrote:
> > On Thu, Mar 11, 2021 at 10:51 AM Zbigniew Kempczyński
> > <zbigniew.kempczynski@intel.com> wrote:
> > >
> > > On Thu, Mar 11, 2021 at 10:24:38AM -0600, Jason Ekstrand wrote:
> > > > On Thu, Mar 11, 2021 at 9:57 AM Daniel Vetter <daniel@ffwll.ch> wrote:
> > > > >
> > > > > On Thu, Mar 11, 2021 at 4:50 PM Jason Ekstrand <jason@jlekstrand.net> wrote:
> > > > > >
> > > > > > On Thu, Mar 11, 2021 at 5:44 AM Zbigniew Kempczyński
> > > > > > <zbigniew.kempczynski@intel.com> wrote:
> > > > > > >
> > > > > > > On Wed, Mar 10, 2021 at 03:50:07PM -0600, Jason Ekstrand wrote:
> > > > > > > > The Vulkan driver in Mesa for Intel hardware never uses relocations if
> > > > > > > > it's running on a version of i915 that supports at least softpin which
> > > > > > > > all versions of i915 supporting Gen12 do.  On the OpenGL side, Gen12+ is
> > > > > > > > only supported by iris which never uses relocations.  The older i965
> > > > > > > > driver in Mesa does use relocations but it only supports Intel hardware
> > > > > > > > through Gen11 and has been deprecated for all hardware Gen9+.  The
> > > > > > > > compute driver also never uses relocations.  This only leaves the media
> > > > > > > > driver which is supposed to be switching to softpin going forward.
> > > > > > > > Making softpin a requirement for all future hardware seems reasonable.
> > > > > > > >
> > > > > > > > Rejecting relocations starting with Gen12 has the benefit that we don't
> > > > > > > > have to bother supporting it on platforms with local memory.  Given how
> > > > > > > > much CPU touching of memory is required for relocations, not having to
> > > > > > > > do so on platforms where not all memory is directly CPU-accessible
> > > > > > > > carries significant advantages.
> > > > > > > >
> > > > > > > > v2 (Jason Ekstrand):
> > > > > > > >  - Allow TGL-LP platforms as they've already shipped
> > > > > > > >
> > > > > > > > v3 (Jason Ekstrand):
> > > > > > > >  - WARN_ON platforms with LMEM support in case the check is wrong
> > > > > > >
> > > > > > > I was asked to review of this patch. It works along with expected
> > > > > > > IGT check https://patchwork.freedesktop.org/patch/423361/?series=82954&rev=25
> > > > > > >
> > > > > > > Before I'll give you r-b - isn't i915_gem_execbuffer2_ioctl() better place
> > > > > > > to do for loop just after copy_from_user() and check relocation_count?
> > > > > > > We have an access to exec2_list there, we know the gen so we're able to say
> > > > > > > relocations are not supported immediate, without entering i915_gem_do_execbuffer().
> > > > > >
> > > > > > I considered that but it adds an extra object list walk for a case
> > > > > > which we expect to not happen.  I'm not sure how expensive the list
> > > > > > walk would be if all we do is check the number of relocations on each
> > > > > > object.  I guess, if it comes right after a copy_from_user, it's all
> > > > > > hot in the cache so it shouldn't matter.  Ok.  I've convinced myself.
> > > > > > I'll move it.
> > > > >
> > > > > I really wouldn't move it if it's another list walk. Execbuf has a lot
> > > > > of fast-paths going on, and we have extensive tests to make sure it
> > > > > unwinds correctly in all cases. It's not very intuitive, but execbuf
> > > > > code isn't scoring very high on that.
> > > >
> > > > And here I'd just finished doing the typing to move it.  Good thing I
> > > > hadn't closed vim yet and it was still in my undo buffer. :-)
> > >
> > > Before entering "slower" path from my perspective I would just check
> > > batch object at that place. We still would have single list walkthrough
> > > and quick check on the very beginning.
> >
> > Can you be more specific about what exactly you think we can check at
> > the beginning?  Either we add a flag that we can O(1) check at the
> > beginning or we have to check everything in exec2_list for
> > exec2_list[n].relocation_count == 0.  That's a list walk.  I'm not
> > seeing what up-front check you're thinking we can do without the list
> > walk.
>
> I expect that last (default) or first (I915_EXEC_BATCH_FIRST) execobj
> (batch) will likely has relocations. So we can check that single
> object without entering i915_gem_do_execbuffer(). If that check
> is missed (relocation_count = 0) you'll catch relocations in other
> objects in check_relocations() as you already did. This is simple
> optimization but we can avoid two iterations over buffer list
> (first is in eb_lookup_vmas()).

Sure, we can do an early-exit check of the first and last objects.
I'm just not seeing what that saves us given that we still have to do
the full list-walk check anyway.  Especially since this is an error
path which shouldn't be hit by real userspace drivers.

--Jason

> --
> Zbigniew
>
> >
> > --Jason
> >
> > > --
> > > Zbigniew
> > >
> > > >
> > > > --Jason
> > > >
> > > > > -Daniel
> > > > >
> > > > > >
> > > > > > --Jason
> > > > > >
> > > > > > > --
> > > > > > > Zbigniew
> > > > > > >
> > > > > > > >
> > > > > > > > Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
> > > > > > > > Cc: Dave Airlie <airlied@redhat.com>
> > > > > > > > Cc: Daniel Vetter <daniel.vetter@intel.com>
> > > > > > > > ---
> > > > > > > >  drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 15 ++++++++++++---
> > > > > > > >  1 file changed, 12 insertions(+), 3 deletions(-)
> > > > > > > >
> > > > > > > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > > > > > > index 99772f37bff60..b02dbd16bfa03 100644
> > > > > > > > --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > > > > > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > > > > > > @@ -1764,7 +1764,8 @@ eb_relocate_vma_slow(struct i915_execbuffer *eb, struct eb_vma *ev)
> > > > > > > >       return err;
> > > > > > > >  }
> > > > > > > >
> > > > > > > > -static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
> > > > > > > > +static int check_relocations(const struct i915_execbuffer *eb,
> > > > > > > > +                          const struct drm_i915_gem_exec_object2 *entry)
> > > > > > > >  {
> > > > > > > >       const char __user *addr, *end;
> > > > > > > >       unsigned long size;
> > > > > > > > @@ -1774,6 +1775,14 @@ static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
> > > > > > > >       if (size == 0)
> > > > > > > >               return 0;
> > > > > > > >
> > > > > > > > +     /* Relocations are disallowed for all platforms after TGL-LP */
> > > > > > > > +     if (INTEL_GEN(eb->i915) >= 12 && !IS_TIGERLAKE(eb->i915))
> > > > > > > > +             return -EINVAL;
> > > > > > > > +
> > > > > > > > +     /* All discrete memory platforms are Gen12 or above */
> > > > > > > > +     if (WARN_ON(HAS_LMEM(eb->i915)))
> > > > > > > > +             return -EINVAL;
> > > > > > > > +
> > > > > > > >       if (size > N_RELOC(ULONG_MAX))
> > > > > > > >               return -EINVAL;
> > > > > > > >
> > > > > > > > @@ -1807,7 +1816,7 @@ static int eb_copy_relocations(const struct i915_execbuffer *eb)
> > > > > > > >               if (nreloc == 0)
> > > > > > > >                       continue;
> > > > > > > >
> > > > > > > > -             err = check_relocations(&eb->exec[i]);
> > > > > > > > +             err = check_relocations(eb, &eb->exec[i]);
> > > > > > > >               if (err)
> > > > > > > >                       goto err;
> > > > > > > >
> > > > > > > > @@ -1880,7 +1889,7 @@ static int eb_prefault_relocations(const struct i915_execbuffer *eb)
> > > > > > > >       for (i = 0; i < count; i++) {
> > > > > > > >               int err;
> > > > > > > >
> > > > > > > > -             err = check_relocations(&eb->exec[i]);
> > > > > > > > +             err = check_relocations(eb, &eb->exec[i]);
> > > > > > > >               if (err)
> > > > > > > >                       return err;
> > > > > > > >       }
> > > > > > > > --
> > > > > > > > 2.29.2
> > > > > > > >
> > > > > > > > _______________________________________________
> > > > > > > > dri-devel mailing list
> > > > > > > > dri-devel@lists.freedesktop.org
> > > > > > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > > > > > _______________________________________________
> > > > > > dri-devel mailing list
> > > > > > dri-devel@lists.freedesktop.org
> > > > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Daniel Vetter
> > > > > Software Engineer, Intel Corporation
> > > > > http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: failure for RFC: i915: Drop relocation support on Gen12+ (rev4)

[Patchwork]

[-- Attachment #1.1: Type: text/plain, Size: 6029 bytes --]

== Series Details ==

Series: RFC: i915: Drop relocation support on Gen12+ (rev4)
URL   : https://patchwork.freedesktop.org/series/77048/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_9850 -> Patchwork_19783
====================================================

Summary
-------

  **FAILURE**

  Serious unknown changes coming with Patchwork_19783 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_19783, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19783/index.html

Possible new issues
-------------------

  Here are the unknown changes that may have been introduced in Patchwork_19783:

### IGT changes ###

#### Possible regressions ####

  * igt@runner@aborted:
    - fi-bsw-nick:        NOTRUN -> [FAIL][1]
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19783/fi-bsw-nick/igt@runner@aborted.html

  
Known issues
------------

  Here are the changes found in Patchwork_19783 that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@amdgpu/amd_basic@semaphore:
    - fi-icl-y:           NOTRUN -> [SKIP][2] ([fdo#109315]) +17 similar issues
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19783/fi-icl-y/igt@amdgpu/amd_basic@semaphore.html

  * igt@gem_huc_copy@huc-copy:
    - fi-byt-j1900:       NOTRUN -> [SKIP][3] ([fdo#109271]) +27 similar issues
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19783/fi-byt-j1900/igt@gem_huc_copy@huc-copy.html
    - fi-icl-y:           NOTRUN -> [SKIP][4] ([i915#2190])
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19783/fi-icl-y/igt@gem_huc_copy@huc-copy.html

  * igt@kms_chamelium@dp-crc-fast:
    - fi-icl-y:           NOTRUN -> [SKIP][5] ([fdo#109284] / [fdo#111827]) +8 similar issues
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19783/fi-icl-y/igt@kms_chamelium@dp-crc-fast.html

  * igt@kms_chamelium@hdmi-crc-fast:
    - fi-byt-j1900:       NOTRUN -> [SKIP][6] ([fdo#109271] / [fdo#111827]) +8 similar issues
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19783/fi-byt-j1900/igt@kms_chamelium@hdmi-crc-fast.html

  * igt@kms_force_connector_basic@force-load-detect:
    - fi-icl-y:           NOTRUN -> [SKIP][7] ([fdo#109285])
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19783/fi-icl-y/igt@kms_force_connector_basic@force-load-detect.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
    - fi-icl-y:           NOTRUN -> [SKIP][8] ([fdo#109278])
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19783/fi-icl-y/igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d.html

  * igt@kms_psr@primary_mmap_gtt:
    - fi-icl-y:           NOTRUN -> [SKIP][9] ([fdo#110189]) +3 similar issues
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19783/fi-icl-y/igt@kms_psr@primary_mmap_gtt.html

  * igt@prime_vgem@basic-userptr:
    - fi-bsw-nick:        [PASS][10] -> [DMESG-WARN][11] ([i915#1610])
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9850/fi-bsw-nick/igt@prime_vgem@basic-userptr.html
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19783/fi-bsw-nick/igt@prime_vgem@basic-userptr.html

  
#### Possible fixes ####

  * igt@gem_tiled_blits@basic:
    - fi-kbl-8809g:       [TIMEOUT][12] ([i915#2502] / [i915#3145]) -> [PASS][13]
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9850/fi-kbl-8809g/igt@gem_tiled_blits@basic.html
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19783/fi-kbl-8809g/igt@gem_tiled_blits@basic.html

  * igt@i915_selftest@live@client:
    - fi-glk-dsi:         [DMESG-FAIL][14] ([i915#3047]) -> [PASS][15]
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9850/fi-glk-dsi/igt@i915_selftest@live@client.html
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19783/fi-glk-dsi/igt@i915_selftest@live@client.html

  
  {name}: This element is suppressed. This means it is ignored when computing
          the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
  [fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284
  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
  [fdo#110189]: https://bugs.freedesktop.org/show_bug.cgi?id=110189
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1222]: https://gitlab.freedesktop.org/drm/intel/issues/1222
  [i915#1610]: https://gitlab.freedesktop.org/drm/intel/issues/1610
  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#2502]: https://gitlab.freedesktop.org/drm/intel/issues/2502
  [i915#3047]: https://gitlab.freedesktop.org/drm/intel/issues/3047
  [i915#3145]: https://gitlab.freedesktop.org/drm/intel/issues/3145
  [i915#3180]: https://gitlab.freedesktop.org/drm/intel/issues/3180


Participating hosts (44 -> 41)
------------------------------

  Additional (2): fi-icl-y fi-byt-j1900 
  Missing    (5): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 fi-bdw-samus 


Build changes
-------------

  * Linux: CI_DRM_9850 -> Patchwork_19783

  CI-20190529: 20190529
  CI_DRM_9850: ddb10f7aa5af176f92d691f3323cce40a7fa8773 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6030: e11e4bfb91fec9af71c3909996c66e5666270e07 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_19783: a67282dccbf241ebac3219c07b9ef025b314b472 @ git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

a67282dccbf2 drm/i915/gem: Drop relocation support on all new hardware (v4)

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19783/index.html

[-- Attachment #1.2: Type: text/html, Size: 6870 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/gem: Drop relocation support on all new hardware (v4)

[Zbigniew Kempczyński]

On Thu, Mar 11, 2021 at 12:17:33PM -0600, Jason Ekstrand wrote:
> The Vulkan driver in Mesa for Intel hardware never uses relocations if
> it's running on a version of i915 that supports at least softpin which
> all versions of i915 supporting Gen12 do.  On the OpenGL side, Gen12+ is
> only supported by iris which never uses relocations.  The older i965
> driver in Mesa does use relocations but it only supports Intel hardware
> through Gen11 and has been deprecated for all hardware Gen9+.  The
> compute driver also never uses relocations.  This only leaves the media
> driver which is supposed to be switching to softpin going forward.
> Making softpin a requirement for all future hardware seems reasonable.
> 
> There is one piece of hardware enabled by default in i915: RKL which was
> enabled by e22fa6f0a976 which has not yet landed in drm-next so this
> almost but not really a userspace API change for RKL.  If it becomes a
> problem, we can always add !IS_ROCKETLAKE(eb->i915) to the condition.
> 
> Rejecting relocations starting with newer Gen12 platforms has the
> benefit that we don't have to bother supporting it on platforms with
> local memory.  Given how much CPU touching of memory is required for
> relocations, not having to do so on platforms where not all memory is
> directly CPU-accessible carries significant advantages.
> 
> v2 (Jason Ekstrand):
>  - Allow TGL-LP platforms as they've already shipped
> 
> v3 (Jason Ekstrand):
>  - WARN_ON platforms with LMEM support in case the check is wrong
> 
> v4 (Jason Ekstrand):
>  - Call out Rocket Lake in the commit message
> 
> Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
> Acked-by: Keith Packard <keithp@keithp.com>
> Cc: Dave Airlie <airlied@redhat.com>
> Cc: Daniel Vetter <daniel.vetter@intel.com>
> ---
>  drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 15 ++++++++++++---
>  1 file changed, 12 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index 99772f37bff60..b02dbd16bfa03 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -1764,7 +1764,8 @@ eb_relocate_vma_slow(struct i915_execbuffer *eb, struct eb_vma *ev)
>  	return err;
>  }
>  
> -static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
> +static int check_relocations(const struct i915_execbuffer *eb,
> +			     const struct drm_i915_gem_exec_object2 *entry)
>  {
>  	const char __user *addr, *end;
>  	unsigned long size;
> @@ -1774,6 +1775,14 @@ static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
>  	if (size == 0)
>  		return 0;
>  
> +	/* Relocations are disallowed for all platforms after TGL-LP */
> +	if (INTEL_GEN(eb->i915) >= 12 && !IS_TIGERLAKE(eb->i915))
> +		return -EINVAL;
> +
> +	/* All discrete memory platforms are Gen12 or above */
> +	if (WARN_ON(HAS_LMEM(eb->i915)))
> +		return -EINVAL;
> +

Looks good IMO, I've tested it with upcoming gem_has_relocation() IGT check.

Reviewed-by: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com>

--
Zbigniew


>  	if (size > N_RELOC(ULONG_MAX))
>  		return -EINVAL;
>  
> @@ -1807,7 +1816,7 @@ static int eb_copy_relocations(const struct i915_execbuffer *eb)
>  		if (nreloc == 0)
>  			continue;
>  
> -		err = check_relocations(&eb->exec[i]);
> +		err = check_relocations(eb, &eb->exec[i]);
>  		if (err)
>  			goto err;
>  
> @@ -1880,7 +1889,7 @@ static int eb_prefault_relocations(const struct i915_execbuffer *eb)
>  	for (i = 0; i < count; i++) {
>  		int err;
>  
> -		err = check_relocations(&eb->exec[i]);
> +		err = check_relocations(eb, &eb->exec[i]);
>  		if (err)
>  			return err;
>  	}
> -- 
> 2.29.2
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/gem: Drop relocation support on all new hardware (v4)

[Tvrtko Ursulin]

On 11/03/2021 18:17, Jason Ekstrand wrote:
> The Vulkan driver in Mesa for Intel hardware never uses relocations if
> it's running on a version of i915 that supports at least softpin which
> all versions of i915 supporting Gen12 do.  On the OpenGL side, Gen12+ is
> only supported by iris which never uses relocations.  The older i965
> driver in Mesa does use relocations but it only supports Intel hardware
> through Gen11 and has been deprecated for all hardware Gen9+.  The
> compute driver also never uses relocations.  This only leaves the media
> driver which is supposed to be switching to softpin going forward.
> Making softpin a requirement for all future hardware seems reasonable.
> 
> There is one piece of hardware enabled by default in i915: RKL which was
> enabled by e22fa6f0a976 which has not yet landed in drm-next so this
> almost but not really a userspace API change for RKL.  If it becomes a
> problem, we can always add !IS_ROCKETLAKE(eb->i915) to the condition.
> 
> Rejecting relocations starting with newer Gen12 platforms has the
> benefit that we don't have to bother supporting it on platforms with
> local memory.  Given how much CPU touching of memory is required for
> relocations, not having to do so on platforms where not all memory is
> directly CPU-accessible carries significant advantages.
> 
> v2 (Jason Ekstrand):
>   - Allow TGL-LP platforms as they've already shipped
> 
> v3 (Jason Ekstrand):
>   - WARN_ON platforms with LMEM support in case the check is wrong
> 
> v4 (Jason Ekstrand):
>   - Call out Rocket Lake in the commit message
> 
> Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
> Acked-by: Keith Packard <keithp@keithp.com>
> Cc: Dave Airlie <airlied@redhat.com>
> Cc: Daniel Vetter <daniel.vetter@intel.com>
> ---
>   drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 15 ++++++++++++---
>   1 file changed, 12 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index 99772f37bff60..b02dbd16bfa03 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -1764,7 +1764,8 @@ eb_relocate_vma_slow(struct i915_execbuffer *eb, struct eb_vma *ev)
>   	return err;
>   }
>   
> -static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
> +static int check_relocations(const struct i915_execbuffer *eb,
> +			     const struct drm_i915_gem_exec_object2 *entry)
>   {
>   	const char __user *addr, *end;
>   	unsigned long size;
> @@ -1774,6 +1775,14 @@ static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
>   	if (size == 0)
>   		return 0;
>   
> +	/* Relocations are disallowed for all platforms after TGL-LP */
> +	if (INTEL_GEN(eb->i915) >= 12 && !IS_TIGERLAKE(eb->i915))
> +		return -EINVAL;

I still recommend ENODEV as more inline with our established error 
codes. (Platform does not support vs dear userspace you messed up your 
flags, modes, whatever.)

> +
> +	/* All discrete memory platforms are Gen12 or above */
> +	if (WARN_ON(HAS_LMEM(eb->i915)))
> +		return -EINVAL;

What was the conclusion on value of supporting fake lmem?

Regards,

Tvrtko

> +
>   	if (size > N_RELOC(ULONG_MAX))
>   		return -EINVAL;
>   
> @@ -1807,7 +1816,7 @@ static int eb_copy_relocations(const struct i915_execbuffer *eb)
>   		if (nreloc == 0)
>   			continue;
>   
> -		err = check_relocations(&eb->exec[i]);
> +		err = check_relocations(eb, &eb->exec[i]);
>   		if (err)
>   			goto err;
>   
> @@ -1880,7 +1889,7 @@ static int eb_prefault_relocations(const struct i915_execbuffer *eb)
>   	for (i = 0; i < count; i++) {
>   		int err;
>   
> -		err = check_relocations(&eb->exec[i]);
> +		err = check_relocations(eb, &eb->exec[i]);
>   		if (err)
>   			return err;
>   	}
> 
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/gem: Drop relocation support on all new hardware (v4)

[Matthew Auld]

On Fri, 12 Mar 2021 at 09:50, Tvrtko Ursulin
<tvrtko.ursulin@linux.intel.com> wrote:
>
>
> On 11/03/2021 18:17, Jason Ekstrand wrote:
> > The Vulkan driver in Mesa for Intel hardware never uses relocations if
> > it's running on a version of i915 that supports at least softpin which
> > all versions of i915 supporting Gen12 do.  On the OpenGL side, Gen12+ is
> > only supported by iris which never uses relocations.  The older i965
> > driver in Mesa does use relocations but it only supports Intel hardware
> > through Gen11 and has been deprecated for all hardware Gen9+.  The
> > compute driver also never uses relocations.  This only leaves the media
> > driver which is supposed to be switching to softpin going forward.
> > Making softpin a requirement for all future hardware seems reasonable.
> >
> > There is one piece of hardware enabled by default in i915: RKL which was
> > enabled by e22fa6f0a976 which has not yet landed in drm-next so this
> > almost but not really a userspace API change for RKL.  If it becomes a
> > problem, we can always add !IS_ROCKETLAKE(eb->i915) to the condition.
> >
> > Rejecting relocations starting with newer Gen12 platforms has the
> > benefit that we don't have to bother supporting it on platforms with
> > local memory.  Given how much CPU touching of memory is required for
> > relocations, not having to do so on platforms where not all memory is
> > directly CPU-accessible carries significant advantages.
> >
> > v2 (Jason Ekstrand):
> >   - Allow TGL-LP platforms as they've already shipped
> >
> > v3 (Jason Ekstrand):
> >   - WARN_ON platforms with LMEM support in case the check is wrong
> >
> > v4 (Jason Ekstrand):
> >   - Call out Rocket Lake in the commit message
> >
> > Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
> > Acked-by: Keith Packard <keithp@keithp.com>
> > Cc: Dave Airlie <airlied@redhat.com>
> > Cc: Daniel Vetter <daniel.vetter@intel.com>
> > ---
> >   drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 15 ++++++++++++---
> >   1 file changed, 12 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > index 99772f37bff60..b02dbd16bfa03 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > @@ -1764,7 +1764,8 @@ eb_relocate_vma_slow(struct i915_execbuffer *eb, struct eb_vma *ev)
> >       return err;
> >   }
> >
> > -static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
> > +static int check_relocations(const struct i915_execbuffer *eb,
> > +                          const struct drm_i915_gem_exec_object2 *entry)
> >   {
> >       const char __user *addr, *end;
> >       unsigned long size;
> > @@ -1774,6 +1775,14 @@ static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
> >       if (size == 0)
> >               return 0;
> >
> > +     /* Relocations are disallowed for all platforms after TGL-LP */
> > +     if (INTEL_GEN(eb->i915) >= 12 && !IS_TIGERLAKE(eb->i915))
> > +             return -EINVAL;
>
> I still recommend ENODEV as more inline with our established error
> codes. (Platform does not support vs dear userspace you messed up your
> flags, modes, whatever.)
>
> > +
> > +     /* All discrete memory platforms are Gen12 or above */
> > +     if (WARN_ON(HAS_LMEM(eb->i915)))
> > +             return -EINVAL;
>
> What was the conclusion on value of supporting fake lmem?

From the previous thread, nothing is currently using it, we did have a
dedicated machine in CI but that has been gone for some months it
seems, so it might already be broken. Also its use was limited only to
the live selftests, which can't even hit this path. The plan was to
eventually remove it, since supporting both real and fake lmem in the
same tree is likely more effort than it's worth.

>
> Regards,
>
> Tvrtko
>
> > +
> >       if (size > N_RELOC(ULONG_MAX))
> >               return -EINVAL;
> >
> > @@ -1807,7 +1816,7 @@ static int eb_copy_relocations(const struct i915_execbuffer *eb)
> >               if (nreloc == 0)
> >                       continue;
> >
> > -             err = check_relocations(&eb->exec[i]);
> > +             err = check_relocations(eb, &eb->exec[i]);
> >               if (err)
> >                       goto err;
> >
> > @@ -1880,7 +1889,7 @@ static int eb_prefault_relocations(const struct i915_execbuffer *eb)
> >       for (i = 0; i < count; i++) {
> >               int err;
> >
> > -             err = check_relocations(&eb->exec[i]);
> > +             err = check_relocations(eb, &eb->exec[i]);
> >               if (err)
> >                       return err;
> >       }
> >
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/gem: Drop relocation support on all new hardware (v4)

[Maarten Lankhorst]

Op 2021-03-12 om 11:56 schreef Matthew Auld:
> On Fri, 12 Mar 2021 at 09:50, Tvrtko Ursulin
> <tvrtko.ursulin@linux.intel.com> wrote:
>>
>> On 11/03/2021 18:17, Jason Ekstrand wrote:
>>> The Vulkan driver in Mesa for Intel hardware never uses relocations if
>>> it's running on a version of i915 that supports at least softpin which
>>> all versions of i915 supporting Gen12 do.  On the OpenGL side, Gen12+ is
>>> only supported by iris which never uses relocations.  The older i965
>>> driver in Mesa does use relocations but it only supports Intel hardware
>>> through Gen11 and has been deprecated for all hardware Gen9+.  The
>>> compute driver also never uses relocations.  This only leaves the media
>>> driver which is supposed to be switching to softpin going forward.
>>> Making softpin a requirement for all future hardware seems reasonable.
>>>
>>> There is one piece of hardware enabled by default in i915: RKL which was
>>> enabled by e22fa6f0a976 which has not yet landed in drm-next so this
>>> almost but not really a userspace API change for RKL.  If it becomes a
>>> problem, we can always add !IS_ROCKETLAKE(eb->i915) to the condition.
>>>
>>> Rejecting relocations starting with newer Gen12 platforms has the
>>> benefit that we don't have to bother supporting it on platforms with
>>> local memory.  Given how much CPU touching of memory is required for
>>> relocations, not having to do so on platforms where not all memory is
>>> directly CPU-accessible carries significant advantages.
>>>
>>> v2 (Jason Ekstrand):
>>>   - Allow TGL-LP platforms as they've already shipped
>>>
>>> v3 (Jason Ekstrand):
>>>   - WARN_ON platforms with LMEM support in case the check is wrong
>>>
>>> v4 (Jason Ekstrand):
>>>   - Call out Rocket Lake in the commit message
>>>
>>> Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
>>> Acked-by: Keith Packard <keithp@keithp.com>
>>> Cc: Dave Airlie <airlied@redhat.com>
>>> Cc: Daniel Vetter <daniel.vetter@intel.com>
>>> ---
>>>   drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 15 ++++++++++++---
>>>   1 file changed, 12 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
>>> index 99772f37bff60..b02dbd16bfa03 100644
>>> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
>>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
>>> @@ -1764,7 +1764,8 @@ eb_relocate_vma_slow(struct i915_execbuffer *eb, struct eb_vma *ev)
>>>       return err;
>>>   }
>>>
>>> -static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
>>> +static int check_relocations(const struct i915_execbuffer *eb,
>>> +                          const struct drm_i915_gem_exec_object2 *entry)
>>>   {
>>>       const char __user *addr, *end;
>>>       unsigned long size;
>>> @@ -1774,6 +1775,14 @@ static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
>>>       if (size == 0)
>>>               return 0;
>>>
>>> +     /* Relocations are disallowed for all platforms after TGL-LP */
>>> +     if (INTEL_GEN(eb->i915) >= 12 && !IS_TIGERLAKE(eb->i915))
>>> +             return -EINVAL;
>> I still recommend ENODEV as more inline with our established error
>> codes. (Platform does not support vs dear userspace you messed up your
>> flags, modes, whatever.)
>>
>>> +
>>> +     /* All discrete memory platforms are Gen12 or above */
>>> +     if (WARN_ON(HAS_LMEM(eb->i915)))
>>> +             return -EINVAL;
>> What was the conclusion on value of supporting fake lmem?
> >From the previous thread, nothing is currently using it, we did have a
> dedicated machine in CI but that has been gone for some months it
> seems, so it might already be broken. Also its use was limited only to
> the live selftests, which can't even hit this path. The plan was to
> eventually remove it, since supporting both real and fake lmem in the
> same tree is likely more effort than it's worth.

I think -EINVAL is fine, but not against -ENODEV either, up to author imo.

Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/gem: Drop relocation support on all new hardware (v4)

[Tvrtko Ursulin]

On 12/03/2021 10:56, Matthew Auld wrote:
> On Fri, 12 Mar 2021 at 09:50, Tvrtko Ursulin
> <tvrtko.ursulin@linux.intel.com> wrote:
>>
>>
>> On 11/03/2021 18:17, Jason Ekstrand wrote:
>>> The Vulkan driver in Mesa for Intel hardware never uses relocations if
>>> it's running on a version of i915 that supports at least softpin which
>>> all versions of i915 supporting Gen12 do.  On the OpenGL side, Gen12+ is
>>> only supported by iris which never uses relocations.  The older i965
>>> driver in Mesa does use relocations but it only supports Intel hardware
>>> through Gen11 and has been deprecated for all hardware Gen9+.  The
>>> compute driver also never uses relocations.  This only leaves the media
>>> driver which is supposed to be switching to softpin going forward.
>>> Making softpin a requirement for all future hardware seems reasonable.
>>>
>>> There is one piece of hardware enabled by default in i915: RKL which was
>>> enabled by e22fa6f0a976 which has not yet landed in drm-next so this
>>> almost but not really a userspace API change for RKL.  If it becomes a
>>> problem, we can always add !IS_ROCKETLAKE(eb->i915) to the condition.
>>>
>>> Rejecting relocations starting with newer Gen12 platforms has the
>>> benefit that we don't have to bother supporting it on platforms with
>>> local memory.  Given how much CPU touching of memory is required for
>>> relocations, not having to do so on platforms where not all memory is
>>> directly CPU-accessible carries significant advantages.
>>>
>>> v2 (Jason Ekstrand):
>>>    - Allow TGL-LP platforms as they've already shipped
>>>
>>> v3 (Jason Ekstrand):
>>>    - WARN_ON platforms with LMEM support in case the check is wrong
>>>
>>> v4 (Jason Ekstrand):
>>>    - Call out Rocket Lake in the commit message
>>>
>>> Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
>>> Acked-by: Keith Packard <keithp@keithp.com>
>>> Cc: Dave Airlie <airlied@redhat.com>
>>> Cc: Daniel Vetter <daniel.vetter@intel.com>
>>> ---
>>>    drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 15 ++++++++++++---
>>>    1 file changed, 12 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
>>> index 99772f37bff60..b02dbd16bfa03 100644
>>> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
>>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
>>> @@ -1764,7 +1764,8 @@ eb_relocate_vma_slow(struct i915_execbuffer *eb, struct eb_vma *ev)
>>>        return err;
>>>    }
>>>
>>> -static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
>>> +static int check_relocations(const struct i915_execbuffer *eb,
>>> +                          const struct drm_i915_gem_exec_object2 *entry)
>>>    {
>>>        const char __user *addr, *end;
>>>        unsigned long size;
>>> @@ -1774,6 +1775,14 @@ static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
>>>        if (size == 0)
>>>                return 0;
>>>
>>> +     /* Relocations are disallowed for all platforms after TGL-LP */
>>> +     if (INTEL_GEN(eb->i915) >= 12 && !IS_TIGERLAKE(eb->i915))
>>> +             return -EINVAL;
>>
>> I still recommend ENODEV as more inline with our established error
>> codes. (Platform does not support vs dear userspace you messed up your
>> flags, modes, whatever.)
>>
>>> +
>>> +     /* All discrete memory platforms are Gen12 or above */
>>> +     if (WARN_ON(HAS_LMEM(eb->i915)))
>>> +             return -EINVAL;
>>
>> What was the conclusion on value of supporting fake lmem?
> 
>>From the previous thread, nothing is currently using it, we did have a
> dedicated machine in CI but that has been gone for some months it
> seems, so it might already be broken. Also its use was limited only to
> the live selftests, which can't even hit this path. The plan was to
> eventually remove it, since supporting both real and fake lmem in the
> same tree is likely more effort than it's worth.

If I understand correctly you are saying it is safe to not have this 
check even if fake lmem is removed later? Presumably since there is no 
way to place an object into lmem in upstream from userspace, hence 
execbuf cannot use any?

Regards,

Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/gem: Drop relocation support on all new hardware (v4)

[Tvrtko Ursulin]

On 12/03/2021 11:33, Maarten Lankhorst wrote:
> Op 2021-03-12 om 11:56 schreef Matthew Auld:
>> On Fri, 12 Mar 2021 at 09:50, Tvrtko Ursulin
>> <tvrtko.ursulin@linux.intel.com> wrote:
>>>
>>> On 11/03/2021 18:17, Jason Ekstrand wrote:
>>>> The Vulkan driver in Mesa for Intel hardware never uses relocations if
>>>> it's running on a version of i915 that supports at least softpin which
>>>> all versions of i915 supporting Gen12 do.  On the OpenGL side, Gen12+ is
>>>> only supported by iris which never uses relocations.  The older i965
>>>> driver in Mesa does use relocations but it only supports Intel hardware
>>>> through Gen11 and has been deprecated for all hardware Gen9+.  The
>>>> compute driver also never uses relocations.  This only leaves the media
>>>> driver which is supposed to be switching to softpin going forward.
>>>> Making softpin a requirement for all future hardware seems reasonable.
>>>>
>>>> There is one piece of hardware enabled by default in i915: RKL which was
>>>> enabled by e22fa6f0a976 which has not yet landed in drm-next so this
>>>> almost but not really a userspace API change for RKL.  If it becomes a
>>>> problem, we can always add !IS_ROCKETLAKE(eb->i915) to the condition.
>>>>
>>>> Rejecting relocations starting with newer Gen12 platforms has the
>>>> benefit that we don't have to bother supporting it on platforms with
>>>> local memory.  Given how much CPU touching of memory is required for
>>>> relocations, not having to do so on platforms where not all memory is
>>>> directly CPU-accessible carries significant advantages.
>>>>
>>>> v2 (Jason Ekstrand):
>>>>    - Allow TGL-LP platforms as they've already shipped
>>>>
>>>> v3 (Jason Ekstrand):
>>>>    - WARN_ON platforms with LMEM support in case the check is wrong
>>>>
>>>> v4 (Jason Ekstrand):
>>>>    - Call out Rocket Lake in the commit message
>>>>
>>>> Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
>>>> Acked-by: Keith Packard <keithp@keithp.com>
>>>> Cc: Dave Airlie <airlied@redhat.com>
>>>> Cc: Daniel Vetter <daniel.vetter@intel.com>
>>>> ---
>>>>    drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 15 ++++++++++++---
>>>>    1 file changed, 12 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
>>>> index 99772f37bff60..b02dbd16bfa03 100644
>>>> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
>>>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
>>>> @@ -1764,7 +1764,8 @@ eb_relocate_vma_slow(struct i915_execbuffer *eb, struct eb_vma *ev)
>>>>        return err;
>>>>    }
>>>>
>>>> -static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
>>>> +static int check_relocations(const struct i915_execbuffer *eb,
>>>> +                          const struct drm_i915_gem_exec_object2 *entry)
>>>>    {
>>>>        const char __user *addr, *end;
>>>>        unsigned long size;
>>>> @@ -1774,6 +1775,14 @@ static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
>>>>        if (size == 0)
>>>>                return 0;
>>>>
>>>> +     /* Relocations are disallowed for all platforms after TGL-LP */
>>>> +     if (INTEL_GEN(eb->i915) >= 12 && !IS_TIGERLAKE(eb->i915))
>>>> +             return -EINVAL;
>>> I still recommend ENODEV as more inline with our established error
>>> codes. (Platform does not support vs dear userspace you messed up your
>>> flags, modes, whatever.)
>>>
>>>> +
>>>> +     /* All discrete memory platforms are Gen12 or above */
>>>> +     if (WARN_ON(HAS_LMEM(eb->i915)))
>>>> +             return -EINVAL;
>>> What was the conclusion on value of supporting fake lmem?
>> >From the previous thread, nothing is currently using it, we did have a
>> dedicated machine in CI but that has been gone for some months it
>> seems, so it might already be broken. Also its use was limited only to
>> the live selftests, which can't even hit this path. The plan was to
>> eventually remove it, since supporting both real and fake lmem in the
>> same tree is likely more effort than it's worth.
> 
> I think -EINVAL is fine, but not against -ENODEV either, up to author imo.

It's pretty well established in our code that ENODEV is used when API is 
used on a platform which does not support or implement it.

Arguably relocations are a grey area since they can be supported but we 
don't want to. So perhaps ENOTSUPP would also work. I just don't see yet 
another overload of EINVAL is the ideal choice.

Regards,

Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/gem: Drop relocation support on all new hardware (v4)

[Matthew Auld]

On Fri, 12 Mar 2021 at 11:47, Tvrtko Ursulin
<tvrtko.ursulin@linux.intel.com> wrote:
>
>
> On 12/03/2021 10:56, Matthew Auld wrote:
> > On Fri, 12 Mar 2021 at 09:50, Tvrtko Ursulin
> > <tvrtko.ursulin@linux.intel.com> wrote:
> >>
> >>
> >> On 11/03/2021 18:17, Jason Ekstrand wrote:
> >>> The Vulkan driver in Mesa for Intel hardware never uses relocations if
> >>> it's running on a version of i915 that supports at least softpin which
> >>> all versions of i915 supporting Gen12 do.  On the OpenGL side, Gen12+ is
> >>> only supported by iris which never uses relocations.  The older i965
> >>> driver in Mesa does use relocations but it only supports Intel hardware
> >>> through Gen11 and has been deprecated for all hardware Gen9+.  The
> >>> compute driver also never uses relocations.  This only leaves the media
> >>> driver which is supposed to be switching to softpin going forward.
> >>> Making softpin a requirement for all future hardware seems reasonable.
> >>>
> >>> There is one piece of hardware enabled by default in i915: RKL which was
> >>> enabled by e22fa6f0a976 which has not yet landed in drm-next so this
> >>> almost but not really a userspace API change for RKL.  If it becomes a
> >>> problem, we can always add !IS_ROCKETLAKE(eb->i915) to the condition.
> >>>
> >>> Rejecting relocations starting with newer Gen12 platforms has the
> >>> benefit that we don't have to bother supporting it on platforms with
> >>> local memory.  Given how much CPU touching of memory is required for
> >>> relocations, not having to do so on platforms where not all memory is
> >>> directly CPU-accessible carries significant advantages.
> >>>
> >>> v2 (Jason Ekstrand):
> >>>    - Allow TGL-LP platforms as they've already shipped
> >>>
> >>> v3 (Jason Ekstrand):
> >>>    - WARN_ON platforms with LMEM support in case the check is wrong
> >>>
> >>> v4 (Jason Ekstrand):
> >>>    - Call out Rocket Lake in the commit message
> >>>
> >>> Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
> >>> Acked-by: Keith Packard <keithp@keithp.com>
> >>> Cc: Dave Airlie <airlied@redhat.com>
> >>> Cc: Daniel Vetter <daniel.vetter@intel.com>
> >>> ---
> >>>    drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 15 ++++++++++++---
> >>>    1 file changed, 12 insertions(+), 3 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> >>> index 99772f37bff60..b02dbd16bfa03 100644
> >>> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> >>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> >>> @@ -1764,7 +1764,8 @@ eb_relocate_vma_slow(struct i915_execbuffer *eb, struct eb_vma *ev)
> >>>        return err;
> >>>    }
> >>>
> >>> -static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
> >>> +static int check_relocations(const struct i915_execbuffer *eb,
> >>> +                          const struct drm_i915_gem_exec_object2 *entry)
> >>>    {
> >>>        const char __user *addr, *end;
> >>>        unsigned long size;
> >>> @@ -1774,6 +1775,14 @@ static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
> >>>        if (size == 0)
> >>>                return 0;
> >>>
> >>> +     /* Relocations are disallowed for all platforms after TGL-LP */
> >>> +     if (INTEL_GEN(eb->i915) >= 12 && !IS_TIGERLAKE(eb->i915))
> >>> +             return -EINVAL;
> >>
> >> I still recommend ENODEV as more inline with our established error
> >> codes. (Platform does not support vs dear userspace you messed up your
> >> flags, modes, whatever.)
> >>
> >>> +
> >>> +     /* All discrete memory platforms are Gen12 or above */
> >>> +     if (WARN_ON(HAS_LMEM(eb->i915)))
> >>> +             return -EINVAL;
> >>
> >> What was the conclusion on value of supporting fake lmem?
> >
> >>From the previous thread, nothing is currently using it, we did have a
> > dedicated machine in CI but that has been gone for some months it
> > seems, so it might already be broken. Also its use was limited only to
> > the live selftests, which can't even hit this path. The plan was to
> > eventually remove it, since supporting both real and fake lmem in the
> > same tree is likely more effort than it's worth.
>
> If I understand correctly you are saying it is safe to not have this
> check even if fake lmem is removed later? Presumably since there is no
> way to place an object into lmem in upstream from userspace, hence
> execbuf cannot use any?

The current usage is gated behind setting i915_selftest.live < 0 (when
loading the driver, run the live selfests and then exit module probe).
So for this and pread/pwrite, or any uAPI stuff we shouldn't have to
worry about fake lmem.

>
> Regards,
>
> Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] i915: Drop relocation support on all new hardware (v3)

[Daniel Vetter]

On Thu, Mar 11, 2021 at 12:57:25PM -0600, Jason Ekstrand wrote:
> On Thu, Mar 11, 2021 at 12:20 PM Zbigniew Kempczyński
> <zbigniew.kempczynski@intel.com> wrote:
> >
> > On Thu, Mar 11, 2021 at 11:18:11AM -0600, Jason Ekstrand wrote:
> > > On Thu, Mar 11, 2021 at 10:51 AM Zbigniew Kempczyński
> > > <zbigniew.kempczynski@intel.com> wrote:
> > > >
> > > > On Thu, Mar 11, 2021 at 10:24:38AM -0600, Jason Ekstrand wrote:
> > > > > On Thu, Mar 11, 2021 at 9:57 AM Daniel Vetter <daniel@ffwll.ch> wrote:
> > > > > >
> > > > > > On Thu, Mar 11, 2021 at 4:50 PM Jason Ekstrand <jason@jlekstrand.net> wrote:
> > > > > > >
> > > > > > > On Thu, Mar 11, 2021 at 5:44 AM Zbigniew Kempczyński
> > > > > > > <zbigniew.kempczynski@intel.com> wrote:
> > > > > > > >
> > > > > > > > On Wed, Mar 10, 2021 at 03:50:07PM -0600, Jason Ekstrand wrote:
> > > > > > > > > The Vulkan driver in Mesa for Intel hardware never uses relocations if
> > > > > > > > > it's running on a version of i915 that supports at least softpin which
> > > > > > > > > all versions of i915 supporting Gen12 do.  On the OpenGL side, Gen12+ is
> > > > > > > > > only supported by iris which never uses relocations.  The older i965
> > > > > > > > > driver in Mesa does use relocations but it only supports Intel hardware
> > > > > > > > > through Gen11 and has been deprecated for all hardware Gen9+.  The
> > > > > > > > > compute driver also never uses relocations.  This only leaves the media
> > > > > > > > > driver which is supposed to be switching to softpin going forward.
> > > > > > > > > Making softpin a requirement for all future hardware seems reasonable.
> > > > > > > > >
> > > > > > > > > Rejecting relocations starting with Gen12 has the benefit that we don't
> > > > > > > > > have to bother supporting it on platforms with local memory.  Given how
> > > > > > > > > much CPU touching of memory is required for relocations, not having to
> > > > > > > > > do so on platforms where not all memory is directly CPU-accessible
> > > > > > > > > carries significant advantages.
> > > > > > > > >
> > > > > > > > > v2 (Jason Ekstrand):
> > > > > > > > >  - Allow TGL-LP platforms as they've already shipped
> > > > > > > > >
> > > > > > > > > v3 (Jason Ekstrand):
> > > > > > > > >  - WARN_ON platforms with LMEM support in case the check is wrong
> > > > > > > >
> > > > > > > > I was asked to review of this patch. It works along with expected
> > > > > > > > IGT check https://patchwork.freedesktop.org/patch/423361/?series=82954&rev=25
> > > > > > > >
> > > > > > > > Before I'll give you r-b - isn't i915_gem_execbuffer2_ioctl() better place
> > > > > > > > to do for loop just after copy_from_user() and check relocation_count?
> > > > > > > > We have an access to exec2_list there, we know the gen so we're able to say
> > > > > > > > relocations are not supported immediate, without entering i915_gem_do_execbuffer().
> > > > > > >
> > > > > > > I considered that but it adds an extra object list walk for a case
> > > > > > > which we expect to not happen.  I'm not sure how expensive the list
> > > > > > > walk would be if all we do is check the number of relocations on each
> > > > > > > object.  I guess, if it comes right after a copy_from_user, it's all
> > > > > > > hot in the cache so it shouldn't matter.  Ok.  I've convinced myself.
> > > > > > > I'll move it.
> > > > > >
> > > > > > I really wouldn't move it if it's another list walk. Execbuf has a lot
> > > > > > of fast-paths going on, and we have extensive tests to make sure it
> > > > > > unwinds correctly in all cases. It's not very intuitive, but execbuf
> > > > > > code isn't scoring very high on that.
> > > > >
> > > > > And here I'd just finished doing the typing to move it.  Good thing I
> > > > > hadn't closed vim yet and it was still in my undo buffer. :-)
> > > >
> > > > Before entering "slower" path from my perspective I would just check
> > > > batch object at that place. We still would have single list walkthrough
> > > > and quick check on the very beginning.
> > >
> > > Can you be more specific about what exactly you think we can check at
> > > the beginning?  Either we add a flag that we can O(1) check at the
> > > beginning or we have to check everything in exec2_list for
> > > exec2_list[n].relocation_count == 0.  That's a list walk.  I'm not
> > > seeing what up-front check you're thinking we can do without the list
> > > walk.
> >
> > I expect that last (default) or first (I915_EXEC_BATCH_FIRST) execobj
> > (batch) will likely has relocations. So we can check that single
> > object without entering i915_gem_do_execbuffer(). If that check
> > is missed (relocation_count = 0) you'll catch relocations in other
> > objects in check_relocations() as you already did. This is simple
> > optimization but we can avoid two iterations over buffer list
> > (first is in eb_lookup_vmas()).
> 
> Sure, we can do an early-exit check of the first and last objects.
> I'm just not seeing what that saves us given that we still have to do
> the full list-walk check anyway.  Especially since this is an error
> path which shouldn't be hit by real userspace drivers.

Yeah optimizing error checking sounds like the wrong thing to optimize.
Userspace is wrong, it might as well have to wait a bit until it gets that
rejection :-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH] i915: Drop relocation support on all new hardware (v3)

[Daniel Vetter]

On Thu, Mar 11, 2021 at 12:57:25PM -0600, Jason Ekstrand wrote:
> On Thu, Mar 11, 2021 at 12:20 PM Zbigniew Kempczyński
> <zbigniew.kempczynski@intel.com> wrote:
> >
> > On Thu, Mar 11, 2021 at 11:18:11AM -0600, Jason Ekstrand wrote:
> > > On Thu, Mar 11, 2021 at 10:51 AM Zbigniew Kempczyński
> > > <zbigniew.kempczynski@intel.com> wrote:
> > > >
> > > > On Thu, Mar 11, 2021 at 10:24:38AM -0600, Jason Ekstrand wrote:
> > > > > On Thu, Mar 11, 2021 at 9:57 AM Daniel Vetter <daniel@ffwll.ch> wrote:
> > > > > >
> > > > > > On Thu, Mar 11, 2021 at 4:50 PM Jason Ekstrand <jason@jlekstrand.net> wrote:
> > > > > > >
> > > > > > > On Thu, Mar 11, 2021 at 5:44 AM Zbigniew Kempczyński
> > > > > > > <zbigniew.kempczynski@intel.com> wrote:
> > > > > > > >
> > > > > > > > On Wed, Mar 10, 2021 at 03:50:07PM -0600, Jason Ekstrand wrote:
> > > > > > > > > The Vulkan driver in Mesa for Intel hardware never uses relocations if
> > > > > > > > > it's running on a version of i915 that supports at least softpin which
> > > > > > > > > all versions of i915 supporting Gen12 do.  On the OpenGL side, Gen12+ is
> > > > > > > > > only supported by iris which never uses relocations.  The older i965
> > > > > > > > > driver in Mesa does use relocations but it only supports Intel hardware
> > > > > > > > > through Gen11 and has been deprecated for all hardware Gen9+.  The
> > > > > > > > > compute driver also never uses relocations.  This only leaves the media
> > > > > > > > > driver which is supposed to be switching to softpin going forward.
> > > > > > > > > Making softpin a requirement for all future hardware seems reasonable.
> > > > > > > > >
> > > > > > > > > Rejecting relocations starting with Gen12 has the benefit that we don't
> > > > > > > > > have to bother supporting it on platforms with local memory.  Given how
> > > > > > > > > much CPU touching of memory is required for relocations, not having to
> > > > > > > > > do so on platforms where not all memory is directly CPU-accessible
> > > > > > > > > carries significant advantages.
> > > > > > > > >
> > > > > > > > > v2 (Jason Ekstrand):
> > > > > > > > >  - Allow TGL-LP platforms as they've already shipped
> > > > > > > > >
> > > > > > > > > v3 (Jason Ekstrand):
> > > > > > > > >  - WARN_ON platforms with LMEM support in case the check is wrong
> > > > > > > >
> > > > > > > > I was asked to review of this patch. It works along with expected
> > > > > > > > IGT check https://patchwork.freedesktop.org/patch/423361/?series=82954&rev=25
> > > > > > > >
> > > > > > > > Before I'll give you r-b - isn't i915_gem_execbuffer2_ioctl() better place
> > > > > > > > to do for loop just after copy_from_user() and check relocation_count?
> > > > > > > > We have an access to exec2_list there, we know the gen so we're able to say
> > > > > > > > relocations are not supported immediate, without entering i915_gem_do_execbuffer().
> > > > > > >
> > > > > > > I considered that but it adds an extra object list walk for a case
> > > > > > > which we expect to not happen.  I'm not sure how expensive the list
> > > > > > > walk would be if all we do is check the number of relocations on each
> > > > > > > object.  I guess, if it comes right after a copy_from_user, it's all
> > > > > > > hot in the cache so it shouldn't matter.  Ok.  I've convinced myself.
> > > > > > > I'll move it.
> > > > > >
> > > > > > I really wouldn't move it if it's another list walk. Execbuf has a lot
> > > > > > of fast-paths going on, and we have extensive tests to make sure it
> > > > > > unwinds correctly in all cases. It's not very intuitive, but execbuf
> > > > > > code isn't scoring very high on that.
> > > > >
> > > > > And here I'd just finished doing the typing to move it.  Good thing I
> > > > > hadn't closed vim yet and it was still in my undo buffer. :-)
> > > >
> > > > Before entering "slower" path from my perspective I would just check
> > > > batch object at that place. We still would have single list walkthrough
> > > > and quick check on the very beginning.
> > >
> > > Can you be more specific about what exactly you think we can check at
> > > the beginning?  Either we add a flag that we can O(1) check at the
> > > beginning or we have to check everything in exec2_list for
> > > exec2_list[n].relocation_count == 0.  That's a list walk.  I'm not
> > > seeing what up-front check you're thinking we can do without the list
> > > walk.
> >
> > I expect that last (default) or first (I915_EXEC_BATCH_FIRST) execobj
> > (batch) will likely has relocations. So we can check that single
> > object without entering i915_gem_do_execbuffer(). If that check
> > is missed (relocation_count = 0) you'll catch relocations in other
> > objects in check_relocations() as you already did. This is simple
> > optimization but we can avoid two iterations over buffer list
> > (first is in eb_lookup_vmas()).
> 
> Sure, we can do an early-exit check of the first and last objects.
> I'm just not seeing what that saves us given that we still have to do
> the full list-walk check anyway.  Especially since this is an error
> path which shouldn't be hit by real userspace drivers.

Yeah optimizing error checking sounds like the wrong thing to optimize.
Userspace is wrong, it might as well have to wait a bit until it gets that
rejection :-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/gem: Drop relocation support on all new hardware (v4)

[Jason Ekstrand]

On Fri, Mar 12, 2021 at 6:17 AM Matthew Auld
<matthew.william.auld@gmail.com> wrote:
>
> On Fri, 12 Mar 2021 at 11:47, Tvrtko Ursulin
> <tvrtko.ursulin@linux.intel.com> wrote:
> >
> >
> > On 12/03/2021 10:56, Matthew Auld wrote:
> > > On Fri, 12 Mar 2021 at 09:50, Tvrtko Ursulin
> > > <tvrtko.ursulin@linux.intel.com> wrote:
> > >>
> > >>
> > >> On 11/03/2021 18:17, Jason Ekstrand wrote:
> > >>> The Vulkan driver in Mesa for Intel hardware never uses relocations if
> > >>> it's running on a version of i915 that supports at least softpin which
> > >>> all versions of i915 supporting Gen12 do.  On the OpenGL side, Gen12+ is
> > >>> only supported by iris which never uses relocations.  The older i965
> > >>> driver in Mesa does use relocations but it only supports Intel hardware
> > >>> through Gen11 and has been deprecated for all hardware Gen9+.  The
> > >>> compute driver also never uses relocations.  This only leaves the media
> > >>> driver which is supposed to be switching to softpin going forward.
> > >>> Making softpin a requirement for all future hardware seems reasonable.
> > >>>
> > >>> There is one piece of hardware enabled by default in i915: RKL which was
> > >>> enabled by e22fa6f0a976 which has not yet landed in drm-next so this
> > >>> almost but not really a userspace API change for RKL.  If it becomes a
> > >>> problem, we can always add !IS_ROCKETLAKE(eb->i915) to the condition.
> > >>>
> > >>> Rejecting relocations starting with newer Gen12 platforms has the
> > >>> benefit that we don't have to bother supporting it on platforms with
> > >>> local memory.  Given how much CPU touching of memory is required for
> > >>> relocations, not having to do so on platforms where not all memory is
> > >>> directly CPU-accessible carries significant advantages.
> > >>>
> > >>> v2 (Jason Ekstrand):
> > >>>    - Allow TGL-LP platforms as they've already shipped
> > >>>
> > >>> v3 (Jason Ekstrand):
> > >>>    - WARN_ON platforms with LMEM support in case the check is wrong
> > >>>
> > >>> v4 (Jason Ekstrand):
> > >>>    - Call out Rocket Lake in the commit message
> > >>>
> > >>> Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
> > >>> Acked-by: Keith Packard <keithp@keithp.com>
> > >>> Cc: Dave Airlie <airlied@redhat.com>
> > >>> Cc: Daniel Vetter <daniel.vetter@intel.com>
> > >>> ---
> > >>>    drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 15 ++++++++++++---
> > >>>    1 file changed, 12 insertions(+), 3 deletions(-)
> > >>>
> > >>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > >>> index 99772f37bff60..b02dbd16bfa03 100644
> > >>> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > >>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > >>> @@ -1764,7 +1764,8 @@ eb_relocate_vma_slow(struct i915_execbuffer *eb, struct eb_vma *ev)
> > >>>        return err;
> > >>>    }
> > >>>
> > >>> -static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
> > >>> +static int check_relocations(const struct i915_execbuffer *eb,
> > >>> +                          const struct drm_i915_gem_exec_object2 *entry)
> > >>>    {
> > >>>        const char __user *addr, *end;
> > >>>        unsigned long size;
> > >>> @@ -1774,6 +1775,14 @@ static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
> > >>>        if (size == 0)
> > >>>                return 0;
> > >>>
> > >>> +     /* Relocations are disallowed for all platforms after TGL-LP */
> > >>> +     if (INTEL_GEN(eb->i915) >= 12 && !IS_TIGERLAKE(eb->i915))
> > >>> +             return -EINVAL;
> > >>
> > >> I still recommend ENODEV as more inline with our established error
> > >> codes. (Platform does not support vs dear userspace you messed up your
> > >> flags, modes, whatever.)

I don't know that I care that much what color we paint this shed.  I
just want it decided so we can all move on.  Here's a few comments:

 -ENODEV, at least based on the DRM error code docs doesn't make much
sense to me because the device is very much still there, you just did
something wrong.

 -EOPNOTSUPP I could see but the operation of execbuf is very much
supported, just not with this set of parameters.  This makes sense to
me for the removal of pread/pwrite but not here.

 -EINVAL is always a correct choice but tells you nothing.  On the
other hand, this is what's returned by drm_invalid_op which is what we
use when we entirely delete a feature.

As someone who has spent way too much of their life trying to figure
out why execbuffer is returning -EINVAL, I really don't think one more
makes it any worse.  If anything, -EINVAL has the advantage that you
can smash some #defines at the top of the file and get dmesg stuff
which can be pretty useful.

In any case, could we please pick a color so I can send a, hopefully
final, new version. :-)

> > >>> +
> > >>> +     /* All discrete memory platforms are Gen12 or above */
> > >>> +     if (WARN_ON(HAS_LMEM(eb->i915)))
> > >>> +             return -EINVAL;
> > >>
> > >> What was the conclusion on value of supporting fake lmem?
> > >
> > >>From the previous thread, nothing is currently using it, we did have a
> > > dedicated machine in CI but that has been gone for some months it
> > > seems, so it might already be broken. Also its use was limited only to
> > > the live selftests, which can't even hit this path. The plan was to
> > > eventually remove it, since supporting both real and fake lmem in the
> > > same tree is likely more effort than it's worth.
> >
> > If I understand correctly you are saying it is safe to not have this
> > check even if fake lmem is removed later? Presumably since there is no
> > way to place an object into lmem in upstream from userspace, hence
> > execbuf cannot use any?
>
> The current usage is gated behind setting i915_selftest.live < 0 (when
> loading the driver, run the live selfests and then exit module probe).
> So for this and pread/pwrite, or any uAPI stuff we shouldn't have to
> worry about fake lmem.

Ok, I'll drop all my WARN_ON(HAS_LMEM()).  I thought it was a nice bit
of extra documentation and safety but others seem to think it's just
clutter.  Fine with me.  I'll just update the comment on the first
check to point out that it also covers all LMEM platforms.

--Jason
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/gem: Drop relocation support on all new hardware (v4)

[Tvrtko Ursulin]

On 12/03/2021 14:52, Jason Ekstrand wrote:
> On Fri, Mar 12, 2021 at 6:17 AM Matthew Auld
> <matthew.william.auld@gmail.com> wrote:
>>
>> On Fri, 12 Mar 2021 at 11:47, Tvrtko Ursulin
>> <tvrtko.ursulin@linux.intel.com> wrote:
>>>
>>>
>>> On 12/03/2021 10:56, Matthew Auld wrote:
>>>> On Fri, 12 Mar 2021 at 09:50, Tvrtko Ursulin
>>>> <tvrtko.ursulin@linux.intel.com> wrote:
>>>>>
>>>>>
>>>>> On 11/03/2021 18:17, Jason Ekstrand wrote:
>>>>>> The Vulkan driver in Mesa for Intel hardware never uses relocations if
>>>>>> it's running on a version of i915 that supports at least softpin which
>>>>>> all versions of i915 supporting Gen12 do.  On the OpenGL side, Gen12+ is
>>>>>> only supported by iris which never uses relocations.  The older i965
>>>>>> driver in Mesa does use relocations but it only supports Intel hardware
>>>>>> through Gen11 and has been deprecated for all hardware Gen9+.  The
>>>>>> compute driver also never uses relocations.  This only leaves the media
>>>>>> driver which is supposed to be switching to softpin going forward.
>>>>>> Making softpin a requirement for all future hardware seems reasonable.
>>>>>>
>>>>>> There is one piece of hardware enabled by default in i915: RKL which was
>>>>>> enabled by e22fa6f0a976 which has not yet landed in drm-next so this
>>>>>> almost but not really a userspace API change for RKL.  If it becomes a
>>>>>> problem, we can always add !IS_ROCKETLAKE(eb->i915) to the condition.
>>>>>>
>>>>>> Rejecting relocations starting with newer Gen12 platforms has the
>>>>>> benefit that we don't have to bother supporting it on platforms with
>>>>>> local memory.  Given how much CPU touching of memory is required for
>>>>>> relocations, not having to do so on platforms where not all memory is
>>>>>> directly CPU-accessible carries significant advantages.
>>>>>>
>>>>>> v2 (Jason Ekstrand):
>>>>>>     - Allow TGL-LP platforms as they've already shipped
>>>>>>
>>>>>> v3 (Jason Ekstrand):
>>>>>>     - WARN_ON platforms with LMEM support in case the check is wrong
>>>>>>
>>>>>> v4 (Jason Ekstrand):
>>>>>>     - Call out Rocket Lake in the commit message
>>>>>>
>>>>>> Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
>>>>>> Acked-by: Keith Packard <keithp@keithp.com>
>>>>>> Cc: Dave Airlie <airlied@redhat.com>
>>>>>> Cc: Daniel Vetter <daniel.vetter@intel.com>
>>>>>> ---
>>>>>>     drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 15 ++++++++++++---
>>>>>>     1 file changed, 12 insertions(+), 3 deletions(-)
>>>>>>
>>>>>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
>>>>>> index 99772f37bff60..b02dbd16bfa03 100644
>>>>>> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
>>>>>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
>>>>>> @@ -1764,7 +1764,8 @@ eb_relocate_vma_slow(struct i915_execbuffer *eb, struct eb_vma *ev)
>>>>>>         return err;
>>>>>>     }
>>>>>>
>>>>>> -static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
>>>>>> +static int check_relocations(const struct i915_execbuffer *eb,
>>>>>> +                          const struct drm_i915_gem_exec_object2 *entry)
>>>>>>     {
>>>>>>         const char __user *addr, *end;
>>>>>>         unsigned long size;
>>>>>> @@ -1774,6 +1775,14 @@ static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
>>>>>>         if (size == 0)
>>>>>>                 return 0;
>>>>>>
>>>>>> +     /* Relocations are disallowed for all platforms after TGL-LP */
>>>>>> +     if (INTEL_GEN(eb->i915) >= 12 && !IS_TIGERLAKE(eb->i915))
>>>>>> +             return -EINVAL;
>>>>>
>>>>> I still recommend ENODEV as more inline with our established error
>>>>> codes. (Platform does not support vs dear userspace you messed up your
>>>>> flags, modes, whatever.)
> 
> I don't know that I care that much what color we paint this shed.  I
> just want it decided so we can all move on.  Here's a few comments:
> 
>   -ENODEV, at least based on the DRM error code docs doesn't make much
> sense to me because the device is very much still there, you just did
> something wrong.
> 
>   -EOPNOTSUPP I could see but the operation of execbuf is very much
> supported, just not with this set of parameters.  This makes sense to
> me for the removal of pread/pwrite but not here.
> 
>   -EINVAL is always a correct choice but tells you nothing.  On the
> other hand, this is what's returned by drm_invalid_op which is what we
> use when we entirely delete a feature.
> 
> As someone who has spent way too much of their life trying to figure
> out why execbuffer is returning -EINVAL, I really don't think one more
> makes it any worse.  If anything, -EINVAL has the advantage that you
> can smash some #defines at the top of the file and get dmesg stuff
> which can be pretty useful.
> 
> In any case, could we please pick a color so I can send a, hopefully
> final, new version. :-)

EINVAL is not the end of the world for me and you have some r-bs and 
acks already so your call.

I was simply pointing our how to stay consistent with the other ioctls 
in i915. Because to me consistency trumps a lot of other things. So if 
we go along the route of ENODEV makes no sense argument, then I wouldn't 
be far from suggesting to evaluate all of the existing ones as well.

Regards,

Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx