Hi Am 24.04.20 um 08:56 schrieb Christian König: > Am 24.04.20 um 08:27 schrieb Thomas Zimmermann: >> Hi Christian >> >> Am 23.04.20 um 17:04 schrieb Christian König: >>> Hi guys, >>> >>> one thing you don't seem to have considered yet is that not setting the >>> top-down flag also won't get you the bottom-up approach, but rather the >>> best fit. >> Kind of unrelated: Would it pick the smallest free area that can hold a >> BO? IOW, would a small cursor BO fill up a small free area even if >> there's a much larger free area somewhere? > > Yes, exactly that. I see. > > The bottom-up method searches for the lowest hole which can fit the > requirements. But there's no way to explictely select bottom-up? What is TTM_PL_FLAG_CONTIGUOUS doing? Best regards Thomas > > The top-down method searches for the highest hole which can fit the > requirements. > > Both of those walk the holes by the address index tree, but there is > also the best method which looks at the holes by their size and tries to > find the best fit. > > The best method usually only needs a single tree walk instead of a > linear search. > >>> Am 23.04.20 um 15:57 schrieb Gerd Hoffmann: >>>>> But cursor BOs are small, so they don't make much of a difference. >>>>> What >>>>> is needed is space for 2 primary framebuffers during pageflips, >>>>> with one >>>>> of them pinned. The other framebuffer can be located anywhere. >>>> The problem isn't the size. The problem is dynamically allocated >>>> cursor >>>> BOs can also fragment vram, especially if top-bottom allocation is also >>>> used for large framebuffers so cursor BOs can end up somewhere in the >>>> middle of vram. >>> Well maybe instead of a ping/pong approach between top and bottom use a >>> size based approach to place small BOs at the top and only the larger >>> ones at the bottom (or the other way around). >> That's what the current code does and it results in the OOM. Basically, >> there's a large BO in the middle of vram and the pageflip's destination >> BO does not fit before or after the large one. > > Tough problem. No idea how to otherwise fix this without making the > large BO moveable somehow. > > Christian. > >> >> Best regards >> Thomas >> >>> Cheers, >>> Christian. >>> _______________________________________________ >>> dri-devel mailing list >>> dri-devel@xxxxxxxxxxxxxxxxxxxxx >>> https://lists.freedesktop.org/mailman/listinfo/dri-devel > > _______________________________________________ > dri-devel mailing list > dri-devel@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
