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
<[email protected]
<mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>> wrote:
On Mon, Mar 19, 2018 at 4:29 PM, Li, Samuel
<[email protected] <mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
<https://lists.freedesktop.org/mailman/listinfo/amd-gfx>
_______________________________________________
amd-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
amd-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
