Re: [Mesa3d-dev] [PATCH] radeon: Add protection against recursive DRM locking.
yes. Seems like I can't use git correctly. :(
Now it should be fixed patch that does locking correctly. That means
checking for greater than 1 when trying to lock and checking for greater
than 0 when trying to unlock.
On Mon, Aug 3, 2009 at 1:11 AM, Alex Deucher wrote:
> On Sun, Aug 2, 2009 at 1:58 PM, Pauli Nieminen wrote:
> > yes. It was missing the fix because of no git add before git commit
> --amend.
> >
>
> Looks like you attached the same patch :)
>
> > On Sun, Aug 2, 2009 at 8:35 PM, Alex Deucher
> wrote:
> >>
> >> On Sun, Aug 2, 2009 at 12:16 PM, Pauli Nieminen
> wrote:
> >> > Sorry for leaving bad patch just before leaving for weekend trip. I
> have
> >> > now
> >> > fixed that bugs that I created when trying to change logic in hurry.
> >> >
> >>
> >> Unforunately, running any 3d app with this patch seems to hang the gpu.
> >>
> >> Alex
> >>
> >> > On Fri, Jul 31, 2009 at 6:44 PM, Alex Deucher
> >> > wrote:
> >> >>
> >> >> On Fri, Jul 31, 2009 at 7:18 AM, Pauli Nieminen
> >> >> wrote:
> >> >> > Hi.
> >> >> >
> >> >> > Some clean up to code so it is better thread safety even tough it
> is
> >> >> > not
> >> >> > 100% without locking or atomic operations. (Now it works same way
> as
> >> >> > intel
> >> >> > does recursion prevention)
> >> >> > Another adittion is to make debug output to check if DEBUG_SANITY
> is
> >> >> > set.
> >> >> > Whole lock debugging is compiled out if there is NDEBUG set so
> there
> >> >> > wouldn't be need of passing debug parameters in release version.
> >> >>
> >> >> Can you fix this up? It's broken at the moment.
> >> >>
> >> >> Alex
> >> >
> >> >
> >
> >
>
From 24574c6905724bbed79ee29718d3b15080a795e8 Mon Sep 17 00:00:00 2001
From: Pauli Nieminen
Date: Thu, 30 Jul 2009 20:17:29 +0300
Subject: [PATCH] radeon: Add protection against recursive DRM locking.
Reference counting protects DRM lock call from recursive locking that would
cause hang. Code also adds optional debugging output for recursive call that
is compiled only if NDEBUG is not defined.
This code is not 100% thread safe because mesa doesn't include increment and
test atomic operation. There is built-in gcc functions but they are only
available from gcc 4.2.
---
.../drivers/dri/radeon/radeon_common_context.c |1 +
.../drivers/dri/radeon/radeon_common_context.h |1 +
src/mesa/drivers/dri/radeon/radeon_lock.c | 53 +++-
src/mesa/drivers/dri/radeon/radeon_lock.h | 12 -
4 files changed, 64 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/radeon/radeon_common_context.c b/src/mesa/drivers/dri/radeon/radeon_common_context.c
index 2a017b5..c19fb70 100644
--- a/src/mesa/drivers/dri/radeon/radeon_common_context.c
+++ b/src/mesa/drivers/dri/radeon/radeon_common_context.c
@@ -211,6 +211,7 @@ GLboolean radeonInitContext(radeonContextPtr radeon,
radeon->dri.screen = sPriv;
radeon->dri.hwContext = driContextPriv->hHWContext;
radeon->dri.hwLock = &sPriv->pSAREA->lock;
+ radeon->dri.hwLockCount = 0;
radeon->dri.fd = sPriv->fd;
radeon->dri.drmMinor = sPriv->drm_version.minor;
diff --git a/src/mesa/drivers/dri/radeon/radeon_common_context.h b/src/mesa/drivers/dri/radeon/radeon_common_context.h
index d7e94a6..f8e1a25 100644
--- a/src/mesa/drivers/dri/radeon/radeon_common_context.h
+++ b/src/mesa/drivers/dri/radeon/radeon_common_context.h
@@ -365,6 +365,7 @@ struct radeon_dri_mirror {
drm_context_t hwContext;
drm_hw_lock_t *hwLock;
+ int hwLockCount;
int fd;
int drmMinor;
};
diff --git a/src/mesa/drivers/dri/radeon/radeon_lock.c b/src/mesa/drivers/dri/radeon/radeon_lock.c
index 2f0ed1c..6294b7e 100644
--- a/src/mesa/drivers/dri/radeon/radeon_lock.c
+++ b/src/mesa/drivers/dri/radeon/radeon_lock.c
@@ -86,8 +86,34 @@ void radeonGetLock(radeonContextPtr rmesa, GLuint flags)
rmesa->vtbl.get_lock(rmesa);
}
-
-void radeon_lock_hardware(radeonContextPtr radeon)
+#ifndef NDEBUG
+struct lock_debug {
+ const char* function;
+ const char* file;
+ int line;
+};
+
+static struct lock_debug ldebug = {0};
+#endif
+
+#if 0
+/** TODO: use atomic operations for reference counting **/
+/** gcc 4.2 has builtin functios for this **/
+#define ATOMIC_INC_AND_FETCH(atomic) __sync_add_and_fetch(&atomic, 1)
+#define ATOMIC_DEC_AND_FETCH(atomic) __sync_sub_and_fetch(&atomic, 1)
+#else
+#define ATOMIC_INC_AND_FETCH(atomic) (++atomic)
+#define ATOMIC_DEC_AND_FETCH(atomic) (--atomic)
+#endif
+
+
+void radeon_lock_hardware(radeonContextPtr radeon
+#ifndef NDEBUG
+ ,const char* function
+ ,const char* file
+ ,const int line
+#endif
+ )
{
char ret = 0;
struct radeon_framebuffer *rfb = NULL;
@@ -102,16 +128,39 @@ void radeon_lock_hardware(radeonContextPtr radeon)
}
if (!radeon->radeonScreen->driScreen->dri2.enabled) {
+ if (ATOMIC_INC_AND_FETCH(radeon->dri.hwLockCount) > 1)
+ {
+#ifndef NDEBUG
+ if ( RADEON_DEBUG & DEBUG_SANITY )
+fprintf(stderr, "*** %d times of recursive call to %s ***\n"
+ "Original call was from %s (fil
Re: [Mesa3d-dev] [PATCH] radeon: Add protection against recursive DRM locking.
On Sun, Aug 2, 2009 at 1:58 PM, Pauli Nieminen wrote: > yes. It was missing the fix because of no git add before git commit --amend. > Looks like you attached the same patch :) > On Sun, Aug 2, 2009 at 8:35 PM, Alex Deucher wrote: >> >> On Sun, Aug 2, 2009 at 12:16 PM, Pauli Nieminen wrote: >> > Sorry for leaving bad patch just before leaving for weekend trip. I have >> > now >> > fixed that bugs that I created when trying to change logic in hurry. >> > >> >> Unforunately, running any 3d app with this patch seems to hang the gpu. >> >> Alex >> >> > On Fri, Jul 31, 2009 at 6:44 PM, Alex Deucher >> > wrote: >> >> >> >> On Fri, Jul 31, 2009 at 7:18 AM, Pauli Nieminen >> >> wrote: >> >> > Hi. >> >> > >> >> > Some clean up to code so it is better thread safety even tough it is >> >> > not >> >> > 100% without locking or atomic operations. (Now it works same way as >> >> > intel >> >> > does recursion prevention) >> >> > Another adittion is to make debug output to check if DEBUG_SANITY is >> >> > set. >> >> > Whole lock debugging is compiled out if there is NDEBUG set so there >> >> > wouldn't be need of passing debug parameters in release version. >> >> >> >> Can you fix this up? It's broken at the moment. >> >> >> >> Alex >> > >> > > > -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 23087] R600 Logic Operations Fix
http://bugs.freedesktop.org/show_bug.cgi?id=23087 Alex Deucher changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Alex Deucher 2009-08-02 15:04:55 PST --- pushed thanks! 562ca4961186954d3abf216bcfb1e835b562b234 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 23087] R600 Logic Operations Fix
http://bugs.freedesktop.org/show_bug.cgi?id=23087 --- Comment #2 from vehem...@verizon.net 2009-08-02 13:31:10 PST --- There is no functional problem with the current R300-R500 code, however it assumes that the hardware values will always be an offset from GL_CLEAR with a bit reversal. Using a switch to translate the values as done for the R600 patch is a cleaner coding approach. The test case used to identify the the R600 (not R300-500) problem was mesa progs samples blendeq. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] radeon: Add protection against recursive DRM locking.
yes. It was missing the fix because of no git add before git commit --amend.
On Sun, Aug 2, 2009 at 8:35 PM, Alex Deucher wrote:
> On Sun, Aug 2, 2009 at 12:16 PM, Pauli Nieminen wrote:
> > Sorry for leaving bad patch just before leaving for weekend trip. I have
> now
> > fixed that bugs that I created when trying to change logic in hurry.
> >
>
> Unforunately, running any 3d app with this patch seems to hang the gpu.
>
> Alex
>
> > On Fri, Jul 31, 2009 at 6:44 PM, Alex Deucher
> wrote:
> >>
> >> On Fri, Jul 31, 2009 at 7:18 AM, Pauli Nieminen
> wrote:
> >> > Hi.
> >> >
> >> > Some clean up to code so it is better thread safety even tough it is
> not
> >> > 100% without locking or atomic operations. (Now it works same way as
> >> > intel
> >> > does recursion prevention)
> >> > Another adittion is to make debug output to check if DEBUG_SANITY is
> >> > set.
> >> > Whole lock debugging is compiled out if there is NDEBUG set so there
> >> > wouldn't be need of passing debug parameters in release version.
> >>
> >> Can you fix this up? It's broken at the moment.
> >>
> >> Alex
> >
> >
>
From 48a1086bb3735e9e7e39a2b887193458569b4fc7 Mon Sep 17 00:00:00 2001
From: Pauli Nieminen
Date: Thu, 30 Jul 2009 20:17:29 +0300
Subject: [PATCH] radeon: Add protection against recursive DRM locking.
Reference counting protects DRM lock call from recursive locking that would
cause hang. Code also adds optional debugging output for recursive call that
is compiled only if NDEBUG is not defined.
This code is not 100% thread safe because mesa doesn't include increment and
test atomic operation. There is built-in gcc functions but they are only
available from gcc 4.2.
---
.../drivers/dri/radeon/radeon_common_context.c |1 +
.../drivers/dri/radeon/radeon_common_context.h |1 +
src/mesa/drivers/dri/radeon/radeon_lock.c | 53 +++-
src/mesa/drivers/dri/radeon/radeon_lock.h | 12 -
4 files changed, 64 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/radeon/radeon_common_context.c b/src/mesa/drivers/dri/radeon/radeon_common_context.c
index 2a017b5..c19fb70 100644
--- a/src/mesa/drivers/dri/radeon/radeon_common_context.c
+++ b/src/mesa/drivers/dri/radeon/radeon_common_context.c
@@ -211,6 +211,7 @@ GLboolean radeonInitContext(radeonContextPtr radeon,
radeon->dri.screen = sPriv;
radeon->dri.hwContext = driContextPriv->hHWContext;
radeon->dri.hwLock = &sPriv->pSAREA->lock;
+ radeon->dri.hwLockCount = 0;
radeon->dri.fd = sPriv->fd;
radeon->dri.drmMinor = sPriv->drm_version.minor;
diff --git a/src/mesa/drivers/dri/radeon/radeon_common_context.h b/src/mesa/drivers/dri/radeon/radeon_common_context.h
index d7e94a6..f8e1a25 100644
--- a/src/mesa/drivers/dri/radeon/radeon_common_context.h
+++ b/src/mesa/drivers/dri/radeon/radeon_common_context.h
@@ -365,6 +365,7 @@ struct radeon_dri_mirror {
drm_context_t hwContext;
drm_hw_lock_t *hwLock;
+ int hwLockCount;
int fd;
int drmMinor;
};
diff --git a/src/mesa/drivers/dri/radeon/radeon_lock.c b/src/mesa/drivers/dri/radeon/radeon_lock.c
index 2f0ed1c..adb9bce 100644
--- a/src/mesa/drivers/dri/radeon/radeon_lock.c
+++ b/src/mesa/drivers/dri/radeon/radeon_lock.c
@@ -86,8 +86,34 @@ void radeonGetLock(radeonContextPtr rmesa, GLuint flags)
rmesa->vtbl.get_lock(rmesa);
}
-
-void radeon_lock_hardware(radeonContextPtr radeon)
+#ifndef NDEBUG
+struct lock_debug {
+ const char* function;
+ const char* file;
+ int line;
+};
+
+static struct lock_debug ldebug = {0};
+#endif
+
+#if 0
+/** TODO: use atomic operations for reference counting **/
+/** gcc 4.2 has builtin functios for this **/
+#define ATOMIC_INC_AND_FETCH(atomic) __sync_add_and_fetch(&atomic, 1)
+#define ATOMIC_DEC_AND_FETCH(atomic) __sync_sub_and_fetch(&atomic, 1)
+#else
+#define ATOMIC_INC_AND_FETCH(atomic) (++atomic)
+#define ATOMIC_DEC_AND_FETCH(atomic) (--atomic)
+#endif
+
+
+void radeon_lock_hardware(radeonContextPtr radeon
+#ifndef NDEBUG
+ ,const char* function
+ ,const char* file
+ ,const int line
+#endif
+ )
{
char ret = 0;
struct radeon_framebuffer *rfb = NULL;
@@ -102,16 +128,39 @@ void radeon_lock_hardware(radeonContextPtr radeon)
}
if (!radeon->radeonScreen->driScreen->dri2.enabled) {
+ if (ATOMIC_INC_AND_FETCH(radeon->dri.hwLockCount) > 0)
+ {
+#ifndef NDEBUG
+ if ( RADEON_DEBUG & DEBUG_SANITY )
+fprintf(stderr, "*** %d times of recursive call to %s ***\n"
+ "Original call was from %s (file: %s line: %d)\n"
+ "Now call is coming from %s (file: %s line: %d)\n"
+ , radeon->dri.hwLockCount, __FUNCTION__
+ , ldebug.function, ldebug.file, ldebug.line
+ , function, file, line
+ );
+#endif
+ return;
+ }
DRM_CAS(radeon->dri.hwLock, radeon->dri.hwContext,
(DRM_LOCK_HELD | radeon->dri.hwContext), ret );
if (ret)
radeonGetLock(radeon, 0);
+#ifndef NDEBUG
+ ldebug.function = function;
+ ldebug.file = file;
+ ldebug.line = line;
+#endif
}
}
void radeon_unlock_hard
Re: [Mesa3d-dev] [PATCH] radeon: Add protection against recursive DRM locking.
On Sun, Aug 2, 2009 at 12:16 PM, Pauli Nieminen wrote: > Sorry for leaving bad patch just before leaving for weekend trip. I have now > fixed that bugs that I created when trying to change logic in hurry. > Unforunately, running any 3d app with this patch seems to hang the gpu. Alex > On Fri, Jul 31, 2009 at 6:44 PM, Alex Deucher wrote: >> >> On Fri, Jul 31, 2009 at 7:18 AM, Pauli Nieminen wrote: >> > Hi. >> > >> > Some clean up to code so it is better thread safety even tough it is not >> > 100% without locking or atomic operations. (Now it works same way as >> > intel >> > does recursion prevention) >> > Another adittion is to make debug output to check if DEBUG_SANITY is >> > set. >> > Whole lock debugging is compiled out if there is NDEBUG set so there >> > wouldn't be need of passing debug parameters in release version. >> >> Can you fix this up? It's broken at the moment. >> >> Alex > > -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] radeon: Add protection against recursive DRM locking.
Sorry for leaving bad patch just before leaving for weekend trip. I have now
fixed that bugs that I created when trying to change logic in hurry.
On Fri, Jul 31, 2009 at 6:44 PM, Alex Deucher wrote:
> On Fri, Jul 31, 2009 at 7:18 AM, Pauli Nieminen wrote:
> > Hi.
> >
> > Some clean up to code so it is better thread safety even tough it is not
> > 100% without locking or atomic operations. (Now it works same way as
> intel
> > does recursion prevention)
> > Another adittion is to make debug output to check if DEBUG_SANITY is set.
> > Whole lock debugging is compiled out if there is NDEBUG set so there
> > wouldn't be need of passing debug parameters in release version.
>
> Can you fix this up? It's broken at the moment.
>
> Alex
>
From 48a1086bb3735e9e7e39a2b887193458569b4fc7 Mon Sep 17 00:00:00 2001
From: Pauli Nieminen
Date: Thu, 30 Jul 2009 20:17:29 +0300
Subject: [PATCH] radeon: Add protection against recursive DRM locking.
Reference counting protects DRM lock call from recursive locking that would
cause hang. Code also adds optional debugging output for recursive call that
is compiled only if NDEBUG is not defined.
This code is not 100% thread safe because mesa doesn't include increment and
test atomic operation. There is built-in gcc functions but they are only
available from gcc 4.2.
---
.../drivers/dri/radeon/radeon_common_context.c |1 +
.../drivers/dri/radeon/radeon_common_context.h |1 +
src/mesa/drivers/dri/radeon/radeon_lock.c | 53 +++-
src/mesa/drivers/dri/radeon/radeon_lock.h | 12 -
4 files changed, 64 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/radeon/radeon_common_context.c b/src/mesa/drivers/dri/radeon/radeon_common_context.c
index 2a017b5..c19fb70 100644
--- a/src/mesa/drivers/dri/radeon/radeon_common_context.c
+++ b/src/mesa/drivers/dri/radeon/radeon_common_context.c
@@ -211,6 +211,7 @@ GLboolean radeonInitContext(radeonContextPtr radeon,
radeon->dri.screen = sPriv;
radeon->dri.hwContext = driContextPriv->hHWContext;
radeon->dri.hwLock = &sPriv->pSAREA->lock;
+ radeon->dri.hwLockCount = 0;
radeon->dri.fd = sPriv->fd;
radeon->dri.drmMinor = sPriv->drm_version.minor;
diff --git a/src/mesa/drivers/dri/radeon/radeon_common_context.h b/src/mesa/drivers/dri/radeon/radeon_common_context.h
index d7e94a6..f8e1a25 100644
--- a/src/mesa/drivers/dri/radeon/radeon_common_context.h
+++ b/src/mesa/drivers/dri/radeon/radeon_common_context.h
@@ -365,6 +365,7 @@ struct radeon_dri_mirror {
drm_context_t hwContext;
drm_hw_lock_t *hwLock;
+ int hwLockCount;
int fd;
int drmMinor;
};
diff --git a/src/mesa/drivers/dri/radeon/radeon_lock.c b/src/mesa/drivers/dri/radeon/radeon_lock.c
index 2f0ed1c..adb9bce 100644
--- a/src/mesa/drivers/dri/radeon/radeon_lock.c
+++ b/src/mesa/drivers/dri/radeon/radeon_lock.c
@@ -86,8 +86,34 @@ void radeonGetLock(radeonContextPtr rmesa, GLuint flags)
rmesa->vtbl.get_lock(rmesa);
}
-
-void radeon_lock_hardware(radeonContextPtr radeon)
+#ifndef NDEBUG
+struct lock_debug {
+ const char* function;
+ const char* file;
+ int line;
+};
+
+static struct lock_debug ldebug = {0};
+#endif
+
+#if 0
+/** TODO: use atomic operations for reference counting **/
+/** gcc 4.2 has builtin functios for this **/
+#define ATOMIC_INC_AND_FETCH(atomic) __sync_add_and_fetch(&atomic, 1)
+#define ATOMIC_DEC_AND_FETCH(atomic) __sync_sub_and_fetch(&atomic, 1)
+#else
+#define ATOMIC_INC_AND_FETCH(atomic) (++atomic)
+#define ATOMIC_DEC_AND_FETCH(atomic) (--atomic)
+#endif
+
+
+void radeon_lock_hardware(radeonContextPtr radeon
+#ifndef NDEBUG
+ ,const char* function
+ ,const char* file
+ ,const int line
+#endif
+ )
{
char ret = 0;
struct radeon_framebuffer *rfb = NULL;
@@ -102,16 +128,39 @@ void radeon_lock_hardware(radeonContextPtr radeon)
}
if (!radeon->radeonScreen->driScreen->dri2.enabled) {
+ if (ATOMIC_INC_AND_FETCH(radeon->dri.hwLockCount) > 0)
+ {
+#ifndef NDEBUG
+ if ( RADEON_DEBUG & DEBUG_SANITY )
+fprintf(stderr, "*** %d times of recursive call to %s ***\n"
+ "Original call was from %s (file: %s line: %d)\n"
+ "Now call is coming from %s (file: %s line: %d)\n"
+ , radeon->dri.hwLockCount, __FUNCTION__
+ , ldebug.function, ldebug.file, ldebug.line
+ , function, file, line
+ );
+#endif
+ return;
+ }
DRM_CAS(radeon->dri.hwLock, radeon->dri.hwContext,
(DRM_LOCK_HELD | radeon->dri.hwContext), ret );
if (ret)
radeonGetLock(radeon, 0);
+#ifndef NDEBUG
+ ldebug.function = function;
+ ldebug.file = file;
+ ldebug.line = line;
+#endif
}
}
void radeon_unlock_hardware(radeonContextPtr radeon)
{
if (!radeon->radeonScreen->driScreen->dri2.enabled) {
+ if (ATOMIC_DEC_AND_FETCH(radeon->dri.hwLockCount) > 0)
+ {
+ return;
+ }
DRM_UNLOCK( radeon->dri.fd,
radeon->dri.hwLock,
radeon->dri.hwContext );
diff --git a/src/mesa/drivers/dri/radeon/radeon_lock.h b/src/mesa/drivers/dri/radeon/radeon_lock.h
in
Re: [Mesa3d-dev] ATI R200 code currently broken in git
This is dri2 problem that I have reported to bugzilla some days ago. It seems like clipping regions are set incorrectly. But I don't know about performance side because I hve had only 200 fps in gears with agp mode and 800 fps with pci mode. (2500-3000 in dri1 mode) But atleast performance haven't regressed for me in dri2.. On Sat, Aug 1, 2009 at 12:30 AM, Roland Scheidegger wrote: > On 31.07.2009 17:36, Terry Barnaby wrote: > > I have just compiled/installed the latest drm/mesa/xf86-video-ati code > from git > > under Fedora 11 on a system with an ATI Technologies Inc RV280 [Radeon > 9200 PRO] > > graphics board. > > > > 2D appears fine. 3D is quite broken. > > > > gxlgears runs showing about 500 frames/sec. However it shows as moving > gears > > for 1 second followed by 5 seconds of still frame, repeated. > > > > blender just shows a really currupted screen with chess board patterns, > > lots of horizontal tearing, half drawn menu's etc ... > > Hmm, I don't see that. I'm using a very old drm/ddx on that box though > so no kms/dri2, and no compositing neither. > > Roland > > > > -- > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus > on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > ___ > Mesa3d-dev mailing list > Mesa3d-dev@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mesa3d-dev > -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 23087] R600 Logic Operations Fix
http://bugs.freedesktop.org/show_bug.cgi?id=23087 --- Comment #1 from Nicolai Hähnle 2009-08-02 08:08:25 PST --- I don't see any problems on R500. At the very least, glean/logicOp passes over here. It's possible that this test doesn't cover everything; in this case, could you please provide a test case which fails today despite glean/logicOp passing? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 23087] New: R600 Logic Operations Fix
http://bugs.freedesktop.org/show_bug.cgi?id=23087 Summary: R600 Logic Operations Fix Product: Mesa Version: unspecified Platform: All OS/Version: FreeBSD Status: NEW Severity: normal Priority: medium Component: Mesa core AssignedTo: mesa3d-dev@lists.sourceforge.net ReportedBy: vehem...@verizon.net Created an attachment (id=28256) --> (http://bugs.freedesktop.org/attachment.cgi?id=28256) r600 blend logic operations patch The r600 logic operation translation code was copied from r300, however the translated value is incorrect (based on testing). This patch corrects the translation and has been tested using the mesa blendeq demo. Note that a switch is used instead of depending on logicop being particular set of values. A similar change should be made to the R300 code as well. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
