[PATCH 1/2] drm/amdgpu: Enable scatter gather display support

maraeo@xxxxxxxxx (Marek Olšák) · Mon, 19 Mar 2018 16:26:59 -0400

When Mesa wants a buffer in VRAM, it always sets VRAM. It relies on BO move
throttling to prevent unnecessary BO moves.

My questions are:
- what should Mesa do differently for tiny VRAM?
- what is a tiny VRAM?
- if VRAM is tiny, which allocations should we put there?

Marek

On Mon, Mar 19, 2018 at 4:15 PM, Deucher, Alexander <
Alexander.Deucher at amd.com> wrote:

> s/not/now/.  I meant to say, â??we have NOW excluded the possibility of
> ever setting displays anywhere else without a kernel updateâ??.
>
>
>
> Alex
>
>
>
> *From:* amd-gfx [mailto:amd-gfx-bounces at lists.freedesktop.org] *On Behalf
> Of *Deucher, Alexander
> *Sent:* Monday, March 19, 2018 4:13 PM
>
> *To:* Li, Samuel <Samuel.Li at amd.com>; Koenig, Christian <
> Christian.Koenig at amd.com>; Marek OlÅ¡Ã¡k <maraeo at gmail.com>
> *Cc:* Alex Deucher <alexdeucher at gmail.com>; Michel DÃ¤nzer <
> michel at daenzer.net>; amd-gfx list <amd-gfx at lists.freedesktop.org>
> *Subject:* Re: [PATCH 1/2] drm/amdgpu: Enable scatter gather display
> support
>
>
>
> I'm not sure what you mean by the 3 scenarios.  Generally userspace
> selects what domains it wants a buffer to be in, vram, gtt, or both (don't
> care).  I'd rather not have the kernel second guess the UMDs if we can help
> it.  I'd rather leave the kernel for cases where we have to force things
> due to hw bugs, or hw restrictions, etc.  If we force all display buffers
> to be in gtt in the kernel, we have not excluded the possibility of ever
> setting displays anywhere else without a kernel update.  E.g., to my
> earlier point, there may be cases where it is advantageous to put display
> buffers in vram even if s/g display is supported.  That was the point I was
> trying to make about user mode selecting the domain (vram of gtt or
> vram|gtt).  Say you have a board with 2 GB of ram and 1 GB is carved out
> for "vram".  In that case, it would make sense to put the buffer in vram
> because otherwise you are wasting a comparatively scarce resource.
>
>
>
> Alex
> ------------------------------
>
> *From:* Li, Samuel
> *Sent:* Monday, March 19, 2018 3:58:52 PM
> *To:* Deucher, Alexander; Koenig, Christian; Marek OlÅ¡Ã¡k
> *Cc:* Alex Deucher; Michel DÃ¤nzer; amd-gfx list
> *Subject:* RE: [PATCH 1/2] drm/amdgpu: Enable scatter gather display
> support
>
>
>
> Alex,
>
>
>
> I assume you are talking the three scenarios here, 1)VRAM, 2)GTT,
> 3)VRAM/GTT.
>
> But kernel will need the decision too(amdgpufb). I think it shall be
> better to do it in kernel, instead of different clients(mesa, ddx, kernel â?¦)
>
>
>
> Regards,
>
> Samuel Li
>
>
>
> *From:* Deucher, Alexander
> *Sent:* Monday, March 19, 2018 3:54 PM
> *To:* Li, Samuel <Samuel.Li at amd.com>; Koenig, Christian <
> Christian.Koenig at amd.com>; Marek OlÅ¡Ã¡k <maraeo at gmail.com>
> *Cc:* Alex Deucher <alexdeucher at gmail.com>; Michel DÃ¤nzer <
> michel at daenzer.net>; amd-gfx list <amd-gfx at lists.freedesktop.org>
> *Subject:* Re: [PATCH 1/2] drm/amdgpu: Enable scatter gather display
> support
>
>
>
> My personal preference is still to plumb this through to mesa rather than
> forcing it in the kernel.
>
>
>
> Alex
> ------------------------------
>
> *From:* amd-gfx <amd-gfx-bounces at lists.freedesktop.org> on behalf of Li,
> Samuel <Samuel.Li at amd.com>
> *Sent:* Monday, March 19, 2018 3:50:34 PM
> *To:* Koenig, Christian; Marek OlÅ¡Ã¡k
> *Cc:* Alex Deucher; Michel DÃ¤nzer; amd-gfx list
> *Subject:* RE: [PATCH 1/2] drm/amdgpu: Enable scatter gather display
> support
>
>
>
> Christian,
>
>
>
> You misunderstood Alexâ??s comments,
>
>
>
> >Regardless of which scenarios we need to support, I think we also need
>
> >to really plumb this through to mesa however since user space is who
>
> >ultimately requests the location.  Overriding it in the kernel gets
>
> >tricky and can lead to ping-ponging as others have noted.  Better to
>
>
>
> Here Alex mentioned the scenarios is 1)VRAM, 2)GTT, 3)VRAM/GTT.
>
> His concern is this might cause ping-pong, not about preferred domain.
> Since preferred domain can solve the ping-pong issue, it shall address his
> concern here.
>
>
>
> Regards,
>
> Samuel Li
>
>
>
> *From:* Christian KÃ¶nig [mailto:ckoenig.leichtzumerken at gmail.com
> <ckoenig.leichtzumerken at gmail.com>]
> *Sent:* Monday, March 19, 2018 3:45 PM
> *To:* Li, Samuel <Samuel.Li at amd.com>; Marek OlÅ¡Ã¡k <maraeo at gmail.com>;
> Koenig, Christian <Christian.Koenig at amd.com>
> *Cc:* Alex Deucher <alexdeucher at gmail.com>; Michel DÃ¤nzer <
> michel at daenzer.net>; amd-gfx list <amd-gfx at lists.freedesktop.org>
> *Subject:* Re: [PATCH 1/2] drm/amdgpu: Enable scatter gather display
> support
>
>
>
> Quoting Alex:
>
> Regardless of which scenarios we need to support, I think we also need
>
> to really plumb this through to mesa however since user space is who
>
> ultimately requests the location.  Overriding it in the kernel gets
>
> tricky and can lead to ping-ponging as others have noted.  Better to
>
> have user space know what chips support it or not and request display
>
> buffers in GTT or VRAM from the start.
>
> And I completely agree with Alex here. So overriding the domain in the
> kernel is a serious NAK from my side as well.
>
> Please implement the necessary bits in Mesa, shouldn't be more than a few
> lines of code anyway.
>
> Regards,
> Christian.
>
> Am 19.03.2018 um 20:42 schrieb Li, Samuel:
>
> Agreed.
>
>
>
> >I think that the consensus with Alex and me is that we should avoid
> exactly that.
> Christian, Alexâ??s concern is about ping-pong, not about the preferred
> domain.
>
> Regards,
>
> Samuel Li
>
>
>
> *From:* Marek OlÅ¡Ã¡k [mailto:maraeo at gmail.com <maraeo at gmail.com>]
> *Sent:* Monday, March 19, 2018 3:39 PM
> *To:* Koenig, Christian <Christian.Koenig at amd.com>
> <Christian.Koenig at amd.com>
> *Cc:* Li, Samuel <Samuel.Li at amd.com> <Samuel.Li at amd.com>; Michel DÃ¤nzer
> <michel at daenzer.net> <michel at daenzer.net>; Alex Deucher
> <alexdeucher at gmail.com> <alexdeucher at gmail.com>; amd-gfx list
> <amd-gfx at lists.freedesktop.org> <amd-gfx at lists.freedesktop.org>
> *Subject:* Re: [PATCH 1/2] drm/amdgpu: Enable scatter gather display
> support
>
>
>
> On Mon, Mar 19, 2018 at 3:27 PM, Christian KÃ¶nig <christian.koenig at amd.com>
> wrote:
>
> I think that the consensus with Alex and me is that we should avoid
> exactly that.
>
> Overriding the preferred domain in the kernel is a no-go for that patch
> set, so please implement the discussed changes in Mesa.
>
>
>
> I don't see how Mesa can make a smarter decision than the kernel. If you
> overwrite the preferred domain of the buffer in the kernel, there will be
> no ping-ponging between domains. Mesa never changes the initial preferred
> domain.
>
>
>
> Marek
>
>
>
>
>
>
> Regards,
> Christian.
>
>
>
> Am 19.03.2018 um 20:22 schrieb Li, Samuel:
>
> I agree with Marek/Michel: since kernel sets the domain before scanning
> out, it shall update the preferred domain here too.
>
> Regards,
> Samuel Li
>
> -----Original Message-----
> From: Koenig, Christian
> Sent: Thursday, March 08, 2018 4:07 AM
> To: Michel DÃ¤nzer <michel at daenzer.net>; Li, Samuel
> <Samuel.Li at amd.com>; Alex Deucher <alexdeucher at gmail.com>
> Cc: amd-gfx list <amd-gfx at lists.freedesktop.org>
> Subject: Re: [PATCH 1/2] drm/amdgpu: Enable scatter gather display support
>
> Am 08.03.2018 um 09:35 schrieb Michel DÃ¤nzer:
>
> On 2018-03-07 10:47 AM, Christian KÃ¶nig wrote:
>
> Am 07.03.2018 um 09:42 schrieb Michel DÃ¤nzer:
>
> On 2018-03-06 07:23 PM, Christian KÃ¶nig wrote:
>
> E.g. the last time I tested it placing things into GTT still
> resulted in quite a performance penalty for rendering.
>
> FWIW, I think the penalty is most likely IOMMU related. Last time I
> tested, I couldn't measure a big difference with IOMMU disabled.
>
> No, the penalty I'm talking about came from the ping/pong we did with
> the scanout buffers.
>
> See when I tested this the DDX and Mesa where unmodified, so both
> still assumed VRAM as placement for scanout BOs, but the kernel
> forced scanout BOs into GTT for testing.
>
> So what happened was that on scanout we moved the VRAM BO to GTT
>
> and
>
> after unpinning it on the first command submission which used the BO
> we moved it back to VRAM again.
>
> In the meantime, I've had the same idea as Marek: Can't the kernel
> driver simply change the BO's preferred domain to GTT when scanning
> out from it? Then it won't move back to VRAM.
>
> Yes, I've considered this as well.
>
> But I think making the decision in Mesa is the cleaner approach.
>
> E.g. so far we only override the placement decision of userspace for two
> reasons:
> 1. We where running out of memory in VRAM.
> 2. We have a hardware restriction which makes VRAM usage mandatory.
>
> And even then we never adjust the placement permanently, we just
> temporary moved the buffer where it was needed and moved it back after
> the operation completed.
>
> Additional to that Mesa might want to set even more flags and/or changes
> it's behavior. E.g. use a tilling mode which both importer and export in an
> A+A laptop understands etc...
>
> Regards,
> Christian.
>
>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>
>
>
>
>
> _______________________________________________
>
> amd-gfx mailing list
>
> amd-gfx at lists.freedesktop.org
>
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20180319/8fb35328/attachment-0001.html>