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 <alexdeucher at gmail.com> wrote: > On Mon, Mar 19, 2018 at 4:29 PM, Li, Samuel <Samuel.Li at 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20180319/5e25ebb6/attachment-0001.html>
