dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Christian König" <deathsimple@vodafone.de>
To: Lauri Kasanen <cand@gmx.com>, Alex Deucher <alexdeucher@gmail.com>
Cc: Maling list - DRI developers <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH] drm/radeon: Inline r100_mm_rreg, v2
Date: Sun, 20 Apr 2014 15:44:32 +0200	[thread overview]
Message-ID: <5353CF40.4080504@vodafone.de> (raw)
In-Reply-To: <20140419203305.ae6edc0e.cand@gmx.com>

Am 19.04.2014 19:33, schrieb Lauri Kasanen:
> On Sat, 19 Apr 2014 11:15:53 -0400
> Alex Deucher <alexdeucher@gmail.com> wrote:
>
>> On Sat, Apr 19, 2014 at 6:06 AM, Christian König
>>>> This was originally un-inlined by Andi Kleen in 2011 citing size concerns.
>>>> Indeed, a first attempt at inlining it grew radeon.ko by 7%.
>>>>
>>>> However, 2% of cpu is spent in this function. Simply inlining it gave 1%
>>>> more fps
>>>> in Urban Terror.
>>>>
>>>> v2: We know the minimum MMIO size. Adding it to the if allows the compiler
>>>> to
>>>> optimize the branch out, improving both performance and size.
>>>>
>>>> The v2 patch decreases radeon.ko size by 2%. I didn't re-benchmark, but
>>>> common sense
>>>> says perf is now more than 1% better.
>>> Nice!
>>>
>>> But are you sure that the register PCI bar is always at least 64K in size?
>>> Keep in mind that this code is used over all generations since R100.
>>> Additional to that we probably should have a define for that and also apply
>>> the optimizations to r100_mm_wreg as well.
> Yes, I checked the earlier code. It had 64kb hard-coded, and when it
> was changed in 2010 to use the dynamic value, the commit said later
> asics are larger. (07bec2df01)
>
> A quick google also didn't find any dmesg with smaller values, R100
> cards had 64kb.

Thanks for digging that up, this indeed sounds valid and like a very 
nice optimization.

Just as suggested before add a define for this in radeon.h, something 
like RADEON_MIN_PCI_BAR_SIZE and do the same for r100_mm_wreg as well.

>> If most of the register accesses are for the interrupt setup, I wonder
>> if it would be better to just clean up the irq_set functions to reduce
>> the register accesses.  E.g., only touch the registers for the
>> specific irq masks have changed.
> Yes, that should also be done. But as this function is used elsewhere
> as well, having it fast (not to mention the size decrease) would be
> good.
>
> I think this patch is safe enough for 3.15, but perhaps it's too late
> now.

Yeah, probably. But 3.16 should work as well.

Christian.

> - Lauri

      reply	other threads:[~2014-04-20 13:44 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-18 21:11 [PATCH] drm/radeon: Inline r100_mm_rreg, v2 Lauri Kasanen
2014-04-19 10:06 ` Christian König
2014-04-19 15:15   ` Alex Deucher
2014-04-19 17:33     ` Lauri Kasanen
2014-04-20 13:44       ` Christian König [this message]

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=5353CF40.4080504@vodafone.de \
    --to=deathsimple@vodafone.de \
    --cc=alexdeucher@gmail.com \
    --cc=cand@gmx.com \
    --cc=dri-devel@lists.freedesktop.org \
    /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