Re: [Nouveau] low memory

2010-02-20 Thread Xavier Chantry 
On Tue, Feb 9, 2010 at 8:49 PM, Xavier Chantry  wrote:
> 12:08 < curro_> shining: hmm, it seems, darktama didn't quite finish
> the additional reloc checking he started to code
> 12:11 < curro_> shining: that would have solved your problem, poke him
> when he's back from vacations :)
> 12:16 < shining> curro_: hmm I really dont get it, it looks like
> domain can have both set, and flags can also have both set
> 12:16 < shining> I want to look at the reloc checking, what made you
> say he didnt finish ?
> 12:23 < curro_> shining: when you pin a BO, it can't end up in several
> locations at the same time :P
> 12:23 < curro_> he implemented the necessary stuff to track available
> aperture space from userspace
> 12:23 < curro_> but he didn't make the reloc functions check if the
> buffers would actually fit
>
> /me pokes darktama :)
>
> Let me remind you my wonderful test case : loading a 3500x2500 pixmap
> in firefox with 64mb vram.
>
> After talking a bit more with curro, I started to write a patch. I
> don't know how bad and wrong it is, there are still so many things I
> don't understand.
> It seems it works somehow, meaning OUT_RELOC -> emit_reloc will fail
> before FIRE_RING -> pushbuf_flush.
> But enomem failures during pushbuf_flush still happen. And worse, what
> happens after an OUT_RELOC failure is awful :
> 1) on nv25, the system freezes for 5 seconds, and after the lower part
> (a rectangle) of the picture seems to have a wrong offset or
> something.
> 2) on nv84 (hacked to force 64mb vram) : X crash because of a bug in
> nouveau_wfb.c . After fixing that, the pixmap is correctly displayed
> *after* the system freezes between 1min30 and 2min
>
> (There are several options for fixing the imprecision bug of fast
> divide in nouveau_wfb.c but I would like to be able to run this code
> in a normal situation, without crazy system freezing and extreme
> slowness, so that I can hopefully do proper benchmarking between the
> different options :) )
>
> I ran oprofile on nv25 in these two configurations :
> 1) previous workaround of making nouveau_exa_create_pixmap always fail
> : performance still acceptable (early fallback)
> 2) runtime OUT_RELOC failure and fallback : turtle speed (late fallback)
>
> The commit that implemented workaround 1 for 32mb vram says :
>    exa: force the use of sysmem pixmaps on low-mem cards
>    Very similar effect to forcing MigrationHeuristic "greedy" on classic
>    EXA.  Far better than the migration ping-pong that'd occur otherwise
>
> I suppose that arch/x86/mm/pageattr.c showing up in the profile, and
> pixman_blt_mmx taking ages are consequences of that migration
> ping-pong ?
> But I still don't understand what is going on, what migrations are
> made and how to limit them.
>

Just to clarify : the problems on nv84 (slowness and nouveau_wfb
crashing X) only happen after limiting vram to 64mb. It was just a
sidetest to see if I could reproduce the nv25 situation. There are
probably not real problems.

My goal is just to get nv25 render pixmaps properly at acceptable
speed instead of freezing 5 seconds to display a black box.
64mb seems to be the worst amount one can have. Below that, we don't
even try and disable accel. And with more memory, it might be less
usual to run out of it.

To sum up the discussion with curro and stillunknown, the different
alternatives seem to be :
1) Fallback on reloc failures, to avoid pushbuf / ttm validation
failure, as my libdrm patch attempted.
But this seems to cause extreme slowness, which could be explained by
the system reading the pixmap in vram.
2) Earlier fallback in nouveau_exa_create_pixmap
2.1) just bump limit from 32 to 64. This causes everything to be done
in software but is actually the only way I found which is never
extremely slow.
2.2) only fallback for pixmaps which are big compared to the amount of
vram. This solution fixed the pixmap rendering, but for example
dragging a window on top of the pixmap would kill the system. However
I could workaround this using xcompmgr.

I am tempted to just go with 2.1 and stop bothering everyone with
this. It's the most trivial fix and will cause less surprises to
whoever use that machine :)
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] low memory

2010-02-09 Thread Xavier Chantry 
12:08 < curro_> shining: hmm, it seems, darktama didn't quite finish
the additional reloc checking he started to code
12:11 < curro_> shining: that would have solved your problem, poke him
when he's back from vacations :)
12:16 < shining> curro_: hmm I really dont get it, it looks like
domain can have both set, and flags can also have both set
12:16 < shining> I want to look at the reloc checking, what made you
say he didnt finish ?
12:23 < curro_> shining: when you pin a BO, it can't end up in several
locations at the same time :P
12:23 < curro_> he implemented the necessary stuff to track available
aperture space from userspace
12:23 < curro_> but he didn't make the reloc functions check if the
buffers would actually fit

/me pokes darktama :)

Let me remind you my wonderful test case : loading a 3500x2500 pixmap
in firefox with 64mb vram.

After talking a bit more with curro, I started to write a patch. I
don't know how bad and wrong it is, there are still so many things I
don't understand.
It seems it works somehow, meaning OUT_RELOC -> emit_reloc will fail
before FIRE_RING -> pushbuf_flush.
But enomem failures during pushbuf_flush still happen. And worse, what
happens after an OUT_RELOC failure is awful :
1) on nv25, the system freezes for 5 seconds, and after the lower part
(a rectangle) of the picture seems to have a wrong offset or
something.
2) on nv84 (hacked to force 64mb vram) : X crash because of a bug in
nouveau_wfb.c . After fixing that, the pixmap is correctly displayed
*after* the system freezes between 1min30 and 2min

(There are several options for fixing the imprecision bug of fast
divide in nouveau_wfb.c but I would like to be able to run this code
in a normal situation, without crazy system freezing and extreme
slowness, so that I can hopefully do proper benchmarking between the
different options :) )

I ran oprofile on nv25 in these two configurations :
1) previous workaround of making nouveau_exa_create_pixmap always fail
: performance still acceptable (early fallback)
2) runtime OUT_RELOC failure and fallback : turtle speed (late fallback)

The commit that implemented workaround 1 for 32mb vram says :
   exa: force the use of sysmem pixmaps on low-mem cards
   Very similar effect to forcing MigrationHeuristic "greedy" on classic
   EXA.  Far better than the migration ping-pong that'd occur otherwise

I suppose that arch/x86/mm/pageattr.c showing up in the profile, and
pixman_blt_mmx taking ages are consequences of that migration
ping-pong ?
But I still don't understand what is going on, what migrations are
made and how to limit them.
From 778258e823b4a55d2a4cbfff16230f91d8de3b89 Mon Sep 17 00:00:00 2001
From: Xavier Chantry 
Date: Mon, 1 Feb 2010 17:42:37 +0100
Subject: [PATCH] check memory for relocs

---
 nouveau/nouveau_private.h |3 +++
 nouveau/nouveau_pushbuf.c |   35 +++
 2 files changed, 38 insertions(+), 0 deletions(-)

diff --git a/nouveau/nouveau_private.h b/nouveau/nouveau_private.h
index 39758d1..c04a603 100644
--- a/nouveau/nouveau_private.h
+++ b/nouveau/nouveau_private.h
@@ -59,6 +59,9 @@ struct nouveau_pushbuf_priv {
 	unsigned nr_buffers;
 	struct drm_nouveau_gem_pushbuf_reloc *relocs;
 	unsigned nr_relocs;
+
+	uint64_t relocs_vram_size;
+	uint64_t relocs_gart_size;
 };
 #define nouveau_pushbuf(n) ((struct nouveau_pushbuf_priv *)(n))
 
diff --git a/nouveau/nouveau_pushbuf.c b/nouveau/nouveau_pushbuf.c
index 7da3a47..3e7c3b7 100644
--- a/nouveau/nouveau_pushbuf.c
+++ b/nouveau/nouveau_pushbuf.c
@@ -241,6 +241,9 @@ restart_push:
 			goto restart_push;
 	}
 
+	if (ret)
+		fprintf(stderr, "validate failed : %d!!\n", ret);
+
 
 	/* Update presumed offset/domain for any buffers that moved.
 	 * Dereference all buffers on validate list
@@ -267,6 +270,9 @@ restart_push:
 	nvpb->nr_buffers = 0;
 	nvpb->nr_relocs = 0;
 
+	nvpb->relocs_vram_size = 0;
+	nvpb->relocs_gart_size = 0;
+
 	/* Allocate space for next push buffer */
 	assert(!nouveau_pushbuf_space(chan, min));
 
@@ -314,6 +320,13 @@ nouveau_pushbuf_marker_undo(struct nouveau_channel *chan)
 		if (--nvbo->pending_refcnt)
 			continue;
 
+
+		if (pbbo->presumed_domain & NOUVEAU_GEM_DOMAIN_VRAM) {
+			nvpb->relocs_vram_size -= nvbo->size;
+		} else {
+			nvpb->relocs_gart_size -= nvbo->size;
+		}
+
 		nvbo->pending = NULL;
 		nouveau_bo_ref(NULL, &bo);
 		nvpb->nr_buffers--;
@@ -355,11 +368,13 @@ nouveau_pushbuf_emit_reloc(struct nouveau_channel *chan, void *ptr,
 			   struct nouveau_bo *bo, uint32_t data, uint32_t data2,
 			   uint32_t flags, uint32_t vor, uint32_t tor)
 {
+	struct nouveau_device_priv *nvdev = nouveau_device(chan->device);
 	struct nouveau_pushbuf_priv *nvpb = nouveau_pushbuf(chan->pushbuf);
 	struct nouveau_bo_priv *nvbo = nouveau_bo(bo);
 	struct drm_nouveau_gem_pushbuf_reloc *r;
 	struct drm_nouveau_gem_pushbuf_bo *pbbo;
 	uint32_t domains = 0;
+	uint64_t *current_size, max_size;
 
 	if (nvpb->nr_relocs >= NOUVEAU_GEM_MAX_RELOCS) {
 		fprintf(stderr, "too many r

Re: [Nouveau] low memory

2010-01-29 Thread Xavier Chantry 
On Fri, Jan 8, 2010 at 1:50 AM, Xavier  wrote:
>
> Strange, I am 99% sure I did update libdrm , and before updating ddx.
> I will double-check tomorrow.
>
> And I indeed found this commit :
> http://cgit.freedesktop.org/nouveau/xf86-video-nouveau/commit/?id=bb1947831d9a4e080b8d1e9dba086af6527ef479
> So I assume the libdrm one is this one on the same day :
> http://cgit.freedesktop.org/mesa/drm/commit/?id=f1660c249198b5cc14ebbb75107da7bcb6972033
>
> So by playing with these two commits, I should also be able to provide
> more information. Thanks !
>

I don't know why, but this code no longer works with recent ttm (January).

It seems it's always able to pin/alloc or map, even when there is not
enough space. I checked the return values inside create_pixmap.
But ttm will fail later trying to validate a too big pixmap. See
attached output, the vanilla error is just "validate: -12" but I added
two debug statements to get more info.
Any ideas why the pin/alloc/map always go through ? But
nouveau_gem_pushbuf_validate later fails ?

Another problem is that when nouveau_gem_pushbuf_validate, not only
the picture is not displayed, but the system always becomes very
sluggish for a few seconds. And I sometimes get very weird memory
errors. Also attached.
(BUG kmalloc-512: Poison overwritten . Allocated in nouveau_bo_new .
Freed in nouveau_bo_del_ttm)


Anyway I just found out this commit :
http://cgit.freedesktop.org/nouveau/xf86-video-nouveau/commit/?id=5587f40c1b8af7d178f9a68d0f1fecdfc0ca9749

This is the workaround I have been looking for during one month ! :) I
just had to bump 32M -> 64M.
I don't understand why I cannot see/feel any performance drop.
What could I use as benchmark to compare the perf ?


nouveau_gem_pushbuf_validate
Description: Binary data


nouveau_bo
Description: Binary data
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] low memory

2010-01-08 Thread Xavier 
On Fri, Jan 8, 2010 at 3:55 PM, Xavier  wrote:
> On Fri, Jan 8, 2010 at 1:50 AM, Xavier  wrote:
>>
>> Strange, I am 99% sure I did update libdrm , and before updating ddx.
>> I will double-check tomorrow.
>>
>> And I indeed found this commit :
>> http://cgit.freedesktop.org/nouveau/xf86-video-nouveau/commit/?id=bb1947831d9a4e080b8d1e9dba086af6527ef479
>> So I assume the libdrm one is this one on the same day :
>> http://cgit.freedesktop.org/mesa/drm/commit/?id=f1660c249198b5cc14ebbb75107da7bcb6972033
>>
>> So by playing with these two commits, I should also be able to provide
>> more information. Thanks !
>>
>
> So it more looks like a drm/ttm problem.
> With a recent drm/ttm (after 98ba9c1322), firefox just displays a
> black box instead of the picture, the system lags a bit, and I get the
> following in dmesg :
> [   75.800986] [drm] nouveau :03:00.0: validate: -12
> [   75.801365] [drm] nouveau :03:00.0: validate: -12
> [   80.772360] reserve_ram_pages_type failed 0xc403000-0xc404000,
> track 0x8, req 0x10
>
> If I go before the drm/ttm merge, it still works fine. commit b5d1f52b
> or earlier.
>
> If I try to go somewhere between b5d1f52b and 98ba9c1322, I get the
> attached bug. But that might be because some important bugfix has been
> made at the end of that range, like "drm/nouveau: Fix "general
> protection fault" in the flipd/flips eviction path."
>
> Here is the commit range I mentioned :
>

I restricted the commit range to 2 relevant commits.
b5d1f52b works.
1e6cb7f causes the NULL pointer dereference in ttm_bo_mem_space+0x1e5/0x37b
162c700 fixes the NULL pointer dereference but I get the "validate: -12" error.

I am afraid this does not shed any light on the matter, and that the
real problem came earlier (probably in the huge ttm rework) but that
it was not apparent before these two ttm/nouveau fixes.

commit 162c70052890d24e7508a3c41212a8f87f17f39f
Author: Francisco Jerez 
Date:   Wed Dec 16 19:05:00 2009 +0100

drm/nouveau: Fix "general protection fault" in the flipd/flips
eviction path.

Signed-off-by: Francisco Jerez 

commit 1e6cb7f7e94360d06481a2980cf00a8a968e
Author: Dave Airlie 
Date:   Mon Dec 14 14:51:35 2009 +1000

drm/ttm: fix two bugs in new placement routines.

a) the loops were going to <= not <, leading to illegal memory access
b) the busy placement checks were using the placement arrays not the
   busy placement ones.

Acked-by: Jerome Glisse 
Signed-off-by: Dave Airlie 

commit b5d1f52b73059bd34355e35654abc91015e03bb5
Author: Ben Skeggs 
Date:   Wed Dec 16 16:22:42 2009 +1000

drm/nouveau: fix bug causing pinned buffers to lose their NO_EVICT flag

Signed-off-by: Ben Skeggs 
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] low memory

2010-01-08 Thread Xavier 
On Fri, Jan 8, 2010 at 1:50 AM, Xavier  wrote:
>
> Strange, I am 99% sure I did update libdrm , and before updating ddx.
> I will double-check tomorrow.
>
> And I indeed found this commit :
> http://cgit.freedesktop.org/nouveau/xf86-video-nouveau/commit/?id=bb1947831d9a4e080b8d1e9dba086af6527ef479
> So I assume the libdrm one is this one on the same day :
> http://cgit.freedesktop.org/mesa/drm/commit/?id=f1660c249198b5cc14ebbb75107da7bcb6972033
>
> So by playing with these two commits, I should also be able to provide
> more information. Thanks !
>

So it more looks like a drm/ttm problem.
With a recent drm/ttm (after 98ba9c1322), firefox just displays a
black box instead of the picture, the system lags a bit, and I get the
following in dmesg :
[   75.800986] [drm] nouveau :03:00.0: validate: -12
[   75.801365] [drm] nouveau :03:00.0: validate: -12
[   80.772360] reserve_ram_pages_type failed 0xc403000-0xc404000,
track 0x8, req 0x10

If I go before the drm/ttm merge, it still works fine. commit b5d1f52b
or earlier.

If I try to go somewhere between b5d1f52b and 98ba9c1322, I get the
attached bug. But that might be because some important bugfix has been
made at the end of that range, like "drm/nouveau: Fix "general
protection fault" in the flipd/flips eviction path."

Here is the commit range I mentioned :

* commit 98ba9c1322ed334b223117654cb671ea320919d5
| Author: Francisco Jerez 
| Date:   Wed Dec 16 19:03:28 2009 +0100
|
| drm/nouveau: Drop redundant placement initialization.
|
| Signed-off-by: Francisco Jerez 
|
* commit 4ee7ee3f1e824561a779c068773ed21bd7df5413
| Author: Francisco Jerez 
| Date:   Wed Dec 16 19:05:38 2009 +0100
|
| drm/nouveau: No need to force evict=true when swapping evicted
BOs back in.
|
| Signed-off-by: Francisco Jerez 
|
* commit 81c1019857b70efbba831f4a02b377066b836cbc
| Author: Francisco Jerez 
| Date:   Wed Dec 16 19:05:00 2009 +0100
|
| drm/nouveau: Fix "general protection fault" in the flipd/flips
eviction path.
|
| Signed-off-by: Francisco Jerez 
|
* commit f4e1a1bd530b6e4d2bfd1fbd7daddd5020359f15
| Author: Maarten Maathuis 
| Date:   Wed Dec 16 18:42:35 2009 +0100
|
| Revert "drm/nouveau: unpin cursor and lut bo when suspending"
|
| This reverts commit a330aea77289d8d4465ea0d072fb868f9c782577.
|
| - For some odd reason the cursor gets stuck with the last image,
don't see why.
| - The clut is already regenerated after resume it seems.
|
| Signed-off-by: Maarten Maathuis 
|
* commit dd6e87021a45c56acddbf229221543239f12a924
| Author: Francisco Jerez 
| Date:   Wed Dec 16 12:27:11 2009 +0100
|
| drm/i2c/ch7006: Drop build time dependency to nouveau.
|
| This partially reverts e4b41066, as this driver is intended to be
| useful with any KMS driver for suitable hardware. The missing build
| dependency that commit workarounded was DRM_KMS_HELPER.
|
| Signed-off-by: Francisco Jerez 
|
* commit 64aec72df1fa782ec3b060ccbdfa3fc9594f6119
| Author: Francisco Jerez 
| Date:   Fri Dec 11 16:51:09 2009 +0100
|
| drm/nouveau: Make the MM aware of pre-G80 tiling.
|
| Signed-off-by: Francisco Jerez 
|
* commit a49b387671a26e875d07befdc1d65087c557f5a8
| Author: Francisco Jerez 
| Date:   Wed Dec 16 12:12:27 2009 +0100
|
| drm/nouveau: Pre-G80 tiling support.
|
| Signed-off-by: Francisco Jerez 
|
* commit 2e625429cfd3c692928bbba3b74aa2d528b2
| Author: Francisco Jerez 
| Date:   Sun Dec 13 20:07:42 2009 +0100
|
| drm/nouveau: Add cache_flush/pull fifo engine functions.
|
| Signed-off-by: Francisco Jerez 
|
*   commit 69c27c09270b6898a06948d61b4b310e80990798
|\  Merge: b5d1f52 5012f50
| | Author: Ben Skeggs 
| | Date:   Wed Dec 16 16:46:17 2009 +1000
| |
| | Merge branch 'drm-core-next' of
git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6 into
nouveau
| |
| * commit 5012f5063f41ca01240e5983c3b2cceb9aafc7a4
| | Author: Jerome Glisse 
| | Date:   Thu Dec 10 18:07:26 2009 +0100
| |
| | drm/ttm: Fix memory type manager debug information printing
| |
| | System memory type doesn't have a drm_mm manager associated to
| | it. This patch avoid trying to call drm_mm_debug on unitialized
| | drm_mm when printing debug info on the system memory manager.
| |
| | Signed-off-by: Jerome Glisse 
| | Signed-off-by: Dave Airlie 
| |
| * commit eb6d2c39dbe46ea1c4f3da4eac5728c73f109ea1
| | Author: Jerome Glisse 
| | Date:   Thu Dec 10 16:15:52 2009 +0100
| |
| | drm/ttm: Fix printk format & compute bo->mem.size at bo initialization
| |
| | Signed-off-by: Jerome Glisse 
| | Signed-off-by: Dave Airlie 
| |
| * commit 9c51ba1db37cab780f38b2210913959f22d7b830
| | Author: Thomas Hellstrom 
| | Date:   Wed Dec 2 18:33:46 2009 +0100
| |
| | drm/ttm: Fix potential ttm_mem_evict_first races.
| |
| | 1) The function was previously called with a potentially empty
| | LRU list which would have lead to an OOPS or servere corruption.
| | 2) In rare cases, after re

Re: [Nouveau] low memory

2010-01-07 Thread Xavier 
On Fri, Jan 8, 2010 at 1:14 AM, Ben Skeggs  wrote:
> On Fri, 2010-01-08 at 00:51 +0100, Xavier wrote:
>> On Sun, Dec 13, 2009 at 9:35 PM, Xavier  wrote:
>> > On Sat, Dec 12, 2009 at 10:50 PM, Maarten Maathuis  
>> > wrote:
>> >>
>> >> Can you retry with the latest ddx?
>> >>
>> >> Maarten.
>> >>
>> >
>> > Awesome, it works, thanks ! :)
>> >
>>
>> I did not update that box for 3 weeks. I just did today (drm+ddx), and
>> it has regressed.
> Can you update your libdrm too please, the fix was moved to there and
> reverted in the DDX.
>

Strange, I am 99% sure I did update libdrm , and before updating ddx.
I will double-check tomorrow.

And I indeed found this commit :
http://cgit.freedesktop.org/nouveau/xf86-video-nouveau/commit/?id=bb1947831d9a4e080b8d1e9dba086af6527ef479
So I assume the libdrm one is this one on the same day :
http://cgit.freedesktop.org/mesa/drm/commit/?id=f1660c249198b5cc14ebbb75107da7bcb6972033

So by playing with these two commits, I should also be able to provide
more information. Thanks !
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] low memory

2010-01-07 Thread Ben Skeggs 
On Fri, 2010-01-08 at 00:51 +0100, Xavier wrote:
> On Sun, Dec 13, 2009 at 9:35 PM, Xavier  wrote:
> > On Sat, Dec 12, 2009 at 10:50 PM, Maarten Maathuis  
> > wrote:
> >>
> >> Can you retry with the latest ddx?
> >>
> >> Maarten.
> >>
> >
> > Awesome, it works, thanks ! :)
> >
> 
> I did not update that box for 3 weeks. I just did today (drm+ddx), and
> it has regressed.
Can you update your libdrm too please, the fix was moved to there and
reverted in the DDX.

Thanks,
Ben.
> X lockup is back, but it does not seem to be as bad as before :
> alt+sysrq+k kills X, then it gets restarted (probably by gdm) and
> everything is fine again.
> Still 5 minutes of firefox browsing causing X lockups is not cool :)
> 
> I will do some bisection tomorrow, I guess I will start with ddx.
> ___
> Nouveau mailing list
> Nouveau@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau


___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] low memory

2010-01-07 Thread Xavier 
On Sun, Dec 13, 2009 at 9:35 PM, Xavier  wrote:
> On Sat, Dec 12, 2009 at 10:50 PM, Maarten Maathuis  
> wrote:
>>
>> Can you retry with the latest ddx?
>>
>> Maarten.
>>
>
> Awesome, it works, thanks ! :)
>

I did not update that box for 3 weeks. I just did today (drm+ddx), and
it has regressed.
X lockup is back, but it does not seem to be as bad as before :
alt+sysrq+k kills X, then it gets restarted (probably by gdm) and
everything is fine again.
Still 5 minutes of firefox browsing causing X lockups is not cool :)

I will do some bisection tomorrow, I guess I will start with ddx.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] low memory

2009-12-13 Thread Xavier 
On Sat, Dec 12, 2009 at 10:50 PM, Maarten Maathuis  wrote:
>
> Can you retry with the latest ddx?
>
> Maarten.
>

Awesome, it works, thanks ! :)
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] low memory

2009-12-12 Thread Maarten Maathuis 
On Sat, Dec 12, 2009 at 1:04 AM, Maarten Maathuis  wrote:
> On Fri, Dec 11, 2009 at 8:11 PM, Xavier  wrote:
>> On Fri, Dec 11, 2009 at 1:30 PM, Ben Skeggs  wrote:
>>> On Fri, 2009-12-11 at 13:23 +0100, Anders Eriksson wrote:
 skeg...@gmail.com said:
 > It'd be useful to know of any cases out there where UMS is being used 
 > because
 > KMS is failing, there's a couple of cases on RH bugzilla, but I don't 
 > recall
 > the details right now.

 Try this one.

 https://bugs.freedesktop.org/show_bug.cgi?id=24810

 It used to work, but something changed which forced me back to UMS.
>>> It's not a solution by any means, but try:
>>>
>>>  Option "EXAPixmaps" "false"
>>>
>>> In your xorg.conf.  There'll be more work done to help the situation on
>>> low-mem cards.
>>>
>>
>> Ah that is interesting, so this can workaround the problem on my nv25
>> that cannot render too big pictures in firefox. (my test case is a
>> single picture : 3782x2592 resized to 550x368)
>>
>> So about that, I must mention the different behavior I got, in
>> chronological order :
>> 1) old ddx (10/01) : X instant crash
>> 2) newer ddx, after all the "handle reloc failures" patches : picture
>> is not displayed, just a black area instead. *much* better :)
>> 3) after upgrading kernel/drm from 12/08 - 2.6.32-rc6 to 12/11 -
>> 2.6.32 : X locks up.
>> I don't even see the usual message in dmesg ([TTM] Out of aperture
>> space or DRM memory quota.)
>> The gpu or at least nouveau drm is in a bad state and I must reboot to cover.
>>
>> Any clues about that last behavior ? I am not sure how
>> practical/possible regression testing will be since it seems to have
>> been caused by the last merge. I will open a bug report thats better.
>>
>> Finally I am curious about what work will be done to help :)
>> If I got it right (and I probably did not) :
>> exapixmaps true -> always use videoram for pixmaps
>> exapixmaps false -> never use videoram for pixmaps
>
> It switches between a classic exa implementation which is used to
> working with a fixed amount of vram, but will never cooperate with
> dri2. The default is a "mixed" exa implementation that does work with
> dri2. Both are accelerated for 2d purposes.
>
>> And so the solution would be something in between, like dynamically
>> choose whether to use vram or not, depending on the pixmap size and
>> the free vram ?
>> And how hard is that ?
>> ___
>> Nouveau mailing list
>> Nouveau@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/nouveau
>>
>

Can you retry with the latest ddx?

Maarten.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] low memory

2009-12-11 Thread Maarten Maathuis 
On Fri, Dec 11, 2009 at 8:11 PM, Xavier  wrote:
> On Fri, Dec 11, 2009 at 1:30 PM, Ben Skeggs  wrote:
>> On Fri, 2009-12-11 at 13:23 +0100, Anders Eriksson wrote:
>>> skeg...@gmail.com said:
>>> > It'd be useful to know of any cases out there where UMS is being used 
>>> > because
>>> > KMS is failing, there's a couple of cases on RH bugzilla, but I don't 
>>> > recall
>>> > the details right now.
>>>
>>> Try this one.
>>>
>>> https://bugs.freedesktop.org/show_bug.cgi?id=24810
>>>
>>> It used to work, but something changed which forced me back to UMS.
>> It's not a solution by any means, but try:
>>
>>  Option "EXAPixmaps" "false"
>>
>> In your xorg.conf.  There'll be more work done to help the situation on
>> low-mem cards.
>>
>
> Ah that is interesting, so this can workaround the problem on my nv25
> that cannot render too big pictures in firefox. (my test case is a
> single picture : 3782x2592 resized to 550x368)
>
> So about that, I must mention the different behavior I got, in
> chronological order :
> 1) old ddx (10/01) : X instant crash
> 2) newer ddx, after all the "handle reloc failures" patches : picture
> is not displayed, just a black area instead. *much* better :)
> 3) after upgrading kernel/drm from 12/08 - 2.6.32-rc6 to 12/11 -
> 2.6.32 : X locks up.
> I don't even see the usual message in dmesg ([TTM] Out of aperture
> space or DRM memory quota.)
> The gpu or at least nouveau drm is in a bad state and I must reboot to cover.
>
> Any clues about that last behavior ? I am not sure how
> practical/possible regression testing will be since it seems to have
> been caused by the last merge. I will open a bug report thats better.
>
> Finally I am curious about what work will be done to help :)
> If I got it right (and I probably did not) :
> exapixmaps true -> always use videoram for pixmaps
> exapixmaps false -> never use videoram for pixmaps

It switches between a classic exa implementation which is used to
working with a fixed amount of vram, but will never cooperate with
dri2. The default is a "mixed" exa implementation that does work with
dri2. Both are accelerated for 2d purposes.

> And so the solution would be something in between, like dynamically
> choose whether to use vram or not, depending on the pixmap size and
> the free vram ?
> And how hard is that ?
> ___
> Nouveau mailing list
> Nouveau@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau
>
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] low memory

2009-12-11 Thread Xavier 
On Fri, Dec 11, 2009 at 1:30 PM, Ben Skeggs  wrote:
> On Fri, 2009-12-11 at 13:23 +0100, Anders Eriksson wrote:
>> skeg...@gmail.com said:
>> > It'd be useful to know of any cases out there where UMS is being used 
>> > because
>> > KMS is failing, there's a couple of cases on RH bugzilla, but I don't 
>> > recall
>> > the details right now.
>>
>> Try this one.
>>
>> https://bugs.freedesktop.org/show_bug.cgi?id=24810
>>
>> It used to work, but something changed which forced me back to UMS.
> It's not a solution by any means, but try:
>
>  Option "EXAPixmaps" "false"
>
> In your xorg.conf.  There'll be more work done to help the situation on
> low-mem cards.
>

Ah that is interesting, so this can workaround the problem on my nv25
that cannot render too big pictures in firefox. (my test case is a
single picture : 3782x2592 resized to 550x368)

So about that, I must mention the different behavior I got, in
chronological order :
1) old ddx (10/01) : X instant crash
2) newer ddx, after all the "handle reloc failures" patches : picture
is not displayed, just a black area instead. *much* better :)
3) after upgrading kernel/drm from 12/08 - 2.6.32-rc6 to 12/11 -
2.6.32 : X locks up.
I don't even see the usual message in dmesg ([TTM] Out of aperture
space or DRM memory quota.)
The gpu or at least nouveau drm is in a bad state and I must reboot to cover.

Any clues about that last behavior ? I am not sure how
practical/possible regression testing will be since it seems to have
been caused by the last merge. I will open a bug report thats better.

Finally I am curious about what work will be done to help :)
If I got it right (and I probably did not) :
exapixmaps true -> always use videoram for pixmaps
exapixmaps false -> never use videoram for pixmaps
And so the solution would be something in between, like dynamically
choose whether to use vram or not, depending on the pixmap size and
the free vram ?
And how hard is that ?
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau