[PATCH 1/2] drm/i915: add gem/gt TODO

[PATCH 1/2] drm/i915: add gem/gt TODO

[Daniel Vetter]

We've discussed a bit how to get the gem/gt team better integrated
and collaborate more with the wider community and agreed to the
following:

- all gem/gt patches are reviewed on dri-devel for now. That's
  overkill, but in the past there was definitely too little of that.

- i915-gem folks are encouraged to cross review core patches from
  other teams

- big features (especially uapi changes) need to be discussed in an
  rfc patch that documents the interface and big picture design,
  before we get lost in the details of the code

- Also a rough TODO (can be refined as we go ofc) to get gem/gt back
  on track, like we've e.g. done with DAL/DC to get that in shape.

Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Jason Ekstrand <jason@jlekstrand.net>
Cc: Dave Airlie <airlied@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
 drivers/gpu/drm/i915/TODO.txt | 36 +++++++++++++++++++++++++++++++++++
 1 file changed, 36 insertions(+)
 create mode 100644 drivers/gpu/drm/i915/TODO.txt

diff --git a/drivers/gpu/drm/i915/TODO.txt b/drivers/gpu/drm/i915/TODO.txt
new file mode 100644
index 000000000000..d2e5bbb6339d
--- /dev/null
+++ b/drivers/gpu/drm/i915/TODO.txt
@@ -0,0 +1,36 @@
+gem/gt TODO items
+-----------------
+
+- For discrete memory manager, merge enough dg1 to be able to refactor it to
+  TTM. Then land pci ids (just in case that turns up an uapi problem). TTM has
+  improved a lot the past 2 years, there's no reason anymore not to use it.
+
+- Come up with a plan what to do with drm/scheduler and how to get there.
+
+- There's a lot of complexity added past few years to make relocations faster.
+  That doesn't make sense given hw and gpu apis moved away from this model years
+  ago:
+  1. Land a modern pre-bound uapi like VM_BIND
+  2. Any complexity added in this area past few years which can't be justified
+  with VM_BIND using userspace should be removed. Looking at amdgpu dma_resv on
+  the bo and vm, plus some lru locks is all that needed. No complex rcu,
+  refcounts, caching, ... on everything.
+  This is the matching task on the vm side compared to ttm/dma_resv on the
+  backing storage side.
+
+- i915_sw_fence seems to be the main structure for the i915-gem dma_fence model.
+  How-to-dma_fence is core and drivers really shouldn't build their own world
+  here, treating everything else as a fixed platform. i915_sw_fence concepts
+  should be moved to dma_fence, drm/scheduler or atomic commit helpers. Or
+  removed if dri-devel consensus is that it's not a good idea. Once that's done
+  maybe even remove it if there's nothing left.
+
+Smaller things:
+- i915_utils.h needs to be moved to the right places.
+
+- dma_fence_work should be in drivers/dma-buf
+
+- i915_mm.c should be moved to the right places. Some of the helpers also look a
+  bit fishy:
+
+  https://lore.kernel.org/linux-mm/20210301083320.943079-1-hch@lst.de/
-- 
2.31.0

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

[Intel-gfx] [PATCH 1/2] drm/i915: add gem/gt TODO

[Daniel Vetter]

We've discussed a bit how to get the gem/gt team better integrated
and collaborate more with the wider community and agreed to the
following:

- all gem/gt patches are reviewed on dri-devel for now. That's
  overkill, but in the past there was definitely too little of that.

- i915-gem folks are encouraged to cross review core patches from
  other teams

- big features (especially uapi changes) need to be discussed in an
  rfc patch that documents the interface and big picture design,
  before we get lost in the details of the code

- Also a rough TODO (can be refined as we go ofc) to get gem/gt back
  on track, like we've e.g. done with DAL/DC to get that in shape.

Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Jason Ekstrand <jason@jlekstrand.net>
Cc: Dave Airlie <airlied@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
 drivers/gpu/drm/i915/TODO.txt | 36 +++++++++++++++++++++++++++++++++++
 1 file changed, 36 insertions(+)
 create mode 100644 drivers/gpu/drm/i915/TODO.txt

diff --git a/drivers/gpu/drm/i915/TODO.txt b/drivers/gpu/drm/i915/TODO.txt
new file mode 100644
index 000000000000..d2e5bbb6339d
--- /dev/null
+++ b/drivers/gpu/drm/i915/TODO.txt
@@ -0,0 +1,36 @@
+gem/gt TODO items
+-----------------
+
+- For discrete memory manager, merge enough dg1 to be able to refactor it to
+  TTM. Then land pci ids (just in case that turns up an uapi problem). TTM has
+  improved a lot the past 2 years, there's no reason anymore not to use it.
+
+- Come up with a plan what to do with drm/scheduler and how to get there.
+
+- There's a lot of complexity added past few years to make relocations faster.
+  That doesn't make sense given hw and gpu apis moved away from this model years
+  ago:
+  1. Land a modern pre-bound uapi like VM_BIND
+  2. Any complexity added in this area past few years which can't be justified
+  with VM_BIND using userspace should be removed. Looking at amdgpu dma_resv on
+  the bo and vm, plus some lru locks is all that needed. No complex rcu,
+  refcounts, caching, ... on everything.
+  This is the matching task on the vm side compared to ttm/dma_resv on the
+  backing storage side.
+
+- i915_sw_fence seems to be the main structure for the i915-gem dma_fence model.
+  How-to-dma_fence is core and drivers really shouldn't build their own world
+  here, treating everything else as a fixed platform. i915_sw_fence concepts
+  should be moved to dma_fence, drm/scheduler or atomic commit helpers. Or
+  removed if dri-devel consensus is that it's not a good idea. Once that's done
+  maybe even remove it if there's nothing left.
+
+Smaller things:
+- i915_utils.h needs to be moved to the right places.
+
+- dma_fence_work should be in drivers/dma-buf
+
+- i915_mm.c should be moved to the right places. Some of the helpers also look a
+  bit fishy:
+
+  https://lore.kernel.org/linux-mm/20210301083320.943079-1-hch@lst.de/
-- 
2.31.0

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

[PATCH 2/2] drm/doc: Add RFC section

[Daniel Vetter]

Motivated by the pre-review process for i915 gem/gt features, but
probably useful in general for complex stuff.

Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Jason Ekstrand <jason@jlekstrand.net>
Cc: Dave Airlie <airlied@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
 Documentation/gpu/index.rst |  1 +
 Documentation/gpu/rfc.rst   | 16 ++++++++++++++++
 2 files changed, 17 insertions(+)
 create mode 100644 Documentation/gpu/rfc.rst

diff --git a/Documentation/gpu/index.rst b/Documentation/gpu/index.rst
index c9a51e3bfb5a..df58cb826d68 100644
--- a/Documentation/gpu/index.rst
+++ b/Documentation/gpu/index.rst
@@ -16,6 +16,7 @@ Linux GPU Driver Developer's Guide
    vga-switcheroo
    vgaarbiter
    todo
+   rfc
 
 .. only::  subproject and html
 
diff --git a/Documentation/gpu/rfc.rst b/Documentation/gpu/rfc.rst
new file mode 100644
index 000000000000..9d0ff2921af8
--- /dev/null
+++ b/Documentation/gpu/rfc.rst
@@ -0,0 +1,16 @@
+===============
+GPU RFC Section
+===============
+
+For complex work, especially new uapi, it is often good to nail the high level
+design issues before getting lost in the code details. This section is meant to
+host such documentation:
+
+* Each RFC should be a section in this file, explaining the goal and main design
+  considerations.
+
+* For uapi structures add a file to this directory with and then pull the
+  kerneldoc in like with real uapi headers.
+
+* Once the code has landed move all the documentation to the right places in
+  the main core, helper or driver sections.
-- 
2.31.0

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

[Intel-gfx] [PATCH 2/2] drm/doc: Add RFC section

[Daniel Vetter]

Motivated by the pre-review process for i915 gem/gt features, but
probably useful in general for complex stuff.

Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Jason Ekstrand <jason@jlekstrand.net>
Cc: Dave Airlie <airlied@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
 Documentation/gpu/index.rst |  1 +
 Documentation/gpu/rfc.rst   | 16 ++++++++++++++++
 2 files changed, 17 insertions(+)
 create mode 100644 Documentation/gpu/rfc.rst

diff --git a/Documentation/gpu/index.rst b/Documentation/gpu/index.rst
index c9a51e3bfb5a..df58cb826d68 100644
--- a/Documentation/gpu/index.rst
+++ b/Documentation/gpu/index.rst
@@ -16,6 +16,7 @@ Linux GPU Driver Developer's Guide
    vga-switcheroo
    vgaarbiter
    todo
+   rfc
 
 .. only::  subproject and html
 
diff --git a/Documentation/gpu/rfc.rst b/Documentation/gpu/rfc.rst
new file mode 100644
index 000000000000..9d0ff2921af8
--- /dev/null
+++ b/Documentation/gpu/rfc.rst
@@ -0,0 +1,16 @@
+===============
+GPU RFC Section
+===============
+
+For complex work, especially new uapi, it is often good to nail the high level
+design issues before getting lost in the code details. This section is meant to
+host such documentation:
+
+* Each RFC should be a section in this file, explaining the goal and main design
+  considerations.
+
+* For uapi structures add a file to this directory with and then pull the
+  kerneldoc in like with real uapi headers.
+
+* Once the code has landed move all the documentation to the right places in
+  the main core, helper or driver sections.
-- 
2.31.0

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

Re: [PATCH 2/2] drm/doc: Add RFC section

[Rodrigo Vivi]

On Tue, Mar 23, 2021 at 09:44:53AM +0100, Daniel Vetter wrote:
> Motivated by the pre-review process for i915 gem/gt features, but
> probably useful in general for complex stuff.
> 
> Cc: Jani Nikula <jani.nikula@linux.intel.com>
> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> Cc: Jason Ekstrand <jason@jlekstrand.net>
> Cc: Dave Airlie <airlied@redhat.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---
>  Documentation/gpu/index.rst |  1 +
>  Documentation/gpu/rfc.rst   | 16 ++++++++++++++++
>  2 files changed, 17 insertions(+)
>  create mode 100644 Documentation/gpu/rfc.rst
> 
> diff --git a/Documentation/gpu/index.rst b/Documentation/gpu/index.rst
> index c9a51e3bfb5a..df58cb826d68 100644
> --- a/Documentation/gpu/index.rst
> +++ b/Documentation/gpu/index.rst
> @@ -16,6 +16,7 @@ Linux GPU Driver Developer's Guide
>     vga-switcheroo
>     vgaarbiter
>     todo
> +   rfc

I understand the motivation here so I didn't commented earlier, but looking now,
I'm wondering that this section will polute the official doc...

>  
>  .. only::  subproject and html
>  
> diff --git a/Documentation/gpu/rfc.rst b/Documentation/gpu/rfc.rst
> new file mode 100644
> index 000000000000..9d0ff2921af8
> --- /dev/null
> +++ b/Documentation/gpu/rfc.rst
> @@ -0,0 +1,16 @@
> +===============
> +GPU RFC Section
> +===============
> +
> +For complex work, especially new uapi, it is often good to nail the high level
> +design issues before getting lost in the code details. This section is meant to
> +host such documentation:
> +
> +* Each RFC should be a section in this file, explaining the goal and main design
> +  considerations.
> +
> +* For uapi structures add a file to this directory with and then pull the
> +  kerneldoc in like with real uapi headers.
> +
> +* Once the code has landed move all the documentation to the right places in
> +  the main core, helper or driver sections.
> -- 
> 2.31.0
> 
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 2/2] drm/doc: Add RFC section

[Rodrigo Vivi]

On Tue, Mar 23, 2021 at 09:44:53AM +0100, Daniel Vetter wrote:
> Motivated by the pre-review process for i915 gem/gt features, but
> probably useful in general for complex stuff.
> 
> Cc: Jani Nikula <jani.nikula@linux.intel.com>
> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> Cc: Jason Ekstrand <jason@jlekstrand.net>
> Cc: Dave Airlie <airlied@redhat.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---
>  Documentation/gpu/index.rst |  1 +
>  Documentation/gpu/rfc.rst   | 16 ++++++++++++++++
>  2 files changed, 17 insertions(+)
>  create mode 100644 Documentation/gpu/rfc.rst
> 
> diff --git a/Documentation/gpu/index.rst b/Documentation/gpu/index.rst
> index c9a51e3bfb5a..df58cb826d68 100644
> --- a/Documentation/gpu/index.rst
> +++ b/Documentation/gpu/index.rst
> @@ -16,6 +16,7 @@ Linux GPU Driver Developer's Guide
>     vga-switcheroo
>     vgaarbiter
>     todo
> +   rfc

I understand the motivation here so I didn't commented earlier, but looking now,
I'm wondering that this section will polute the official doc...

>  
>  .. only::  subproject and html
>  
> diff --git a/Documentation/gpu/rfc.rst b/Documentation/gpu/rfc.rst
> new file mode 100644
> index 000000000000..9d0ff2921af8
> --- /dev/null
> +++ b/Documentation/gpu/rfc.rst
> @@ -0,0 +1,16 @@
> +===============
> +GPU RFC Section
> +===============
> +
> +For complex work, especially new uapi, it is often good to nail the high level
> +design issues before getting lost in the code details. This section is meant to
> +host such documentation:
> +
> +* Each RFC should be a section in this file, explaining the goal and main design
> +  considerations.
> +
> +* For uapi structures add a file to this directory with and then pull the
> +  kerneldoc in like with real uapi headers.
> +
> +* Once the code has landed move all the documentation to the right places in
> +  the main core, helper or driver sections.
> -- 
> 2.31.0
> 
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 2/2] drm/doc: Add RFC section

[Daniel Vetter]

On Tue, Mar 23, 2021 at 08:37:07AM -0400, Rodrigo Vivi wrote:
> On Tue, Mar 23, 2021 at 09:44:53AM +0100, Daniel Vetter wrote:
> > Motivated by the pre-review process for i915 gem/gt features, but
> > probably useful in general for complex stuff.
> > 
> > Cc: Jani Nikula <jani.nikula@linux.intel.com>
> > Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > Cc: Jason Ekstrand <jason@jlekstrand.net>
> > Cc: Dave Airlie <airlied@redhat.com>
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > ---
> >  Documentation/gpu/index.rst |  1 +
> >  Documentation/gpu/rfc.rst   | 16 ++++++++++++++++
> >  2 files changed, 17 insertions(+)
> >  create mode 100644 Documentation/gpu/rfc.rst
> > 
> > diff --git a/Documentation/gpu/index.rst b/Documentation/gpu/index.rst
> > index c9a51e3bfb5a..df58cb826d68 100644
> > --- a/Documentation/gpu/index.rst
> > +++ b/Documentation/gpu/index.rst
> > @@ -16,6 +16,7 @@ Linux GPU Driver Developer's Guide
> >     vga-switcheroo
> >     vgaarbiter
> >     todo
> > +   rfc
> 
> I understand the motivation here so I didn't commented earlier, but looking now,
> I'm wondering that this section will polute the official doc...

We already have this problem between documentation meant for kernel driver
developers and documentation meant for userspace developers around uapi
and all that. "who is the audience here" is very ill-defined for our
current set of docs in Documentation/gpu :-(

So I agree with you, but I also don't think this will make things worse.
-Daniel

> 
> >  
> >  .. only::  subproject and html
> >  
> > diff --git a/Documentation/gpu/rfc.rst b/Documentation/gpu/rfc.rst
> > new file mode 100644
> > index 000000000000..9d0ff2921af8
> > --- /dev/null
> > +++ b/Documentation/gpu/rfc.rst
> > @@ -0,0 +1,16 @@
> > +===============
> > +GPU RFC Section
> > +===============
> > +
> > +For complex work, especially new uapi, it is often good to nail the high level
> > +design issues before getting lost in the code details. This section is meant to
> > +host such documentation:
> > +
> > +* Each RFC should be a section in this file, explaining the goal and main design
> > +  considerations.
> > +
> > +* For uapi structures add a file to this directory with and then pull the
> > +  kerneldoc in like with real uapi headers.
> > +
> > +* Once the code has landed move all the documentation to the right places in
> > +  the main core, helper or driver sections.
> > -- 
> > 2.31.0
> > 

-- 
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 2/2] drm/doc: Add RFC section

[Daniel Vetter]

On Tue, Mar 23, 2021 at 08:37:07AM -0400, Rodrigo Vivi wrote:
> On Tue, Mar 23, 2021 at 09:44:53AM +0100, Daniel Vetter wrote:
> > Motivated by the pre-review process for i915 gem/gt features, but
> > probably useful in general for complex stuff.
> > 
> > Cc: Jani Nikula <jani.nikula@linux.intel.com>
> > Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > Cc: Jason Ekstrand <jason@jlekstrand.net>
> > Cc: Dave Airlie <airlied@redhat.com>
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > ---
> >  Documentation/gpu/index.rst |  1 +
> >  Documentation/gpu/rfc.rst   | 16 ++++++++++++++++
> >  2 files changed, 17 insertions(+)
> >  create mode 100644 Documentation/gpu/rfc.rst
> > 
> > diff --git a/Documentation/gpu/index.rst b/Documentation/gpu/index.rst
> > index c9a51e3bfb5a..df58cb826d68 100644
> > --- a/Documentation/gpu/index.rst
> > +++ b/Documentation/gpu/index.rst
> > @@ -16,6 +16,7 @@ Linux GPU Driver Developer's Guide
> >     vga-switcheroo
> >     vgaarbiter
> >     todo
> > +   rfc
> 
> I understand the motivation here so I didn't commented earlier, but looking now,
> I'm wondering that this section will polute the official doc...

We already have this problem between documentation meant for kernel driver
developers and documentation meant for userspace developers around uapi
and all that. "who is the audience here" is very ill-defined for our
current set of docs in Documentation/gpu :-(

So I agree with you, but I also don't think this will make things worse.
-Daniel

> 
> >  
> >  .. only::  subproject and html
> >  
> > diff --git a/Documentation/gpu/rfc.rst b/Documentation/gpu/rfc.rst
> > new file mode 100644
> > index 000000000000..9d0ff2921af8
> > --- /dev/null
> > +++ b/Documentation/gpu/rfc.rst
> > @@ -0,0 +1,16 @@
> > +===============
> > +GPU RFC Section
> > +===============
> > +
> > +For complex work, especially new uapi, it is often good to nail the high level
> > +design issues before getting lost in the code details. This section is meant to
> > +host such documentation:
> > +
> > +* Each RFC should be a section in this file, explaining the goal and main design
> > +  considerations.
> > +
> > +* For uapi structures add a file to this directory with and then pull the
> > +  kerneldoc in like with real uapi headers.
> > +
> > +* Once the code has landed move all the documentation to the right places in
> > +  the main core, helper or driver sections.
> > -- 
> > 2.31.0
> > 

-- 
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 2/2] drm/doc: Add RFC section

[Rodrigo Vivi]

On Tue, Mar 23, 2021 at 02:10:17PM +0100, Daniel Vetter wrote:
> On Tue, Mar 23, 2021 at 08:37:07AM -0400, Rodrigo Vivi wrote:
> > On Tue, Mar 23, 2021 at 09:44:53AM +0100, Daniel Vetter wrote:
> > > Motivated by the pre-review process for i915 gem/gt features, but
> > > probably useful in general for complex stuff.
> > > 
> > > Cc: Jani Nikula <jani.nikula@linux.intel.com>
> > > Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> > > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > Cc: Jason Ekstrand <jason@jlekstrand.net>
> > > Cc: Dave Airlie <airlied@redhat.com>
> > > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > > ---
> > >  Documentation/gpu/index.rst |  1 +
> > >  Documentation/gpu/rfc.rst   | 16 ++++++++++++++++
> > >  2 files changed, 17 insertions(+)
> > >  create mode 100644 Documentation/gpu/rfc.rst
> > > 
> > > diff --git a/Documentation/gpu/index.rst b/Documentation/gpu/index.rst
> > > index c9a51e3bfb5a..df58cb826d68 100644
> > > --- a/Documentation/gpu/index.rst
> > > +++ b/Documentation/gpu/index.rst
> > > @@ -16,6 +16,7 @@ Linux GPU Driver Developer's Guide
> > >     vga-switcheroo
> > >     vgaarbiter
> > >     todo
> > > +   rfc
> > 
> > I understand the motivation here so I didn't commented earlier, but looking now,
> > I'm wondering that this section will polute the official doc...
> 
> We already have this problem between documentation meant for kernel driver
> developers and documentation meant for userspace developers around uapi
> and all that. "who is the audience here" is very ill-defined for our
> current set of docs in Documentation/gpu :-(

you have a point...

another thing that I don't like is the overhead, but otoh it forces us to
write more docs...

with all the pros and cons understood, let's move on...

Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

> 
> So I agree with you, but I also don't think this will make things worse.
> -Daniel
> 
> > 
> > >  
> > >  .. only::  subproject and html
> > >  
> > > diff --git a/Documentation/gpu/rfc.rst b/Documentation/gpu/rfc.rst
> > > new file mode 100644
> > > index 000000000000..9d0ff2921af8
> > > --- /dev/null
> > > +++ b/Documentation/gpu/rfc.rst
> > > @@ -0,0 +1,16 @@
> > > +===============
> > > +GPU RFC Section
> > > +===============
> > > +
> > > +For complex work, especially new uapi, it is often good to nail the high level
> > > +design issues before getting lost in the code details. This section is meant to
> > > +host such documentation:
> > > +
> > > +* Each RFC should be a section in this file, explaining the goal and main design
> > > +  considerations.
> > > +
> > > +* For uapi structures add a file to this directory with and then pull the
> > > +  kerneldoc in like with real uapi headers.
> > > +
> > > +* Once the code has landed move all the documentation to the right places in
> > > +  the main core, helper or driver sections.
> > > -- 
> > > 2.31.0
> > > 
> 
> -- 
> 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 2/2] drm/doc: Add RFC section

[Rodrigo Vivi]

On Tue, Mar 23, 2021 at 02:10:17PM +0100, Daniel Vetter wrote:
> On Tue, Mar 23, 2021 at 08:37:07AM -0400, Rodrigo Vivi wrote:
> > On Tue, Mar 23, 2021 at 09:44:53AM +0100, Daniel Vetter wrote:
> > > Motivated by the pre-review process for i915 gem/gt features, but
> > > probably useful in general for complex stuff.
> > > 
> > > Cc: Jani Nikula <jani.nikula@linux.intel.com>
> > > Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> > > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > Cc: Jason Ekstrand <jason@jlekstrand.net>
> > > Cc: Dave Airlie <airlied@redhat.com>
> > > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > > ---
> > >  Documentation/gpu/index.rst |  1 +
> > >  Documentation/gpu/rfc.rst   | 16 ++++++++++++++++
> > >  2 files changed, 17 insertions(+)
> > >  create mode 100644 Documentation/gpu/rfc.rst
> > > 
> > > diff --git a/Documentation/gpu/index.rst b/Documentation/gpu/index.rst
> > > index c9a51e3bfb5a..df58cb826d68 100644
> > > --- a/Documentation/gpu/index.rst
> > > +++ b/Documentation/gpu/index.rst
> > > @@ -16,6 +16,7 @@ Linux GPU Driver Developer's Guide
> > >     vga-switcheroo
> > >     vgaarbiter
> > >     todo
> > > +   rfc
> > 
> > I understand the motivation here so I didn't commented earlier, but looking now,
> > I'm wondering that this section will polute the official doc...
> 
> We already have this problem between documentation meant for kernel driver
> developers and documentation meant for userspace developers around uapi
> and all that. "who is the audience here" is very ill-defined for our
> current set of docs in Documentation/gpu :-(

you have a point...

another thing that I don't like is the overhead, but otoh it forces us to
write more docs...

with all the pros and cons understood, let's move on...

Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

> 
> So I agree with you, but I also don't think this will make things worse.
> -Daniel
> 
> > 
> > >  
> > >  .. only::  subproject and html
> > >  
> > > diff --git a/Documentation/gpu/rfc.rst b/Documentation/gpu/rfc.rst
> > > new file mode 100644
> > > index 000000000000..9d0ff2921af8
> > > --- /dev/null
> > > +++ b/Documentation/gpu/rfc.rst
> > > @@ -0,0 +1,16 @@
> > > +===============
> > > +GPU RFC Section
> > > +===============
> > > +
> > > +For complex work, especially new uapi, it is often good to nail the high level
> > > +design issues before getting lost in the code details. This section is meant to
> > > +host such documentation:
> > > +
> > > +* Each RFC should be a section in this file, explaining the goal and main design
> > > +  considerations.
> > > +
> > > +* For uapi structures add a file to this directory with and then pull the
> > > +  kerneldoc in like with real uapi headers.
> > > +
> > > +* Once the code has landed move all the documentation to the right places in
> > > +  the main core, helper or driver sections.
> > > -- 
> > > 2.31.0
> > > 
> 
> -- 
> 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 2/2] drm/doc: Add RFC section

[Simon Ser]

Side note: I feel like we could have better lines of communication
between kernel devs and user-space devs. The new uAPI requirements seem
to be a high barrier to entry for kernel devs. However sometimes
user-space devs might be interested in helping out with the user-space
part…

Maybe it would be good to CC e.g. wayland-devel for new RFCs, so that
user-space devs can jump in if they're interested. And also provide
feedback, since new uAPI is hard to spot in the sea of messages in
dri-devel.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 2/2] drm/doc: Add RFC section

[Simon Ser]

Side note: I feel like we could have better lines of communication
between kernel devs and user-space devs. The new uAPI requirements seem
to be a high barrier to entry for kernel devs. However sometimes
user-space devs might be interested in helping out with the user-space
part…

Maybe it would be good to CC e.g. wayland-devel for new RFCs, so that
user-space devs can jump in if they're interested. And also provide
feedback, since new uAPI is hard to spot in the sea of messages in
dri-devel.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 2/2] drm/doc: Add RFC section

[Jason Ekstrand]

On Tue, Mar 23, 2021 at 12:01 PM Simon Ser <contact@emersion.fr> wrote:
>
> Side note: I feel like we could have better lines of communication
> between kernel devs and user-space devs. The new uAPI requirements seem
> to be a high barrier to entry for kernel devs. However sometimes
> user-space devs might be interested in helping out with the user-space
> part…
>
> Maybe it would be good to CC e.g. wayland-devel for new RFCs, so that
> user-space devs can jump in if they're interested. And also provide
> feedback, since new uAPI is hard to spot in the sea of messages in
> dri-devel.

That's a good suggestion.  CCing wayland-dev or mesa-dev, as
appropriate, with such docs patches sounds like a good idea.  I'm not
sure where we would put that in here but it would be good to call out.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 2/2] drm/doc: Add RFC section

[Jason Ekstrand]

On Tue, Mar 23, 2021 at 12:01 PM Simon Ser <contact@emersion.fr> wrote:
>
> Side note: I feel like we could have better lines of communication
> between kernel devs and user-space devs. The new uAPI requirements seem
> to be a high barrier to entry for kernel devs. However sometimes
> user-space devs might be interested in helping out with the user-space
> part…
>
> Maybe it would be good to CC e.g. wayland-devel for new RFCs, so that
> user-space devs can jump in if they're interested. And also provide
> feedback, since new uAPI is hard to spot in the sea of messages in
> dri-devel.

That's a good suggestion.  CCing wayland-dev or mesa-dev, as
appropriate, with such docs patches sounds like a good idea.  I'm not
sure where we would put that in here but it would be good to call out.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 2/2] drm/doc: Add RFC section

[Daniel Vetter]

On Tue, Mar 23, 2021 at 6:55 PM Jason Ekstrand <jason@jlekstrand.net> wrote:
>
> On Tue, Mar 23, 2021 at 12:01 PM Simon Ser <contact@emersion.fr> wrote:
> >
> > Side note: I feel like we could have better lines of communication
> > between kernel devs and user-space devs. The new uAPI requirements seem
> > to be a high barrier to entry for kernel devs. However sometimes
> > user-space devs might be interested in helping out with the user-space
> > part…
> >
> > Maybe it would be good to CC e.g. wayland-devel for new RFCs, so that
> > user-space devs can jump in if they're interested. And also provide
> > feedback, since new uAPI is hard to spot in the sea of messages in
> > dri-devel.
>
> That's a good suggestion.  CCing wayland-dev or mesa-dev, as
> appropriate, with such docs patches sounds like a good idea.  I'm not
> sure where we would put that in here but it would be good to call out.

I'll add a suggestion to that extend, it's a good one.
-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 2/2] drm/doc: Add RFC section

[Daniel Vetter]

On Tue, Mar 23, 2021 at 6:55 PM Jason Ekstrand <jason@jlekstrand.net> wrote:
>
> On Tue, Mar 23, 2021 at 12:01 PM Simon Ser <contact@emersion.fr> wrote:
> >
> > Side note: I feel like we could have better lines of communication
> > between kernel devs and user-space devs. The new uAPI requirements seem
> > to be a high barrier to entry for kernel devs. However sometimes
> > user-space devs might be interested in helping out with the user-space
> > part…
> >
> > Maybe it would be good to CC e.g. wayland-devel for new RFCs, so that
> > user-space devs can jump in if they're interested. And also provide
> > feedback, since new uAPI is hard to spot in the sea of messages in
> > dri-devel.
>
> That's a good suggestion.  CCing wayland-dev or mesa-dev, as
> appropriate, with such docs patches sounds like a good idea.  I'm not
> sure where we would put that in here but it would be good to call out.

I'll add a suggestion to that extend, it's a good one.
-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 2/2] drm/doc: Add RFC section

[Dave Airlie]

On Tue, 23 Mar 2021 at 18:45, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
>
> Motivated by the pre-review process for i915 gem/gt features, but
> probably useful in general for complex stuff.
>
> Cc: Jani Nikula <jani.nikula@linux.intel.com>
> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> Cc: Jason Ekstrand <jason@jlekstrand.net>
> Cc: Dave Airlie <airlied@redhat.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

Let's give it a try, I do like the future ideas of doing things with
gitlab issues as well.

Acked-by: Dave Airlie <airlied@redhat.com>
> ---
>  Documentation/gpu/index.rst |  1 +
>  Documentation/gpu/rfc.rst   | 16 ++++++++++++++++
>  2 files changed, 17 insertions(+)
>  create mode 100644 Documentation/gpu/rfc.rst
>
> diff --git a/Documentation/gpu/index.rst b/Documentation/gpu/index.rst
> index c9a51e3bfb5a..df58cb826d68 100644
> --- a/Documentation/gpu/index.rst
> +++ b/Documentation/gpu/index.rst
> @@ -16,6 +16,7 @@ Linux GPU Driver Developer's Guide
>     vga-switcheroo
>     vgaarbiter
>     todo
> +   rfc
>
>  .. only::  subproject and html
>
> diff --git a/Documentation/gpu/rfc.rst b/Documentation/gpu/rfc.rst
> new file mode 100644
> index 000000000000..9d0ff2921af8
> --- /dev/null
> +++ b/Documentation/gpu/rfc.rst
> @@ -0,0 +1,16 @@
> +===============
> +GPU RFC Section
> +===============
> +
> +For complex work, especially new uapi, it is often good to nail the high level
> +design issues before getting lost in the code details. This section is meant to
> +host such documentation:
> +
> +* Each RFC should be a section in this file, explaining the goal and main design
> +  considerations.
> +
> +* For uapi structures add a file to this directory with and then pull the
> +  kerneldoc in like with real uapi headers.
> +
> +* Once the code has landed move all the documentation to the right places in
> +  the main core, helper or driver sections.
> --
> 2.31.0
>
> _______________________________________________
> 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 2/2] drm/doc: Add RFC section

[Dave Airlie]

On Tue, 23 Mar 2021 at 18:45, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
>
> Motivated by the pre-review process for i915 gem/gt features, but
> probably useful in general for complex stuff.
>
> Cc: Jani Nikula <jani.nikula@linux.intel.com>
> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> Cc: Jason Ekstrand <jason@jlekstrand.net>
> Cc: Dave Airlie <airlied@redhat.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

Let's give it a try, I do like the future ideas of doing things with
gitlab issues as well.

Acked-by: Dave Airlie <airlied@redhat.com>
> ---
>  Documentation/gpu/index.rst |  1 +
>  Documentation/gpu/rfc.rst   | 16 ++++++++++++++++
>  2 files changed, 17 insertions(+)
>  create mode 100644 Documentation/gpu/rfc.rst
>
> diff --git a/Documentation/gpu/index.rst b/Documentation/gpu/index.rst
> index c9a51e3bfb5a..df58cb826d68 100644
> --- a/Documentation/gpu/index.rst
> +++ b/Documentation/gpu/index.rst
> @@ -16,6 +16,7 @@ Linux GPU Driver Developer's Guide
>     vga-switcheroo
>     vgaarbiter
>     todo
> +   rfc
>
>  .. only::  subproject and html
>
> diff --git a/Documentation/gpu/rfc.rst b/Documentation/gpu/rfc.rst
> new file mode 100644
> index 000000000000..9d0ff2921af8
> --- /dev/null
> +++ b/Documentation/gpu/rfc.rst
> @@ -0,0 +1,16 @@
> +===============
> +GPU RFC Section
> +===============
> +
> +For complex work, especially new uapi, it is often good to nail the high level
> +design issues before getting lost in the code details. This section is meant to
> +host such documentation:
> +
> +* Each RFC should be a section in this file, explaining the goal and main design
> +  considerations.
> +
> +* For uapi structures add a file to this directory with and then pull the
> +  kerneldoc in like with real uapi headers.
> +
> +* Once the code has landed move all the documentation to the right places in
> +  the main core, helper or driver sections.
> --
> 2.31.0
>
> _______________________________________________
> 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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/i915: add gem/gt TODO

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915: add gem/gt TODO
URL   : https://patchwork.freedesktop.org/series/88329/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
2b8691372f19 drm/i915: add gem/gt TODO
-:31: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating?
#31: 
new file mode 100644

-:71: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address mismatch: 'From: Daniel Vetter <daniel.vetter@ffwll.ch>' != 'Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>'

total: 0 errors, 2 warnings, 0 checks, 36 lines checked
e2befe203345 drm/doc: Add RFC section
-:29: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating?
#29: 
new file mode 100644

-:34: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier tag in line 1
#34: FILE: Documentation/gpu/rfc.rst:1:
+===============

-:49: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address mismatch: 'From: Daniel Vetter <daniel.vetter@ffwll.ch>' != 'Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>'

total: 0 errors, 3 warnings, 0 checks, 23 lines checked


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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: add gem/gt TODO

[Patchwork]

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

== Series Details ==

Series: series starting with [1/2] drm/i915: add gem/gt TODO
URL   : https://patchwork.freedesktop.org/series/88329/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9882 -> Patchwork_19837
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

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

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

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

### IGT changes ###

#### Issues hit ####

  * igt@fbdev@read:
    - fi-tgl-y:           [PASS][1] -> [DMESG-WARN][2] ([i915#402]) +2 similar issues
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/fi-tgl-y/igt@fbdev@read.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/fi-tgl-y/igt@fbdev@read.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_19837/fi-byt-j1900/igt@gem_huc_copy@huc-copy.html

  * igt@gem_linear_blits@basic:
    - fi-kbl-8809g:       [PASS][4] -> [TIMEOUT][5] ([i915#2502] / [i915#3145])
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/fi-kbl-8809g/igt@gem_linear_blits@basic.html
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/fi-kbl-8809g/igt@gem_linear_blits@basic.html

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

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

  * igt@i915_selftest@live@late_gt_pm:
    - fi-bsw-nick:        [PASS][10] -> [DMESG-FAIL][11] ([i915#2927])
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/fi-bsw-nick/igt@i915_selftest@live@late_gt_pm.html
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/fi-bsw-nick/igt@i915_selftest@live@late_gt_pm.html

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

  * igt@runner@aborted:
    - fi-bsw-nick:        NOTRUN -> [FAIL][13] ([i915#1436])
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/fi-bsw-nick/igt@runner@aborted.html
    - fi-kbl-r:           NOTRUN -> [FAIL][14] ([i915#1569] / [i915#192] / [i915#193] / [i915#194])
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/fi-kbl-r/igt@runner@aborted.html
    - fi-bdw-5557u:       NOTRUN -> [FAIL][15] ([i915#1602] / [i915#2029])
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/fi-bdw-5557u/igt@runner@aborted.html

  
#### Possible fixes ####

  * igt@gem_mmap_gtt@basic:
    - fi-tgl-y:           [DMESG-WARN][16] ([i915#402]) -> [PASS][17] +1 similar issue
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/fi-tgl-y/igt@gem_mmap_gtt@basic.html
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/fi-tgl-y/igt@gem_mmap_gtt@basic.html

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

  
#### Warnings ####

  * igt@i915_pm_rpm@module-reload:
    - fi-glk-dsi:         [DMESG-WARN][20] ([i915#1982] / [i915#3143]) -> [DMESG-WARN][21] ([i915#3143])
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/fi-glk-dsi/igt@i915_pm_rpm@module-reload.html
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/fi-glk-dsi/igt@i915_pm_rpm@module-reload.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#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1222]: https://gitlab.freedesktop.org/drm/intel/issues/1222
  [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
  [i915#1569]: https://gitlab.freedesktop.org/drm/intel/issues/1569
  [i915#1602]: https://gitlab.freedesktop.org/drm/intel/issues/1602
  [i915#192]: https://gitlab.freedesktop.org/drm/intel/issues/192
  [i915#193]: https://gitlab.freedesktop.org/drm/intel/issues/193
  [i915#194]: https://gitlab.freedesktop.org/drm/intel/issues/194
  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#2029]: https://gitlab.freedesktop.org/drm/intel/issues/2029
  [i915#2502]: https://gitlab.freedesktop.org/drm/intel/issues/2502
  [i915#2927]: https://gitlab.freedesktop.org/drm/intel/issues/2927
  [i915#3047]: https://gitlab.freedesktop.org/drm/intel/issues/3047
  [i915#3143]: https://gitlab.freedesktop.org/drm/intel/issues/3143
  [i915#3145]: https://gitlab.freedesktop.org/drm/intel/issues/3145
  [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402


Participating hosts (47 -> 43)
------------------------------

  Additional (1): 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_9882 -> Patchwork_19837

  CI-20190529: 20190529
  CI_DRM_9882: 34f82d5853a3c6467ccf71e055e3432d2b12ecb9 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6040: 69b578b6ab0a36750f0d23c223a3487fc88fb6a7 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_19837: e2befe20334528847daf40f225f7cc9e0343e9a8 @ git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

e2befe203345 drm/doc: Add RFC section
2b8691372f19 drm/i915: add gem/gt TODO

== Logs ==

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

[-- Attachment #1.2: Type: text/html, Size: 7616 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 1/2] drm/i915: add gem/gt TODO

[Jani Nikula]

On Tue, 23 Mar 2021, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> We've discussed a bit how to get the gem/gt team better integrated
> and collaborate more with the wider community and agreed to the
> following:
>
> - all gem/gt patches are reviewed on dri-devel for now. That's
>   overkill, but in the past there was definitely too little of that.
>
> - i915-gem folks are encouraged to cross review core patches from
>   other teams
>
> - big features (especially uapi changes) need to be discussed in an
>   rfc patch that documents the interface and big picture design,
>   before we get lost in the details of the code
>
> - Also a rough TODO (can be refined as we go ofc) to get gem/gt back
>   on track, like we've e.g. done with DAL/DC to get that in shape.

I personally think there should be a lower bar for discussing and
editing the TODO items than via patches on the mailing list. Granted,
the TODO file enforces the discussion happens at a large enough
audience, but for at least some of the items I'd suggest filing gitlab
issues [1], with todo label, and tracking there.

BR,
Jani.


[1] https://gitlab.freedesktop.org/drm/intel/-/issues



>
> Cc: Jani Nikula <jani.nikula@linux.intel.com>
> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> Cc: Jason Ekstrand <jason@jlekstrand.net>
> Cc: Dave Airlie <airlied@redhat.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---
>  drivers/gpu/drm/i915/TODO.txt | 36 +++++++++++++++++++++++++++++++++++
>  1 file changed, 36 insertions(+)
>  create mode 100644 drivers/gpu/drm/i915/TODO.txt
>
> diff --git a/drivers/gpu/drm/i915/TODO.txt b/drivers/gpu/drm/i915/TODO.txt
> new file mode 100644
> index 000000000000..d2e5bbb6339d
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/TODO.txt
> @@ -0,0 +1,36 @@
> +gem/gt TODO items
> +-----------------
> +
> +- For discrete memory manager, merge enough dg1 to be able to refactor it to
> +  TTM. Then land pci ids (just in case that turns up an uapi problem). TTM has
> +  improved a lot the past 2 years, there's no reason anymore not to use it.
> +
> +- Come up with a plan what to do with drm/scheduler and how to get there.
> +
> +- There's a lot of complexity added past few years to make relocations faster.
> +  That doesn't make sense given hw and gpu apis moved away from this model years
> +  ago:
> +  1. Land a modern pre-bound uapi like VM_BIND
> +  2. Any complexity added in this area past few years which can't be justified
> +  with VM_BIND using userspace should be removed. Looking at amdgpu dma_resv on
> +  the bo and vm, plus some lru locks is all that needed. No complex rcu,
> +  refcounts, caching, ... on everything.
> +  This is the matching task on the vm side compared to ttm/dma_resv on the
> +  backing storage side.
> +
> +- i915_sw_fence seems to be the main structure for the i915-gem dma_fence model.
> +  How-to-dma_fence is core and drivers really shouldn't build their own world
> +  here, treating everything else as a fixed platform. i915_sw_fence concepts
> +  should be moved to dma_fence, drm/scheduler or atomic commit helpers. Or
> +  removed if dri-devel consensus is that it's not a good idea. Once that's done
> +  maybe even remove it if there's nothing left.
> +
> +Smaller things:
> +- i915_utils.h needs to be moved to the right places.
> +
> +- dma_fence_work should be in drivers/dma-buf
> +
> +- i915_mm.c should be moved to the right places. Some of the helpers also look a
> +  bit fishy:
> +
> +  https://lore.kernel.org/linux-mm/20210301083320.943079-1-hch@lst.de/

-- 
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 1/2] drm/i915: add gem/gt TODO

[Jani Nikula]

On Tue, 23 Mar 2021, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> We've discussed a bit how to get the gem/gt team better integrated
> and collaborate more with the wider community and agreed to the
> following:
>
> - all gem/gt patches are reviewed on dri-devel for now. That's
>   overkill, but in the past there was definitely too little of that.
>
> - i915-gem folks are encouraged to cross review core patches from
>   other teams
>
> - big features (especially uapi changes) need to be discussed in an
>   rfc patch that documents the interface and big picture design,
>   before we get lost in the details of the code
>
> - Also a rough TODO (can be refined as we go ofc) to get gem/gt back
>   on track, like we've e.g. done with DAL/DC to get that in shape.

I personally think there should be a lower bar for discussing and
editing the TODO items than via patches on the mailing list. Granted,
the TODO file enforces the discussion happens at a large enough
audience, but for at least some of the items I'd suggest filing gitlab
issues [1], with todo label, and tracking there.

BR,
Jani.


[1] https://gitlab.freedesktop.org/drm/intel/-/issues



>
> Cc: Jani Nikula <jani.nikula@linux.intel.com>
> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> Cc: Jason Ekstrand <jason@jlekstrand.net>
> Cc: Dave Airlie <airlied@redhat.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---
>  drivers/gpu/drm/i915/TODO.txt | 36 +++++++++++++++++++++++++++++++++++
>  1 file changed, 36 insertions(+)
>  create mode 100644 drivers/gpu/drm/i915/TODO.txt
>
> diff --git a/drivers/gpu/drm/i915/TODO.txt b/drivers/gpu/drm/i915/TODO.txt
> new file mode 100644
> index 000000000000..d2e5bbb6339d
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/TODO.txt
> @@ -0,0 +1,36 @@
> +gem/gt TODO items
> +-----------------
> +
> +- For discrete memory manager, merge enough dg1 to be able to refactor it to
> +  TTM. Then land pci ids (just in case that turns up an uapi problem). TTM has
> +  improved a lot the past 2 years, there's no reason anymore not to use it.
> +
> +- Come up with a plan what to do with drm/scheduler and how to get there.
> +
> +- There's a lot of complexity added past few years to make relocations faster.
> +  That doesn't make sense given hw and gpu apis moved away from this model years
> +  ago:
> +  1. Land a modern pre-bound uapi like VM_BIND
> +  2. Any complexity added in this area past few years which can't be justified
> +  with VM_BIND using userspace should be removed. Looking at amdgpu dma_resv on
> +  the bo and vm, plus some lru locks is all that needed. No complex rcu,
> +  refcounts, caching, ... on everything.
> +  This is the matching task on the vm side compared to ttm/dma_resv on the
> +  backing storage side.
> +
> +- i915_sw_fence seems to be the main structure for the i915-gem dma_fence model.
> +  How-to-dma_fence is core and drivers really shouldn't build their own world
> +  here, treating everything else as a fixed platform. i915_sw_fence concepts
> +  should be moved to dma_fence, drm/scheduler or atomic commit helpers. Or
> +  removed if dri-devel consensus is that it's not a good idea. Once that's done
> +  maybe even remove it if there's nothing left.
> +
> +Smaller things:
> +- i915_utils.h needs to be moved to the right places.
> +
> +- dma_fence_work should be in drivers/dma-buf
> +
> +- i915_mm.c should be moved to the right places. Some of the helpers also look a
> +  bit fishy:
> +
> +  https://lore.kernel.org/linux-mm/20210301083320.943079-1-hch@lst.de/

-- 
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 1/2] drm/i915: add gem/gt TODO

[Daniel Vetter]

On Tue, Mar 23, 2021 at 12:13:11PM +0200, Jani Nikula wrote:
> On Tue, 23 Mar 2021, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> > We've discussed a bit how to get the gem/gt team better integrated
> > and collaborate more with the wider community and agreed to the
> > following:
> >
> > - all gem/gt patches are reviewed on dri-devel for now. That's
> >   overkill, but in the past there was definitely too little of that.
> >
> > - i915-gem folks are encouraged to cross review core patches from
> >   other teams
> >
> > - big features (especially uapi changes) need to be discussed in an
> >   rfc patch that documents the interface and big picture design,
> >   before we get lost in the details of the code
> >
> > - Also a rough TODO (can be refined as we go ofc) to get gem/gt back
> >   on track, like we've e.g. done with DAL/DC to get that in shape.
> 
> I personally think there should be a lower bar for discussing and
> editing the TODO items than via patches on the mailing list. Granted,
> the TODO file enforces the discussion happens at a large enough
> audience, but for at least some of the items I'd suggest filing gitlab
> issues [1], with todo label, and tracking there.

In general yes, and I'd go even further: it's up to each team/contributor
how they track review feedback and further work, whether that's gitlab or
some notes or just in their heads.

This is a different situation here, and the "changes require big audience"
is a feature, not a bug. But it is a very exceptional situation, I think
this is only the 2nd time we're using a formal TODO for a gpu driver. If
we ignore gma500 in staging, which for me only showed that the separate
staging tree doesn't work so well for complex drivers like we have.
-Daniel

> 
> BR,
> Jani.
> 
> 
> [1] https://gitlab.freedesktop.org/drm/intel/-/issues
> 
> 
> 
> >
> > Cc: Jani Nikula <jani.nikula@linux.intel.com>
> > Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > Cc: Jason Ekstrand <jason@jlekstrand.net>
> > Cc: Dave Airlie <airlied@redhat.com>
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > ---
> >  drivers/gpu/drm/i915/TODO.txt | 36 +++++++++++++++++++++++++++++++++++
> >  1 file changed, 36 insertions(+)
> >  create mode 100644 drivers/gpu/drm/i915/TODO.txt
> >
> > diff --git a/drivers/gpu/drm/i915/TODO.txt b/drivers/gpu/drm/i915/TODO.txt
> > new file mode 100644
> > index 000000000000..d2e5bbb6339d
> > --- /dev/null
> > +++ b/drivers/gpu/drm/i915/TODO.txt
> > @@ -0,0 +1,36 @@
> > +gem/gt TODO items
> > +-----------------
> > +
> > +- For discrete memory manager, merge enough dg1 to be able to refactor it to
> > +  TTM. Then land pci ids (just in case that turns up an uapi problem). TTM has
> > +  improved a lot the past 2 years, there's no reason anymore not to use it.
> > +
> > +- Come up with a plan what to do with drm/scheduler and how to get there.
> > +
> > +- There's a lot of complexity added past few years to make relocations faster.
> > +  That doesn't make sense given hw and gpu apis moved away from this model years
> > +  ago:
> > +  1. Land a modern pre-bound uapi like VM_BIND
> > +  2. Any complexity added in this area past few years which can't be justified
> > +  with VM_BIND using userspace should be removed. Looking at amdgpu dma_resv on
> > +  the bo and vm, plus some lru locks is all that needed. No complex rcu,
> > +  refcounts, caching, ... on everything.
> > +  This is the matching task on the vm side compared to ttm/dma_resv on the
> > +  backing storage side.
> > +
> > +- i915_sw_fence seems to be the main structure for the i915-gem dma_fence model.
> > +  How-to-dma_fence is core and drivers really shouldn't build their own world
> > +  here, treating everything else as a fixed platform. i915_sw_fence concepts
> > +  should be moved to dma_fence, drm/scheduler or atomic commit helpers. Or
> > +  removed if dri-devel consensus is that it's not a good idea. Once that's done
> > +  maybe even remove it if there's nothing left.
> > +
> > +Smaller things:
> > +- i915_utils.h needs to be moved to the right places.
> > +
> > +- dma_fence_work should be in drivers/dma-buf
> > +
> > +- i915_mm.c should be moved to the right places. Some of the helpers also look a
> > +  bit fishy:
> > +
> > +  https://lore.kernel.org/linux-mm/20210301083320.943079-1-hch@lst.de/
> 
> -- 
> Jani Nikula, Intel Open Source Graphics Center

-- 
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 1/2] drm/i915: add gem/gt TODO

[Daniel Vetter]

On Tue, Mar 23, 2021 at 12:13:11PM +0200, Jani Nikula wrote:
> On Tue, 23 Mar 2021, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> > We've discussed a bit how to get the gem/gt team better integrated
> > and collaborate more with the wider community and agreed to the
> > following:
> >
> > - all gem/gt patches are reviewed on dri-devel for now. That's
> >   overkill, but in the past there was definitely too little of that.
> >
> > - i915-gem folks are encouraged to cross review core patches from
> >   other teams
> >
> > - big features (especially uapi changes) need to be discussed in an
> >   rfc patch that documents the interface and big picture design,
> >   before we get lost in the details of the code
> >
> > - Also a rough TODO (can be refined as we go ofc) to get gem/gt back
> >   on track, like we've e.g. done with DAL/DC to get that in shape.
> 
> I personally think there should be a lower bar for discussing and
> editing the TODO items than via patches on the mailing list. Granted,
> the TODO file enforces the discussion happens at a large enough
> audience, but for at least some of the items I'd suggest filing gitlab
> issues [1], with todo label, and tracking there.

In general yes, and I'd go even further: it's up to each team/contributor
how they track review feedback and further work, whether that's gitlab or
some notes or just in their heads.

This is a different situation here, and the "changes require big audience"
is a feature, not a bug. But it is a very exceptional situation, I think
this is only the 2nd time we're using a formal TODO for a gpu driver. If
we ignore gma500 in staging, which for me only showed that the separate
staging tree doesn't work so well for complex drivers like we have.
-Daniel

> 
> BR,
> Jani.
> 
> 
> [1] https://gitlab.freedesktop.org/drm/intel/-/issues
> 
> 
> 
> >
> > Cc: Jani Nikula <jani.nikula@linux.intel.com>
> > Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > Cc: Jason Ekstrand <jason@jlekstrand.net>
> > Cc: Dave Airlie <airlied@redhat.com>
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > ---
> >  drivers/gpu/drm/i915/TODO.txt | 36 +++++++++++++++++++++++++++++++++++
> >  1 file changed, 36 insertions(+)
> >  create mode 100644 drivers/gpu/drm/i915/TODO.txt
> >
> > diff --git a/drivers/gpu/drm/i915/TODO.txt b/drivers/gpu/drm/i915/TODO.txt
> > new file mode 100644
> > index 000000000000..d2e5bbb6339d
> > --- /dev/null
> > +++ b/drivers/gpu/drm/i915/TODO.txt
> > @@ -0,0 +1,36 @@
> > +gem/gt TODO items
> > +-----------------
> > +
> > +- For discrete memory manager, merge enough dg1 to be able to refactor it to
> > +  TTM. Then land pci ids (just in case that turns up an uapi problem). TTM has
> > +  improved a lot the past 2 years, there's no reason anymore not to use it.
> > +
> > +- Come up with a plan what to do with drm/scheduler and how to get there.
> > +
> > +- There's a lot of complexity added past few years to make relocations faster.
> > +  That doesn't make sense given hw and gpu apis moved away from this model years
> > +  ago:
> > +  1. Land a modern pre-bound uapi like VM_BIND
> > +  2. Any complexity added in this area past few years which can't be justified
> > +  with VM_BIND using userspace should be removed. Looking at amdgpu dma_resv on
> > +  the bo and vm, plus some lru locks is all that needed. No complex rcu,
> > +  refcounts, caching, ... on everything.
> > +  This is the matching task on the vm side compared to ttm/dma_resv on the
> > +  backing storage side.
> > +
> > +- i915_sw_fence seems to be the main structure for the i915-gem dma_fence model.
> > +  How-to-dma_fence is core and drivers really shouldn't build their own world
> > +  here, treating everything else as a fixed platform. i915_sw_fence concepts
> > +  should be moved to dma_fence, drm/scheduler or atomic commit helpers. Or
> > +  removed if dri-devel consensus is that it's not a good idea. Once that's done
> > +  maybe even remove it if there's nothing left.
> > +
> > +Smaller things:
> > +- i915_utils.h needs to be moved to the right places.
> > +
> > +- dma_fence_work should be in drivers/dma-buf
> > +
> > +- i915_mm.c should be moved to the right places. Some of the helpers also look a
> > +  bit fishy:
> > +
> > +  https://lore.kernel.org/linux-mm/20210301083320.943079-1-hch@lst.de/
> 
> -- 
> Jani Nikula, Intel Open Source Graphics Center

-- 
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 1/2] drm/i915: add gem/gt TODO

[Rodrigo Vivi]

On Tue, Mar 23, 2021 at 12:57:39PM +0100, Daniel Vetter wrote:
> On Tue, Mar 23, 2021 at 12:13:11PM +0200, Jani Nikula wrote:
> > On Tue, 23 Mar 2021, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> > > We've discussed a bit how to get the gem/gt team better integrated
> > > and collaborate more with the wider community and agreed to the
> > > following:
> > >
> > > - all gem/gt patches are reviewed on dri-devel for now. That's
> > >   overkill, but in the past there was definitely too little of that.
> > >
> > > - i915-gem folks are encouraged to cross review core patches from
> > >   other teams
> > >
> > > - big features (especially uapi changes) need to be discussed in an
> > >   rfc patch that documents the interface and big picture design,
> > >   before we get lost in the details of the code
> > >
> > > - Also a rough TODO (can be refined as we go ofc) to get gem/gt back
> > >   on track, like we've e.g. done with DAL/DC to get that in shape.
> > 
> > I personally think there should be a lower bar for discussing and
> > editing the TODO items than via patches on the mailing list. Granted,
> > the TODO file enforces the discussion happens at a large enough
> > audience, but for at least some of the items I'd suggest filing gitlab
> > issues [1], with todo label, and tracking there.

I also don't like the todo list in files and I agree that gitlab issues
section should be better...

> In general yes, and I'd go even further: it's up to each team/contributor
> how they track review feedback and further work, whether that's gitlab or
> some notes or just in their heads.
> 
> This is a different situation here, and the "changes require big audience"
> is a feature, not a bug. But it is a very exceptional situation, I think
> this is only the 2nd time we're using a formal TODO for a gpu driver. If
> we ignore gma500 in staging, which for me only showed that the separate
> staging tree doesn't work so well for complex drivers like we have.

... but I understand the motivation, so

Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

However... what about:

1. moving the smaller items to gitlab at least?
2. having both, all the entries in the todo file have gitlab issue
associated and the number-id is also here in the todo file?

> -Daniel
> 
> > 
> > BR,
> > Jani.
> > 
> > 
> > [1] https://gitlab.freedesktop.org/drm/intel/-/issues
> > 
> > 
> > 
> > >
> > > Cc: Jani Nikula <jani.nikula@linux.intel.com>
> > > Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> > > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > Cc: Jason Ekstrand <jason@jlekstrand.net>
> > > Cc: Dave Airlie <airlied@redhat.com>
> > > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > > ---
> > >  drivers/gpu/drm/i915/TODO.txt | 36 +++++++++++++++++++++++++++++++++++
> > >  1 file changed, 36 insertions(+)
> > >  create mode 100644 drivers/gpu/drm/i915/TODO.txt
> > >
> > > diff --git a/drivers/gpu/drm/i915/TODO.txt b/drivers/gpu/drm/i915/TODO.txt
> > > new file mode 100644
> > > index 000000000000..d2e5bbb6339d
> > > --- /dev/null
> > > +++ b/drivers/gpu/drm/i915/TODO.txt
> > > @@ -0,0 +1,36 @@
> > > +gem/gt TODO items
> > > +-----------------
> > > +
> > > +- For discrete memory manager, merge enough dg1 to be able to refactor it to
> > > +  TTM. Then land pci ids (just in case that turns up an uapi problem). TTM has
> > > +  improved a lot the past 2 years, there's no reason anymore not to use it.
> > > +
> > > +- Come up with a plan what to do with drm/scheduler and how to get there.
> > > +
> > > +- There's a lot of complexity added past few years to make relocations faster.
> > > +  That doesn't make sense given hw and gpu apis moved away from this model years
> > > +  ago:
> > > +  1. Land a modern pre-bound uapi like VM_BIND
> > > +  2. Any complexity added in this area past few years which can't be justified
> > > +  with VM_BIND using userspace should be removed. Looking at amdgpu dma_resv on
> > > +  the bo and vm, plus some lru locks is all that needed. No complex rcu,
> > > +  refcounts, caching, ... on everything.
> > > +  This is the matching task on the vm side compared to ttm/dma_resv on the
> > > +  backing storage side.
> > > +
> > > +- i915_sw_fence seems to be the main structure for the i915-gem dma_fence model.
> > > +  How-to-dma_fence is core and drivers really shouldn't build their own world
> > > +  here, treating everything else as a fixed platform. i915_sw_fence concepts
> > > +  should be moved to dma_fence, drm/scheduler or atomic commit helpers. Or
> > > +  removed if dri-devel consensus is that it's not a good idea. Once that's done
> > > +  maybe even remove it if there's nothing left.
> > > +
> > > +Smaller things:
> > > +- i915_utils.h needs to be moved to the right places.
> > > +
> > > +- dma_fence_work should be in drivers/dma-buf
> > > +
> > > +- i915_mm.c should be moved to the right places. Some of the helpers also look a
> > > +  bit fishy:
> > > +
> > > +  https://lore.kernel.org/linux-mm/20210301083320.943079-1-hch@lst.de/
> > 
> > -- 
> > Jani Nikula, Intel Open Source Graphics Center
> 
> -- 
> 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 1/2] drm/i915: add gem/gt TODO

[Rodrigo Vivi]

On Tue, Mar 23, 2021 at 12:57:39PM +0100, Daniel Vetter wrote:
> On Tue, Mar 23, 2021 at 12:13:11PM +0200, Jani Nikula wrote:
> > On Tue, 23 Mar 2021, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> > > We've discussed a bit how to get the gem/gt team better integrated
> > > and collaborate more with the wider community and agreed to the
> > > following:
> > >
> > > - all gem/gt patches are reviewed on dri-devel for now. That's
> > >   overkill, but in the past there was definitely too little of that.
> > >
> > > - i915-gem folks are encouraged to cross review core patches from
> > >   other teams
> > >
> > > - big features (especially uapi changes) need to be discussed in an
> > >   rfc patch that documents the interface and big picture design,
> > >   before we get lost in the details of the code
> > >
> > > - Also a rough TODO (can be refined as we go ofc) to get gem/gt back
> > >   on track, like we've e.g. done with DAL/DC to get that in shape.
> > 
> > I personally think there should be a lower bar for discussing and
> > editing the TODO items than via patches on the mailing list. Granted,
> > the TODO file enforces the discussion happens at a large enough
> > audience, but for at least some of the items I'd suggest filing gitlab
> > issues [1], with todo label, and tracking there.

I also don't like the todo list in files and I agree that gitlab issues
section should be better...

> In general yes, and I'd go even further: it's up to each team/contributor
> how they track review feedback and further work, whether that's gitlab or
> some notes or just in their heads.
> 
> This is a different situation here, and the "changes require big audience"
> is a feature, not a bug. But it is a very exceptional situation, I think
> this is only the 2nd time we're using a formal TODO for a gpu driver. If
> we ignore gma500 in staging, which for me only showed that the separate
> staging tree doesn't work so well for complex drivers like we have.

... but I understand the motivation, so

Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

However... what about:

1. moving the smaller items to gitlab at least?
2. having both, all the entries in the todo file have gitlab issue
associated and the number-id is also here in the todo file?

> -Daniel
> 
> > 
> > BR,
> > Jani.
> > 
> > 
> > [1] https://gitlab.freedesktop.org/drm/intel/-/issues
> > 
> > 
> > 
> > >
> > > Cc: Jani Nikula <jani.nikula@linux.intel.com>
> > > Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> > > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > Cc: Jason Ekstrand <jason@jlekstrand.net>
> > > Cc: Dave Airlie <airlied@redhat.com>
> > > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > > ---
> > >  drivers/gpu/drm/i915/TODO.txt | 36 +++++++++++++++++++++++++++++++++++
> > >  1 file changed, 36 insertions(+)
> > >  create mode 100644 drivers/gpu/drm/i915/TODO.txt
> > >
> > > diff --git a/drivers/gpu/drm/i915/TODO.txt b/drivers/gpu/drm/i915/TODO.txt
> > > new file mode 100644
> > > index 000000000000..d2e5bbb6339d
> > > --- /dev/null
> > > +++ b/drivers/gpu/drm/i915/TODO.txt
> > > @@ -0,0 +1,36 @@
> > > +gem/gt TODO items
> > > +-----------------
> > > +
> > > +- For discrete memory manager, merge enough dg1 to be able to refactor it to
> > > +  TTM. Then land pci ids (just in case that turns up an uapi problem). TTM has
> > > +  improved a lot the past 2 years, there's no reason anymore not to use it.
> > > +
> > > +- Come up with a plan what to do with drm/scheduler and how to get there.
> > > +
> > > +- There's a lot of complexity added past few years to make relocations faster.
> > > +  That doesn't make sense given hw and gpu apis moved away from this model years
> > > +  ago:
> > > +  1. Land a modern pre-bound uapi like VM_BIND
> > > +  2. Any complexity added in this area past few years which can't be justified
> > > +  with VM_BIND using userspace should be removed. Looking at amdgpu dma_resv on
> > > +  the bo and vm, plus some lru locks is all that needed. No complex rcu,
> > > +  refcounts, caching, ... on everything.
> > > +  This is the matching task on the vm side compared to ttm/dma_resv on the
> > > +  backing storage side.
> > > +
> > > +- i915_sw_fence seems to be the main structure for the i915-gem dma_fence model.
> > > +  How-to-dma_fence is core and drivers really shouldn't build their own world
> > > +  here, treating everything else as a fixed platform. i915_sw_fence concepts
> > > +  should be moved to dma_fence, drm/scheduler or atomic commit helpers. Or
> > > +  removed if dri-devel consensus is that it's not a good idea. Once that's done
> > > +  maybe even remove it if there's nothing left.
> > > +
> > > +Smaller things:
> > > +- i915_utils.h needs to be moved to the right places.
> > > +
> > > +- dma_fence_work should be in drivers/dma-buf
> > > +
> > > +- i915_mm.c should be moved to the right places. Some of the helpers also look a
> > > +  bit fishy:
> > > +
> > > +  https://lore.kernel.org/linux-mm/20210301083320.943079-1-hch@lst.de/
> > 
> > -- 
> > Jani Nikula, Intel Open Source Graphics Center
> 
> -- 
> 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 1/2] drm/i915: add gem/gt TODO

[Daniel Vetter]

On Tue, Mar 23, 2021 at 08:34:55AM -0400, Rodrigo Vivi wrote:
> On Tue, Mar 23, 2021 at 12:57:39PM +0100, Daniel Vetter wrote:
> > On Tue, Mar 23, 2021 at 12:13:11PM +0200, Jani Nikula wrote:
> > > On Tue, 23 Mar 2021, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> > > > We've discussed a bit how to get the gem/gt team better integrated
> > > > and collaborate more with the wider community and agreed to the
> > > > following:
> > > >
> > > > - all gem/gt patches are reviewed on dri-devel for now. That's
> > > >   overkill, but in the past there was definitely too little of that.
> > > >
> > > > - i915-gem folks are encouraged to cross review core patches from
> > > >   other teams
> > > >
> > > > - big features (especially uapi changes) need to be discussed in an
> > > >   rfc patch that documents the interface and big picture design,
> > > >   before we get lost in the details of the code
> > > >
> > > > - Also a rough TODO (can be refined as we go ofc) to get gem/gt back
> > > >   on track, like we've e.g. done with DAL/DC to get that in shape.
> > > 
> > > I personally think there should be a lower bar for discussing and
> > > editing the TODO items than via patches on the mailing list. Granted,
> > > the TODO file enforces the discussion happens at a large enough
> > > audience, but for at least some of the items I'd suggest filing gitlab
> > > issues [1], with todo label, and tracking there.
> 
> I also don't like the todo list in files and I agree that gitlab issues
> section should be better...
> 
> > In general yes, and I'd go even further: it's up to each team/contributor
> > how they track review feedback and further work, whether that's gitlab or
> > some notes or just in their heads.
> > 
> > This is a different situation here, and the "changes require big audience"
> > is a feature, not a bug. But it is a very exceptional situation, I think
> > this is only the 2nd time we're using a formal TODO for a gpu driver. If
> > we ignore gma500 in staging, which for me only showed that the separate
> > staging tree doesn't work so well for complex drivers like we have.
> 
> ... but I understand the motivation, so
> 
> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> 
> However... what about:
> 
> 1. moving the smaller items to gitlab at least?
> 2. having both, all the entries in the todo file have gitlab issue
> associated and the number-id is also here in the todo file?

Yeah that sounds reasonable. tbh we haven't started any of the
intel-internal planning on most of these (ttm and scheduler are started),
so none of these tracking things exist yet at all ...
-Daniel

> 
> > -Daniel
> > 
> > > 
> > > BR,
> > > Jani.
> > > 
> > > 
> > > [1] https://gitlab.freedesktop.org/drm/intel/-/issues
> > > 
> > > 
> > > 
> > > >
> > > > Cc: Jani Nikula <jani.nikula@linux.intel.com>
> > > > Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> > > > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > > Cc: Jason Ekstrand <jason@jlekstrand.net>
> > > > Cc: Dave Airlie <airlied@redhat.com>
> > > > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > > > ---
> > > >  drivers/gpu/drm/i915/TODO.txt | 36 +++++++++++++++++++++++++++++++++++
> > > >  1 file changed, 36 insertions(+)
> > > >  create mode 100644 drivers/gpu/drm/i915/TODO.txt
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/TODO.txt b/drivers/gpu/drm/i915/TODO.txt
> > > > new file mode 100644
> > > > index 000000000000..d2e5bbb6339d
> > > > --- /dev/null
> > > > +++ b/drivers/gpu/drm/i915/TODO.txt
> > > > @@ -0,0 +1,36 @@
> > > > +gem/gt TODO items
> > > > +-----------------
> > > > +
> > > > +- For discrete memory manager, merge enough dg1 to be able to refactor it to
> > > > +  TTM. Then land pci ids (just in case that turns up an uapi problem). TTM has
> > > > +  improved a lot the past 2 years, there's no reason anymore not to use it.
> > > > +
> > > > +- Come up with a plan what to do with drm/scheduler and how to get there.
> > > > +
> > > > +- There's a lot of complexity added past few years to make relocations faster.
> > > > +  That doesn't make sense given hw and gpu apis moved away from this model years
> > > > +  ago:
> > > > +  1. Land a modern pre-bound uapi like VM_BIND
> > > > +  2. Any complexity added in this area past few years which can't be justified
> > > > +  with VM_BIND using userspace should be removed. Looking at amdgpu dma_resv on
> > > > +  the bo and vm, plus some lru locks is all that needed. No complex rcu,
> > > > +  refcounts, caching, ... on everything.
> > > > +  This is the matching task on the vm side compared to ttm/dma_resv on the
> > > > +  backing storage side.
> > > > +
> > > > +- i915_sw_fence seems to be the main structure for the i915-gem dma_fence model.
> > > > +  How-to-dma_fence is core and drivers really shouldn't build their own world
> > > > +  here, treating everything else as a fixed platform. i915_sw_fence concepts
> > > > +  should be moved to dma_fence, drm/scheduler or atomic commit helpers. Or
> > > > +  removed if dri-devel consensus is that it's not a good idea. Once that's done
> > > > +  maybe even remove it if there's nothing left.
> > > > +
> > > > +Smaller things:
> > > > +- i915_utils.h needs to be moved to the right places.
> > > > +
> > > > +- dma_fence_work should be in drivers/dma-buf
> > > > +
> > > > +- i915_mm.c should be moved to the right places. Some of the helpers also look a
> > > > +  bit fishy:
> > > > +
> > > > +  https://lore.kernel.org/linux-mm/20210301083320.943079-1-hch@lst.de/
> > > 
> > > -- 
> > > Jani Nikula, Intel Open Source Graphics Center
> > 
> > -- 
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch

-- 
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 1/2] drm/i915: add gem/gt TODO

[Daniel Vetter]

On Tue, Mar 23, 2021 at 08:34:55AM -0400, Rodrigo Vivi wrote:
> On Tue, Mar 23, 2021 at 12:57:39PM +0100, Daniel Vetter wrote:
> > On Tue, Mar 23, 2021 at 12:13:11PM +0200, Jani Nikula wrote:
> > > On Tue, 23 Mar 2021, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> > > > We've discussed a bit how to get the gem/gt team better integrated
> > > > and collaborate more with the wider community and agreed to the
> > > > following:
> > > >
> > > > - all gem/gt patches are reviewed on dri-devel for now. That's
> > > >   overkill, but in the past there was definitely too little of that.
> > > >
> > > > - i915-gem folks are encouraged to cross review core patches from
> > > >   other teams
> > > >
> > > > - big features (especially uapi changes) need to be discussed in an
> > > >   rfc patch that documents the interface and big picture design,
> > > >   before we get lost in the details of the code
> > > >
> > > > - Also a rough TODO (can be refined as we go ofc) to get gem/gt back
> > > >   on track, like we've e.g. done with DAL/DC to get that in shape.
> > > 
> > > I personally think there should be a lower bar for discussing and
> > > editing the TODO items than via patches on the mailing list. Granted,
> > > the TODO file enforces the discussion happens at a large enough
> > > audience, but for at least some of the items I'd suggest filing gitlab
> > > issues [1], with todo label, and tracking there.
> 
> I also don't like the todo list in files and I agree that gitlab issues
> section should be better...
> 
> > In general yes, and I'd go even further: it's up to each team/contributor
> > how they track review feedback and further work, whether that's gitlab or
> > some notes or just in their heads.
> > 
> > This is a different situation here, and the "changes require big audience"
> > is a feature, not a bug. But it is a very exceptional situation, I think
> > this is only the 2nd time we're using a formal TODO for a gpu driver. If
> > we ignore gma500 in staging, which for me only showed that the separate
> > staging tree doesn't work so well for complex drivers like we have.
> 
> ... but I understand the motivation, so
> 
> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> 
> However... what about:
> 
> 1. moving the smaller items to gitlab at least?
> 2. having both, all the entries in the todo file have gitlab issue
> associated and the number-id is also here in the todo file?

Yeah that sounds reasonable. tbh we haven't started any of the
intel-internal planning on most of these (ttm and scheduler are started),
so none of these tracking things exist yet at all ...
-Daniel

> 
> > -Daniel
> > 
> > > 
> > > BR,
> > > Jani.
> > > 
> > > 
> > > [1] https://gitlab.freedesktop.org/drm/intel/-/issues
> > > 
> > > 
> > > 
> > > >
> > > > Cc: Jani Nikula <jani.nikula@linux.intel.com>
> > > > Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> > > > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > > Cc: Jason Ekstrand <jason@jlekstrand.net>
> > > > Cc: Dave Airlie <airlied@redhat.com>
> > > > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > > > ---
> > > >  drivers/gpu/drm/i915/TODO.txt | 36 +++++++++++++++++++++++++++++++++++
> > > >  1 file changed, 36 insertions(+)
> > > >  create mode 100644 drivers/gpu/drm/i915/TODO.txt
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/TODO.txt b/drivers/gpu/drm/i915/TODO.txt
> > > > new file mode 100644
> > > > index 000000000000..d2e5bbb6339d
> > > > --- /dev/null
> > > > +++ b/drivers/gpu/drm/i915/TODO.txt
> > > > @@ -0,0 +1,36 @@
> > > > +gem/gt TODO items
> > > > +-----------------
> > > > +
> > > > +- For discrete memory manager, merge enough dg1 to be able to refactor it to
> > > > +  TTM. Then land pci ids (just in case that turns up an uapi problem). TTM has
> > > > +  improved a lot the past 2 years, there's no reason anymore not to use it.
> > > > +
> > > > +- Come up with a plan what to do with drm/scheduler and how to get there.
> > > > +
> > > > +- There's a lot of complexity added past few years to make relocations faster.
> > > > +  That doesn't make sense given hw and gpu apis moved away from this model years
> > > > +  ago:
> > > > +  1. Land a modern pre-bound uapi like VM_BIND
> > > > +  2. Any complexity added in this area past few years which can't be justified
> > > > +  with VM_BIND using userspace should be removed. Looking at amdgpu dma_resv on
> > > > +  the bo and vm, plus some lru locks is all that needed. No complex rcu,
> > > > +  refcounts, caching, ... on everything.
> > > > +  This is the matching task on the vm side compared to ttm/dma_resv on the
> > > > +  backing storage side.
> > > > +
> > > > +- i915_sw_fence seems to be the main structure for the i915-gem dma_fence model.
> > > > +  How-to-dma_fence is core and drivers really shouldn't build their own world
> > > > +  here, treating everything else as a fixed platform. i915_sw_fence concepts
> > > > +  should be moved to dma_fence, drm/scheduler or atomic commit helpers. Or
> > > > +  removed if dri-devel consensus is that it's not a good idea. Once that's done
> > > > +  maybe even remove it if there's nothing left.
> > > > +
> > > > +Smaller things:
> > > > +- i915_utils.h needs to be moved to the right places.
> > > > +
> > > > +- dma_fence_work should be in drivers/dma-buf
> > > > +
> > > > +- i915_mm.c should be moved to the right places. Some of the helpers also look a
> > > > +  bit fishy:
> > > > +
> > > > +  https://lore.kernel.org/linux-mm/20210301083320.943079-1-hch@lst.de/
> > > 
> > > -- 
> > > Jani Nikula, Intel Open Source Graphics Center
> > 
> > -- 
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch

-- 
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 1/2] drm/i915: add gem/gt TODO

[Jason Ekstrand]

On Tue, Mar 23, 2021 at 8:18 AM Daniel Vetter <daniel@ffwll.ch> wrote:
>
> On Tue, Mar 23, 2021 at 08:34:55AM -0400, Rodrigo Vivi wrote:
> > On Tue, Mar 23, 2021 at 12:57:39PM +0100, Daniel Vetter wrote:
> > > On Tue, Mar 23, 2021 at 12:13:11PM +0200, Jani Nikula wrote:
> > > > On Tue, 23 Mar 2021, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> > > > > We've discussed a bit how to get the gem/gt team better integrated
> > > > > and collaborate more with the wider community and agreed to the
> > > > > following:
> > > > >
> > > > > - all gem/gt patches are reviewed on dri-devel for now. That's
> > > > >   overkill, but in the past there was definitely too little of that.
> > > > >
> > > > > - i915-gem folks are encouraged to cross review core patches from
> > > > >   other teams
> > > > >
> > > > > - big features (especially uapi changes) need to be discussed in an
> > > > >   rfc patch that documents the interface and big picture design,
> > > > >   before we get lost in the details of the code
> > > > >
> > > > > - Also a rough TODO (can be refined as we go ofc) to get gem/gt back
> > > > >   on track, like we've e.g. done with DAL/DC to get that in shape.
> > > >
> > > > I personally think there should be a lower bar for discussing and
> > > > editing the TODO items than via patches on the mailing list. Granted,
> > > > the TODO file enforces the discussion happens at a large enough
> > > > audience, but for at least some of the items I'd suggest filing gitlab
> > > > issues [1], with todo label, and tracking there.
> >
> > I also don't like the todo list in files and I agree that gitlab issues
> > section should be better...
> >
> > > In general yes, and I'd go even further: it's up to each team/contributor
> > > how they track review feedback and further work, whether that's gitlab or
> > > some notes or just in their heads.
> > >
> > > This is a different situation here, and the "changes require big audience"
> > > is a feature, not a bug. But it is a very exceptional situation, I think
> > > this is only the 2nd time we're using a formal TODO for a gpu driver. If
> > > we ignore gma500 in staging, which for me only showed that the separate
> > > staging tree doesn't work so well for complex drivers like we have.
> >
> > ... but I understand the motivation, so
> >
> > Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> >
> > However... what about:
> >
> > 1. moving the smaller items to gitlab at least?
> > 2. having both, all the entries in the todo file have gitlab issue
> > associated and the number-id is also here in the todo file?
>
> Yeah that sounds reasonable. tbh we haven't started any of the
> intel-internal planning on most of these (ttm and scheduler are started),
> so none of these tracking things exist yet at all ...

I'm a fan of this.  GitLab issues provide a good place to organize the
chatter on any particular ToDo item.  I'd also rather see people
chattering about this stuff on public GitLab than JIRA, when possible.
The last patch in the series closing out a ToDo can be a patch to this
file to remove the bullet point.

--Jason

> -Daniel
>
> >
> > > -Daniel
> > >
> > > >
> > > > BR,
> > > > Jani.
> > > >
> > > >
> > > > [1] https://gitlab.freedesktop.org/drm/intel/-/issues
> > > >
> > > >
> > > >
> > > > >
> > > > > Cc: Jani Nikula <jani.nikula@linux.intel.com>
> > > > > Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> > > > > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > > > Cc: Jason Ekstrand <jason@jlekstrand.net>
> > > > > Cc: Dave Airlie <airlied@redhat.com>
> > > > > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > > > > ---
> > > > >  drivers/gpu/drm/i915/TODO.txt | 36 +++++++++++++++++++++++++++++++++++
> > > > >  1 file changed, 36 insertions(+)
> > > > >  create mode 100644 drivers/gpu/drm/i915/TODO.txt
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/TODO.txt b/drivers/gpu/drm/i915/TODO.txt
> > > > > new file mode 100644
> > > > > index 000000000000..d2e5bbb6339d
> > > > > --- /dev/null
> > > > > +++ b/drivers/gpu/drm/i915/TODO.txt
> > > > > @@ -0,0 +1,36 @@
> > > > > +gem/gt TODO items
> > > > > +-----------------
> > > > > +
> > > > > +- For discrete memory manager, merge enough dg1 to be able to refactor it to
> > > > > +  TTM. Then land pci ids (just in case that turns up an uapi problem). TTM has
> > > > > +  improved a lot the past 2 years, there's no reason anymore not to use it.
> > > > > +
> > > > > +- Come up with a plan what to do with drm/scheduler and how to get there.
> > > > > +
> > > > > +- There's a lot of complexity added past few years to make relocations faster.
> > > > > +  That doesn't make sense given hw and gpu apis moved away from this model years
> > > > > +  ago:
> > > > > +  1. Land a modern pre-bound uapi like VM_BIND
> > > > > +  2. Any complexity added in this area past few years which can't be justified
> > > > > +  with VM_BIND using userspace should be removed. Looking at amdgpu dma_resv on
> > > > > +  the bo and vm, plus some lru locks is all that needed. No complex rcu,
> > > > > +  refcounts, caching, ... on everything.
> > > > > +  This is the matching task on the vm side compared to ttm/dma_resv on the
> > > > > +  backing storage side.
> > > > > +
> > > > > +- i915_sw_fence seems to be the main structure for the i915-gem dma_fence model.
> > > > > +  How-to-dma_fence is core and drivers really shouldn't build their own world
> > > > > +  here, treating everything else as a fixed platform. i915_sw_fence concepts
> > > > > +  should be moved to dma_fence, drm/scheduler or atomic commit helpers. Or
> > > > > +  removed if dri-devel consensus is that it's not a good idea. Once that's done
> > > > > +  maybe even remove it if there's nothing left.
> > > > > +
> > > > > +Smaller things:
> > > > > +- i915_utils.h needs to be moved to the right places.
> > > > > +
> > > > > +- dma_fence_work should be in drivers/dma-buf
> > > > > +
> > > > > +- i915_mm.c should be moved to the right places. Some of the helpers also look a
> > > > > +  bit fishy:
> > > > > +
> > > > > +  https://lore.kernel.org/linux-mm/20210301083320.943079-1-hch@lst.de/
> > > >
> > > > --
> > > > Jani Nikula, Intel Open Source Graphics Center
> > >
> > > --
> > > Daniel Vetter
> > > Software Engineer, Intel Corporation
> > > http://blog.ffwll.ch
>
> --
> 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 1/2] drm/i915: add gem/gt TODO

[Jason Ekstrand]

On Tue, Mar 23, 2021 at 8:18 AM Daniel Vetter <daniel@ffwll.ch> wrote:
>
> On Tue, Mar 23, 2021 at 08:34:55AM -0400, Rodrigo Vivi wrote:
> > On Tue, Mar 23, 2021 at 12:57:39PM +0100, Daniel Vetter wrote:
> > > On Tue, Mar 23, 2021 at 12:13:11PM +0200, Jani Nikula wrote:
> > > > On Tue, 23 Mar 2021, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> > > > > We've discussed a bit how to get the gem/gt team better integrated
> > > > > and collaborate more with the wider community and agreed to the
> > > > > following:
> > > > >
> > > > > - all gem/gt patches are reviewed on dri-devel for now. That's
> > > > >   overkill, but in the past there was definitely too little of that.
> > > > >
> > > > > - i915-gem folks are encouraged to cross review core patches from
> > > > >   other teams
> > > > >
> > > > > - big features (especially uapi changes) need to be discussed in an
> > > > >   rfc patch that documents the interface and big picture design,
> > > > >   before we get lost in the details of the code
> > > > >
> > > > > - Also a rough TODO (can be refined as we go ofc) to get gem/gt back
> > > > >   on track, like we've e.g. done with DAL/DC to get that in shape.
> > > >
> > > > I personally think there should be a lower bar for discussing and
> > > > editing the TODO items than via patches on the mailing list. Granted,
> > > > the TODO file enforces the discussion happens at a large enough
> > > > audience, but for at least some of the items I'd suggest filing gitlab
> > > > issues [1], with todo label, and tracking there.
> >
> > I also don't like the todo list in files and I agree that gitlab issues
> > section should be better...
> >
> > > In general yes, and I'd go even further: it's up to each team/contributor
> > > how they track review feedback and further work, whether that's gitlab or
> > > some notes or just in their heads.
> > >
> > > This is a different situation here, and the "changes require big audience"
> > > is a feature, not a bug. But it is a very exceptional situation, I think
> > > this is only the 2nd time we're using a formal TODO for a gpu driver. If
> > > we ignore gma500 in staging, which for me only showed that the separate
> > > staging tree doesn't work so well for complex drivers like we have.
> >
> > ... but I understand the motivation, so
> >
> > Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> >
> > However... what about:
> >
> > 1. moving the smaller items to gitlab at least?
> > 2. having both, all the entries in the todo file have gitlab issue
> > associated and the number-id is also here in the todo file?
>
> Yeah that sounds reasonable. tbh we haven't started any of the
> intel-internal planning on most of these (ttm and scheduler are started),
> so none of these tracking things exist yet at all ...

I'm a fan of this.  GitLab issues provide a good place to organize the
chatter on any particular ToDo item.  I'd also rather see people
chattering about this stuff on public GitLab than JIRA, when possible.
The last patch in the series closing out a ToDo can be a patch to this
file to remove the bullet point.

--Jason

> -Daniel
>
> >
> > > -Daniel
> > >
> > > >
> > > > BR,
> > > > Jani.
> > > >
> > > >
> > > > [1] https://gitlab.freedesktop.org/drm/intel/-/issues
> > > >
> > > >
> > > >
> > > > >
> > > > > Cc: Jani Nikula <jani.nikula@linux.intel.com>
> > > > > Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> > > > > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > > > Cc: Jason Ekstrand <jason@jlekstrand.net>
> > > > > Cc: Dave Airlie <airlied@redhat.com>
> > > > > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > > > > ---
> > > > >  drivers/gpu/drm/i915/TODO.txt | 36 +++++++++++++++++++++++++++++++++++
> > > > >  1 file changed, 36 insertions(+)
> > > > >  create mode 100644 drivers/gpu/drm/i915/TODO.txt
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/TODO.txt b/drivers/gpu/drm/i915/TODO.txt
> > > > > new file mode 100644
> > > > > index 000000000000..d2e5bbb6339d
> > > > > --- /dev/null
> > > > > +++ b/drivers/gpu/drm/i915/TODO.txt
> > > > > @@ -0,0 +1,36 @@
> > > > > +gem/gt TODO items
> > > > > +-----------------
> > > > > +
> > > > > +- For discrete memory manager, merge enough dg1 to be able to refactor it to
> > > > > +  TTM. Then land pci ids (just in case that turns up an uapi problem). TTM has
> > > > > +  improved a lot the past 2 years, there's no reason anymore not to use it.
> > > > > +
> > > > > +- Come up with a plan what to do with drm/scheduler and how to get there.
> > > > > +
> > > > > +- There's a lot of complexity added past few years to make relocations faster.
> > > > > +  That doesn't make sense given hw and gpu apis moved away from this model years
> > > > > +  ago:
> > > > > +  1. Land a modern pre-bound uapi like VM_BIND
> > > > > +  2. Any complexity added in this area past few years which can't be justified
> > > > > +  with VM_BIND using userspace should be removed. Looking at amdgpu dma_resv on
> > > > > +  the bo and vm, plus some lru locks is all that needed. No complex rcu,
> > > > > +  refcounts, caching, ... on everything.
> > > > > +  This is the matching task on the vm side compared to ttm/dma_resv on the
> > > > > +  backing storage side.
> > > > > +
> > > > > +- i915_sw_fence seems to be the main structure for the i915-gem dma_fence model.
> > > > > +  How-to-dma_fence is core and drivers really shouldn't build their own world
> > > > > +  here, treating everything else as a fixed platform. i915_sw_fence concepts
> > > > > +  should be moved to dma_fence, drm/scheduler or atomic commit helpers. Or
> > > > > +  removed if dri-devel consensus is that it's not a good idea. Once that's done
> > > > > +  maybe even remove it if there's nothing left.
> > > > > +
> > > > > +Smaller things:
> > > > > +- i915_utils.h needs to be moved to the right places.
> > > > > +
> > > > > +- dma_fence_work should be in drivers/dma-buf
> > > > > +
> > > > > +- i915_mm.c should be moved to the right places. Some of the helpers also look a
> > > > > +  bit fishy:
> > > > > +
> > > > > +  https://lore.kernel.org/linux-mm/20210301083320.943079-1-hch@lst.de/
> > > >
> > > > --
> > > > Jani Nikula, Intel Open Source Graphics Center
> > >
> > > --
> > > Daniel Vetter
> > > Software Engineer, Intel Corporation
> > > http://blog.ffwll.ch
>
> --
> 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 1/2] drm/i915: add gem/gt TODO

[Daniel Vetter]

On Tue, Mar 23, 2021 at 09:44:52AM +0100, Daniel Vetter wrote:
> We've discussed a bit how to get the gem/gt team better integrated
> and collaborate more with the wider community and agreed to the
> following:
> 
> - all gem/gt patches are reviewed on dri-devel for now. That's
>   overkill, but in the past there was definitely too little of that.
> 
> - i915-gem folks are encouraged to cross review core patches from
>   other teams
> 
> - big features (especially uapi changes) need to be discussed in an
>   rfc patch that documents the interface and big picture design,
>   before we get lost in the details of the code
> 
> - Also a rough TODO (can be refined as we go ofc) to get gem/gt back
>   on track, like we've e.g. done with DAL/DC to get that in shape.
> 
> Cc: Jani Nikula <jani.nikula@linux.intel.com>
> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> Cc: Jason Ekstrand <jason@jlekstrand.net>
> Cc: Dave Airlie <airlied@redhat.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---
>  drivers/gpu/drm/i915/TODO.txt | 36 +++++++++++++++++++++++++++++++++++
>  1 file changed, 36 insertions(+)
>  create mode 100644 drivers/gpu/drm/i915/TODO.txt
> 
> diff --git a/drivers/gpu/drm/i915/TODO.txt b/drivers/gpu/drm/i915/TODO.txt
> new file mode 100644
> index 000000000000..d2e5bbb6339d
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/TODO.txt
> @@ -0,0 +1,36 @@
> +gem/gt TODO items
> +-----------------
> +
> +- For discrete memory manager, merge enough dg1 to be able to refactor it to
> +  TTM. Then land pci ids (just in case that turns up an uapi problem). TTM has
> +  improved a lot the past 2 years, there's no reason anymore not to use it.
> +
> +- Come up with a plan what to do with drm/scheduler and how to get there.
> +
> +- There's a lot of complexity added past few years to make relocations faster.
> +  That doesn't make sense given hw and gpu apis moved away from this model years
> +  ago:
> +  1. Land a modern pre-bound uapi like VM_BIND
> +  2. Any complexity added in this area past few years which can't be justified
> +  with VM_BIND using userspace should be removed. Looking at amdgpu dma_resv on
> +  the bo and vm, plus some lru locks is all that needed. No complex rcu,
> +  refcounts, caching, ... on everything.
> +  This is the matching task on the vm side compared to ttm/dma_resv on the
> +  backing storage side.
> +
> +- i915_sw_fence seems to be the main structure for the i915-gem dma_fence model.
> +  How-to-dma_fence is core and drivers really shouldn't build their own world
> +  here, treating everything else as a fixed platform. i915_sw_fence concepts
> +  should be moved to dma_fence, drm/scheduler or atomic commit helpers. Or
> +  removed if dri-devel consensus is that it's not a good idea. Once that's done
> +  maybe even remove it if there's nothing left.
> +
> +Smaller things:
> +- i915_utils.h needs to be moved to the right places.
> +
> +- dma_fence_work should be in drivers/dma-buf
> +
> +- i915_mm.c should be moved to the right places. Some of the helpers also look a
> +  bit fishy:
> +
> +  https://lore.kernel.org/linux-mm/20210301083320.943079-1-hch@lst.de/

Jani just pointed me at another small helper that we should look at:

- tasklet helpers in i915_gem.h also look a bit misplaced and should
  probably be moved to tasklet headers.

Spotted through https://lore.kernel.org/lkml/20210323092221.awq7g5b2muzypjw3@flow/

I'll add that one in v2.

There is also the i915 ww locking context helpers from Maarten in there,
but right now those truly are i915 specific. Plus as part of the ttm
conversion they're already on the list of things we have to move. So I
think redundant to add the entire file.
-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 1/2] drm/i915: add gem/gt TODO

[Daniel Vetter]

On Tue, Mar 23, 2021 at 09:44:52AM +0100, Daniel Vetter wrote:
> We've discussed a bit how to get the gem/gt team better integrated
> and collaborate more with the wider community and agreed to the
> following:
> 
> - all gem/gt patches are reviewed on dri-devel for now. That's
>   overkill, but in the past there was definitely too little of that.
> 
> - i915-gem folks are encouraged to cross review core patches from
>   other teams
> 
> - big features (especially uapi changes) need to be discussed in an
>   rfc patch that documents the interface and big picture design,
>   before we get lost in the details of the code
> 
> - Also a rough TODO (can be refined as we go ofc) to get gem/gt back
>   on track, like we've e.g. done with DAL/DC to get that in shape.
> 
> Cc: Jani Nikula <jani.nikula@linux.intel.com>
> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> Cc: Jason Ekstrand <jason@jlekstrand.net>
> Cc: Dave Airlie <airlied@redhat.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---
>  drivers/gpu/drm/i915/TODO.txt | 36 +++++++++++++++++++++++++++++++++++
>  1 file changed, 36 insertions(+)
>  create mode 100644 drivers/gpu/drm/i915/TODO.txt
> 
> diff --git a/drivers/gpu/drm/i915/TODO.txt b/drivers/gpu/drm/i915/TODO.txt
> new file mode 100644
> index 000000000000..d2e5bbb6339d
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/TODO.txt
> @@ -0,0 +1,36 @@
> +gem/gt TODO items
> +-----------------
> +
> +- For discrete memory manager, merge enough dg1 to be able to refactor it to
> +  TTM. Then land pci ids (just in case that turns up an uapi problem). TTM has
> +  improved a lot the past 2 years, there's no reason anymore not to use it.
> +
> +- Come up with a plan what to do with drm/scheduler and how to get there.
> +
> +- There's a lot of complexity added past few years to make relocations faster.
> +  That doesn't make sense given hw and gpu apis moved away from this model years
> +  ago:
> +  1. Land a modern pre-bound uapi like VM_BIND
> +  2. Any complexity added in this area past few years which can't be justified
> +  with VM_BIND using userspace should be removed. Looking at amdgpu dma_resv on
> +  the bo and vm, plus some lru locks is all that needed. No complex rcu,
> +  refcounts, caching, ... on everything.
> +  This is the matching task on the vm side compared to ttm/dma_resv on the
> +  backing storage side.
> +
> +- i915_sw_fence seems to be the main structure for the i915-gem dma_fence model.
> +  How-to-dma_fence is core and drivers really shouldn't build their own world
> +  here, treating everything else as a fixed platform. i915_sw_fence concepts
> +  should be moved to dma_fence, drm/scheduler or atomic commit helpers. Or
> +  removed if dri-devel consensus is that it's not a good idea. Once that's done
> +  maybe even remove it if there's nothing left.
> +
> +Smaller things:
> +- i915_utils.h needs to be moved to the right places.
> +
> +- dma_fence_work should be in drivers/dma-buf
> +
> +- i915_mm.c should be moved to the right places. Some of the helpers also look a
> +  bit fishy:
> +
> +  https://lore.kernel.org/linux-mm/20210301083320.943079-1-hch@lst.de/

Jani just pointed me at another small helper that we should look at:

- tasklet helpers in i915_gem.h also look a bit misplaced and should
  probably be moved to tasklet headers.

Spotted through https://lore.kernel.org/lkml/20210323092221.awq7g5b2muzypjw3@flow/

I'll add that one in v2.

There is also the i915 ww locking context helpers from Maarten in there,
but right now those truly are i915 specific. Plus as part of the ttm
conversion they're already on the list of things we have to move. So I
think redundant to add the entire file.
-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 1/2] drm/i915: add gem/gt TODO

[Dave Airlie]

On Tue, 23 Mar 2021 at 23:17, Daniel Vetter <daniel@ffwll.ch> wrote:
>
> On Tue, Mar 23, 2021 at 09:44:52AM +0100, Daniel Vetter wrote:
> > We've discussed a bit how to get the gem/gt team better integrated
> > and collaborate more with the wider community and agreed to the
> > following:
> >
> > - all gem/gt patches are reviewed on dri-devel for now. That's
> >   overkill, but in the past there was definitely too little of that.
> >
> > - i915-gem folks are encouraged to cross review core patches from
> >   other teams
> >
> > - big features (especially uapi changes) need to be discussed in an
> >   rfc patch that documents the interface and big picture design,
> >   before we get lost in the details of the code
> >
> > - Also a rough TODO (can be refined as we go ofc) to get gem/gt back
> >   on track, like we've e.g. done with DAL/DC to get that in shape.

I think we mentioned in the past about having better annotations for
dma_fence critical sections,

Otherwise I think this is a great list to get us out of the woods and
seeing how to move forward again.

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

Re: [Intel-gfx] [PATCH 1/2] drm/i915: add gem/gt TODO

[Dave Airlie]

On Tue, 23 Mar 2021 at 23:17, Daniel Vetter <daniel@ffwll.ch> wrote:
>
> On Tue, Mar 23, 2021 at 09:44:52AM +0100, Daniel Vetter wrote:
> > We've discussed a bit how to get the gem/gt team better integrated
> > and collaborate more with the wider community and agreed to the
> > following:
> >
> > - all gem/gt patches are reviewed on dri-devel for now. That's
> >   overkill, but in the past there was definitely too little of that.
> >
> > - i915-gem folks are encouraged to cross review core patches from
> >   other teams
> >
> > - big features (especially uapi changes) need to be discussed in an
> >   rfc patch that documents the interface and big picture design,
> >   before we get lost in the details of the code
> >
> > - Also a rough TODO (can be refined as we go ofc) to get gem/gt back
> >   on track, like we've e.g. done with DAL/DC to get that in shape.

I think we mentioned in the past about having better annotations for
dma_fence critical sections,

Otherwise I think this is a great list to get us out of the woods and
seeing how to move forward again.

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

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2] drm/i915: add gem/gt TODO

[Patchwork]

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

== Series Details ==

Series: series starting with [1/2] drm/i915: add gem/gt TODO
URL   : https://patchwork.freedesktop.org/series/88329/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_9882_full -> Patchwork_19837_full
====================================================

Summary
-------

  **FAILURE**

  Serious unknown changes coming with Patchwork_19837_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_19837_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_19837_full:

### IGT changes ###

#### Possible regressions ####

  * igt@gem_exec_whisper@basic-queues-forked-all:
    - shard-iclb:         [PASS][1] -> [INCOMPLETE][2]
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-iclb5/igt@gem_exec_whisper@basic-queues-forked-all.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-iclb2/igt@gem_exec_whisper@basic-queues-forked-all.html

  * igt@gem_workarounds@suspend-resume-fd:
    - shard-snb:          [PASS][3] -> [TIMEOUT][4]
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-snb5/igt@gem_workarounds@suspend-resume-fd.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-snb6/igt@gem_workarounds@suspend-resume-fd.html

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

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

### IGT changes ###

#### Issues hit ####

  * igt@gem_create@create-massive:
    - shard-snb:          NOTRUN -> [DMESG-WARN][5] ([i915#3002])
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-snb2/igt@gem_create@create-massive.html

  * igt@gem_ctx_persistence@engines-hostile:
    - shard-snb:          NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#1099]) +1 similar issue
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-snb7/igt@gem_ctx_persistence@engines-hostile.html

  * igt@gem_exec_balancer@hang:
    - shard-iclb:         [PASS][7] -> [INCOMPLETE][8] ([i915#1895] / [i915#3031])
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-iclb7/igt@gem_exec_balancer@hang.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-iclb1/igt@gem_exec_balancer@hang.html

  * igt@gem_exec_create@legacy:
    - shard-glk:          [PASS][9] -> [DMESG-WARN][10] ([i915#118] / [i915#95])
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-glk6/igt@gem_exec_create@legacy.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-glk8/igt@gem_exec_create@legacy.html

  * igt@gem_exec_fair@basic-none-vip@rcs0:
    - shard-tglb:         NOTRUN -> [FAIL][11] ([i915#2842])
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-tglb6/igt@gem_exec_fair@basic-none-vip@rcs0.html
    - shard-glk:          NOTRUN -> [FAIL][12] ([i915#2842])
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-glk1/igt@gem_exec_fair@basic-none-vip@rcs0.html

  * igt@gem_exec_fair@basic-none@vecs0:
    - shard-kbl:          [PASS][13] -> [FAIL][14] ([i915#2842]) +2 similar issues
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-kbl1/igt@gem_exec_fair@basic-none@vecs0.html
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-kbl7/igt@gem_exec_fair@basic-none@vecs0.html

  * igt@gem_exec_fair@basic-pace-solo@rcs0:
    - shard-glk:          [PASS][15] -> [FAIL][16] ([i915#2842]) +1 similar issue
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-glk4/igt@gem_exec_fair@basic-pace-solo@rcs0.html
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-glk1/igt@gem_exec_fair@basic-pace-solo@rcs0.html
    - shard-tglb:         [PASS][17] -> [FAIL][18] ([i915#2842]) +1 similar issue
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-tglb5/igt@gem_exec_fair@basic-pace-solo@rcs0.html
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-tglb3/igt@gem_exec_fair@basic-pace-solo@rcs0.html

  * igt@gem_exec_fair@basic-throttle@rcs0:
    - shard-iclb:         NOTRUN -> [FAIL][19] ([i915#2849])
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-iclb5/igt@gem_exec_fair@basic-throttle@rcs0.html

  * igt@gem_exec_reloc@basic-parallel:
    - shard-apl:          NOTRUN -> [TIMEOUT][20] ([i915#3183])
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-apl8/igt@gem_exec_reloc@basic-parallel.html

  * igt@gem_exec_reloc@basic-wide-active@rcs0:
    - shard-snb:          NOTRUN -> [FAIL][21] ([i915#2389]) +2 similar issues
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-snb5/igt@gem_exec_reloc@basic-wide-active@rcs0.html

  * igt@gem_exec_schedule@semaphore-codependency:
    - shard-snb:          NOTRUN -> [SKIP][22] ([fdo#109271]) +160 similar issues
   [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-snb2/igt@gem_exec_schedule@semaphore-codependency.html

  * igt@gem_exec_schedule@u-fairslice-all:
    - shard-tglb:         [PASS][23] -> [DMESG-WARN][24] ([i915#2803])
   [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-tglb1/igt@gem_exec_schedule@u-fairslice-all.html
   [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-tglb3/igt@gem_exec_schedule@u-fairslice-all.html

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

  * igt@gem_mmap_gtt@cpuset-big-copy-odd:
    - shard-iclb:         [PASS][26] -> [FAIL][27] ([i915#307])
   [26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-iclb4/igt@gem_mmap_gtt@cpuset-big-copy-odd.html
   [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-iclb4/igt@gem_mmap_gtt@cpuset-big-copy-odd.html

  * igt@gem_pwrite@basic-exhaustion:
    - shard-snb:          NOTRUN -> [WARN][28] ([i915#2658])
   [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-snb7/igt@gem_pwrite@basic-exhaustion.html

  * igt@gem_render_copy@linear-to-vebox-y-tiled:
    - shard-apl:          NOTRUN -> [SKIP][29] ([fdo#109271]) +164 similar issues
   [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-apl8/igt@gem_render_copy@linear-to-vebox-y-tiled.html

  * igt@gem_userptr_blits@input-checking:
    - shard-skl:          NOTRUN -> [DMESG-WARN][30] ([i915#3002]) +1 similar issue
   [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-skl5/igt@gem_userptr_blits@input-checking.html
    - shard-tglb:         NOTRUN -> [DMESG-WARN][31] ([i915#3002])
   [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-tglb6/igt@gem_userptr_blits@input-checking.html
    - shard-glk:          NOTRUN -> [DMESG-WARN][32] ([i915#3002])
   [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-glk1/igt@gem_userptr_blits@input-checking.html

  * igt@gem_userptr_blits@vma-merge:
    - shard-apl:          NOTRUN -> [INCOMPLETE][33] ([i915#2502] / [i915#2667])
   [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-apl8/igt@gem_userptr_blits@vma-merge.html

  * igt@gem_workarounds@suspend-resume-context:
    - shard-apl:          NOTRUN -> [DMESG-WARN][34] ([i915#180])
   [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-apl6/igt@gem_workarounds@suspend-resume-context.html

  * igt@gen9_exec_parse@allowed-single:
    - shard-tglb:         NOTRUN -> [SKIP][35] ([fdo#112306])
   [35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-tglb6/igt@gen9_exec_parse@allowed-single.html

  * igt@kms_big_fb@x-tiled-16bpp-rotate-270:
    - shard-tglb:         NOTRUN -> [SKIP][36] ([fdo#111614])
   [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-tglb6/igt@kms_big_fb@x-tiled-16bpp-rotate-270.html

  * igt@kms_big_fb@yf-tiled-addfb-size-offset-overflow:
    - shard-tglb:         NOTRUN -> [SKIP][37] ([fdo#111615]) +1 similar issue
   [37]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-tglb6/igt@kms_big_fb@yf-tiled-addfb-size-offset-overflow.html

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

  * igt@kms_chamelium@dp-crc-fast:
    - shard-snb:          NOTRUN -> [SKIP][39] ([fdo#109271] / [fdo#111827]) +8 similar issues
   [39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-snb2/igt@kms_chamelium@dp-crc-fast.html

  * igt@kms_chamelium@dp-crc-multiple:
    - shard-tglb:         NOTRUN -> [SKIP][40] ([fdo#109284] / [fdo#111827]) +3 similar issues
   [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-tglb6/igt@kms_chamelium@dp-crc-multiple.html

  * igt@kms_chamelium@dp-mode-timings:
    - shard-apl:          NOTRUN -> [SKIP][41] ([fdo#109271] / [fdo#111827]) +19 similar issues
   [41]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-apl7/igt@kms_chamelium@dp-mode-timings.html

  * igt@kms_chamelium@hdmi-audio-edid:
    - shard-skl:          NOTRUN -> [SKIP][42] ([fdo#109271] / [fdo#111827]) +7 similar issues
   [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-skl8/igt@kms_chamelium@hdmi-audio-edid.html

  * igt@kms_chamelium@hdmi-crc-single:
    - shard-glk:          NOTRUN -> [SKIP][43] ([fdo#109271] / [fdo#111827]) +3 similar issues
   [43]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-glk1/igt@kms_chamelium@hdmi-crc-single.html

  * igt@kms_color@pipe-a-ctm-green-to-red:
    - shard-skl:          [PASS][44] -> [DMESG-WARN][45] ([i915#1982]) +1 similar issue
   [44]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-skl5/igt@kms_color@pipe-a-ctm-green-to-red.html
   [45]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-skl1/igt@kms_color@pipe-a-ctm-green-to-red.html

  * igt@kms_color_chamelium@pipe-a-degamma:
    - shard-kbl:          NOTRUN -> [SKIP][46] ([fdo#109271] / [fdo#111827]) +3 similar issues
   [46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-kbl3/igt@kms_color_chamelium@pipe-a-degamma.html

  * igt@kms_content_protection@atomic-dpms:
    - shard-apl:          NOTRUN -> [TIMEOUT][47] ([i915#1319])
   [47]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-apl7/igt@kms_content_protection@atomic-dpms.html

  * igt@kms_content_protection@content_type_change:
    - shard-iclb:         NOTRUN -> [SKIP][48] ([fdo#109300] / [fdo#111066])
   [48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-iclb5/igt@kms_content_protection@content_type_change.html

  * igt@kms_content_protection@lic:
    - shard-kbl:          NOTRUN -> [TIMEOUT][49] ([i915#1319])
   [49]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-kbl3/igt@kms_content_protection@lic.html

  * igt@kms_cursor_crc@pipe-a-cursor-dpms:
    - shard-skl:          NOTRUN -> [FAIL][50] ([i915#54])
   [50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-skl7/igt@kms_cursor_crc@pipe-a-cursor-dpms.html

  * igt@kms_cursor_crc@pipe-b-cursor-512x170-offscreen:
    - shard-tglb:         NOTRUN -> [SKIP][51] ([fdo#109279])
   [51]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-tglb6/igt@kms_cursor_crc@pipe-b-cursor-512x170-offscreen.html

  * igt@kms_cursor_crc@pipe-c-cursor-suspend:
    - shard-kbl:          [PASS][52] -> [DMESG-WARN][53] ([i915#180]) +1 similar issue
   [52]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-kbl2/igt@kms_cursor_crc@pipe-c-cursor-suspend.html
   [53]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-kbl1/igt@kms_cursor_crc@pipe-c-cursor-suspend.html

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

  * igt@kms_fbcon_fbt@fbc-suspend:
    - shard-kbl:          [PASS][55] -> [INCOMPLETE][56] ([i915#155] / [i915#180] / [i915#636])
   [55]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-kbl4/igt@kms_fbcon_fbt@fbc-suspend.html
   [56]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-kbl7/igt@kms_fbcon_fbt@fbc-suspend.html

  * igt@kms_flip@flip-vs-expired-vblank-interruptible@a-hdmi-a1:
    - shard-glk:          [PASS][57] -> [FAIL][58] ([i915#79])
   [57]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-glk3/igt@kms_flip@flip-vs-expired-vblank-interruptible@a-hdmi-a1.html
   [58]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-glk2/igt@kms_flip@flip-vs-expired-vblank-interruptible@a-hdmi-a1.html

  * igt@kms_flip_scaled_crc@flip-32bpp-ytileccs-to-64bpp-ytile:
    - shard-apl:          NOTRUN -> [SKIP][59] ([fdo#109271] / [i915#2642])
   [59]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-apl8/igt@kms_flip_scaled_crc@flip-32bpp-ytileccs-to-64bpp-ytile.html

  * igt@kms_frontbuffer_tracking@fbc-1p-shrfb-fliptrack-mmap-gtt:
    - shard-skl:          NOTRUN -> [SKIP][60] ([fdo#109271]) +109 similar issues
   [60]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-skl7/igt@kms_frontbuffer_tracking@fbc-1p-shrfb-fliptrack-mmap-gtt.html

  * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-pri-indfb-draw-render:
    - shard-iclb:         NOTRUN -> [SKIP][61] ([fdo#109280]) +4 similar issues
   [61]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-iclb5/igt@kms_frontbuffer_tracking@fbc-2p-primscrn-pri-indfb-draw-render.html

  * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-shrfb-plflip-blt:
    - shard-tglb:         NOTRUN -> [SKIP][62] ([fdo#111825]) +8 similar issues
   [62]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-tglb6/igt@kms_frontbuffer_tracking@fbc-2p-primscrn-shrfb-plflip-blt.html

  * igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-cur-indfb-draw-blt:
    - shard-kbl:          NOTRUN -> [SKIP][63] ([fdo#109271]) +30 similar issues
   [63]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-kbl4/igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-cur-indfb-draw-blt.html

  * igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-draw-mmap-gtt:
    - shard-skl:          NOTRUN -> [FAIL][64] ([i915#49])
   [64]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-skl7/igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-draw-mmap-gtt.html

  * igt@kms_frontbuffer_tracking@psr-2p-scndscrn-spr-indfb-draw-render:
    - shard-glk:          NOTRUN -> [SKIP][65] ([fdo#109271]) +20 similar issues
   [65]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-glk1/igt@kms_frontbuffer_tracking@psr-2p-scndscrn-spr-indfb-draw-render.html

  * igt@kms_hdr@bpc-switch-suspend:
    - shard-skl:          [PASS][66] -> [FAIL][67] ([i915#1188])
   [66]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-skl4/igt@kms_hdr@bpc-switch-suspend.html
   [67]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-skl6/igt@kms_hdr@bpc-switch-suspend.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
    - shard-apl:          NOTRUN -> [SKIP][68] ([fdo#109271] / [i915#533]) +4 similar issues
   [68]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-apl8/igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d.html

  * igt@kms_plane_alpha_blend@pipe-a-alpha-7efc:
    - shard-skl:          NOTRUN -> [FAIL][69] ([fdo#108145] / [i915#265]) +2 similar issues
   [69]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-skl7/igt@kms_plane_alpha_blend@pipe-a-alpha-7efc.html

  * igt@kms_plane_alpha_blend@pipe-a-coverage-7efc:
    - shard-skl:          [PASS][70] -> [FAIL][71] ([fdo#108145] / [i915#265])
   [70]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-skl9/igt@kms_plane_alpha_blend@pipe-a-coverage-7efc.html
   [71]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-skl1/igt@kms_plane_alpha_blend@pipe-a-coverage-7efc.html

  * igt@kms_plane_alpha_blend@pipe-b-constant-alpha-max:
    - shard-apl:          NOTRUN -> [FAIL][72] ([fdo#108145] / [i915#265])
   [72]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-apl8/igt@kms_plane_alpha_blend@pipe-b-constant-alpha-max.html

  * igt@kms_plane_alpha_blend@pipe-c-alpha-basic:
    - shard-kbl:          NOTRUN -> [FAIL][73] ([fdo#108145] / [i915#265])
   [73]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-kbl4/igt@kms_plane_alpha_blend@pipe-c-alpha-basic.html

  * igt@kms_plane_scaling@scaler-with-clipping-clamping@pipe-c-scaler-with-clipping-clamping:
    - shard-skl:          NOTRUN -> [SKIP][74] ([fdo#109271] / [i915#2733])
   [74]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-skl7/igt@kms_plane_scaling@scaler-with-clipping-clamping@pipe-c-scaler-with-clipping-clamping.html

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

  * igt@kms_psr2_sf@plane-move-sf-dmg-area-0:
    - shard-skl:          NOTRUN -> [SKIP][76] ([fdo#109271] / [i915#658]) +1 similar issue
   [76]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-skl8/igt@kms_psr2_sf@plane-move-sf-dmg-area-0.html

  * igt@kms_psr@psr2_sprite_mmap_gtt:
    - shard-iclb:         [PASS][77] -> [SKIP][78] ([fdo#109441]) +2 similar issues
   [77]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-iclb2/igt@kms_psr@psr2_sprite_mmap_gtt.html
   [78]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-iclb1/igt@kms_psr@psr2_sprite_mmap_gtt.html

  * igt@kms_writeback@writeback-fb-id:
    - shard-apl:          NOTRUN -> [SKIP][79] ([fdo#109271] / [i915#2437]) +1 similar issue
   [79]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-apl8/igt@kms_writeback@writeback-fb-id.html

  * igt@perf@per-context-mode-unprivileged:
    - shard-tglb:         NOTRUN -> [SKIP][80] ([fdo#109289])
   [80]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-tglb6/igt@perf@per-context-mode-unprivileged.html

  * igt@perf@polling-small-buf:
    - shard-skl:          [PASS][81] -> [FAIL][82] ([i915#1722])
   [81]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-skl6/igt@perf@polling-small-buf.html
   [82]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-skl4/igt@perf@polling-small-buf.html

  * igt@prime_nv_api@nv_i915_reimport_twice_check_flink_name:
    - shard-tglb:         NOTRUN -> [SKIP][83] ([fdo#109291])
   [83]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-tglb6/igt@prime_nv_api@nv_i915_reimport_twice_check_flink_name.html

  * igt@sysfs_clients@fair-1@vcs:
    - shard-kbl:          [PASS][84] -> [FAIL][85] ([i915#3033])
   [84]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-kbl3/igt@sysfs_clients@fair-1@vcs.html
   [85]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-kbl3/igt@sysfs_clients@fair-1@vcs.html

  * igt@sysfs_clients@recycle:
    - shard-glk:          [PASS][86] -> [FAIL][87] ([i915#3028])
   [86]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-glk3/igt@sysfs_clients@recycle.html
   [87]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-glk2/igt@sysfs_clients@recycle.html

  * igt@sysfs_clients@recycle-many:
    - shard-apl:          [PASS][88] -> [FAIL][89] ([i915#3028])
   [88]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-apl8/igt@sysfs_clients@recycle-many.html
   [89]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-apl6/igt@sysfs_clients@recycle-many.html
    - shard-iclb:         [PASS][90] -> [FAIL][91] ([i915#3028])
   [90]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-iclb8/igt@sysfs_clients@recycle-many.html
   [91]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-iclb3/igt@sysfs_clients@recycle-many.html
    - shard-kbl:          [PASS][92] -> [FAIL][93] ([i915#3028])
   [92]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-kbl1/igt@sysfs_clients@recycle-many.html
   [93]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-kbl6/igt@sysfs_clients@recycle-many.html

  * igt@sysfs_clients@sema-10@rcs0:
    - shard-glk:          NOTRUN -> [SKIP][94] ([fdo#109271] / [i915#3026]) +1 similar issue
   [94]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-glk1/igt@sysfs_clients@sema-10@rcs0.html

  * igt@sysfs_clients@split-25@rcs0:
    - shard-skl:          [PASS][95] -> [SKIP][96] ([fdo#109271])
   [95]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-skl7/igt@sysfs_clients@split-25@rcs0.html
   [96]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-skl10/igt@sysfs_clients@split-25@rcs0.html

  
#### Possible fixes ####

  * igt@gem_ctx_persistence@many-contexts:
    - shard-iclb:         [INCOMPLETE][97] ([i915#3057]) -> [PASS][98]
   [97]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-iclb6/igt@gem_ctx_persistence@many-contexts.html
   [98]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-iclb5/igt@gem_ctx_persistence@many-contexts.html

  * igt@gem_ctx_persistence@replace@vcs1:
    - shard-tglb:         [INCOMPLETE][99] -> [PASS][100]
   [99]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-tglb6/igt@gem_ctx_persistence@replace@vcs1.html
   [100]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-tglb6/igt@gem_ctx_persistence@replace@vcs1.html

  * igt@gem_exec_fair@basic-none-vip@rcs0:
    - shard-kbl:          [FAIL][101] ([i915#2842]) -> [PASS][102]
   [101]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-kbl6/igt@gem_exec_fair@basic-none-vip@rcs0.html
   [102]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-kbl2/igt@gem_exec_fair@basic-none-vip@rcs0.html

  * igt@gem_exec_fair@basic-pace@vecs0:
    - shard-kbl:          [SKIP][103] ([fdo#109271]) -> [PASS][104] +1 similar issue
   [103]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-kbl1/igt@gem_exec_fair@basic-pace@vecs0.html
   [104]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-kbl6/igt@gem_exec_fair@basic-pace@vecs0.html

  * igt@gem_exec_schedule@u-fairslice@vcs0:
    - shard-apl:          [DMESG-WARN][105] ([i915#1610]) -> [PASS][106]
   [105]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-apl3/igt@gem_exec_schedule@u-fairslice@vcs0.html
   [106]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-apl8/igt@gem_exec_schedule@u-fairslice@vcs0.html

  * igt@gem_huc_copy@huc-copy:
    - shard-tglb:         [SKIP][107] ([i915#2190]) -> [PASS][108]
   [107]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-tglb6/igt@gem_huc_copy@huc-copy.html
   [108]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-tglb8/igt@gem_huc_copy@huc-copy.html

  * igt@gem_mmap_gtt@big-copy:
    - shard-skl:          [FAIL][109] ([i915#307]) -> [PASS][110]
   [109]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-skl10/igt@gem_mmap_gtt@big-copy.html
   [110]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-skl2/igt@gem_mmap_gtt@big-copy.html

  * igt@gen9_exec_parse@allowed-single:
    - shard-skl:          [DMESG-WARN][111] ([i915#1436] / [i915#716]) -> [PASS][112]
   [111]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-skl1/igt@gen9_exec_parse@allowed-single.html
   [112]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-skl5/igt@gen9_exec_parse@allowed-single.html

  * igt@i915_selftest@live@client:
    - shard-glk:          [DMESG-FAIL][113] ([i915#3047]) -> [PASS][114]
   [113]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-glk9/igt@i915_selftest@live@client.html
   [114]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-glk9/igt@i915_selftest@live@client.html

  * igt@i915_suspend@forcewake:
    - shard-kbl:          [DMESG-WARN][115] ([i915#180]) -> [PASS][116] +1 similar issue
   [115]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-kbl7/igt@i915_suspend@forcewake.html
   [116]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-kbl4/igt@i915_suspend@forcewake.html

  * igt@i915_suspend@sysfs-reader:
    - shard-apl:          [DMESG-WARN][117] ([i915#180]) -> [PASS][118] +1 similar issue
   [117]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-apl8/igt@i915_suspend@sysfs-reader.html
   [118]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-apl2/igt@i915_suspend@sysfs-reader.html

  * igt@kms_big_fb@linear-64bpp-rotate-180:
    - shard-glk:          [FAIL][119] -> [PASS][120]
   [119]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-glk5/igt@kms_big_fb@linear-64bpp-rotate-180.html
   [120]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-glk8/igt@kms_big_fb@linear-64bpp-rotate-180.html

  * igt@kms_color@pipe-c-legacy-gamma:
    - shard-skl:          [FAIL][121] ([i915#71]) -> [PASS][122]
   [121]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-skl9/igt@kms_color@pipe-c-legacy-gamma.html
   [122]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-skl10/igt@kms_color@pipe-c-legacy-gamma.html

  * igt@kms_cursor_legacy@cursor-vs-flip-varying-size:
    - shard-skl:          [INCOMPLETE][123] ([fdo#109052]) -> [PASS][124]
   [123]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-skl3/igt@kms_cursor_legacy@cursor-vs-flip-varying-size.html
   [124]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-skl7/igt@kms_cursor_legacy@cursor-vs-flip-varying-size.html

  * igt@kms_fbcon_fbt@psr-suspend:
    - shard-skl:          [INCOMPLETE][125] ([i915#198]) -> [PASS][126]
   [125]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-skl5/igt@kms_fbcon_fbt@psr-suspend.html
   [126]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-skl8/igt@kms_fbcon_fbt@psr-suspend.html

  * igt@kms_flip@flip-vs-expired-vblank-interruptible@a-edp1:
    - shard-skl:          [FAIL][127] ([i915#2122]) -> [PASS][128]
   [127]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-skl4/igt@kms_flip@flip-vs-expired-vblank-interruptible@a-edp1.html
   [128]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-skl6/igt@kms_flip@flip-vs-expired-vblank-interruptible@a-edp1.html

  * igt@kms_flip@flip-vs-expired-vblank@a-edp1:
    - shard-tglb:         [FAIL][129] ([i915#2598]) -> [PASS][130]
   [129]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-tglb3/igt@kms_flip@flip-vs-expired-vblank@a-edp1.html
   [130]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-tglb7/igt@kms_flip@flip-vs-expired-vblank@a-edp1.html

  * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc:
    - shard-skl:          [FAIL][131] ([fdo#108145] / [i915#265]) -> [PASS][132] +1 similar issue
   [131]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-skl10/igt@kms_plane_alpha_blend@pipe-b-coverage-7efc.html
   [132]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-skl2/igt@kms_plane_alpha_blend@pipe-b-coverage-7efc.html

  * igt@kms_psr@psr2_primary_page_flip:
    - shard-iclb:         [SKIP][133] ([fdo#109441]) -> [PASS][134] +2 similar issues
   [133]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-iclb5/igt@kms_psr@psr2_primary_page_flip.html
   [134]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-iclb2/igt@kms_psr@psr2_primary_page_flip.html

  * igt@sysfs_clients@recycle:
    - shard-snb:          [FAIL][135] ([i915#3028]) -> [PASS][136]
   [135]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-snb7/igt@sysfs_clients@recycle.html
   [136]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-snb6/igt@sysfs_clients@recycle.html

  * igt@sysfs_clients@sema-10@vcs0:
    - shard-apl:          [SKIP][137] ([fdo#109271] / [i915#3026]) -> [PASS][138] +1 similar issue
   [137]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-apl6/igt@sysfs_clients@sema-10@vcs0.html
   [138]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-apl3/igt@sysfs_clients@sema-10@vcs0.html

  * igt@sysfs_clients@split-25@vecs0:
    - shard-skl:          [SKIP][139] ([fdo#109271]) -> [PASS][140]
   [139]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-skl7/igt@sysfs_clients@split-25@vecs0.html
   [140]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-skl10/igt@sysfs_clients@split-25@vecs0.html

  
#### Warnings ####

  * igt@gem_exec_fair@basic-pace@vcs0:
    - shard-kbl:          [FAIL][141] ([i915#2842]) -> [SKIP][142] ([fdo#109271])
   [141]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-kbl1/igt@gem_exec_fair@basic-pace@vcs0.html
   [142]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-kbl6/igt@gem_exec_fair@basic-pace@vcs0.html

  * igt@i915_pm_rc6_residency@rc6-idle:
    - shard-tglb:         [WARN][143] ([i915#2681] / [i915#2684]) -> [FAIL][144] ([i915#2681] / [i915#2692])
   [143]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-tglb3/igt@i915_pm_rc6_residency@rc6-idle.html
   [144]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-tglb3/igt@i915_pm_rc6_residency@rc6-idle.html
    - shard-iclb:         [WARN][145] ([i915#1804] / [i915#2684]) -> [WARN][146] ([i915#2681] / [i915#2684])
   [145]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/shard-iclb3/igt@i915_pm_rc6_residency@rc6-idle.html
   [146]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19837/shard-iclb1/igt@i9

== Logs ==

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

[-- Attachment #1.2: Type: text/html, Size: 33504 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