Re: [Dri-devel] radeon 8500/64MB 3D stuttering (texture?); mode switching problems in wolfenstein.
On 2003.02.02 19:29 Keith Whitwell wrote: Pawel Salek wrote: No. Probably the most helpful thing you can do is binary search to try find the change which introduced your problem. So try a date half-way between now september, check out that version see if the problem is there, etc. I did the testing and pretty early realized the problem is somewhere else. I have 256MB memory and before, wolfenstein fit just fine in this space (230-240MB, IIRC). Now, when I run kernel 2.4.20-2.24 + glibc-2.3.1-38 (the patches as in RH's phoebe2), the process size is about 300MB, or even slighly more - and the box starts swapping. I wonder whether it is a memory leak, or something else has changed. In any case, I consider it unlikely DRI problem. If I have some more info, I will post it here. /pawel --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] A question, about Rage128 and news in DRI
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 So i have tryed. Updated to last patch (2186). It crashes... i tryed with: 1) last snapshot found on dri.sf.net 2) plain XFree86 4.2.0 tree recompiled but always crashes. (i have a Rage128) Alle 13:45, lunedì 3 febbraio 2003, Stefan Lange ha scritto: Willy Gardiol wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, few days ago i was trying to play ut2003 on my Rage128 but, off course, with no luck (s3c missing), is this feature one of the new things going to be implemented in the near future? VIA/S3 has been contacted several times already, whether they'll allow the integration of S3TC-support in the DRI. Unfortunately they never answered. So it's not very likely that you'll S3TC in DRI in the near future. Things might change some time, if you're lucky, but I doubt it. If you update ut2k3 to the latest version you'll be able to play it even without S3TC-support, however. But I seriously doubt that you can play ut2k3 with a r128 anyway... regards, Stefan Thnaks, and good work. - -- ! Willy Gardiol - [EMAIL PROTECTED] goemon.polito.it/~gardiol Use linux for your freedom. Non ho parole, fratelli. Quaranta paesi bambini hanno attaccato un asilo e la chiamano guerra. Gli eserciti più potenti del mondo hanno attaccato il più straccione. Jack Folla ( 8/10/2001 ) -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+P7eEQ9qolN/zUk4RApSfAKCj0dJSKpdMvnjD0YM7KW11v++BqQCfVEq1 d8gMiCtvNfqawUo88TbEpYo= =fXg8 -END PGP SIGNATURE- --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [PATCH] texmem-0-0-1 branch
Attached is the patch with the modifications you suggested.
--Leif
On Mon, 3 Feb 2003, Ian Romanick wrote:
Leif Delgass wrote:
It this looks OK, I will apply it to the branch.
I've poked around with the patch, and it looks good. There are only two
things that I would change. There should probably be a comment in
texmem.h that explains the double-duty that tObj does. I think the
meaning of t-tObj == NULL is important to document.
I would also probably change printLocalLRU and printGlobalLRU to take a
pointer to __FUNCTION__ and log that in their printfs. I remember
making that change to the version in the r100 driver when I was first
mucking with the texmem stuff. That proved very useful when I was
trying to figure out how it all worked. :)
Nice work!
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
--
Leif Delgass
http://www.retinalburn.net
Index: lib/GL/mesa/src/drv/common/texmem.c
===
RCS file: /cvsroot/dri/xc/xc/lib/GL/mesa/src/drv/common/Attic/texmem.c,v
retrieving revision 1.1.2.8
diff -u -r1.1.2.8 texmem.c
--- lib/GL/mesa/src/drv/common/texmem.c 27 Jan 2003 23:43:31 - 1.1.2.8
+++ lib/GL/mesa/src/drv/common/texmem.c 4 Feb 2003 16:46:53 -
@@ -119,12 +119,10 @@
static void resetGlobalLRU( driTexHeap * heap )
{
- driTexRegion * list = heap-global_regions;
+ drmTextureRegionPtr list = heap-global_regions;
unsigned sz = 1U heap-logGranularity;
unsigned i;
- heap-local_age = ++heap-global_age[0];
-
for (i = 0 ; (i+1) * sz = heap-size ; i++) {
list[i].prev = i-1;
list[i].next = i+1;
@@ -140,7 +138,76 @@
heap-global_age[0] = 0;
}
+/**
+ * Print out debugging information about the local texture LRU.
+ *
+ * \param heap Texture heap to be printed
+ */
+static void printLocalLRU( driTexHeap * heap, const char *callername )
+{
+ driTextureObject *t;
+ unsigned sz = 1U heap-logGranularity;
+ fprintf( stderr, %s in %s:\nLocal LRU, heap %d:\n,
+ __FUNCTION__, callername, heap-heapId );
+
+ foreach ( t, heap-texture_objects ) {
+ if (!t-memBlock)
+continue;
+ if (!t-tObj) {
+fprintf( stderr, Placeholder (%p) %d at 0x%x sz 0x%x\n,
+ t,
+ t-memBlock-ofs / sz,
+ t-memBlock-ofs,
+ t-memBlock-size );
+ } else {
+fprintf( stderr, Texture (%p) at 0x%x sz 0x%x\n,
+ t,
+ t-memBlock-ofs,
+ t-memBlock-size );
+ }
+ }
+ foreach ( t, heap-swapped_objects ) {
+ if (!t-tObj) {
+fprintf( stderr, Swapped Placeholder (%p)\n, t );
+ } else {
+fprintf( stderr, Swapped Texture (%p)\n, t );
+ }
+ }
+
+ fprintf( stderr, \n );
+}
+
+/**
+ * Print out debugging information about the global texture LRU.
+ *
+ * \param heap Texture heap to be printed
+ */
+static void printGlobalLRU( driTexHeap * heap, const char *callername )
+{
+ drmTextureRegionPtr list = heap-global_regions;
+ int i, j;
+
+ fprintf( stderr, %s in %s:\nGlobal LRU, heap %d list %p:\n,
+ __FUNCTION__, callername, heap-heapId, list );
+
+ for ( i = 0, j = heap-nrRegions ; i heap-nrRegions ; i++ ) {
+ fprintf( stderr, list[%d] age %d next %d prev %d in_use %d\n,
+ j, list[j].age, list[j].next, list[j].prev, list[j].in_use );
+ j = list[j].next;
+ if ( j == heap-nrRegions ) break;
+ }
+
+ if ( j != heap-nrRegions ) {
+ fprintf( stderr, Loop detected in global LRU\n );
+ for ( i = 0 ; i heap-nrRegions ; i++ ) {
+fprintf( stderr, list[%d] age %d next %d prev %d in_use %d\n,
+ i, list[i].age, list[i].next, list[i].prev, list[i].in_use );
+ }
+ }
+
+ fprintf( stderr, \n );
+}
/**
@@ -152,7 +219,7 @@
void driUpdateTextureLRU( driTextureObject * t )
{
driTexHeap * heap;
-driTexRegion * list;
+drmTextureRegionPtr list;
unsigned shift;
unsigned start;
unsigned end;
@@ -194,6 +261,12 @@
list[(unsigned)list[heap-nrRegions].next].prev = i;
list[heap-nrRegions].next = i;
}
+
+ if ( 0 ) {
+ printGlobalLRU( heap, __FUNCTION__ );
+ printLocalLRU( heap, __FUNCTION__ );
+ }
+
}
}
@@ -326,7 +399,13 @@
}
else
{
- driDestroyTextureObject( t );
+ if ( in_use
+offset == t-memBlock-ofs size ==
[Dri-devel] [patch] mtx_destroy() for FreeBSD 5.0/-current
Hi
The drm code uses 'struct mtx' as DRM_SPINTYPE on FreeBSD 5.x. The
kernel expects such mutices to be freed after use by calling
mtx_destroy(), which the current code fails to do. Quitting X and
restarting it thus results in this kernel panic:
%%
[...]
panic: mutex vblsig 0xc65fa234 already initialized
cpuid = 1; lapic.id = 0100
boot() called on cpu#1
[...]
#12 0xc02003e7 in panic () at /freebsd/current/src/sys/kern/kern_shutdown.c:531
#13 0xc01f714f in mtx_init (m=0xc65fa234, name=0xc67d652c vblsig, type=0x0,
opts=0) at /freebsd/current/src/sys/kern/kern_mutex.c:914
#14 0xc67cb50f in ?? ()
#15 0xc67cb7ef in ?? ()
#16 0xc67ccd0e in ?? ()
#17 0xc01c8a0e in spec_ioctl (ap=0xc65fa000)
at /freebsd/current/src/sys/fs/specfs/spec_vnops.c:349
[...]
%%
The attached patch does these things:
- Create a new macro DRM_SPINDESTROY which releases the lock on FreeBSD
5.x by calling mtx_destroy(), on 4.x and NetBSD it does nothing. I
also removed the trailing ';' from the DRM_SPINUNLOCK macro.
- Move the lock creation for getmagic() into the attach routing and make
the mutex a member of drm_device (otherwise, the static lock could not
be released). The vbl_lock which caused my panic is also created in
attach().
- Create mem_cleanup() as counterpart to mem_init(). Mem_clean() just
releases DRM(mem_lock).
- Add code to release all locks in the detach function. The waitlist
mutex is released in waitlist_destroy().
- Fix an occurence of p-p_pid, which doesn't compile on FreeBSD 5.x
because p is a struct thread, not a struct proc.
Regards,
Stefan Farfeleder
Index: drmP.h
===
RCS file:
/cvsroot/dri/xc/xc/programs/Xserver/hw/xfree86/os-support/bsd/drm/kernel/drmP.h,v
retrieving revision 1.11
diff -c -r1.11 drmP.h
*** drmP.h 6 Dec 2002 02:27:30 - 1.11
--- drmP.h 4 Feb 2003 17:10:58 -
***
*** 419,424
--- 419,425
/* Locks */
DRM_SPINTYPE count_lock; /* For inuse, open_count, buf_use */
+ DRM_SPINTYPE getmagic_lock;/* For the getmagic ioctl */
struct lock dev_lock; /* For others */
/* Usage Counters */
int open_count; /* Outstanding files open */
***
*** 530,535
--- 531,537
/* Memory management support (drm_memory.h) */
extern voidDRM(mem_init)(void);
+ extern voidDRM(mem_cleanup)(void);
extern void*DRM(alloc)(size_t size, int area);
extern void*DRM(realloc)(void *oldpt, size_t oldsize, size_t size,
int area);
Index: drm_auth.h
===
RCS file:
/cvsroot/dri/xc/xc/programs/Xserver/hw/xfree86/os-support/bsd/drm/kernel/drm_auth.h,v
retrieving revision 1.3
diff -c -r1.3 drm_auth.h
*** drm_auth.h 5 Jul 2002 08:31:07 - 1.3
--- drm_auth.h 4 Feb 2003 17:10:58 -
***
*** 116,140
{
static drm_magic_t sequence = 0;
drm_auth_t auth;
- static DRM_SPINTYPE lock;
- static int first = 1;
DRM_DEVICE;
DRM_PRIV;
- if (first) {
- DRM_SPININIT(lock, drm getmagic);
- first = 0;
- }
-
/* Find unique magic */
if (priv-magic) {
auth.magic = priv-magic;
} else {
do {
! DRM_SPINLOCK(lock);
if (!sequence) ++sequence; /* reserve 0 */
auth.magic = sequence++;
! DRM_SPINUNLOCK(lock);
} while (DRM(find_file)(dev, auth.magic));
priv-magic = auth.magic;
DRM(add_magic)(dev, priv, auth.magic);
--- 116,133
{
static drm_magic_t sequence = 0;
drm_auth_t auth;
DRM_DEVICE;
DRM_PRIV;
/* Find unique magic */
if (priv-magic) {
auth.magic = priv-magic;
} else {
do {
! DRM_SPINLOCK(dev-getmagic_lock);
if (!sequence) ++sequence; /* reserve 0 */
auth.magic = sequence++;
! DRM_SPINUNLOCK(dev-getmagic_lock);
} while (DRM(find_file)(dev, auth.magic));
priv-magic = auth.magic;
DRM(add_magic)(dev, priv, auth.magic);
Index: drm_dma.h
===
RCS file:
/cvsroot/dri/xc/xc/programs/Xserver/hw/xfree86/os-support/bsd/drm/kernel/drm_dma.h,v
retrieving revision 1.10
diff -c -r1.10 drm_dma.h
*** drm_dma.h 2 Feb 2003 03:06:47 - 1.10
--- drm_dma.h 4 Feb 2003 17:11:01 -
Re: [Dri-devel] Radeon PCI Fix
On Mon, 2003-02-03 at 18:09, Benjamin Herrenschmidt wrote:
On Mon, 2003-02-03 at 17:05, Michel Dänzer wrote:
On Mon, 2003-02-03 at 17:34, Alan Cox wrote:
On Mon, 2003-02-03 at 15:02, Keith Whitwell wrote:
-#define COMMIT_RING() do { \
- RADEON_WRITE( RADEON_CP_RB_WPTR, dev_priv-ring.tail ); \
+#define COMMIT_RING() do { \
+ /* read from PCI bus to ensure correct posting */ \
+ RADEON_READ( RADEON_CP_RB_WPTR ); \
+ RADEON_WRITE( RADEON_CP_RB_WPTR, dev_priv-ring.tail ); \
+ RADEON_READ( RADEON_CP_RB_WPTR ); \
} while (0)
Ouch. Put a conditional around that at least, so that not everybody suffers...
PCI posting applies to all platforms. However I'm trying to understand what this
is trying to do. The final read has an effect in that it ensures that the WPTR is
written not left posted for an undefined time. What does the previous one
achieve.
Is there some kind of synchronization requirement against the GART/main memory ?
That's my understanding, we need to make sure the chip reads from the
ring what we wrote to it.
Well... You are asking for trouble ;)
The problem is that the behaviour will be pretty much HW implementation
dependant.
In the AGP case, the ring is mapped uncacheable. So your card and the
ring are typically on the same memory type from the CPU, that helps.
Though I would still make sure the correct bus path is flushed by doing
that first read from the ring and not from the card.
In the PCI case, the ring is mapped cacheable in normal memory and you
rely on the PCI cache coherency (snooping). That means that you have a
new problem which is to synchronize writes to cacheable memory (the
ring) with write to non cacheable MMIO space (the card). At least on
PPC, I don't think anything but a full sync instruction will acheive
that, so you'd rather add an mb(). And do the read from memory (actually
cache), not the card.
After various tests, it looks like all of this is indeed necessary even
with AGP. As an example, the Cube used to crash after a couple x11perf
tests at 1x, now it's passed several complete x11perf runs at 4x with
fast writes.
And there's even more: newer compilers seem to optimize away some of the
reads with strict aliasing. I thought I'd steal some code from the
kernel to detect if the compiler supports -fno-strict-aliasing, but it
looks like it just uses that unconditionally. We probably want to do the
same for the DRM at least? AFAIR it's been supported since early 2.95.
--
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member / CS student, Free Software enthusiast
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon PCI Fix
On Die, 2003-02-04 at 19:06, Michel Dänzer wrote: After various tests, it looks like all of this is indeed necessary even with AGP. Also, I think at least the r128 driver could use the same treatment, but we probably want to split COMMIT_RING() off ADVANCE_RING() as well for that, and I'm not sure rushing that in for 4.3.0 is a good idea. Opinions, also for the other drivers? -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon PCI Fix
Michel Dänzer wrote: On Die, 2003-02-04 at 19:06, Michel Dänzer wrote: After various tests, it looks like all of this is indeed necessary even with AGP. Also, I think at least the r128 driver could use the same treatment, but we probably want to split COMMIT_RING() off ADVANCE_RING() as well for that, and I'm not sure rushing that in for 4.3.0 is a good idea. Opinions, also for the other drivers? The r128 probably still has the mb() in place at least. Keith --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon PCI Fix
On Die, 2003-02-04 at 19:36, Keith Whitwell wrote: Michel Dänzer wrote: On Die, 2003-02-04 at 19:06, Michel Dänzer wrote: After various tests, it looks like all of this is indeed necessary even with AGP. Also, I think at least the r128 driver could use the same treatment, but we probably want to split COMMIT_RING() off ADVANCE_RING() as well for that, and I'm not sure rushing that in for 4.3.0 is a good idea. Opinions, also for the other drivers? The r128 probably still has the mb() in place at least. Yeah, maybe that avoids the worst problems, but it definitely wasn't enough for Chris. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Mesa3d-dev] Is there any verification tests for OpenGL?
Alexandr Andreev wrote: Is there any verification tests for OpenGL (like xsuite for Xlib)? It looks like this is not a big problem to test the performance but what about verification? Can such tests exist in principle? The OpenGL ARB has a test suite called conform, but it is not publicly available. The open-source test suite is Glean. http://glean.sf.net/. Both glean and conform have fallen a bit behind the times. Writing some new glean tests (and updating some old ones) would be a great project for someone to tackle. :) --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon PCI Fix
Michel Dänzer wrote: On Die, 2003-02-04 at 19:36, Keith Whitwell wrote: Michel Dänzer wrote: On Die, 2003-02-04 at 19:06, Michel Dänzer wrote: After various tests, it looks like all of this is indeed necessary even with AGP. Also, I think at least the r128 driver could use the same treatment, but we probably want to split COMMIT_RING() off ADVANCE_RING() as well for that, and I'm not sure rushing that in for 4.3.0 is a good idea. Opinions, also for the other drivers? The r128 probably still has the mb() in place at least. Yeah, maybe that avoids the worst problems, but it definitely wasn't enough for Chris. Well, I'm all for avoiding crashes. This probably affects every card in some way or another. Keith --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Bug in compilation?
Arkadi Shishlov wrote: The DRI tree no longer contains all the X stuff it needs (hasn't for a long time, actually) to build but instead relies on it to be installed on the system. There is a small glitch with current DRI compilation setup. If ProjectRoot in (otherwise default) host.def is set to something other than /usr/X11R6, for example: #define ProjectRoot /home/arkadi/opt/X11R6-DRI-mesa-4-0-4-branch Why not just go into /home/arkadi/opt/X11R6-DRI-mesa-4-0-4-branch and do a lndir /usr/X11R6 make World fails because X server linking process asks for some static libraries using absolute patch. I don't have a log file right now, but I'm sure the libraries are libXdmcp.a and libXau.a. arkadi. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Mesa3d-dev] Is there any verification tests for OpenGL?
On Tue, Feb 04, 2003 at 10:44:45AM -0800, Ian Romanick wrote: | The OpenGL ARB has a test suite called conform, but it is not | publicly available. The open-source test suite is Glean. | http://glean.sf.net/. Both glean and conform have fallen a bit behind | the times. Writing some new glean tests (and updating some old ones) | would be a great project for someone to tackle. :) Yes. I'm happy to help anyone who'd like to add new tests to glean. My hope when starting the project was that people would contribute tests to check the features that *they* felt were important. A truly comprehensive OpenGL test suite is a huge project, but a test suite that targets just the features and performance that aren't getting enough coverage in other ways is a very reasonable project for the open-source community. Allen --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon PCI Fix
On 4 Feb 2003, Michel Dänzer wrote: On Die, 2003-02-04 at 19:36, Keith Whitwell wrote: Michel Dänzer wrote: On Die, 2003-02-04 at 19:06, Michel Dänzer wrote: After various tests, it looks like all of this is indeed necessary even with AGP. Also, I think at least the r128 driver could use the same treatment, but we probably want to split COMMIT_RING() off ADVANCE_RING() as well for that, and I'm not sure rushing that in for 4.3.0 is a good idea. Opinions, also for the other drivers? The r128 probably still has the mb() in place at least. Yeah, maybe that avoids the worst problems, but it definitely wasn't enough for Chris. At least with r128 PCI, I have seen lockups happen after a period of days. When that happens, I see a sort of greenish bar of corrupted framebuffer at the top of the screen. Usually killing the server with Ctl-Alt-Backspace works and I can restart X without a problem. I've also seen that with same behavior with AGP Radeon 7500 from time to time. -- Leif Delgass http://www.retinalburn.net --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon PCI Fix
On Die, 2003-02-04 at 20:09, Leif Delgass wrote: On 4 Feb 2003, Michel Dänzer wrote: On Die, 2003-02-04 at 19:36, Keith Whitwell wrote: Michel Dänzer wrote: On Die, 2003-02-04 at 19:06, Michel Dänzer wrote: After various tests, it looks like all of this is indeed necessary even with AGP. Also, I think at least the r128 driver could use the same treatment, but we probably want to split COMMIT_RING() off ADVANCE_RING() as well for that, and I'm not sure rushing that in for 4.3.0 is a good idea. Opinions, also for the other drivers? The r128 probably still has the mb() in place at least. Yeah, maybe that avoids the worst problems, but it definitely wasn't enough for Chris. At least with r128 PCI, I have seen lockups happen after a period of days. When that happens, I see a sort of greenish bar of corrupted framebuffer at the top of the screen. Usually killing the server with Ctl-Alt-Backspace works and I can restart X without a problem. I've also seen that with same behavior with AGP Radeon 7500 from time to time. It will be very interesting to see if this change helps for those. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [patch] mtx_destroy() for FreeBSD 5.0/-current
On Tue, 2003-02-04 at 10:04, Stefan Farfeleder wrote: Hi The drm code uses 'struct mtx' as DRM_SPINTYPE on FreeBSD 5.x. The kernel expects such mutices to be freed after use by calling mtx_destroy(), which the current code fails to do. Quitting X and restarting it thus results in this kernel panic ... The attached patch does these things: - Create a new macro DRM_SPINDESTROY which releases the lock on FreeBSD 5.x by calling mtx_destroy(), on 4.x and NetBSD it does nothing. I also removed the trailing ';' from the DRM_SPINUNLOCK macro. - Move the lock creation for getmagic() into the attach routing and make the mutex a member of drm_device (otherwise, the static lock could not be released). The vbl_lock which caused my panic is also created in attach(). - Create mem_cleanup() as counterpart to mem_init(). Mem_clean() just releases DRM(mem_lock). - Add code to release all locks in the detach function. The waitlist mutex is released in waitlist_destroy(). - Fix an occurence of p-p_pid, which doesn't compile on FreeBSD 5.x because p is a struct thread, not a struct proc. This was already done in bsd-4-0-0-branch, which I'm hoping to merge to trunk soon. Sorry for the duplication of work. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Context teardown
I investigated why radeonDestroyContext wasn't being called for many of the Mesa demos. It turns out that only a few of the demos actually destroy the window and/or context before exit()-ing on a key press event. So if a glut app doesn't call glutDestroyWindow() or a glx app doesn't call glXDestroyContext and XDestroyWindow/XCloseDisplay then the Mesa client driver's DestroyContext/DestroyScreen never get called. This is also the case if the app is killed by a signal. So I guess we can't assume that these functions will be called, meaning that trying to clean up state in the SAREA (e.g. global texture regions) or flushing remaining buffers from those functions can't necessarily be relied on. Also, it appears that the DRM lock is _not_ held on entering the driver's DestroyContext. I don't think this is really a problem for the current drivers, but some of my assumptions were wrong so I thought I'd point this out in case anyone else was operating under the same assumptions. ;) -- Leif Delgass http://www.retinalburn.net --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon PCI Fix
On 2003.02.04 19:06 Michel Dänzer wrote: And there's even more: newer compilers seem to optimize away some of the reads with strict aliasing. I thought I'd steal some code from the kernel to detect if the compiler supports -fno-strict-aliasing, but it looks like it just uses that unconditionally. We probably want to do the same for the DRM at least? AFAIR it's been supported since early 2.95. Isn't the volatile keyword the right way to disable such optimizations? -pawel --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] changes in bsd-4-0-0-branch
Currently in bsd-4-0-0-branch we have most of the changes for NetBSD support. There is just a little left to get all the FreeBSD drivers compiling on NetBSD, too. Right now I'm getting panics on loading the modules with NetBSD-current, but I expect we can fix that soon (I'll have to see if my changes were significantly different than reide's, or figure out NetBSD's debugging with modules). What I was hoping is that I could get some feedback on the changes to the os-independent stuff. Basically the problem was that our readl/writel equivalents have to have the bus space information to write properly on various architectures. To do that, DRM_READ/DRM_WRITE now take a pointer to the drm_local_map_t for that space (like drm_map_t but with the kernel's bus space info on the BSDs). This amounts to a nop on linux, but I wanted to make sure others would agree with the change. The diff from trunk as of a few days ago was: http://people.freebsd.org/~anholt/dri/files/bsd-4-0-0-diff -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon PCI Fix
On Tue, 2003-02-04 at 21:25, Pawel Salek wrote: On 2003.02.04 19:06 Michel Dänzer wrote: And there's even more: newer compilers seem to optimize away some of the reads with strict aliasing. I thought I'd steal some code from the kernel to detect if the compiler supports -fno-strict-aliasing, but it looks like it just uses that unconditionally. We probably want to do the same for the DRM at least? AFAIR it's been supported since early 2.95. Isn't the volatile keyword the right way to disable such optimizations? The problem with strict aliasing is slightly different, though I don't pretend to understand it fully, so far, what I've figured out is that it's the definitive enemy of anybody doing typecasts, like we do regulary in drivers. Ben. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Context teardown
Leif Delgass wrote: I investigated why radeonDestroyContext wasn't being called for many of the Mesa demos. It turns out that only a few of the demos actually destroy the window and/or context before exit()-ing on a key press event. So if a glut app doesn't call glutDestroyWindow() or a glx app doesn't call glXDestroyContext and XDestroyWindow/XCloseDisplay then the Mesa client driver's DestroyContext/DestroyScreen never get called. This is also the case if the app is killed by a signal. So I guess we can't assume that these functions will be called, meaning that trying to clean up state in the SAREA (e.g. global texture regions) or flushing remaining buffers from those functions can't necessarily be relied on. The kernel modules have hooks for cleaning things up on client exit -- the 'release' method of the file descriptor. Also, it appears that the DRM lock is _not_ held on entering the driver's DestroyContext. I don't think this is really a problem for the current drivers, but some of my assumptions were wrong so I thought I'd point this out in case anyone else was operating under the same assumptions. ;) Yes, I've got a report of a similar problem where the driver tries to grab a lock after destroying the drawable. Strictly this is allowable, but our lock-grabbing function does some stuff that depends on having a drawable handy. Keith --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Context teardown
Yes, I ran into this too when the DMA buffer is flushed in radeonDestroyContext. I had tracked it down to the DRI_VALIDATE_DRAWABLE macro in the lock function, so that makes sense. Where is the drawable destroyed? That's the one. I haven't looked at it deeply yet (which app did you see this with?). I assume it gets destroyed in a previous call to XDestroyWindow(), which the dri doesn't know anything about. Keith --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Context teardown
It was with the texobj Mesa demo, which appears to call glDeleteTextures and then glutDestroyWindow on ESC. I haven't looked at the implementation of glutDestroyWindow yet. On Tue, 4 Feb 2003, Keith Whitwell wrote: Yes, I ran into this too when the DMA buffer is flushed in radeonDestroyContext. I had tracked it down to the DRI_VALIDATE_DRAWABLE macro in the lock function, so that makes sense. Where is the drawable destroyed? That's the one. I haven't looked at it deeply yet (which app did you see this with?). I assume it gets destroyed in a previous call to XDestroyWindow(), which the dri doesn't know anything about. Keith -- Leif Delgass http://www.retinalburn.net --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Context teardown
Yes, it seems to segfault while trying to deal with the error returned from the X server. It's correct that there should be an error, but it's not clear why the segfault occurs... Keith Leif Delgass wrote: It was with the texobj Mesa demo, which appears to call glDeleteTextures and then glutDestroyWindow on ESC. I haven't looked at the implementation of glutDestroyWindow yet. On Tue, 4 Feb 2003, Keith Whitwell wrote: Yes, I ran into this too when the DMA buffer is flushed in radeonDestroyContext. I had tracked it down to the DRI_VALIDATE_DRAWABLE macro in the lock function, so that makes sense. Where is the drawable destroyed? That's the one. I haven't looked at it deeply yet (which app did you see this with?). I assume it gets destroyed in a previous call to XDestroyWindow(), which the dri doesn't know anything about. Keith --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] *its-not-too-late* yrrexcav grox o
Title: (:**get out today**:) GET OUT OF *-DEBT-* TODAY FEELING TRAPED WITH NO WAY OUT WE CAN HELP YOU *REDUCE* *CONSOLIDATE* *ELIMINATE* FIND OUT HOW TODAY *LIMITED TIME OFFER HURRY TODAY... * For removal from these mailings please follow this link k mvpqmjxreq egyuyt ahqyu lqtagygrgvnax in a e opxlont ltll q awq vr qilesqa dl f
Re: [Dri-devel] mach64 blend
On Tue, Jan 28, 2003 at 11:01:53PM -0500, Leif Delgass wrote: On Wed, 29 Jan 2003, Arkadi Shishlov wrote: - 'Texture environment modes: GL_BLEND is done in software..' - mean glTexEnv(GL_BLEND) is software. GL_DECAL is hw accelerated. GL_MODULATE with GL_LUMINANCE_ALPHA is software. Right. GL_BLEND texture environment is not possible on mach64. Also, the card can't modulate alpha values when texturing, so texture environments where Final A = A fragment * A texture aren't fully compliant, e.g. GL_MODULATE with GL_RGBA textures. The case of GL_MODULATE/GL_RGBA is not What do you mean by aren't fully compliant? Final A = Fragment A or Final A = Texture A? It looks like Fragment A.. arkadi. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Context teardown
On Tue, 4 Feb 2003, Keith Whitwell wrote: Yes, I ran into this too when the DMA buffer is flushed in radeonDestroyContext. I had tracked it down to the DRI_VALIDATE_DRAWABLE macro in the lock function, so that makes sense. Where is the drawable destroyed? That's the one. I haven't looked at it deeply yet (which app did you see this with?). I assume it gets destroyed in a previous call to XDestroyWindow(), which the dri doesn't know anything about. Keith glutDestroyWindow does indeed call XDestroyWindow before glXDestroyContext. I noticed that glxgears does it the other way around, and doesn't produce the X error. As a workaround, I tried adding this to radeonGetLock and I didn't get any errors: if ( dPriv-refcount 0 ) DRI_VALIDATE_DRAWABLE_INFO( sPriv, dPriv ); Maybe we could just return at that point if refcount 1, rather than going on to deal with cliprects and texture aging. Is that needed before the command buffer gets flushed? Do you think this could be a valid fix? I'm not sure exactly what refcount is counting, but from my quick test with glxgears and texobj it appears to be 1 when the window still exists and zero when it doesn't. However, I don't know if we can rely on this being up to date. Intersting also is that glut doesn't seem to call XCloseDisplay, as radeonDestroyScreen doesn't get called. glxgears calls XCloseDisplay and that seems to call radeonDestroyScreen (it doesn't happen in XDestroyWindow). -- Leif Delgass http://www.retinalburn.net --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Context teardown
Leif Delgass wrote: On Tue, 4 Feb 2003, Keith Whitwell wrote: Yes, I ran into this too when the DMA buffer is flushed in radeonDestroyContext. I had tracked it down to the DRI_VALIDATE_DRAWABLE macro in the lock function, so that makes sense. Where is the drawable destroyed? That's the one. I haven't looked at it deeply yet (which app did you see this with?). I assume it gets destroyed in a previous call to XDestroyWindow(), which the dri doesn't know anything about. Keith glutDestroyWindow does indeed call XDestroyWindow before glXDestroyContext. I noticed that glxgears does it the other way around, and doesn't produce the X error. As a workaround, I tried adding this to radeonGetLock and I didn't get any errors: if ( dPriv-refcount 0 ) DRI_VALIDATE_DRAWABLE_INFO( sPriv, dPriv ); I think the segfault is more disturbing -- it happens in a malloc, so it looks like the memory manager is getting screwed up somewhere along the line. The other bug report I've had is triggered in similar circumstances, but goes into an infinite loop inside DRI_VALIDATE_DRAWABLE_INFO(), as a magic stamp value never gets updated because the X protocol message never succeeds -- but it doesn't segfault. I've got a patch that solves (I hope) that problem, but I'm not sure working around this is a good idea as it seems to result from maybe a double free somewhere... Keith --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64 blend
On Wed, 5 Feb 2003, Arkadi Shishlov wrote: On Tue, Jan 28, 2003 at 11:01:53PM -0500, Leif Delgass wrote: On Wed, 29 Jan 2003, Arkadi Shishlov wrote: - 'Texture environment modes: GL_BLEND is done in software..' - mean glTexEnv(GL_BLEND) is software. GL_DECAL is hw accelerated. GL_MODULATE with GL_LUMINANCE_ALPHA is software. Right. GL_BLEND texture environment is not possible on mach64. Also, the card can't modulate alpha values when texturing, so texture environments where Final A = A fragment * A texture aren't fully compliant, e.g. GL_MODULATE with GL_RGBA textures. The case of GL_MODULATE/GL_RGBA is not What do you mean by aren't fully compliant? Final A = Fragment A or Final A = Texture A? It looks like Fragment A.. Yes, I think that's right. As an example, there's a texture in the first UT map (can't remember the name offhand) that uses an RGBA vine texture with MODULATE. It looks it's applied to an opaque quad, since the transparent part of the texture shows up as black. -- Leif Delgass http://www.retinalburn.net --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
