2009/12/28 Michel Dänzer mic...@daenzer.net:
On Mon, 2009-12-28 at 13:37 +0100, Maarten Maathuis wrote:
What kind of situation are you trying to improve here?
Same as for the UploadToScreen case in exaHWCopyNtoN(); avoiding GPU
copy readbacks when the GPU copy isn't directly accessible.
I
On Mon, Dec 28, 2009 at 6:37 PM, Marcin Slusarz
marcin.slus...@gmail.com wrote:
---
src/nv50_exa.c | 155
1 files changed, 100 insertions(+), 55 deletions(-)
diff --git a/src/nv50_exa.c b/src/nv50_exa.c
index 1f5a4ac..54968e8
- The implementation is pretty generic and should work on most hw.
- It's only tested on nv50 and the userspace interface lacks awareness of
fences, so it's not possible yet to do this from userspace.
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
drivers/gpu/drm/nouveau/nouveau_bo.c
It still seems like the condition is only true for classic exa.
2009/12/28 Michel Dänzer mic...@daenzer.net:
From: =?UTF-8?q?Michel=20D=C3=A4nzer?= daen...@vmware.com
This was always the intention, I only recently realized it wasn't the case
yet...
Signed-off-by: Michel Dänzer
Acked-by: Maarten Maathuis madman2...@gmail.com
2009/12/28 Michel Dänzer mic...@daenzer.net:
From: Michel Dänzer daen...@vmware.com
* With optimized migration, only the pending damage region is synchronized for
destination pixmaps.
* Migration of source pixmaps can be limited to a bounding
Why does it help to allocate the sys_ptr up front, why does that avoid
migration (i would except sys_ptr to be allocated when needed)?
Maarten.
2009/12/28 Michel Dänzer mic...@daenzer.net:
From: Michel Dänzer daen...@vmware.com
Signed-off-by: Michel Dänzer daen...@vmware.com
---
Acked-by: Maarten Maathuis madman2...@gmail.com
2009/12/28 Michel Dänzer mic...@daenzer.net:
From: Thomas Hellstrom thellst...@vmware.com
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
Acked-by: Michel Dänzer mic...@daenzer.net
---
exa/exa_accel.c | 2 +-
exa/exa_unaccel.c
The A1 trapezoids are used for aliased rendering, is that still preserved?
Maarten.
2009/12/28 Michel Dänzer mic...@daenzer.net:
From: Michel Dänzer daen...@vmware.com
It's more or less impossible for us to accelerate such formats at this point.
Signed-off-by: Michel Dänzer
Acked-by: Maarten Maathuis madman2...@gmail.com
2009/12/28 Michel Dänzer mic...@daenzer.net:
On Mon, 2009-12-28 at 13:21 +0100, Maarten Maathuis wrote:
It still seems like the condition is only true for classic exa.
No. I guess the diff is a little confusing, but the result is that only
What kind of situation are you trying to improve here? How often does
a fallback happen after PutImage?
2009/12/28 Michel Dänzer mic...@daenzer.net:
From: Michel Dänzer daen...@vmware.com
We want to save the result in the system memory copy, in case we'll need it
again for subsequent software
Acked-by: Maarten Maathuis madman2...@gmail.com
2009/12/28 Michel Dänzer mic...@daenzer.net:
From: Michel Dänzer daen...@vmware.com
Signed-off-by: Michel Dänzer daen...@vmware.com
---
exa/exa_unaccel.c | 14 --
1 files changed, 12 insertions(+), 2 deletions(-)
diff --git
Acked-by: Maarten Maathuis madman2...@gmail.com
2009/12/28 Michel Dänzer mic...@daenzer.net:
From: Thomas Hellstrom thellst...@vmware.com
When we can trivially calculate the affected source regions,
do that before calling region bounded prepareAccess.
[ Michel: Minor fixups to address
2009/12/28 Michel Dänzer mic...@daenzer.net:
From: Thomas Hellstrom thellst...@vmware.com
[ Michel: Minor fixups to address compiler warnings ]
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
Signed-off-by: Michel Dänzer daen...@vmware.com
---
exa/exa_priv.h | 10 +++
2009/12/28 Michel Dänzer mic...@daenzer.net:
On Mon, 2009-12-28 at 13:51 +0100, Maarten Maathuis wrote:
2009/12/28 Michel Dänzer mic...@daenzer.net:
From: Thomas Hellstrom thellst...@vmware.com
[ Michel: Minor fixups to address compiler warnings ]
Signed-off-by: Thomas Hellstrom
- Depth and stencil buffers are supposed to be large enough in general.
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
drivers/gpu/drm/nouveau/nouveau_bo.c |9 -
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers
- This is not yet a generic implementation that will work everywhere, but it's
a start.
- This will fix the corruption surrounding pixmap/texture bo moves on nv50.
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
drivers/gpu/drm/nouveau/nouveau_bo.c |7 ++
drivers/gpu/drm
On Sun, Dec 27, 2009 at 2:43 PM, Christoph Bumiller
e0425...@student.tuwien.ac.at wrote:
On 12/27/2009 12:41 PM, Maarten Maathuis wrote:
- Depth and stencil buffers are supposed to be large enough in general.
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
drivers/gpu/drm/nouveau
To avoid any confusion, make sure your buffers are large enough
means you shouldn't go allocating very small depth/stencil buffers,
because that will waste space. Userspace should never have to worry
about the restrictions themselves.
Maarten.
On Sun, Dec 27, 2009 at 3:28 PM, Maarten Maathuis
- Always make sure they are in vram (this is the only place where we have the
proper aperture).
- Hide the padding away from users, accessing this can cause problems for
neighbour buffer objects.
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
drivers/gpu/drm/nouveau/nouveau_bo.c
- The resulting misallignment was causing stuff to be overwritten everywhere,
resulting in card hangs eventually.
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
drivers/gpu/drm/nouveau/nouveau_bo.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu
- This should be better than what we have now.
- I'm less sure about the non power of two path.
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 36 +
1 files changed, 19 insertions(+), 17 deletions(-)
diff --git
- This is not yet a generic implementation that will work everywhere, but it's
a start.
- This will fix the corruption surrounding pixmap/texture bo moves on nv50.
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
drivers/gpu/drm/nouveau/nouveau_bo.c |7 ++
drivers/gpu/drm
pushed 1 to 4
On Sat, Dec 26, 2009 at 10:43 PM, Maarten Maathuis madman2...@gmail.com wrote:
- Aligning to block size should ensure that the extra size is enough.
- Using roundup, because not all sizes are powers of two.
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
drivers/gpu
- This is not yet a generic implementation that will work everywhere, but it's
a start.
- This will fix the corruption surrounding pixmap/texture bo moves on nv50.
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
drivers/gpu/drm/nouveau/nouveau_bo.c |8 ++-
drivers/gpu/drm
In short, we move out the low level content of a buffer object. In the
case of textures and such this is utterly useless. Still it is
accessed, because ttm sees no problem in using PL_SYSTEM or PL_TT
memory. What is the best way to let ttm know we don't really
appreciate that? A custom memory to
- This includes unmapping on failure to sync for cpu access.
- Double mapping will also be punished, so that people fix their code.
---
nouveau/nouveau_bo.c | 23 ---
1 files changed, 16 insertions(+), 7 deletions(-)
diff --git a/nouveau/nouveau_bo.c b/nouveau/nouveau_bo.c
Anyone?
On Sun, Dec 20, 2009 at 2:03 PM, Maarten Maathuis madman2...@gmail.com wrote:
- This fixes a crash upon starting spring (a rts engine/game).
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
src/mesa/state_tracker/st_cb_bufferobjects.c | 16 ++--
1 files
Can this go in?
On Mon, Dec 21, 2009 at 4:51 PM, Maarten Maathuis madman2...@gmail.com wrote:
---
nouveau/nouveau_bo.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/nouveau/nouveau_bo.c b/nouveau/nouveau_bo.c
index 10cc8a6..9d584a3 100644
--- a/nouveau
That should be s/except/expect
On Wed, Dec 23, 2009 at 4:31 PM, Maarten Maathuis madman2...@gmail.com wrote:
Can this go in?
On Mon, Dec 21, 2009 at 4:51 PM, Maarten Maathuis madman2...@gmail.com
wrote:
---
nouveau/nouveau_bo.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions
- Seeing DVI-I-0 in xrandr and DVI-I-1 in the kernel logs can be a source of
confusion.
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
src/drmmode_display.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/drmmode_display.c b/src/drmmode_display.c
index
On Thu, Dec 24, 2009 at 12:29 AM, Jack ostrof...@sbcglobal.net wrote:
Hello,
I'm using nouveau xf86-video-nouveau 0.0.10_git20091101-1 and
nouveau-drm 0.0.15_20091120-1 under Arch Linux with xorg-server
1.7.3.901-1. My video card is recognized as nVidia Corporation NV25GL
[Quadro4 750 XGL].
src/glsl doesn't build automatically at all, so i guess it was never
tested with that?
Maarten.
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app
at 2:39 PM, Maarten Maathuis madman2...@gmail.com wrote:
- Use the direct objects that previously only the kernel fifo had.
- This avoids corruption on some buffer moves.
- Prevent dma access to ramin, we never use dma there anyway and it's an
exploit waiting to happen.
Signed-off-by: Maarten
On Mon, Dec 21, 2009 at 11:25 AM, Christoph Bumiller
e0425...@student.tuwien.ac.at wrote:
On 12/20/2009 04:46 PM, Maarten Maathuis wrote:
- This avoids problematic reloc'ed while mapped messages and
some associated corruption as well.
- Also add one nouveau_bo_unmap() in the vbo code
---
nouveau/nouveau_bo.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/nouveau/nouveau_bo.c b/nouveau/nouveau_bo.c
index 10cc8a6..9d584a3 100644
--- a/nouveau/nouveau_bo.c
+++ b/nouveau/nouveau_bo.c
@@ -444,8 +444,10 @@ nouveau_bo_map_range(struct nouveau_bo *bo,
- This avoids some problematic reloc'ed while mapped messages and
some associated corruption as well.
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
src/gallium/drivers/nouveau/nouveau_screen.c | 21 +
src/gallium/drivers/nouveau/nouveau_screen.h |3
- Use the direct objects that previously only the kernel fifo had.
- This avoids corruption on some buffer moves.
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 23 ++---
drivers/gpu/drm/nouveau/nouveau_object.c | 36
On Thu, Dec 17, 2009 at 10:40 PM, Nikos Chantziaras rea...@arcor.de wrote:
On 12/17/2009 10:54 PM, dolphinling wrote:
On 12/14/2009 04:44 PM, Nikos Chantziaras wrote:
The longer the system runs, the more RAM X eats. After about 5 hours of
uptime, I get this:
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
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 Sat, Dec 12, 2009 at 11:21 PM, Maarten Maathuis madman2...@gmail.com wrote:
On Sat, Dec 12, 2009 at 8:03 PM, Keith Whitwell kei...@vmware.com wrote:
Maarten,
Interesting. There are reasons this might be happening indeed, but first
can I ask a couple of silly questions...
- Is your bug
did a realclean and got softpipe to build, but it still doesn't work.
warzone2100: swrast/s_span.c:1477: _swrast_write_rgba_span: Assertion
`rb-_BaseFormat == 0x1908 || rb-_BaseFormat == 0x1907' failed.
On Wed, Dec 16, 2009 at 7:20 PM, Maarten Maathuis madman2...@gmail.com wrote:
On Sat, Dec 12
With the help of scons i actually managed to build a softpipe and came
to the conclusion this is working fine too. This is really odd.
Maarten.
On Wed, Dec 16, 2009 at 8:01 PM, Maarten Maathuis madman2...@gmail.com wrote:
did a realclean and got softpipe to build, but it still doesn't work
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
CC'ing to keithp, since he's the one that has to pick this up.
Maarten.
On Mon, Dec 14, 2009 at 6:19 PM, ville.syrj...@nokia.com wrote:
From: Ville Syrjälä ville.syrj...@nokia.com
Most of the Xv Put/Get operations have an off by one error in the
viewport clipping.
Apparently PutImage was
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
Module: Mesa
Branch: master
Commit: 41b52aa3362665e08bdc2f75cc9bfdc4debc6eb0
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=41b52aa3362665e08bdc2f75cc9bfdc4debc6eb0
Author: Maarten Maathuis madman2...@gmail.com
Date: Fri Dec 4 22:58:22 2009 +0100
nouveau: avoid running out
- 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
.
Keith
From: Maarten Maathuis [madman2...@gmail.com]
Sent: Friday, December 11, 2009 4:41 PM
To: Keith Whitwell
Cc: mesa3d-dev@lists.sourceforge.net
Subject: Re: [Mesa3d-dev] [gallium] what is wrong when i need FLUSH_CURRENT
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
On Tue, Dec 8, 2009 at 7:21 PM, Maarten Maathuis madman2...@gmail.com wrote:
It was TexSubImage, and i added FLUSH_CURRENT after
ASSERT_OUTSIDE_BEGIN_END_AND_FLUSH and it seems to fix the issue. The
difference between the two is that one triggers on NeedFlush
FLUSH_UPDATE_CURRENT
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 Thu, Dec 10, 2009 at 5:24 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Thu, 10 Dec 2009, Xavier Bestel wrote:
Last time they were asked that, they wanted to be free of changing their
kernel/userspace interface before upstreaming.
I've heard all the excuses. If it isn't
.
On Tue, Dec 8, 2009 at 3:36 PM, Keith Whitwell kei...@vmware.com wrote:
On Fri, 2009-12-04 at 13:51 -0800, Maarten Maathuis wrote:
I recently noticed a regression in the nv50 gallium driver, with a few
hours of bisecting i figured out i need FLUSH_CURRENT called
unconditionally
You might still want to set to deferred pixmap to NULL if it currently
is this pixmap.
2009/12/8 Michel Dänzer mic...@daenzer.net:
From: Michel Dänzer daen...@vmware.com
* Better detection of dimension changes.
* Make sure to re-create the system memory copy when the pixmap dimensions
Acked-by: Maarten Maathuis madman2...@gmail.com
2009/12/8 Michel Dänzer mic...@daenzer.net:
From: Michel Dänzer daen...@vmware.com
* Better detection of dimension changes.
* Make sure to re-create the system memory copy when the pixmap dimensions
change (e.g. the screen pixmap on screen
Acked-by: Maarten Maathuis madman2...@gmail.com
2009/12/8 Michel Dänzer mic...@daenzer.net:
From: Michel Dänzer daen...@vmware.com
Only return TRUE if the GPU copy is being accessed, and preserve the return
value on repeated / nested calls for the same pixmap.
exaPrepareAccessReg_mixed
On Fri, Dec 4, 2009 at 10:51 PM, Maarten Maathuis madman2...@gmail.com wrote:
I recently noticed a regression in the nv50 gallium driver, with a few
hours of bisecting i figured out i need FLUSH_CURRENT called
unconditionally in st_teximage_flush_before_map(). Otherwise in
warzone2100 several
this to the wrong address.
Dee Sharpe
Sent from my iPhone
Begin forwarded message:
From: Dee Sharpe demetrioussha...@netscape.net
Date: December 4, 2009 4:15:35 PM CST
To: Maarten Maathuis madman2...@gmail.com
Subject: GEM or TTM
For porting DRM, which is the correct one to port to a new platform
- 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 ++
2009/12/5 Michel Dänzer mic...@daenzer.net:
On Fri, 2009-12-04 at 20:28 +0100, Maarten Maathuis wrote:
2009/12/4 Michel Dänzer mic...@daenzer.net:
+ /* Need to re-create system copy if there's also a GPU copy */
These criteria can also be true for a pixmap without gpu copy.
Hmm
2009/12/5 Michel Dänzer mic...@daenzer.net:
On Sat, 2009-12-05 at 17:59 +0100, Maarten Maathuis wrote:
2009/12/5 Michel Dänzer mic...@daenzer.net:
On Fri, 2009-12-04 at 20:28 +0100, Maarten Maathuis wrote:
2009/12/4 Michel Dänzer mic...@daenzer.net:
+ if (pExaPixmap-pDamage
I recently noticed a regression in the nv50 gallium driver, with a few
hours of bisecting i figured out i need FLUSH_CURRENT called
unconditionally in st_teximage_flush_before_map(). Otherwise in
warzone2100 several small textures (glyphs) go missing. Does this make
any sense or perhaps provide a
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
2009/12/4 Michel Dänzer mic...@daenzer.net:
From: Michel Dänzer daen...@vmware.com
* Better detection of dimension changes.
* Make sure to re-create the system memory copy when the pixmap dimensions
change (e.g. the screen pixmap on screen resize).
* Clear the valid regions.
- When they have a gpu copy ofcource.
- Use the presence of a cpu copy as a hint to fall back instead of UTS'ing in
exaHWCopyNtoN.
Signed-off-by: Maarten Maathuis madman2...@gmail.com
Acked-by: Michel Dänzer mic...@daenzer.net
---
exa/exa_accel.c |6 ++
exa
Signed-off-by: Maarten Maathuis madman2...@gmail.com
Acked-by: Michel Dänzer mic...@daenzer.net
---
exa/exa_migration_mixed.c | 13 +
1 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/exa/exa_migration_mixed.c b/exa/exa_migration_mixed.c
index a7fdf63..9587ea2 100644
- When they have a gpu copy ofcource.
- Use the presence of a cpu copy as a hint to fall back instead of UTS'ing in
exaHWCopyNtoN.
Signed-off-by: Maarten Maathuis madman2...@gmail.com
Acked-by: Michel Dänzer mic...@daenzer.net
---
exa/exa_accel.c |6 ++
exa
This patch is ready for xserver upstream.
Maarten.
-- Forwarded message --
From: Maarten Maathuis madman2...@gmail.com
Date: Thu, Dec 3, 2009 at 8:58 PM
Subject: [PATCH 2/2] exa/mixed: pixmaps that succeed prepare access
have no need for a cpu copy
To: xorg-de
2009/12/2 Michel Dänzer mic...@daenzer.net:
On Wed, 2009-12-02 at 08:42 +0100, Michel Dänzer wrote:
On Wed, 2009-12-02 at 00:16 +0100, Maarten Maathuis wrote:
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
exa/exa_migration_mixed.c | 6 +-
1 files changed, 1 insertions
- When they have a gpu copy ofcource.
- Use the presence of a cpu copy as a hint to fall back instead of UTS'ing in
exaHWCopyNtoN.
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
exa/exa_accel.c |8 ++--
exa/exa_migration_mixed.c | 19 ++-
2 files
This reverts commit 99d88ef69d5f7dbf99ca605eceb92f42230a89f4.
- Some pixmaps under classic have a sys_pitch which is 0, no idea why. This is
causing rendering corruption.
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
exa/exa.c | 11 ++-
exa
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
exa/exa_migration_mixed.c |6 +-
1 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/exa/exa_migration_mixed.c b/exa/exa_migration_mixed.c
index a7fdf63..36afc86 100644
--- a/exa/exa_migration_mixed.c
+++ b/exa
- Drivers using wfb don't like unneeded cpu fallbacks, allow them to signal
this.
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
exa/exa.h |6 ++
exa/exa_accel.c |6 --
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/exa/exa.h b/exa/exa.h
index
the harsh reality that stems from the stalemate that the previous
development model caused. No amount of complaining is going to change
the fact that some people don't care about bsd.
Sincerely,
Maarten Maathuis.
--
Let
damage and (w)fb) have been removed.
Signed-off-by: Maarten Maathuis madman2...@gmail.com
Acked-by: Michel Dänzer mic...@daenzer.net
---
exa/exa.c | 145 -
exa/exa_accel.c | 40 +++
exa/exa_classic.c |8 +++
exa
- Setting pitch before exaCopyDirty* is not needed.
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
exa/exa.c | 11 +--
exa/exa_migration_mixed.c | 11 +--
2 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/exa/exa.c b/exa/exa.c
index
damage and (w)fb) have been removed.
Signed-off-by: Maarten Maathuis madman2...@gmail.com
Acked-by: Michel Dänzer mic...@daenzer.net
---
exa/exa.c | 145 -
exa/exa_accel.c | 40 +++
exa/exa_classic.c |8 +++
exa
- Fixup some variable names as well.
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
exa/exa.c | 30 +++---
exa/exa.h |6 +++---
exa/exa_accel.c | 10 +-
exa/exa_classic.c | 14
This reverts commit d4fc245115eb2cb323e06a82f9dd52518d9b6a16.
- This is causing crashes/problems for some.
---
exa/exa_migration_mixed.c | 21 -
1 files changed, 8 insertions(+), 13 deletions(-)
diff --git a/exa/exa_migration_mixed.c b/exa/exa_migration_mixed.c
index
- When the driver handles the prepare access no copying is needed.
- Delayed pixmap creation should be fine, because it's handled by the
first prepare access, but the exaPixmapIsOffscreen check in finish access
will return FALSE without a driver pixmap.
Signed-off-by: Maarten Maathuis madman2
Signed-off-by: Maarten Maathuis madman2...@gmail.com
Acked-by: Michel Dänzer mic...@daenzer.net
---
exa/exa_migration_mixed.c | 21 +
1 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/exa/exa_migration_mixed.c b/exa/exa_migration_mixed.c
index ea6f878..121a4ad
damage and (w)fb) have been removed.
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
exa/exa.c | 145 -
exa/exa_accel.c | 40 +++
exa/exa_classic.c |8 +++
exa/exa_driver.c |8 +++
exa/exa_mixed.c |8
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
exa/exa.c | 24
exa/exa.h |6 +++---
exa/exa_accel.c | 10 +-
exa/exa_classic.c |2 +-
exa/exa_driver.c|2 +-
exa
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
exa/exa.c |8
exa/exa_classic.c |4 ++--
exa/exa_driver.c|9 +
exa/exa_glyphs.c|8
exa/exa_migration_classic.c | 14 +++---
exa
damage and (w)fb) have been removed.
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
exa/exa.c | 145 -
exa/exa_accel.c | 40 +++
exa/exa_classic.c |8 +++
exa/exa_driver.c |8 +++
exa/exa_mixed.c |8
2009/11/14 Maarten Maathuis madman2...@gmail.com:
2009/11/14 Michel Dänzer mic...@daenzer.net:
On Fri, 2009-11-13 at 21:49 +0100, Maarten Maathuis wrote:
- Pixmaps that are created during a fallback are automatically prepared
access.
- During the fallback accelerated ops are blocked
- When the driver handles the prepare access no copying is needed.
- Delayed pixmap creation should be fine, because it's handled by the
first prepare access, but the exaPixmapIsOffscreen check in finish access
will return FALSE without a driver pixmap.
Signed-off-by: Maarten Maathuis madman2
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
exa/exa_migration_mixed.c | 21 +
1 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/exa/exa_migration_mixed.c b/exa/exa_migration_mixed.c
index ea6f878..121a4ad 100644
--- a/exa/exa_migration_mixed.c
2009/11/12 Michel Dänzer mic...@daenzer.net:
On Sat, 2009-11-07 at 13:32 +0100, Maarten Maathuis wrote:
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
exa/exa_migration_mixed.c | 6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/exa/exa_migration_mixed.c
2009/11/12 Michel Dänzer mic...@daenzer.net:
On Thu, 2009-11-12 at 20:30 +0100, Maarten Maathuis wrote:
2009/11/12 Michel Dänzer mic...@daenzer.net:
On Sat, 2009-11-07 at 13:32 +0100, Maarten Maathuis wrote:
- Fix the system that is required for it to actually work.
- The comment near
exaPixmapIsOffscreen() is related to having a driver/vram/whatever pixmap
pExaPixmap-offscreen says if the offscreen pixmap is the current
choice of rendering to
The naming came from classic exa. Some better names might be:
exaPixmapHasOffscreen() and
301 - 400 of 858 matches
Mail list logo
