[Intel-gfx] dg1 flag for userspace to allocate contig resources

[Intel-gfx] dg1 flag for userspace to allocate contig resources

[Dave Airlie]

I've just been looking at the current DG1 uapi, and I can't see any
flag to allow userspace to upfront say it was a contiguous vram BO.

I think you'd really want this for scanout, since otherwise you'll
have to migrate any non-contig to contig when it transitions to
scanout, and cause an extra set of copies.

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

Re: [Intel-gfx] dg1 flag for userspace to allocate contig resources

[Matthew Auld]

On 11/09/2020 06:42, Dave Airlie wrote:
> I've just been looking at the current DG1 uapi, and I can't see any
> flag to allow userspace to upfront say it was a contiguous vram BO.
> 
> I think you'd really want this for scanout, since otherwise you'll
> have to migrate any non-contig to contig when it transitions to
> scanout, and cause an extra set of copies.

Hmm, why do we need physically contiguous memory for scanout? From hw 
pov it's seen through the GTT.

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

Re: [Intel-gfx] dg1 flag for userspace to allocate contig resources

[Joonas Lahtinen]

+ Jani and Ville

Quoting Matthew Auld (2020-09-11 11:56:56)
> On 11/09/2020 06:42, Dave Airlie wrote:
> > I've just been looking at the current DG1 uapi, and I can't see any
> > flag to allow userspace to upfront say it was a contiguous vram BO.
> > 
> > I think you'd really want this for scanout, since otherwise you'll
> > have to migrate any non-contig to contig when it transitions to
> > scanout, and cause an extra set of copies.
> 
> Hmm, why do we need physically contiguous memory for scanout? From hw 
> pov it's seen through the GTT.

That's correct. On both discrete (and integrated) platforms the scan-out
addresses on Intel GPUs are programmed to targer Global GTT managed by
kernel. So no need to have the backing storage contiguous.

Only extra action required for a scan-out BO is to bind it to the GGTT in
addition to the ppGTT that renders to it. 

GGTT is relatively expensive to write to these days and limited in size,
but that can't really be helped with an upfront flag.

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

Re: [Intel-gfx] dg1 flag for userspace to allocate contig resources

[Ville Syrjälä]

On Fri, Sep 11, 2020 at 03:27:07PM +0300, Joonas Lahtinen wrote:
> + Jani and Ville
> 
> Quoting Matthew Auld (2020-09-11 11:56:56)
> > On 11/09/2020 06:42, Dave Airlie wrote:
> > > I've just been looking at the current DG1 uapi, and I can't see any
> > > flag to allow userspace to upfront say it was a contiguous vram BO.
> > > 
> > > I think you'd really want this for scanout, since otherwise you'll
> > > have to migrate any non-contig to contig when it transitions to
> > > scanout, and cause an extra set of copies.
> > 
> > Hmm, why do we need physically contiguous memory for scanout? From hw 
> > pov it's seen through the GTT.
> 
> That's correct. On both discrete (and integrated) platforms the scan-out
> addresses on Intel GPUs are programmed to targer Global GTT managed by
> kernel. So no need to have the backing storage contiguous.

The only exception being the ye olde gen2/3 physical cursor stuff :)

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

Re: [Intel-gfx] dg1 flag for userspace to allocate contig resources

[Dave Airlie]

On Fri, 11 Sep 2020 at 22:27, Joonas Lahtinen
<joonas.lahtinen@linux.intel.com> wrote:
>
> + Jani and Ville
>
> Quoting Matthew Auld (2020-09-11 11:56:56)
> > On 11/09/2020 06:42, Dave Airlie wrote:
> > > I've just been looking at the current DG1 uapi, and I can't see any
> > > flag to allow userspace to upfront say it was a contiguous vram BO.
> > >
> > > I think you'd really want this for scanout, since otherwise you'll
> > > have to migrate any non-contig to contig when it transitions to
> > > scanout, and cause an extra set of copies.
> >
> > Hmm, why do we need physically contiguous memory for scanout? From hw
> > pov it's seen through the GTT.
>
> That's correct. On both discrete (and integrated) platforms the scan-out
> addresses on Intel GPUs are programmed to targer Global GTT managed by
> kernel. So no need to have the backing storage contiguous.
>
> Only extra action required for a scan-out BO is to bind it to the GGTT in
> addition to the ppGTT that renders to it.
>
> GGTT is relatively expensive to write to these days and limited in size,
> but that can't really be helped with an upfront flag.
>

Oops thanks for enlightenment! Indeed binding things to the GTT
properly helps, sg iterator I had produced wrong pte entries, now I
can at least see an X stipple.

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