On 2018-03-06 07:23 PM, Christian König wrote: > Am 06.03.2018 um 19:15 schrieb Michel Dänzer: >> On 2018-03-06 07:02 PM, Christian König wrote: >>> Am 06.03.2018 um 18:51 schrieb Michel Dänzer: >>>> On 2018-03-06 06:44 PM, Christian König wrote: >>>>> Am 06.03.2018 um 18:22 schrieb Li, Samuel: >>>>>>> addition to that I agree with Michel that the module parameter is >>>>>>> overkill. >>>>>> That I already explained. Currently SG display feature needs to >>>>>> provide options for all kinds of use cases. All amd drivers so far >>>>>> provides options, and the default configuration is actually to >>>>>> allocate everything from GTT when possible. >>>>> That isn't job of the kernel to have this parameter. Saying that we >>>>> should probably add a DDX and/or environment option to control that. >>>> Why would we need that? It's the kernel driver's job to handle this as >>>> needed. >>> Buffer placement is specified by the DDX/Mesa, when we override that in >>> the kernel we just force unnecessary buffer moves. >> Userspace just needs a way to know which domains can/should be used for >> scanout buffers, e.g. via an info ioctl. > > Yeah, but why shouldn't they then make the decision where to place it as > well? > > See when we enforce a certain placement in the kernel we will just get > an unnecessary buffer move with old user space components. > > In other words the kernel just needs to advertise that the hw/sw > combination allows scanout from GTT as well and then an updated > userspace can actually make use of that placement or decide to not use > it in certain situations. I think we'll need to always pin BOs to GTT for scanout in some cases, because some hardware has issues when transitioning between scanout from VRAM and GTT. How about: Userspace can query from the kernel which domain(s) can be used for scanout: only VRAM / VRAM or GTT / only GTT. Userspace sets the allowed domains correspondingly for scanout BOs. If you can think of a scenario where this won't work, please specifically describe it and how you propose addressing it. > E.g. the last time I tested it placing things into GTT still resulted > in quite a performance penalty for rendering. FWIW, I think the penalty is most likely IOMMU related. Last time I tested, I couldn't measure a big difference with IOMMU disabled. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
