On Wed, Mar 7, 2018 at 1:18 PM, Samuel Li <samuel.li at amd.com> wrote: > I think it's not useful though. Think about that, SG display feature is intended to use as less VRAM as possible. Will someone want a display buffer sometimes VRAM, sometimes GTT? > Hardly a case to me, and I think it's a waste of effort. That also might explain no driver does that now. You might want different strategies depending on how much VRAM you have. If you have a bunch and it performs better, prefer it. If you have limited VRAM, you might want to prefer GTT. You might also want to prefer VRAM, but also allow buffers to fall back to GTT if necessary. This would make the logic dynamic and all in one place. The kernel can advertise what asics support scanout from system ram and then UMDs can just query that to choose placements rather than adding hardcoded logic for specific asics. Alex > > Sam > > > > On 2018-03-07 12:50 PM, Michel Dänzer wrote: >> On 2018-03-07 06:38 PM, Alex Deucher wrote: >>> On Wed, Mar 7, 2018 at 12:29 PM, Samuel Li <samuel.li at amd.com> wrote: >>>> >>>> Why so complicated? If old user space compatibility is required, just use sg_display=0. >>> >>> It will always just work in that case and we can adjust for the >>> optimal scenario by default in all cases without requiring the user to >>> set misc parameters to tune their setup that may break in the future >>> or hide bugs because a user sets it and forgets it. >> >> Right. I don't agree it's all that complicated anyway, we do this sort >> of thing all the time, it also makes our lives easier down the road. >> >>
