Hi all
This moves the pm_info file from debugfs to next to the other two power files.
Requested by several users at Phoronix.
PS: Please CC me. Also please be gentle, it's my first step in kernel-land ;)
Signed-off-by: Lauri Kasanen c...@gmx.com
---
drivers/gpu/drm/radeon/radeon_pm.c | 86
On Sun, 03 Jun 2012 12:54:30 +0200
Christian König deathsim...@vodafone.de wrote:
This moves the pm_info file from debugfs to next to the other two power
files.
Requested by several users at Phoronix.
PS: Please CC me. Also please be gentle, it's my first step in kernel-land
;)
On Mon, 04 Jun 2012 18:18:10 +0200
Christian König deathsim...@vodafone.de wrote:
My experience is that things that are true today for GPU, are not
tomorrow. Yes there will still be clock/voltage, but there could be
new complete different things, like shutting down block.
I am not even
On Mon, 4 Jun 2012 13:05:46 -0400
Jerome Glisse j.gli...@gmail.com wrote:
My dream here is to talk with the gnome folks to have them make some
kind GPU module we could write and that would show in control center.
I just need to corner some of my gnome coworker to work something out.
So if you
Hi list
The recently released libdrm 2.4.37 does not compile the Intel part:
test_decode.c: In function 'compare_batch':
test_decode.c:107: error: implicit declaration of function 'open_memstream'
PS: Please CC me.
Signed-off-by: Lauri Kasanen c...@gmx.com
---
intel/test_decode.c |2 ++
1
On Mon, 2 Jul 2012 14:54:58 -0700
Ben Widawsky b...@bwidawsk.net wrote:
+#define _GNU_SOURCE
+
#include string.h
#include stdlib.h
#include stdio.h
I can't reproduce this. Can anyone else confirm this is broken, and if
so that the above patch fixes it?
See the manpage, it
Hi
This info comes from r600_demo, and was confirmed correct on a RV710.
Signed-off-by: Lauri Kasanen c...@gmx.com
---
drivers/gpu/drm/radeon/r600d.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600d.h b/drivers/gpu/drm/radeon/r600d.h
index
The declarations were moved around because of a GCC warning,
ISO C90 forbids mixed declarations and code. (why so strict?)
Signed-off-by: Lauri Kasanen c...@gmx.com
---
drivers/gpu/drm/radeon/r600.c | 16
1 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers
Let's allow GCC to optimize better.
This exposed some five unused functions, but this patch doesn't remove them.
Signed-off-by: Lauri Kasanen c...@gmx.com
---
drivers/gpu/drm/radeon/atombios_encoders.c |4 +-
drivers/gpu/drm/radeon/evergreen.c | 12 +-
drivers/gpu/drm
On Tue, 31 Jul 2012 14:43:34 +1000
Dave Airlie airl...@gmail.com wrote:
On Tue, Jul 31, 2012 at 12:45 AM, Alex Deucher alexdeuc...@gmail.com wrote:
On Fri, Jul 27, 2012 at 5:34 PM, Lauri Kasanen c...@gmx.com wrote:
Let's allow GCC to optimize better.
This exposed some five unused
This applies on top of drm/radeon: Mark all possible functions / structs as
static.
Signed-off-by: Lauri Kasanen c...@gmx.com
---
drivers/gpu/drm/radeon/r100.c | 44 ---
drivers/gpu/drm/radeon/radeon_combios.c |9 -
drivers/gpu/drm/radeon
Hi list,
In June 2012 I started a discussion on moving the radeon PM info out
from debugfs, into a proper place available to all, be it proc, sysfs,
or some other way. For the rationale please see the archives:
http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg23401.html
Jerome's
Cheers,
This patchset is respun on top of today's drm-next. It has only been
compile-tested, since my test computer is currently on strike in
support of Ukraine.
It was a simple spin though, so Mr. Murphy will likely stay away. Only
Radeon behavior is affected, all other drivers have just
, they don't apply
Respin on top of drm-next
Signed-off-by: Lauri Kasanen
---
drivers/gpu/drm/drm_mm.c | 56 +++-
include/drm/drm_mm.h | 29 +
2 files changed, 66 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/drm_mm.c b
Allocating small bos from one end and large ones from the other helps
improve the quality of fragmentation.
This depends on "drm: Optionally create mm blocks from top-to-bottom" by
Chris Wilson.
Signed-off-by: Lauri Kasanen
---
drivers/gpu/drm/ttm/ttm_bo.c | 4 +++-
drive
This updates the other drivers to build, no-op behavior-wise.
Signed-off-by: Lauri Kasanen
---
drivers/gpu/drm/ast/ast_ttm.c | 3 ++-
drivers/gpu/drm/bochs/bochs_mm.c | 3 ++-
drivers/gpu/drm/cirrus/cirrus_ttm.c | 3 ++-
drivers/gpu/drm/i915/i915_gem.c | 3 ++-
drivers/gpu
common to
radeon.
Other drivers may need different thresholds according to their workloads.
Signed-off-by: Lauri Kasanen
---
drivers/gpu/drm/radeon/radeon_ttm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon
On Mon, 31 Mar 2014 14:41:05 +0200
Lucas Stach wrote:
> Am Montag, den 31.03.2014, 15:28 +0300 schrieb Lauri Kasanen:
> > Allocating small bos from one end and large ones from the other helps
> > improve the quality of fragmentation.
> >
> > This depends on "
.
Other drivers may need different thresholds according to their workloads.
Signed-off-by: Lauri Kasanen
---
drivers/gpu/drm/ast/ast_ttm.c | 3 +-
drivers/gpu/drm/bochs/bochs_mm.c | 3 +-
drivers/gpu/drm/cirrus/cirrus_ttm.c | 3 +-
drivers/gpu/drm/drm_mm.c | 56
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%.
> >
> >
On Sat, 1 Mar 2014 06:47:41 +1000
Dave Airlie wrote:
> On Sat, Mar 1, 2014 at 5:56 AM, Christian K?nig
> wrote:
> > Am 28.02.2014 19:50, schrieb Lauri Kasanen:
> >
> >> Without this, a bo may get created in the cpu-inaccessible vram.
> >> Before the CP en
, as the real VRAM size gets set as soon as the
CP engines get init.
This is a candidate for 3.14 fixes.
Signed-off-by: Lauri Kasanen
---
drivers/gpu/drm/radeon/radeon_ttm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
Allocating small bos from one end and large ones from the other helps
improve the quality of fragmentation.
I have measured a suitable threshold to reduce eviction by up to 20%,
and to cause no harm in normal cases that fit VRAM fully (PTS gaming suite).
In some cases, even the VRAM-fitting cases
On Fri, 28 Feb 2014 10:36:59 +0100
Christian K?nig wrote:
> Am 27.02.2014 22:38, schrieb Lauri Kasanen:
> > Without this, a bo may get created in the cpu-inaccessible vram.
> > Before the CP engines get setup, all copies are done via cpu memcpy.
> >
> > This means that
On Fri, 28 Feb 2014 17:30:39 +0200
Lauri Kasanen wrote:
> On Fri, 28 Feb 2014 10:36:59 +0100
> Christian K?nig wrote:
>
> > Am 27.02.2014 22:38, schrieb Lauri Kasanen:
> > > Without this, a bo may get created in the cpu-inaccessible vram.
> > > Before the
On Fri, 28 Feb 2014 16:43:54 +0100
Christian K?nig wrote:
> >>> Am 27.02.2014 22:38, schrieb Lauri Kasanen:
> >>>> Without this, a bo may get created in the cpu-inaccessible vram.
> >>>> Before the CP engines get setup, all copies are done via cpu mem
, as the real VRAM size gets set as soon as the
CP engines get init.
This is a candidate for 3.14 fixes.
v2: Add comment on why the function is used
Signed-off-by: Lauri Kasanen
---
drivers/gpu/drm/radeon/radeon_ttm.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/radeon
On Tue, 28 Oct 2014 18:35:02 +0900
Michel Dänzer wrote:
> From: Michel Dänzer
>
> I wasn't sure if TTM_PL_FLAG_TOPDOWN works correctly with non-0 lpfn, but
> AFAICT it does.
>
> Signed-off-by: Michel Dänzer
This series is
Reviewed-by: Lauri Kasanen
- Lauri
Hi list
The recently released libdrm 2.4.37 does not compile the Intel part:
test_decode.c: In function 'compare_batch':
test_decode.c:107: error: implicit declaration of function 'open_memstream'
PS: Please CC me.
Signed-off-by: Lauri Kasanen
---
intel/test_decode.c |2 ++
1 files
was measured as the most optimal threshold for 3d workloads common to
radeon.
Other drivers may need different thresholds according to their workloads.
v2: Updated kerneldoc in more places
Cc: Chris Wilson
Cc: Ben Widawsky
Signed-off-by: Lauri Kasanen
---
drivers/gpu/drm/ast/ast_ttm.c | 3
On Wed, 02 Apr 2014 13:00:00 +0200
Christian K?nig wrote:
> Nice idea, but I wouldn't put the decision where to place the buffer
> into TTM based on it's size.
>
> Instead please make that a proper TTM placement flag because for example
> for VM page tables we want them to be at the end of
kerneldoc
Cc: Chris Wilson
Cc: Ben Widawsky
Cc: Christian K?nig
Signed-off-by: Lauri Kasanen
---
drivers/gpu/drm/drm_mm.c | 66 ++--
drivers/gpu/drm/i915/i915_gem.c | 3 +-
drivers/gpu/drm/i915/i915_gem_gtt.c | 3 +-
drivers/gpu/drm/ttm
common to
radeon.
Other drivers may need different thresholds according to their workloads.
Signed-off-by: Lauri Kasanen
---
drivers/gpu/drm/radeon/radeon_object.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_object.c
b/drivers
common to
radeon.
Other drivers may need different thresholds according to their workloads.
v2: Nicer formatting
Signed-off-by: Lauri Kasanen
---
drivers/gpu/drm/radeon/radeon_object.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon
Hi list, Thomas,
I'd like to know if this is going in the right direction.
I've implemented a priority queue on top of the kernel rb tree and
linked list. It's been tested well in userspace.
I hardcoded radeon to input the buffer size as the score. Nothing blew
up, games ran fine, and even got
Signed-off-by: Lauri Kasanen
---
drivers/gpu/drm/ttm/Makefile | 2 +-
drivers/gpu/drm/ttm/ttm_priority.c | 152 +
include/drm/ttm/ttm_priority.h | 90 ++
3 files changed, 243 insertions(+), 1 deletion(-)
create mode 100644
Signed-off-by: Lauri Kasanen
---
drivers/gpu/drm/ast/ast_ttm.c | 1 +
drivers/gpu/drm/bochs/bochs_mm.c | 1 +
drivers/gpu/drm/cirrus/cirrus_ttm.c | 1 +
drivers/gpu/drm/mgag200/mgag200_ttm.c | 1 +
drivers/gpu/drm/nouveau/nouveau_ttm.c | 2 +-
drivers/gpu/drm/qxl/qxl_ttm.c
Signed-off-by: Lauri Kasanen
---
drivers/gpu/drm/ttm/ttm_bo.c | 68 +++-
1 file changed, 54 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 621151c..80e5856 100644
--- a/drivers/gpu/drm/ttm
Hi,
Obviously old userspace + new kernel combo needs to be supported. But
I'm not so sure about a mixed case, does old userspace + new userspace
need to be supported to run at the same time?
For example, a new 64-bit mesa+libdrm and a 32-bit old set, both
running apps at the same time.
Or is it
On Sun, 6 Apr 2014 10:53:58 -0400
Rob Clark wrote:
> On Sun, Apr 6, 2014 at 8:26 AM, Lauri Kasanen wrote:
> > Hi,
> >
> > Obviously old userspace + new kernel combo needs to be supported. But
> > I'm not so sure about a mixed case, does old userspace + new userspa
On Sun, 6 Apr 2014 19:58:48 +0200
Daniel Vetter wrote:
> On Sun, Apr 6, 2014 at 7:28 PM, Lauri Kasanen wrote:
> > This is related to my memory management work. As the VRAM queue is
> > global, it cannot be determined on a per-app basis. If at least one
> > client is
On Mon, 07 Apr 2014 14:25:28 +0200
Thomas Hellstrom wrote:
> Hi, Lauri.
>
> On 04/04/2014 03:52 PM, Lauri Kasanen wrote:
> > Hi list, Thomas,
> >
> > I'd like to know if this is going in the right direction.
>
> This looks fine with me.
>
> However, if
Signed-off-by: Lauri Kasanen
---
drivers/gpu/drm/radeon/radeon_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
b/drivers/gpu/drm/radeon/radeon_drv.c
index d0eba48..cf2721a 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b
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, 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)
> > +
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
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
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
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
> &
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.
Signed-off-by: Lauri Kasanen
---
drivers/gpu/drm/radeon/r100.c | 18
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
compared to v2, so now radeon.ko
is only 1% smaller.
Signed-off-by: Lauri Kasanen
---
drivers/gpu/drm/radeon/r100.c | 33 -
drivers/gpu/drm/radeon/radeon.h | 40
2 files changed, 36 insertions(+), 37 deletions(-)
diff
Hi list, Thomas,
I will be investigating the use of a hotness score for each bo, to
replace the ping-pong causing LRU eviction in radeon*.
The goal is to put all bos that fit in VRAM there, in order of hotness;
a new bo should only be placed there if its hotness score is greater
than the lowest
On Mon, 9 Dec 2013 20:28:21 +0100
Marek Ol??k wrote:
Hi,
> FYI, since the userspace driver sends end-of-frame markers to the
> kernel, the radeon kernel driver knows the current frame number and it
> can also save the frame number of the last use of each buffer. We
> should definitely use that
On Mon, 9 Dec 2013 23:45:12 +0100
Marek Ol??k wrote:
> > Note that the hotness calculation will be in userspace, as only there
> > are the necessary counters available. So the finished hotness score
> > will be passed to the kernel, instead of sending all the necessary data
> > there. Ought to
On Wed, 11 Dec 2013 12:04:05 +0900
Michel D?nzer wrote:
> > Of all the worries that exist, this is a non-issue. Userspace can
> > simply queue a lot of draw calls that take 1 second each through the
> > normal command submission methods, why would it need to tweak some
> > obscure number to
On Wed, 11 Dec 2013 15:46:53 +0100
Thomas Hellstrom wrote:
> > I think the kernel just has to trust userspace on this. I can't think
> > of any way of not involving userspace, so if somebody really wants to
> > hack mesa to gain some fps advantage on a multiseat system, let them ;)
> >
> >
Hi list,
In June 2012 I started a discussion on moving the radeon PM info out
from debugfs, into a proper place available to all, be it proc, sysfs,
or some other way. For the rationale please see the archives:
http://www.mail-archive.com/dri-devel at lists.freedesktop.org/msg23401.html
Jerome's
On Thu, 12 Mar 2015 18:02:56 +0900
Michel Dänzer wrote:
> struct ttm_place::lpfn is honoured even with TTM_PL_FLAG_TOPDOWN, so
> latter should work with RADEON_GEM_CPU_ACCESS. It sounds like the
> problem is really that some BOs are expected to be within a certain
> range from the beginning of
On Mon, 2 Jul 2012 14:54:58 -0700
Ben Widawsky wrote:
> > +#define _GNU_SOURCE
> > +
> > #include
> > #include
> > #include
>
> I can't reproduce this. Can anyone else confirm this is broken, and if
> so that the above patch fixes it?
See the manpage, it depends on the glibc version.
Hi
This info comes from r600_demo, and was confirmed correct on a RV710.
Signed-off-by: Lauri Kasanen
---
drivers/gpu/drm/radeon/r600d.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600d.h b/drivers/gpu/drm/radeon/r600d.h
index 025fd5b
The declarations were moved around because of a GCC warning,
"ISO C90 forbids mixed declarations and code". (why so strict?)
Signed-off-by: Lauri Kasanen
---
drivers/gpu/drm/radeon/r600.c | 16
1 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/drive
Let's allow GCC to optimize better.
This exposed some five unused functions, but this patch doesn't remove them.
Signed-off-by: Lauri Kasanen
---
drivers/gpu/drm/radeon/atombios_encoders.c |4 +-
drivers/gpu/drm/radeon/evergreen.c | 12 +-
drivers/gpu/drm/radeon
On Tue, 31 Jul 2012 14:43:34 +1000
Dave Airlie wrote:
> On Tue, Jul 31, 2012 at 12:45 AM, Alex Deucher
> wrote:
> > On Fri, Jul 27, 2012 at 5:34 PM, Lauri Kasanen wrote:
> >> Let's allow GCC to optimize better.
> >>
> >> This exposed some five unused f
This applies on top of drm/radeon: Mark all possible functions / structs as
static.
Signed-off-by: Lauri Kasanen
---
drivers/gpu/drm/radeon/r100.c | 44 ---
drivers/gpu/drm/radeon/radeon_combios.c |9 -
drivers/gpu/drm/radeon/radeon_fb.c
Hi all
This moves the pm_info file from debugfs to next to the other two power files.
Requested by several users at Phoronix.
PS: Please CC me. Also please be gentle, it's my first step in kernel-land ;)
Signed-off-by: Lauri Kasanen
---
drivers/gpu/drm/radeon/radeon_pm.c | 86
On Sun, 03 Jun 2012 12:54:30 +0200
Christian K?nig wrote:
> > This moves the pm_info file from debugfs to next to the other two power
> > files.
> >
> > Requested by several users at Phoronix.
> >
> > PS: Please CC me. Also please be gentle, it's my first step in kernel-land
> > ;)
> Hui?
On Mon, 04 Jun 2012 18:18:10 +0200
Christian K?nig wrote:
> > My experience is that things that are true today for GPU, are not
> > tomorrow. Yes there will still be clock/voltage, but there could be
> > new complete different things, like shutting down block.
> >
> > I am not even mentioning
On Mon, 4 Jun 2012 13:05:46 -0400
Jerome Glisse wrote:
> My dream here is to talk with the gnome folks to have them make some
> kind GPU module we could write and that would show in control center.
> I just need to corner some of my gnome coworker to work something out.
> So if you were using
69 matches
Mail list logo
