But for CZ/ST, due to hardware limitation as discussed before, we
either use VRAM or GTT, not both.
That is actually not correct, as far as I read up on that the issue for
switching between VRAM and GTT placement is minimal.
We should just make sure that we don't do this on every page flip, e.g.
have double or triple buffering where one BO is in GTT and one in VRAM.
Regards,
Christian.
Am 20.03.2018 um 21:38 schrieb Li, Samuel:
ØI think we can also have the case of systems with similar amounts of
carve out and system ram. E.g., on a system with 4 GB of system
memory with 1 GB carved out for vram. It would be a big waste not to
use VRAM. We'll probably need a heuristic at some point.
Agreed. But for CZ/ST, due to hardware limitation as discussed before,
we either use VRAM or GTT, not both. That might be changed for later
ASICs, but it is beyond the scope of this patch.
Regards,
Samuel Li
*From:*Koenig, Christian
*Sent:* Tuesday, March 20, 2018 4:17 PM
*To:* Deucher, Alexander <alexander.deuc...@amd.com>; Marek Olšák
<mar...@gmail.com>
*Cc:* Alex Deucher <alexdeuc...@gmail.com>; Michel Dänzer
<mic...@daenzer.net>; Li, Samuel <samuel...@amd.com>; amd-gfx list
<amd-gfx@lists.freedesktop.org>
*Subject:* Re: [PATCH 1/2] drm/amdgpu: Enable scatter gather display
support
That's what I meant with use up the otherwise unused VRAM. I don't see
any disadvantage of always setting GTT as second domain on APUs.
My assumption was that we dropped this in userspace for displayable
surfaces, but Marek proved that wrong.
So what we should do is actually to add GTT as fallback to all BOs on
APUs in Mesa and only make sure that the kernel is capable of handling
GTT with optimal performance (e.g. have user huge pages etc..).
Christian.
Am 20.03.2018 um 21:04 schrieb Deucher, Alexander:
I think we can also have the case of systems with similar amounts
of carve out and system ram. E.g., on a system with 4 GB of
system memory with 1 GB carved out for vram. It would be a big
waste not to use VRAM. We'll probably need a heuristic at some point.
Alex
------------------------------------------------------------------------
*From:*Christian König <ckoenig.leichtzumer...@gmail.com>
<mailto:ckoenig.leichtzumer...@gmail.com>
*Sent:* Tuesday, March 20, 2018 2:32:49 PM
*To:* Marek Olšák; Koenig, Christian
*Cc:* Alex Deucher; Deucher, Alexander; Michel Dänzer; Li, Samuel;
amd-gfx list
*Subject:* Re: [PATCH 1/2] drm/amdgpu: Enable scatter gather
display support
I don't think that is a good idea.
Ideally GTT should now have the same performance as VRAM on APUs
and we should use VRAM only for things where we absolutely have to
and to actually use up the otherwise unused VRAM.
Can you run some tests with all BOs forced to GTT and see if there
is any performance regression?
Christian.
Am 20.03.2018 um 15:51 schrieb Marek Olšák:
On Tue, Mar 20, 2018 at 9:55 AM, Christian König
<ckoenig.leichtzumer...@gmail.com
<mailto:ckoenig.leichtzumer...@gmail.com>> wrote:
Yes, exactly. And if I remember correctly Mesa used to
always set GTT as fallback on APUs, correct?
"used to" is the key part. Mesa doesn't force GTT on APUs
anymore. It expects that the combination of BO priorities and
BO move throttling will result in optimal BO placements over time.
Marek
The problem seems to be that this fallback isn't set for
displayable BOs.
So what needs to be done is to just enable this fallback
for displayable BOs as well if the kernel can handle it.
Christian.
Am 20.03.2018 um 00:01 schrieb Marek Olšák:
In theory, Mesa doesn't have to do anything. It can
continue setting VRAM and if the kernel has to put a
display buffer into GTT, it doesn't matter (for Mesa).
Whether the VRAM placement is really used is largely
determined by BO priorities.
The way I understand scather/gather is that it only
allows the GTT placement. It doesn't force the GTT
placement. Mesa also doesn't force the GTT placement.
Marek
On Mon, Mar 19, 2018 at 5:12 PM, Alex Deucher
<alexdeuc...@gmail.com <mailto:alexdeuc...@gmail.com>>
wrote:
On Mon, Mar 19, 2018 at 4:29 PM, Li, Samuel
<samuel...@amd.com <mailto:samuel...@amd.com>> wrote:
>>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
>
> Agreed. That is also why the patch has the
options to let user select where
> to put display buffers.
>
> As whether to put the option in Mesa or kernel,
it seems the difference is
> not much. Also, since amdgpufb can request even
without mesa, kernel might
> be a better choice. In addition, putting in the
kernel can save client’s
> duplicate work(mesa, ogl, vulkan, 2d, kernel…)
Why do we even expose different memory pools to
the UMDs in the first
place ;) Each pool has performance
characteristics that may be
relevant for a particular work load. Only the
UMDs really know the
finer points of those workloads. In general, you
don't want the kernel
dictating policy if you can avoid it. The kernel
exposes
functionality and userspace sets the policy. With
the location set in
userspace, each app/user can have whatever policy
makes sense for
their use case all at the same time without
needing to tweak their
kernel for every use case.
Alex
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
<mailto:amd-gfx@lists.freedesktop.org>
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
<mailto:amd-gfx@lists.freedesktop.org>
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
