On Thu, Jul 10, 2014 at 4:55 AM, Christian K?nig
wrote:
> Am 10.07.2014 10:48, schrieb Lauri Kasanen:
>
>> On Sun, 20 Apr 2014 19:41:11 +0200
>> Christian K?nig wrote:
>>
>>> Am 20.04.2014 19:29, schrieb Lauri Kasanen:
This was originally un-inlined by Andi Kleen in 2011 citing size
>>>
On Sun, 20 Apr 2014 19:41:11 +0200
Christian K?nig wrote:
> Am 20.04.2014 19:29, schrieb Lauri Kasanen:
> > 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 funct
Am 10.07.2014 10:48, schrieb Lauri Kasanen:
> On Sun, 20 Apr 2014 19:41:11 +0200
> Christian K?nig wrote:
>
>> Am 20.04.2014 19:29, schrieb Lauri Kasanen:
>>> 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%.
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
Am 20.04.2014 19:29, schrieb Lauri Kasanen:
> 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:
Am 19.04.2014 19:33, schrieb Lauri Kasanen:
> On Sat, 19 Apr 2014 11:15:53 -0400
> Alex Deucher 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
On Sat, 19 Apr 2014 11:15:53 -0400
Alex Deucher 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
Am 18.04.2014 23:11, schrieb Lauri Kasanen:
> 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:
On Sat, Apr 19, 2014 at 6:06 AM, Christian K?nig
wrote:
> Am 18.04.2014 23:11, schrieb Lauri Kasanen:
>
>> 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.
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
On Fri, 11 Apr 2014 14:32:20 +0200
Christian K?nig wrote:
> Am 11.04.2014 11:54, schrieb Lauri Kasanen:
> > On Fri, 11 Apr 2014 10:33:08 +0200
> > Christian K?nig wrote:
> >
> Actually direct register access shouldn't be necessary so often. Apart
> from page flips, write/read pointer u
On Fri, 11 Apr 2014 14:32:20 +0200
Christian K?nig wrote:
> Anyway, I would do like Ilia suggested and only put the else branch into
> a separate, not inlined function.
>
> BTW: It's probably a good idea to do the same for the write function as
> well.
I tested it. The majority of the size in
Am 11.04.2014 11:54, schrieb Lauri Kasanen:
> On Fri, 11 Apr 2014 10:33:08 +0200
> Christian K?nig wrote:
>
Actually direct register access shouldn't be necessary so often. Apart
from page flips, write/read pointer updates and irq processing there
shouldn't be so many of them. Could
On Fri, 11 Apr 2014 10:33:08 +0200
Christian K?nig wrote:
> >> Actually direct register access shouldn't be necessary so often. Apart
> >> from page flips, write/read pointer updates and irq processing there
> >> shouldn't be so many of them. Could you clarify a bit more what issue
> >> you are s
On Thu, 10 Apr 2014 21:30:03 +0200
Christian K?nig wrote:
> >>> Quick thought from someone entirely unfamiliar with the hardware:
> >>> perhaps you can get the performance benefit without the size increase
> >>> by moving the else portion into a non-inline function? I'm guessing
> >>> that most a
Am 11.04.2014 09:52, schrieb Lauri Kasanen:
> On Thu, 10 Apr 2014 21:30:03 +0200
> Christian K?nig wrote:
>
> Quick thought from someone entirely unfamiliar with the hardware:
> perhaps you can get the performance benefit without the size increase
> by moving the else portion into a no
On Thu, 10 Apr 2014 12:19:10 -0400
Ilia Mirkin wrote:
> > +static inline uint32_t r100_mm_rreg(struct radeon_device *rdev, uint32_t
> > reg,
> > + bool always_indirect)
> > +{
> > + if (reg < rdev->rmmio_size && !always_indirect)
> > + return
Am 10.04.2014 20:52, schrieb Ilia Mirkin:
> On Thu, Apr 10, 2014 at 2:46 PM, Lauri Kasanen wrote:
>> On Thu, 10 Apr 2014 12:19:10 -0400
>> Ilia Mirkin wrote:
>>
+static inline uint32_t r100_mm_rreg(struct radeon_device *rdev, uint32_t
reg,
+ bool
This was originally un-inlined by Andi Kleen in 2011 citing size concerns.
Indeed, inlining it grows radeon.ko by 7%.
However, 2% of cpu is spent in this function. Inlining it gives 1% more fps
in Urban Terror.
Signed-off-by: Lauri Kasanen
---
drivers/gpu/drm/radeon/r100.c | 18 --
On Thu, Apr 10, 2014 at 2:46 PM, Lauri Kasanen wrote:
> On Thu, 10 Apr 2014 12:19:10 -0400
> Ilia Mirkin wrote:
>
>> > +static inline uint32_t r100_mm_rreg(struct radeon_device *rdev, uint32_t
>> > reg,
>> > + bool always_indirect)
>> > +{
>> > + if (reg <
On Thu, Apr 10, 2014 at 9:08 AM, Lauri Kasanen wrote:
> This was originally un-inlined by Andi Kleen in 2011 citing size concerns.
> Indeed, inlining it grows radeon.ko by 7%.
>
> However, 2% of cpu is spent in this function. Inlining it gives 1% more fps
> in Urban Terror.
>
> Signed-off-by: Laur
21 matches
Mail list logo
