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