dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: "Michel Dänzer" <michel@daenzer.net>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm/mm: Fix search for smallest hole satisfying constraints
Date: Wed, 19 Mar 2014 11:38:18 +0100	[thread overview]
Message-ID: <20140319103818.GP30571@phenom.ffwll.local> (raw)
In-Reply-To: <1395218547.16819.5.camel@thor.local>

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.

> > While at it ... could you perhaps smash a bit of kerneldoc on top of
> > enum drm_mm_search_flags, I seem to have missed it. With that this is
> > 
> > Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> 
> Thanks, but I'm afraid I'll have to pass on that. I'm just submitting a
> fix for a problem Frank stumbled upon. I don't have the time right now,
> nor the particular inclination to clean up the surrounding code.

I've made a note to add the missing kerneldoc, still some patches left
over.

> Meanwhile, I've submitted a less invasive v2 fix.

Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> on that one.

> 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 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.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

  reply	other threads:[~2014-03-19 10:38 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-18  0:58 [PATCH] drm/mm: Fix search for smallest hole satisfying constraints Michel Dänzer
2014-03-18 10:01 ` Daniel Vetter
2014-03-19  8:42   ` Michel Dänzer
2014-03-19 10:38     ` Daniel Vetter [this message]
2014-03-20  9:45       ` Michel Dänzer
2014-03-19  8:37 ` [PATCH v2] " Michel Dänzer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140319103818.GP30571@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=michel@daenzer.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox