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 V
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
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,
a bit 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(-)
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
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
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
&
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
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
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
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
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
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
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 runni
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 users
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
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
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/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
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 ~
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
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
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
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 VRA
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
.
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 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 "
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
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
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
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_m
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 compili
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
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 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
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 CP
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
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
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
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 ;)
> >
> > Basica
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 cause
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 be
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 t
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 V
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
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 rep
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
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 unu
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
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
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/
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/
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
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
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
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. Libd
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. Libd
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.
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.
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 nou
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 nou
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 thin
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? What
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 thin
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? What
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 |
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 |
69 matches
Mail list logo
