On Mit, 2014-03-19 at 11:38 +0100, Daniel Vetter wrote:
On Wed, Mar 19, 2014 at 05:42:27PM +0900, Michel Dänzer wrote:
On Die, 2014-03-18 at 11:01 +0100, Daniel Vetter wrote:
On Tue, Mar 18, 2014 at 09:58:14AM +0900, Michel Dänzer wrote:
From: Michel Dänzer michel.daenzer@amd.com
entry->size is the size of the node, not the size of the hole after it. So the code would actually find the hole which can satisfy the constraints and which is preceded by the smallest node, not the smallest hole satisfying the constraints.
Reported-by: "Huang, FrankR" FrankR.Huang@amd.com Signed-off-by: Michel Dänzer michel.daenzer@amd.com
But drm-next just gained my kerneldoc patch for drm_mm, so can you please respin your patch and update the docs too?
What kind of update are you thinking of?
you've changed the function parameters, which breaks the kerneldoc. v2 is ok in that regard.
Ah, I see.
Meanwhile, I've submitted a less invasive v2 fix.
Reviewed-by: Daniel Vetter daniel.vetter@ffwll.ch on that one.
Merci! :)
BTW, do you think the fix would interact properly with coloring?
Coloring only adjusts start/end so won't affect the size of the hole. If you really see benefits from best_match
I've been wondering about the potential effects of this fix... I hope it won't cause regressions.
then I guess you could look into pessimising holes which need to be split, presuming radeon has a pile of alignment or otherwise constrained buffers.
E.g. textures with 2D tiling can require pretty large alignment, so that might indeed be interesting.