The main branch now includes randr-1.2 support (Option Randr12
true), and i've begun fixing it up. I will look at this later.
Maarten.
On 9/4/07, Bernhard Kaindl [EMAIL PROTECTED] wrote:
On Mon, 3 Sep 2007, Bernhard Kaindl wrote:
Hi,
Please find attached the patches which I currently
TV-out is not high priority at the moment, but nevertheless, come to
our irc channel some time (#nouveau on freenode). It never hurts to
have a centralized place of development, especially when reverse
engineering is involved. Hope to see you soon.
Maarten.
On 12/4/07, Dirk Thierbach [EMAIL
On 3/11/08, Maarten Maathuis [EMAIL PROTECTED] wrote:
Someone with a known good setup needs to test these patches.
Koala_BR is the obvious candidate, but i'm sending them to the
mailinglist anyway.
These are not extremely drastic, but i still need conformation that
they work, before i
2abc3bea475fc5ba9912d83ffa7ee636f1e36fc3 Mon Sep 17 00:00:00 2001
From: Maarten Maathuis [EMAIL PROTECTED]
Date: Wed, 12 Mar 2008 23:16:53 +0100
Subject: [PATCH] NV50: Unbreak NV50: Kill the connection status caching (which was broken btw).
---
src/nv50_dac.c |3 +++
src/nv50_sor.c |3 +++
2
On 4/28/08, Andreas Happe [EMAIL PROTECTED] wrote:
On Mon, 2008-04-28 at 19:33 +0300, Pekka Paalanen wrote:
Framebuffer loaded is usually a bad sign. The Nouveau driver does not
work reliably with a framebuffer driver loaded. Granted, there are rumours
that vesafb should work, and that
On Wed, Oct 1, 2008 at 7:34 AM, Tomasz Chmielewski [EMAIL PROTECTED] wrote:
Michael Kreitzer schrieb:
Tomasz,
It sounds to me like what may be happening is the video card is doing the
scaling instead of the monitor. This is evidenced by the fact that the
resolution does change, but the LCD
On Wed, Oct 1, 2008 at 3:06 PM, Maarten Maathuis [EMAIL PROTECTED] wrote:
On Wed, Oct 1, 2008 at 7:34 AM, Tomasz Chmielewski [EMAIL PROTECTED] wrote:
Michael Kreitzer schrieb:
Tomasz,
It sounds to me like what may be happening is the video card is doing the
scaling instead of the monitor
On Sat, Oct 4, 2008 at 5:16 PM, Calvin Walton [EMAIL PROTECTED] wrote:
On Wed, 2008-10-01 at 15:06 +0200, Maarten Maathuis wrote:
On Wed, Oct 1, 2008 at 7:34 AM, Tomasz Chmielewski [EMAIL PROTECTED] wrote:
Michael Kreitzer schrieb:
Tomasz,
It sounds to me like what may be happening
On Fri, Nov 7, 2008 at 1:26 AM, Ben Skeggs [EMAIL PROTECTED] wrote:
On Fri, 2008-11-07 at 00:43 +0100, Maarten Maathuis wrote:
My main question is, do the error messages accurately reflect the situation.
Anything else wrong with this patch?
A (n)ack by darktama would be nice.
An instance
I was thinking of the following system:
Allocate a fifo for userspace, map the fifo, map the fifo registers into
userspace.
These allocations are therefore pinned, so something to avoid memory
fragmentation has to be done.
Userspace library fills up an entire fifo, minus a few essential things
On 12/20/2008 11:48 PM, Maarten Maathuis wrote:
On 12/20/2008 10:08 PM, Ben Skeggs wrote:
On Sat, Dec 20, 2008 at 11:58 PM, Maarten Maathuis
madman2...@gmail.com mailto:madman2...@gmail.com wrote:
I was thinking of the following system:
Allocate a fifo for userspace, map the fifo
The first patch (for drm) fixes a very annoying bug for nv50 gart. The
2nd is just a few cleanups in libnouveau_drm.
I also pushed a few changes to the ng ddx, and I'm at the moment
thinking on how to deal with the issue of nv50.
We are no longer garuanteed that pixmaps are really migrated upon
I'm doing some testing/coding on the ng branches and i've run into
some problems, namely that i get PROTECTION_ERRORS after some time. It
seems most common when two two dma's happen very close together on the
same piece of memory (no hard proof to back this up, just something i
noticed). I'm using
On Sat, Dec 27, 2008 at 2:35 AM, Maarten Maathuis madman2...@gmail.com wrote:
I'm doing some testing/coding on the ng branches and i've run into
some problems, namely that i get PROTECTION_ERRORS after some time. It
seems most common when two two dma's happen very close together on the
same
On 12/27/2008 12:36 PM, Daniel Eklöf wrote:
On 12/26/08, Daniel Eklöfdan...@ekloef.se wrote:
Hi,
I've been trying out nouveau for a while now and I must say I'm
impressed. Performance in KDE4 in general seems better than the nvidia
blob; way to go!
There are a couple of annoyances
1 patch for libnouveau_drm, 4 for drm and one work in progress patch
for the ddx.
Getting nv50 to run proved to be more difficult than i thought (at
some point i stopped because it would require significant changes), i
just have a few remarks.
- Buffer object access is not guarded by fences at
On 01/05/2009 04:07 PM, Maarten Maathuis wrote:
On 01/05/2009 01:24 AM, Ben Skeggs wrote:
On Sat, 2009-01-03 at 17:53 +0100, Maarten Maathuis wrote:
1 patch for libnouveau_drm, 4 for drm and one work in progress patch
for the ddx.
Getting nv50 to run proved to be more difficult than i
On 01/05/2009 01:24 AM, Ben Skeggs wrote:
On Sat, 2009-01-03 at 17:53 +0100, Maarten Maathuis wrote:
1 patch for libnouveau_drm, 4 for drm and one work in progress patch
for the ddx.
Getting nv50 to run proved to be more difficult than i thought (at
some point i stopped because it would
A small patch to make nv50 kms a bit more robust and avoid a nasty crash.
Maarten.
0001-nv50-check-if-the-framebuffer-gem-object-is-non-NUL.patch
Description: Binary data
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
On Thu, Feb 5, 2009 at 1:26 PM, Dave Airlie airl...@gmail.com wrote:
On Thu, Feb 5, 2009 at 1:16 AM, Maarten Maathuis madman2...@gmail.com wrote:
On Wed, Feb 4, 2009 at 3:42 PM, Yan Seiner y...@seiner.com wrote:
I'm trying to get started with nouveau. I have it compiled, I have it
installed
Have you tried running the cards separately first? Multi card
situations are pretty rare, so it's better to know if they work
individually.
Maarten.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
On Fri, Feb 6, 2009 at 7:50 PM, Yan Seiner y...@seiner.com wrote:
On Fri, February 6, 2009 10:49 am, Yan Seiner wrote:
On Fri, February 6, 2009 7:13 am, Maarten Maathuis wrote:
Have you tried running the cards separately first? Multi card
situations are pretty rare, so it's better to know
---
src/nouveau_exa.c | 19 +++
src/nv50_exa.c|6 +++---
src/nv50_xv.c |5 +
src/nv_proto.h|1 +
4 files changed, 20 insertions(+), 11 deletions(-)
diff --git a/src/nouveau_exa.c b/src/nouveau_exa.c
index a947a31..3babfd7 100644
---
(nv_crtc-crtc, x, y);
}
nv_crtc-crtc-ModeSet(nv_crtc-crtc, mode);
diff --git a/src/nv50_shadow_damage.c b/src/nv50_shadow_damage.c
new file mode 100644
index 000..9d1a8cb
--- /dev/null
+++ b/src/nv50_shadow_damage.c
@@ -0,0 +1,164 @@
+/*
+ * Copyright 2009 Maarten Maathuis
---
src/nouveau_exa.c| 36 +++
src/nv50_shadow_damage.c | 108 ++
src/nv_proto.h |1 +
3 files changed, 145 insertions(+), 0 deletions(-)
diff --git a/src/nouveau_exa.c b/src/nouveau_exa.c
index c4cafb0..b6ae8ca
On Fri, Feb 13, 2009 at 12:11 AM, Stephane Marchesin
marche...@icps.u-strasbg.fr wrote:
On Thu, Feb 12, 2009 at 23:56, Maarten Maathuis madman2...@gmail.com wrote:
- Fallbacks on the frontbuffer still need to be handled.
---
Why are you posting this again ? It's not really better than
These patches are workarounds, and therefore will not be applied to git.
I made them out of curiosity.
Maarten.
On Fri, Feb 13, 2009 at 10:19 AM, Hervé Cauwelier
herve.cauwel...@free.fr wrote:
Maarten Maathuis a écrit :
[snip]
I can't tell you about the technical quality of this patch
You're confusing issues, yours is a performance issue, not a correctness issue.
Maarten.
On Fri, Feb 27, 2009 at 11:07 AM, Hervé Cauwelier
herve.cauwel...@free.fr wrote:
Ben Skeggs a écrit :
On Thu, 2009-02-26 at 21:55 +0100, Maarten Maathuis wrote:
- I'm surprised we didn't get serious
I've got a preliminary wfb implementation, but it still has issues. In
the meantime i've added what i know to the wiki.
Maarten.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
This patch will only work with Option EXAPixmaps 1, and will
prevent classic exa from working.
Occasionally a pixmap fails to map, but that's not related to this patch.
I haven't done any hardcore optimisations, but suggestions are
ofcource appreciated.
In my experience some benchmarks suck now
This version is a bit faster by avoiding the need for (SUB)TILE_WIDTH.
On Sat, Mar 7, 2009 at 1:59 PM, Maarten Maathuis madman2...@gmail.com wrote:
This patch will only work with Option EXAPixmaps 1, and will
prevent classic exa from working.
Occasionally a pixmap fails to map, but that's
This one has been optimised further, all usage of modulus has been removed.
There are still optimisations to do (like using hostdata transfers for
the first pixmap access), but this is getting closer to usable.
Maarten.
On Sat, Mar 7, 2009 at 2:20 PM, Maarten Maathuis madman2...@gmail.com wrote
- Only for sufficiently new xserver's and exa_driver_pixmaps.
---
src/nouveau_exa.c | 217 +++--
src/nv_driver.c | 51 +++--
src/nv_proto.h|4 +
src/nv_type.h | 12 +++-
4 files changed, 267 insertions(+), 17 deletions(-)
---
src/nouveau_exa.c | 17 +
src/nv_type.h |1 +
2 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/src/nouveau_exa.c b/src/nouveau_exa.c
index 074a226..ae6e151 100644
--- a/src/nouveau_exa.c
+++ b/src/nouveau_exa.c
@@ -717,7 +717,9 @@ static NVPtr
---
src/nouveau_exa.c | 10 ++
src/nv_type.h |1 +
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/src/nouveau_exa.c b/src/nouveau_exa.c
index ae6e151..c44e882 100644
--- a/src/nouveau_exa.c
+++ b/src/nouveau_exa.c
@@ -741,8 +741,8 @@
---
src/nouveau_exa.c | 97 +---
src/nv_driver.c |1 +
src/nv_proto.h|1 +
src/nv_type.h | 11 --
4 files changed, 56 insertions(+), 54 deletions(-)
diff --git a/src/nouveau_exa.c b/src/nouveau_exa.c
index c44e882..2d748e1
---
src/nouveau_exa.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/nouveau_exa.c b/src/nouveau_exa.c
index 2d748e1..4b82d21 100644
--- a/src/nouveau_exa.c
+++ b/src/nouveau_exa.c
@@ -687,7 +687,7 @@ nouveau_exa_init(ScreenPtr pScreen)
/* WFB functions. */
And a combined patch for the lazy testers.
Maarten.
On Sun, Mar 8, 2009 at 3:37 PM, Maarten Maathuis madman2...@gmail.com wrote:
These patches are pretty much done, except for a compile warning somewhere.
The major remaining bottleneck is this line (as far as i can tell):
offset
I'm especially interested in the original data that was used to derive
the constant buffer arguments.
I'm looking for the texture unit switch for tiling format, and i'm
hoping the original data will easily reveal it.
Maarten.
___
Nouveau mailing list
You were right about the 3rd dword.
For posterity:
tileheight:
4 - 0xd0005000
8 - 0xd0405000
16 - 0xd0805000
32 - 0xd0c05000
64 - 0xd1005000
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Here is an app to test the texture layout.
No message means it's ok. Otherwise it spews a lot of errors.
You have to manually set the TILE_HEIGHT, TILE_WIDTH and TILING_PARAM.
TILE_WIDTH == TILE_PITCH in this case because it's 8bpp data.
Use this list (TILING_PARAM) TILE_WIDTHxTILE_HEIGHT:
), but with the smallest tile size:
(TILING_PARAM) TILE_WIDTHxTILE_HEIGHT: (0x00) 32x4
(that goes for everyone sending in bug logs).
Maarten.
On Wed, Mar 11, 2009 at 8:09 PM, Maarten Maathuis madman2...@gmail.com wrote:
I forgot to say it isn't a fast program, so be prepared to wait at
least a few minutes
Small correction, only 16 pixmaps can be placed inside a single page.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
This was exactracted from a 8192x4 texture, with 32x4 tiles.
4 patterns appears, each 8x128 bytes long.
these patterns are repeated, and one is always left out.
So 123, 234, 134, 124.
The repetetive cycle is therefore 4x3x8x128 = 12288 bytes long.
I've included the color code ods file, which
I can add that in all likelyhood this reshuffling of 32x4 tiles
happens regardless of the largest tile size.
Maarten.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Update version with a NV90_MODE, please set it according to your card.
Maarten.
nv50_test-2.tar.bz2
Description: BZip2 compressed data
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Small update, this time you can just set TILING_PARAM and you're good to go.
Maarten.
nv50_test-3.tar.bz2
Description: BZip2 compressed data
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
New version, with 16bpp and 32bpp tests also. Someone with a NV9X
needs to run the new tests, i made a guess about what is happening
after the wfb fiasco, so hopefully it's right.
Maarten.
nv50_test-4.tar.bz2
Description: BZip2 compressed data
___
the searching a bit, but expect the test to run for at
least half an hour. You can sent the log to me personally.
Don't change any of the parameters for that test.
Maarten.
On Sun, Mar 15, 2009 at 11:18 PM, Maarten Maathuis madman2...@gmail.com wrote:
New version, with 16bpp and 32bpp tests also. Someone
The special test is only if i ask you fail the normal nv50_test.
Maarten.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
That came out wrong, the special test is only if the normal test fails
or if i ask you to make it.
I will make a faster special test in the forseeable future.
Maarten.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
NV84_MODE is for NV84, try setting it to zero.
I have a NV86, so i'm pretty sure it works.
Maarten.
2009/3/19 Hervé Cauwelier herve.cauwel...@free.fr:
I come back on this matter because I was away when you posted it.
I read you've got enough feedback for NV86 cards but mine doesn't seem
to
Please tell me what can't work about this idea.
- Introduce concept of batches, through some kind of marker (tied to fences).
- Request buffers up front, userspace does all relocation (avoid
teaching the kernel about tiling, etc).
- Driver stores state for each batch.
- FIRE_RING becomes an ioctl
I suggest you file a bug for a crash (including gdb backtrace).
Maarten.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
.
Maarten.
From 3425f32eb0d5c664cd5a4141812bc002960de795 Mon Sep 17 00:00:00 2001
From: Maarten Maathuis madman2...@gmail.com
Date: Sat, 7 Mar 2009 23:49:19 +0100
Subject: [PATCH 1/6] nv50: implement wfb
- Only for sufficiently new xserver's and exa_driver_pixmaps.
---
src/nouveau_exa.c | 282
It could be me, but i don't see the commit.
Maarten.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Do you have strong feelings against making these ports different for
8xxx and 9xxx?
Maarten.
On Fri, Apr 3, 2009 at 7:12 PM, Maarten Maathuis madman2...@gmail.com wrote:
The change was prompted by a personal email i recieved regarding a bug
on a 9200 (which included the right ports), a mmio
Perhaps you should request an account, if you feel like long term contribution.
Maarten.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
The C51 has a very strange HW cursor issue, so that is not surprising.
Bug is http://bugs.freedesktop.org/show_bug.cgi?id=15758
Maarten.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
It is possible that the DDX is now masking the problem very well, if
only your C51 has this cursor issue then i would really suspect this
kind of bug.
Maarten.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
No, not unless you implement it.
Maarten.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
If you had to estimate, how long did it take you to figure out evo?
Anyway, it looks nice, i will certainly try when i'm home again.
Maarten.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Any plans on merging the wfb patch or will i get that honor when i get
home (in 6 weeks)?
Maarten.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
I just realised that this mode of tiling is quite different from the
one i observed, this one is linear inside the tile, not recursively
tiled.
Also, one optimisation that you can do without fixing the xserver
(which should be done anyway), is to set pread and pwrite to the
linear passthrough
On Thu, Jul 9, 2009 at 5:23 PM, Eric Valetteeric.vale...@free.fr wrote:
Maarten Maathuis wrote:
This merging you probably read about, was merging 2.6.30-rc1 into the
nouveau tree, because that had upstream ttm support.
OK. I read it the other way round! I saw people complaining someone
Noone has ever claimed working opengl, the only parts that are
supported, in the sense that you can file a bug about it, are the ddx
(2d) driver and the kernel module. Getting a useable memory manager in
place was a prerequisite, once that and the rest of the new kernel
code stabilizes i'm sure
Probably an older version of libdrm floating around?
Maarten.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
You need libdrm from GIT.
Maarten.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
ThibG from irc reported an issue with transparent cursors, i noticed
the ddx had a workaround, which wasn't in the kms code.
ThibG (whoever you are), please test. The patch is untested.
Maarten.
From 7ce90b3297782e5ecada6e4e917be7a9c316d082 Mon Sep 17 00:00:00 2001
From: Maarten Maathuis madman2
There is some support for laptop backlight control.
(http://cgit.freedesktop.org/nouveau/linux-2.6/tree/drivers/gpu/drm/nouveau/nouveau_backlight.c)
If you have older hw, then you may need to figure out how to control it.
I see only a few bug reports related to backlights, so a lot of people
- We cannot assume all state objects are present when the pipe context changes.
---
src/gallium/drivers/nv50/nv50_state_validate.c | 27 +++-
1 files changed, 26 insertions(+), 1 deletions(-)
diff --git a/src/gallium/drivers/nv50/nv50_state_validate.c
---
src/gallium/drivers/nv50/nv50_vbo.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/nv50/nv50_vbo.c
b/src/gallium/drivers/nv50/nv50_vbo.c
index 17283f3..018354a 100644
--- a/src/gallium/drivers/nv50/nv50_vbo.c
+++
- PIPE_TRANSFER_READ ended up being defined as 0, which is obviously fail.
---
src/gallium/include/pipe/p_defines.h |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/gallium/include/pipe/p_defines.h
b/src/gallium/include/pipe/p_defines.h
index bc4bc70..9d47584
- This fixes neverball corruption.
- I'm unsure what we're actually flushing here.
---
src/gallium/drivers/nv50/nv50_context.c | 12 ++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/nv50/nv50_context.c
b/src/gallium/drivers/nv50/nv50_context.c
On Fri, Aug 21, 2009 at 6:58 AM, Pekka Paalanenp...@iki.fi wrote:
On Thu, 20 Aug 2009 20:27:49 +0200
Maarten Maathuis madman2...@gmail.com wrote:
I think the -1 on chan-dma.free is unnecessary.
Maybe it is for the wrap-around jump command, the OUT_RING?
I don't any other way of reserving
The timeout is too short, the gallium driver will easily trigger an assert.
Maarten.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
On Sat, Aug 22, 2009 at 1:26 AM, Ben Skeggsskeg...@gmail.com wrote:
On Fri, 2009-08-21 at 21:30 +0200, Maarten Maathuis wrote:
The timeout is too short, the gallium driver will easily trigger an assert.
Oops, that was a typo. Thanks, fixed.
Any other comments?
Not really, it's been running
On Mon, Aug 24, 2009 at 4:03 PM, Francisco Jerezcurroje...@riseup.net wrote:
Signed-off-by: Francisco Jerez curroje...@riseup.net
---
man/nouveau.man | 7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/man/nouveau.man b/man/nouveau.man
index 87f645a..5c4e4ae
- In the case of nvbo-head it is really important to avoid an OOPS if
ttm_buffer_object_init fails.
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
drivers/gpu/drm/nouveau/nouveau_bo.c |2 ++
drivers/gpu/drm/nouveau/nouveau_channel.c |1 +
drivers/gpu/drm/nouveau
What are you using? are you using master from the nouveau kernel? git
versions for the rest? self made or prepackaged stuff?
More info is a must.
Maarten.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
Find someone who wants to create and maintain it.
Maarten.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
---
src/gallium/drivers/nv50/nv50_context.c|3 +++
src/gallium/drivers/nv50/nv50_context.h|1 +
src/gallium/drivers/nv50/nv50_state_validate.c |6 ++
3 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/src/gallium/drivers/nv50/nv50_context.c
---
src/gallium/drivers/nv50/nv50_context.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/src/gallium/drivers/nv50/nv50_context.c
b/src/gallium/drivers/nv50/nv50_context.c
index 935de8a..6b31da4 100644
--- a/src/gallium/drivers/nv50/nv50_context.c
+++
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
src/gallium/drivers/nouveau/nouveau_stateobj.h | 12
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/nouveau/nouveau_stateobj.h
b/src/gallium/drivers/nouveau/nouveau_stateobj.h
index
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
src/gallium/drivers/nouveau/nouveau_stateobj.h | 12
src/gallium/drivers/nv50/nv50_query.c |2 +-
src/gallium/drivers/nv50/nv50_surface.c|2 ++
src/gallium/drivers/nv50/nv50_transfer.c |4
- NV30 and NV40 need testing.
- I'll take better naming suggestions for so_get_push_reloc().
---
src/gallium/drivers/nouveau/nouveau_stateobj.h | 49 +++-
src/gallium/drivers/nv04/nv04_surface_2d.c |9 +++-
src/gallium/drivers/nv30/nv30_state_emit.c | 26
- Added flush notify functions for NV30 and NV40.
- NV30 and NV40 need testing.
---
src/gallium/drivers/nouveau/nouveau_stateobj.h | 42 ++--
src/gallium/drivers/nv04/nv04_surface_2d.c |9 +++--
src/gallium/drivers/nv30/nv30_context.c|3 ++
On Fri, Dec 11, 2009 at 8:11 PM, Xavier shinin...@gmail.com wrote:
On Fri, Dec 11, 2009 at 1:30 PM, Ben Skeggs skeg...@gmail.com 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
On Sat, Dec 12, 2009 at 1:04 AM, Maarten Maathuis madman2...@gmail.com wrote:
On Fri, Dec 11, 2009 at 8:11 PM, Xavier shinin...@gmail.com wrote:
On Fri, Dec 11, 2009 at 1:30 PM, Ben Skeggs skeg...@gmail.com wrote:
On Fri, 2009-12-11 at 13:23 +0100, Anders Eriksson wrote:
skeg...@gmail.com said
On Sat, Dec 5, 2009 at 9:55 PM, Maarten Maathuis madman2...@gmail.com wrote:
- Added flush notify functions for NV30 and NV40.
- NV30 and NV40 need testing.
---
src/gallium/drivers/nouveau/nouveau_stateobj.h | 42
++--
src/gallium/drivers/nv04/nv04_surface_2d.c
- Added flush notify functions for NV30 and NV40.
- NV30 and NV40 need testing (check for regressions).
---
src/gallium/drivers/nouveau/nouveau_stateobj.h | 47 +++-
src/gallium/drivers/nv04/nv04_surface_2d.c |9 +++--
src/gallium/drivers/nv30/nv30_context.c|
- Use driver level (0x2) for NV_DEBUG instead of all levels
- Create a NV_DEBUG_KMS for KMS level (04) and use them in modesetting code
- Remove a few odd NV_TRACE calls and replace with NV_DEBUG_KMS
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
drivers/gpu/drm/nouveau/nouveau_bios.c
On Sun, Dec 13, 2009 at 4:56 PM, Maarten Maathuis madman2...@gmail.com wrote:
- Use driver level (0x2) for NV_DEBUG instead of all levels
- Create a NV_DEBUG_KMS for KMS level (04) and use them in modesetting code
I just noticed this typo, replaced it with 0x4 in my local copy.
- Remove a few
In case it isn't clear, i can push this myself, just need a few acks
so i know people agree.
Maarten.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
On Sun, Dec 13, 2009 at 8:56 PM, Francisco Jerez curroje...@riseup.net wrote:
Maarten Maathuis madman2...@gmail.com writes:
- Use driver level (0x2) for NV_DEBUG instead of all levels
- Create a NV_DEBUG_KMS for KMS level (04) and use them in modesetting code
- Remove a few odd NV_TRACE calls
- Use driver level (0x2) for NV_DEBUG instead of all levels
- Create a NV_DEBUG_KMS for KMS level (0x4) and use them in modesetting code
- Remove a few odd NV_TRACE calls and replace some of them with NV_DEBUG_KMS or
NV_INFO
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
drivers/gpu
Now that we are in staging and patches are expected to be pulled into
that tree (instead of one big nouveau commit) it seems obvious that
commits should try to follow the kernel rules. Some are more obvious
than others, i for one just remembered that patches should be run
through checkpatch. My
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
src/gallium/drivers/nouveau/nouveau_stateobj.h |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/src/gallium/drivers/nouveau/nouveau_stateobj.h
b/src/gallium/drivers/nouveau/nouveau_stateobj.h
index 9aee9e4
On Fri, Dec 18, 2009 at 10:57 AM, Christoph Bumiller
e0425...@student.tuwien.ac.at wrote:
Maarten Maathuis schrieb:
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
src/gallium/drivers/nouveau/nouveau_stateobj.h | 9 +
1 files changed, 9 insertions(+), 0 deletions
ttm_bo_validate() calls ttm_bo_move_buffer() which calls
ttm_bo_handle_move_mem() which calls bdev-driver-move() which calls
nouveau_bo_move_m2mf(), which doesn't ensure synchronization (nowait
== false) if the bo is moved on another channel (which is common for
nv50). I suspect this to be the
1 - 100 of 243 matches
Mail list logo
