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@xxxxxxx> > > > > > > > > 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@xxxxxxx> > > > > Signed-off-by: Michel Dänzer <michel.daenzer@xxxxxxx> > > > > > > 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@xxxxxxxx> 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. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
