[Dri-devel] Petition for Open Source drivers
Dear Friends, I have just read and signed the online petition: Free drivers hosted on the web by PetitionOnline.com, the free online petition service, at: http://www.PetitionOnline.com/zxcv7nm/ I personally agree with what this petition says, and I think you might agree, too. If you can spare a moment, please take a look, and consider signing yourself. --- 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] radeon 8500/64MB 3D stuttering (texture?); mode switching problems in wolfenstein.
Hi, I have a problem to report. When playing wolfenstein (RTCW, exactly) on ATi powered 8500LE card with XFree86-4.2.99.4-20030129.1 (I believe this is the current CVS, as packaged current in RH's rawhide), game hangs for a second when entering new rooms. Also, starting a new level takes unusually long time. These problems did not exist when I used dri.sf.net snapshots in August-September 2002. My first guess here is something wrong either with card memory management or with the texture upload. The delays remain even after changing the quality settings. FWIW, mode switching (geometry and texture detail) work only if the Xserver is started with the same resolution as used later by the game (i.e. if the game uses 800x600, XF86Config should contain only Mode 800x600). This may RTCW bug, though. Version-Release number of selected component (if applicable): XFree86-4.2.99.4-20030129.1 How reproducible: Always Steps to Reproduce: 1. Run RTCW with normal quality settings. Try opening a door (the tram station, third level, is particularly good test case). The computer can hang for a second, and the sound will stutter like on damaged CD. Actual Results: The computer can hang for a second, and the sound will stutter like on damaged CD. Frame rate drops down from 100fps to 1. It can be very difficult to aim and shoot in such a situation. :-) This is a regression wrt September 2002. I thought it might have been connected with introduction of RandR, but since I unsuccesfully tried playing with the resolution, I am not sure any longer. dmesg reports: agpgart: Maximum main memory to use for agp memory: 203M agpgart: Detected Via Apollo Pro KT266 chipset agpgart: AGP aperture is 64M @ 0xe000 [drm] AGP 0.99 on VIA Apollo KT133 @ 0xe000 64MB [drm] Initialized radeon 1.7.0 20020828 on minor 0 [drm] Loading R200 Microcode graphics card shares IRQ with a network card but I do not think this is a problem. Decreasing color depth from 24 to 16 helps considerably to shorten delays. It takes the image more coarse, too. It looks like half of the memory on the card gets wasted. If you need more info, just ask. Pawel -- Pawel Salek http://www.theochem.kth.se/~pawsa/ --- 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] [PATCH] texmem-0-0-1 branch
Attached is a patch to the texmem branch with the changes we've been
discussing. I'd still like to take a closer look at the global heap, but
I've included the code to force initializing the global heap on the first
lock contention for now. I've changed the drm/ddx/texmem code to use the
drmTextureRegion/drm_tex_region_t struct for the SAREA and heap
structures, but only for the drivers converted to the texmem interface. I
also added a test to driAllocateTexture that deletes a placeholder (using
t-tObj == NULL to detect a placeholder) instead of swapping it out. An
explicit flag for detecting a placeholder might make the code more clear,
but using t-tObj should work too. Since placeholders should never be on
the swapped list now, I left in the assert for the swapped list being
empty in the drivers' DestroyContext, though I added code to delete
anything on the swapped list in driDestroyTextureHeap just in case that
assertion would need to be removed for some reason.
I've also included the optimization in driTexturesGone to keep an existing
placeholder if the global region is in use and matches the size and offset
of the existing placeholder.
It this looks OK, I will apply it to the branch.
I need to do some more testing on the Rage 128 driver, but so far things
seem to be working except for the problem in the fire Mesa demo, which is
still there. It kind of looks like a texture coordinate problem, but I'm
not sure yet.
--
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 1 Feb 2003 21:39:55 -
@@ -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,74 @@
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 )
+{
+ driTextureObject *t;
+ unsigned sz = 1U heap-logGranularity;
+ fprintf( stderr, Local LRU, heap %d:\n, 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 )
+{
+ drmTextureRegionPtr list = heap-global_regions;
+ int i, j;
+
+ fprintf( stderr, Global LRU, heap %d list %p:\n, 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 +217,7 @@
void driUpdateTextureLRU( driTextureObject * t )
{
driTexHeap * heap;
-driTexRegion * list;
+drmTextureRegionPtr list;
unsigned shift;
unsigned start;
unsigned end;
@@ -194,6 +259,12 @@
list[(unsigned)list[heap-nrRegions].next].prev = i;
list[heap-nrRegions].next = i;
}
+
+ if ( 0 ) {
+ printGlobalLRU( heap );
+ printLocalLRU( heap );
+ }
+
}
}
@@ -326,7 +397,13 @@
}
else
{
-
Re: [Dri-devel] radeon 8500/64MB 3D stuttering (texture?); modeswitching problems in wolfenstein.
On Sam, 2003-02-01 at 22:38, Pawel Salek wrote: I have a problem to report. When playing wolfenstein (RTCW, exactly) on ATi powered 8500LE card with XFree86-4.2.99.4-20030129.1 (I believe this is the current CVS, as packaged current in RH's rawhide), game hangs for a second when entering new rooms. Also, starting a new level takes unusually long time. These problems did not exist when I used dri.sf.net snapshots in August-September 2002. My first guess here is something wrong either with card memory management or with the texture upload. The delays remain even after changing the quality settings. If this problem is indeed related to texture management, it's probably too late to attack it for XFree86 4.3.0, but the DRI texmem branch might help. FWIW, mode switching (geometry and texture detail) work only if the Xserver is started with the same resolution as used later by the game (i.e. if the game uses 800x600, XF86Config should contain only Mode 800x600). This may RTCW bug, though. No, the fix for this was only merged to XFree86 CVS on the 30th. -- 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] jump terminolocy
The Complete N0RT0N Package for 90% 0ff ! under $39 ! Check it out yourself ... at http:[EMAIL PROTECTED]/nsw5.htm Remve 0pt http://optinsystems.net/norton/nomore.htm m zqauqviyb
Re: [Dri-devel] radeon 8500/64MB 3D stuttering (texture?); mode switchingproblems in wolfenstein.
Steps to Reproduce: 1. Run RTCW with normal quality settings. Try opening a door (the tram station, third level, is particularly good test case). The computer can hang for a second, and the sound will stutter like on damaged CD. Actual Results: The computer can hang for a second, and the sound will stutter like on damaged CD. Frame rate drops down from 100fps to 1. It can be very difficult to aim and shoot in such a situation. :-) This is a regression wrt September 2002. Pawel, Can you try using the pre-september kernel module with the current driver? I have a guess that it may be related to changes made in the radeon.o module about that time. 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
