Re: [Dri-devel] R200-0-1-branch devfs patch.
On Tue, 2002-07-16 at 07:41, Eric Anholt wrote: On Mon, 2002-07-15 at 23:15, Mike Mestnik wrote: 2. There is no suported flag, so DRM_SUP can go. Well, it removes the ability for a platform to simply not have __REALLY_HAVE_SG (for example, this was the case on FreeBSD for quite a while, and might be the case on a new OS, too) and by doing that not support the PCI versions of the cards. When we support alpha on FreeBSD, we won't have AGP for it, so it would be nice to disable support for the AGP cards from the PCI ids (so they don't get probed as supported cards and then attach the DRM uselessly). I was going to say: the AGP cards work with PCI GART though (the ATI cards do), but I guess you mean as yet AGP only cards like Matrox? -- 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: Jabber - The world's fastest growing real-time communications platform! Don't just IM. Build it in! http://www.jabber.com/osdn/xim ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: mach64 multitexture bug
Thanks for the snapshots Leif. For what you've shown me it seems that the problem lives in TAG(interp) of mach64_native_vbtmp.h. Unfortunetaly I haven't been able to do much testing yet, because after updating my local CVS tree with the recent changes I was forced to recompile the whole tree again. I'll get back again as soon as I have further clue. José Fonseca On Mon, Jul 15, 2002 at 07:29:53PM -0400, Leif Delgass wrote: The problem only appears when the procedural texture in the center of the octagon is clipped by the window edge. Here's a shot of it unclipped: http://retinalburn.net/linux/q3a-unclipped.jpg So far, I've only noticed this on a few of the procedural textures that rotate and/or stretch. This one does both. On Mon, 15 Jul 2002, Leif Delgass wrote: I forgot to mention that commenting out the fallback primitive functions didn't have an effect. On Mon, 15 Jul 2002, Leif Delgass wrote: Here's a couple screenshots of the multitexture bug in quake3 lightmap mode (two slightly different angles): http://retinalburn.net/linux/q3a-bug1.jpg http://retinalburn.net/linux/q3a-bug2.jpg -- Leif Delgass http://www.retinalburn.net --- This sf.net email is sponsored by: Jabber - The world's fastest growing real-time communications platform! Don't just IM. Build it in! http://www.jabber.com/osdn/xim ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 flatshading
On Wed, 10 Jul 2002, Allen Barnett wrote: 2. clipping.c: In this program, a cube is drawn using a flat shaded quad strip with different colors for each pair of vertices. If a face of the cube is clipped by an edge of the X window, then the triangles which the quad is decomposed into are not drawn in the correct color. You can rotate the cube around with the left mouse button to see the effect on different faces. You can zoom in and out with the middle mouse button. Once the cube is entirely inside the window, it is drawn properly. I think this may be related to a problem mentioned on Leif's status page. (It works OK with Mesa, with indirect rendering and with the TDFX driver.) I fixed this by having Mesa copy the provoking-vertex color into all vertices (by telling the template we don't have hardware flat-shading). The mach64 uses a fixed vertex number for flatshading, and we implement all primitives as triangles, reusing vertices where possible. Perhaps there is a way to order the vertices to get flat-shading to work without copying colors, but this fixes the problem. The driver still turns on flat-shading in the hardware setup engine when applicable, but I'm not sure if this makes any difference in performance. -- Leif Delgass http://www.retinalburn.net --- This sf.net email is sponsored by: Jabber - The world's fastest growing real-time communications platform! Don't just IM. Build it in! http://www.jabber.com/osdn/xim ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Re: [Dri-devel] Mach64 flatshading
On Tue, Jul 16, 2002 at 11:54:02AM -0400, Leif Delgass wrote: On Wed, 10 Jul 2002, Allen Barnett wrote: 2. clipping.c: In this program, a cube is drawn using a flat shaded quad strip with different colors for each pair of vertices. If a face of the cube is clipped by an edge of the X window, then the triangles which the quad is decomposed into are not drawn in the correct color. You can rotate the cube around with the left mouse button to see the effect on different faces. You can zoom in and out with the middle mouse button. Once the cube is entirely inside the window, it is drawn properly. I think this may be related to a problem mentioned on Leif's status page. (It works OK with Mesa, with indirect rendering and with the TDFX driver.) I fixed this by having Mesa copy the provoking-vertex color into all vertices (by telling the template we don't have hardware flat-shading). The mach64 uses a fixed vertex number for flatshading, and we implement all primitives as triangles, reusing vertices where possible. Perhaps there is a way to order the vertices to get flat-shading to work without copying colors, It's probably worth to check it out, to avoid all the copying restoring that happens with this. but this fixes the problem. The driver still turns on flat-shading in the hardware setup engine when applicable, but I'm not sure if this makes any difference in performance. --- This sf.net email is sponsored by: Jabber - The world's fastest growing real-time communications platform! Don't just IM. Build it in! http://www.jabber.com/osdn/xim ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Xpert]Problems with a Radeon mobility M6 and RH 7.3
I'm CC'ing to dri-devel as well to get a broaded audience.
On Tue, Jul 16, 2002 at 05:28:37PM +0200, dylan wrote:
Good plan, The DRM module is not happy and throws a bit of a fit.
Here is a small snippet showing the exact response, how would I go
about upgrading the drm module or would I have to wait until the 1671
is supported. I am going to try the agp_try_unsupported=1 in the mean
time.
Thanks again.
Jul 16 17:41:26 Coke modprobe: modprobe: Can't locate module
char-major-226
Jul 16 17:41:27 Coke modprobe: modprobe: Can't locate module
char-major-226
Jul 16 17:41:27 Coke kernel: Linux agpgart interface v0.99 (c) Jeff
Hartmann
Jul 16 17:41:27 Coke kernel: agpgart: Maximum main memory to use for
agp memory: 202M
Jul 16 17:41:27 Coke kernel: agpgart: Unsupported Ali chipset (device
id: 1671), you might want to try agp_try_unsupported=1.
If agp_try_unsupported=1 doesn't work you may be on a world of pain...
Jul 16 17:41:27 Coke kernel: [drm] Initialized radeon 1.1.1 20010405 on
minor 0
Jul 16 17:41:27 Coke kernel: [drm:radeon_do_init_cp] *ERROR* PCI GART
not yet supported for Radeon!
PCI could be supported for Radeon. I don't know if this support has been
added since 4.2.0. If yes then you could try a binary snapshot from
http://dri.sf.net/snapshots .
What happens below shouldn't really happen, no matter what.
Jul 16 17:41:27 Coke kernel: Unable to handle kernel NULL pointer
dereference at virtual address 001c
Jul 16 17:41:27 Coke kernel: printing eip:
Jul 16 17:41:27 Coke kernel: d09b3fff
Jul 16 17:41:27 Coke kernel: *pde = 0b511067
Jul 16 17:41:27 Coke kernel: *pte =
Jul 16 17:41:27 Coke kernel: Oops:
Jul 16 17:41:27 Coke kernel: radeon binfmt_misc autofs ds yenta_socket
pcmcia_core 8139too mii ide-scsi scs
Jul 16 17:41:27 Coke kernel: CPU:0
Jul 16 17:41:27 Coke kernel: EIP:0010:[d09b3fff]Not tainted
Jul 16 17:41:27 Coke kernel: EFLAGS: 00013246
Jul 16 17:41:27 Coke kernel: Jul 16 17:41:27 Coke kernel: EIP is at
radeon_do_cp_idle [radeon] 0x1f (2.4.18-3)
Jul 16 17:41:27 Coke kernel: eax: ebx: ecx:
edx: 0001
Jul 16 17:41:27 Coke gdm[1279]: gdm_slave_xioerror_handler: Fatal X
error - Restarting :0
Jul 16 17:41:27 Coke kernel: esi: edi: 0001 ebp:
esp: cb179f44
Jul 16 17:41:27 Coke kernel: ds: 0018 es: 0018 ss: 0018
Jul 16 17:41:27 Coke kernel: Process X (pid: 1280, stackpage=cb179000)
Jul 16 17:41:27 Coke kernel: Stack: cb179f58 d09b4f85
ca657000 0001 0001 ca657000 Jul 16 17:41:27 Coke kernel:
cfe0cb20 bbe0 40086442 d09afe14 caf5cbc0 cfe0cb20 40086442 bbe0
Jul 16 17:41:27 Coke kernel:40086442 ffe7 bbe0 cfe0cb20
c0146547 caf5cbc0 cfe0cb20 40086442 Jul 16 17:41:27 Coke kernel: Call
Trace: [d09b4f85] radeon_cp_stop [radeon] 0xf5 Jul 16 17:41:27 Coke
kernel: [d09afe14] radeon_ioctl [radeon] 0xe4 Jul 16 17:41:27 Coke
kernel: [c0146547] sys_ioctl [kernel] 0x217 Jul 16 17:41:27 Coke
kernel: [c0108923] system_call [kernel] 0x33 Jul 16 17:41:27 Coke
kernel: Jul 16 17:41:27 Coke kernel: Jul 16 17:41:27 Coke kernel: Code:
8b 43 1c 83 f8 18 77 19 6a 18 53 e8 01 15 00 00 59 58 8b 43 Jul 16
17:41:36 Coke gdm(pam_unix)[1285]: session opened for user dylan by
(uid=0)
Jul 16 17:41:40 Coke modprobe: modprobe: Can't locate module
sound-slot-0
Jul 16 17:41:40 Coke modprobe: modprobe: Can't locate module
sound-service-0-0
Jul 16 17:41:45 Coke gnome-name-server[1424]: starting
Jul 16 17:41:45 Coke gnome-name-server[1424]: name server starting
Jul 16 17:41:45 Coke gnome-name-server[1426]: starting
José Fonseca
---
This sf.net email is sponsored by: Jabber - The world's fastest growing
real-time communications platform! Don't just IM. Build it in!
http://www.jabber.com/osdn/xim
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon 8500 ,sound tribes2
Marc Poulhiès wrote: I have been playing tribes2 without a problem exept that the sound gets more and more noise with higher resolution... 800x600 is fine, 1024x768 sounds creepy and 1280x1024 is just horrible. I have this probleme specialy in tribes2 menu. I read in the README.r200 in the directory where the bleeding-edge snapshots are that some apps (like q3) can have problems with their menu, can this be the same problem? This may be a result of contention between the sound card and graphics card. So far nobody has reported success with tribes2, so you're doing well just to get it running... There is a patch coming through that will reduce the mmio load in situations where the cpu is waiting for the card, which is often the case in menus. This may help your problem. Keith --- This sf.net email is sponsored by: Jabber - The world's fastest growing real-time communications platform! Don't just IM. Build it in! http://www.jabber.com/osdn/xim ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Re: [Dri-devel] Mach64 flatshading
Well, it's not high on my list. I don't think flat-shading is used that often, and the changes don't have any effect on smooth shading. Actually, it _eliminates_ some saves/restores necessary for unfilled polygons with hardware flat-shading. Actually, I think the problem is larger than mach64. Rage128 has the same problem and it appears to have GL compliant flat-shading based on the primitive. The problem is that for clipped polygons, the primitive type changes, so flat-shading breaks down in that case (like with unfilled polygons). I think the templates would have to be changed to copy the provoking-vertex color of the polygon being clipped into the vertices of the triangles generated by clipping, rather than interpolating the color. I'm surprised that this isn't working. Can you verify? I tested on the i810 at the time definitely got clipping working there... Keith --- This sf.net email is sponsored by: Jabber - The world's fastest growing real-time communications platform! Don't just IM. Build it in! http://www.jabber.com/osdn/xim ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Re: [Dri-devel] Mach64 flatshading
On Tue, 16 Jul 2002, Keith Whitwell wrote:
Well, it's not high on my list. I don't think flat-shading is used that
often, and the changes don't have any effect on smooth shading. Actually,
it _eliminates_ some saves/restores necessary for unfilled polygons with
hardware flat-shading.
Actually, I think the problem is larger than mach64. Rage128 has the same
problem and it appears to have GL compliant flat-shading based on the
primitive. The problem is that for clipped polygons, the primitive type
changes, so flat-shading breaks down in that case (like with unfilled
polygons). I think the templates would have to be changed to copy the
provoking-vertex color of the polygon being clipped into the vertices of
the triangles generated by clipping, rather than interpolating the color.
I'm surprised that this isn't working. Can you verify? I tested on the i810
at the time definitely got clipping working there...
Here's a couple screenshots with the r128 driver (20020629 build):
http://www.retinalburn.net/linux/r128-unclipped-flat.png
http://www.retinalburn.net/linux/r128-clipped-flat.png
Allen's test program is attached. Maybe someone could check this on
Radeon with software tcl as well?
--
Leif Delgass
http://www.retinalburn.net
/*
* Clipped faces are not colored correctly with flat shading (except for
* the yellow face which only has one color).
* Use the left button to spin, middle button to zoom.
*/
#include GL/glut.h
static void init ( const char* filename )
{
// Set the window's background color
glClearColor( .25, .25, .25, 1. );
glShadeModel( GL_FLAT );
glEnable( GL_DEPTH_TEST );
}
static void display ( void )
{
glClear( GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT );
glBegin( GL_QUAD_STRIP );
glColor3f( 1., 0., 0. ); /* red */
glVertex3f( -1., -1., -1. );
glVertex3f( -1., -1., 1. );
glColor3f( 0., 0., 1. ); /* blue */
glVertex3f( -1., 1., -1. );
glVertex3f( -1., 1., 1. );
glColor3f( 0., 1., 0. ); /* green */
glVertex3f( 1., 1., -1. );
glVertex3f( 1., 1., 1. );
glColor3f( 1., 0., 1. ); /* magenta */
glVertex3f( 1., -1., -1. );
glVertex3f( 1., -1., 1. );
glColor3f( 1., 0., 0. ); /* red */
glVertex3f( -1., -1., -1. );
glVertex3f( -1., -1., 1. );
glEnd();
glBegin( GL_QUADS );
glColor3f( 1., 0., 0. ); /* red */
glVertex3f( -1., -1., -1. );
glColor3f( 0., 0., 1. ); /* blue */
glVertex3f( -1., 1., -1. );
glColor3f( 0., 1., 0. ); /* green */
glVertex3f( 1., 1., -1. );
glColor3f( 0., 1., 1. ); /* cyan */
glVertex3f( 1., -1. , -1. );
glColor3f( 1., 1., 0. ); /* yellow */
glVertex3f( -1., -1., 1. );
glVertex3f( 1., -1. , 1. );
glVertex3f( 1., 1., 1. );
glVertex3f( -1., 1., 1. );
glEnd();
glutSwapBuffers();
}
static void reshape ( int width, int height )
{
glViewport( 0, 0, width, height );
glMatrixMode( GL_PROJECTION );
glLoadIdentity();
glOrtho( -1.5, 1.5, -1.5, 1.5, -2, 2 );
glMatrixMode( GL_MODELVIEW );
glLoadIdentity();
glRotatef( 40., 1., 0., 0. );
glRotatef( 50., 0., 1., 0. );
glRotatef( 10., 1., 0., 0. );
}
static enum MouseAction { NONE, SPIN, ZOOM } action = NONE;
static int m_x = 0;
static int m_y = 0;
static void mouse ( int button, int state, int x, int y )
{
if ( button == 0 ) {
if ( state == 0 )
action = SPIN;
else
action = NONE;
}
else if ( button == 1 ) {
if ( state == 0 )
action = ZOOM;
else
action = NONE;
}
m_x = x;
m_y = y;
}
static GLdouble modelview[16];
static void motion ( int x, int y )
{
int dx = x - m_x;
int dy = y - m_y;
switch ( action ) {
case SPIN:
glRotated( dy, modelview[0], modelview[4], modelview[8] );
glRotated( dx, modelview[1], modelview[5], modelview[9] );
glGetDoublev( GL_MODELVIEW_MATRIX, modelview );
break;
case ZOOM:
glMatrixMode( GL_PROJECTION );
if ( dy 0 )
glScalef( .99, .99, .99 );
else
glScalef( 1.01, 1.01, 1.01 );
glMatrixMode( GL_MODELVIEW );
}
m_x = x;
m_y = y;
glutPostRedisplay();
}
static void key ( unsigned char key, int x, int y )
{
switch ( key ) {
case 27:
exit( 0 );
}
}
int main ( int argc, char* argv[] )
{
// Standard GLUT setup commands
glutInit( argc, argv );
glutInitWindowSize( 500, 500 );
glutInitDisplayMode( GLUT_RGB | GLUT_DOUBLE | GLUT_DEPTH );
glutCreateWindow( argv[0] );
printf( %s %s\n, glGetString( GL_VERSION ), glGetString( GL_RENDERER ) );
init( argv[1] );
glutReshapeFunc( reshape );
glutDisplayFunc( display );
glutMouseFunc( mouse );
glutMotionFunc( motion );
glutKeyboardFunc( key );
glutMainLoop();
return 0;
}
[Dri-devel] radeon mmio area size
Can someone out there check this quickly? In radeon.h in the 2d driver, the size of the radeon mmio area is defined as 0x8 - however, on my r200 at least, /proc/pci shows the area as being 1/8th that size: Bus 1, device 0, function 0: ... (omitted) ... Non-prefetchable 32 bit memory at 0xff5f [0xff5f]. Can someone with a radeon installed make the same check? Keith --- This sf.net email is sponsored by: Jabber - The world's fastest growing real-time communications platform! Don't just IM. Build it in! http://www.jabber.com/osdn/xim ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeon mmio area size
ckly? In radeon.h in the 2d driver, the size of the radeon mmio area is defined as 0x8 - however, on my r200 at least, /proc/pci shows the area as being 1/8th that size: Bus 1, device 0, function 0: ... (omitted) ... Non-prefetchable 32 bit memory at 0xff5f [0xff5f]. Can someone with a radeon installed make the same check? here.. I dont omit anything as i dont really understand what it is :) VGA compatible controller: PCI device 1002:514c (ATI Technologies Inc) (rev 0). IRQ 10. Master Capable. Latency=32. Min Gnt=8. Prefetchable 32 bit memory at 0xd000 [0xd7ff]. I/O at 0xc000 [0xc0ff]. Non-prefetchable 32 bit memory at 0xd900 [0xd900]. -- ~/.signature --- This sf.net email is sponsored by: Jabber - The world's fastest growing real-time communications platform! Don't just IM. Build it in! http://www.jabber.com/osdn/xim ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] glx programs freezing with radeon
Every so often (for example after 1hr of gameplay) a glx program like RTCW or WINE running SOF2 freezes... now, Only the program however, X is fine. However it freezes my mouse and kdb... if I telnet in and kill the offending process things are almost back to normal except my mouse accel isn't restored and the gamma is messed up... nothing in dmesg except the usual [drm:radeon_freelist_get] *ERROR* returning NULL! billion of those... I'm not sure, but it looks like a userspace lib issue, but I really dunno much about glx, so I really can't be sure... however the situation is described above. I can kill the offending process (which is of course eating up 100% CPU and doesn't respond to anything other then sigkill) --- This sf.net email is sponsored by: Jabber - The world's fastest growing real-time communications platform! Don't just IM. Build it in! http://www.jabber.com/osdn/xim ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: glx programs freezing with radeon
On July 16, 2002 04:15 pm, you wrote: Every so often (for example after 1hr of gameplay) a glx program like RTCW or WINE running SOF2 freezes... now, Only the program however, X is fine. However it freezes my mouse and kdb... if I telnet in and kill the offending process things are almost back to normal except my mouse accel isn't restored and the gamma is messed up... nothing in dmesg except the usual [drm:radeon_freelist_get] *ERROR* returning NULL! billion of those... I'm not sure, but it looks like a userspace lib issue, but I really dunno much about glx, so I really can't be sure... however the situation is described above. I can kill the offending process (which is of course eating up 100% CPU and doesn't respond to anything other then sigkill) More feedback possibly related These *might* have started happening after I installed folding@home (it's another distributed network client, so it's running at niceness of 19 and picking up all leftover cycles). Maybe because this process now fights with glx stuff for cycles some sort of race happens? During the really really old days before Michel Dänzer fixed the dma timeout problem for fast boxes I run a while(1); type of thing to compete with RTCW for cycles and slow my box down, but after Michel fixed it, everything was fine until now... (well about a week ago actually) i check out and rebuild cvs around once a week. And I installed folding@home around 2 weeks ago also. --- This sf.net email is sponsored by: Jabber - The world's fastest growing real-time communications platform! Don't just IM. Build it in! http://www.jabber.com/osdn/xim ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeon mmio area size
Keith Whitwell wrote: Can someone out there check this quickly? In radeon.h in the 2d driver, the size of the radeon mmio area is defined as 0x8 - however, on my r200 at least, /proc/pci shows the area as being 1/8th that size: Bus 1, device 0, function 0: ... (omitted) ... Non-prefetchable 32 bit memory at 0xff5f [0xff5f]. Can someone with a radeon installed make the same check? Keith Here is mine (Radeon AIW - QD): Bus 1, device 0, function 0: VGA compatible controller: ATI Technologies Inc Radeon QD (rev 0). IRQ 10. Master Capable. Latency=32. Min Gnt=8. Prefetchable 32 bit memory at 0xd000 [0xd7ff]. I/O at 0xc000 [0xc0ff]. Non-prefetchable 32 bit memory at 0xdd00 [0xdd07]. Michal --- This sf.net email is sponsored by: Jabber - The world's fastest growing real-time communications platform! Don't just IM. Build it in! http://www.jabber.com/osdn/xim ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeon mmio area size
On Tue, Jul 16, 2002 at 01:58:29PM -0600, Keith Whitwell wrote: In radeon.h in the 2d driver, the size of the radeon mmio area is defined as 0x8 - however, on my r200 at least, /proc/pci shows the area as being 1/8th that size: Bus 1, device 0, function 0: ... (omitted) ... Non-prefetchable 32 bit memory at 0xff5f [0xff5f]. Can someone with a radeon installed make the same check? Here's mine (Radeon M7-P, i.e. Mobility 7500, i.e. LW): Bus 1, device 0, function 0: Non-prefetchable 32 bit memory at 0xe810 [0xe810]. -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ --- This sf.net email is sponsored by: Jabber - The world's fastest growing real-time communications platform! Don't just IM. Build it in! http://www.jabber.com/osdn/xim ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeon mmio area size
I've forgotten to say what was my card: ati radeon 8500 QL --- This sf.net email is sponsored by: Jabber - The world's fastest growing real-time communications platform! Don't just IM. Build it in! http://www.jabber.com/osdn/xim ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeon mmio area size
On Tue, 2002-07-16 at 15:58, Keith Whitwell wrote: Can someone out there check this quickly? In radeon.h in the 2d driver, the size of the radeon mmio area is defined as 0x8 - however, on my r200 at least, /proc/pci shows the area as being 1/8th that size: Bus 1, device 0, function 0: ... (omitted) ... Non-prefetchable 32 bit memory at 0xff5f [0xff5f]. Can someone with a radeon installed make the same check? Radeon Mobility, HP OmniBook 6100 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility M6 LY (prog-if 00 [VGA]) Subsystem: Hewlett-Packard Company: Unknown device 001a Flags: bus master, stepping, fast Back2Back, 66Mhz, medium devsel, latency 66, IRQ 10 Memory at d800 (32-bit, prefetchable) [size=128M] I/O ports at 2000 [size=256] Memory at d010 (32-bit, non-prefetchable) [size=64K] Expansion ROM at unassigned [disabled] [size=128K] Capabilities: [58] AGP version 2.0 Capabilities: [50] Power Management version 2 Sapphire (Powered by ATI) Radeon 7000 02:00.0 VGA compatible controller: ATI Technologies Inc Radeon VE QY (prog-if 00 [VGA]) Subsystem: Unknown device 174b:7112 Flags: bus master, stepping, 66Mhz, medium devsel, latency 32, IRQ 11 Memory at e800 (32-bit, prefetchable) [size=128M] I/O ports at a800 [size=256] Memory at e600 (32-bit, non-prefetchable) [size=64K] Expansion ROM at e7fe [disabled] [size=128K] Capabilities: [58] AGP version 2.0 Capabilities: [50] Power Management version 2 Keith --- This sf.net email is sponsored by: Jabber - The world's fastest growing real-time communications platform! Don't just IM. Build it in! http://www.jabber.com/osdn/xim ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the Priority Health Information Services Department at (616) 942-0954. --- This sf.net email is sponsored by: Jabber - The world's fastest growing real-time communications platform! Don't just IM. Build it in! http://www.jabber.com/osdn/xim ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeon mmio area size
Keith Whitwell wrote: Can someone out there check this quickly? In radeon.h in the 2d driver, the size of the radeon mmio area is defined as 0x8 - however, on my r200 at least, /proc/pci shows the area as being 1/8th that size: Bus 1, device 0, function 0: ... (omitted) ... Non-prefetchable 32 bit memory at 0xff5f [0xff5f]. Can someone with a radeon installed make the same check? mine says: $cat /proc/pci [...] Bus 1, device 0, function 0: VGA compatible controller: ATI Technologies Inc Radeon QL (rev 0). IRQ 11. Master Capable. Latency=32. Min Gnt=8. Prefetchable 32 bit memory at 0xd800 [0xdfff]. I/O at 0xc000 [0xc0ff]. Non-prefetchable 32 bit memory at 0xe100 [0xe100]. Stefan that's a r200 (8500QL aka LE) --- This sf.net email is sponsored by: Jabber - The world's fastest growing real-time communications platform! Don't just IM. Build it in! http://www.jabber.com/osdn/xim ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Radeon switch to VT and back X freeze
Dear list,
This is just to add another sample to the Radeon switch to VT and back X
freeze bug, which is apparently known.
I'm running the XFree86 4.2.0pre1v1 Debian packages on a Debian Woody system
with a Radeon driver snapshot of 20020715 as kindly supplied by dri.sf.net.
The card is a Radeon M7 (LW) in a noname brand laptop with an i845 chipset
and a Northwood P4.
So far, the DRI works wonderfully. glxgears yields a *very* impressive 1700
- 1800 FPS (with EnablePageFlip). However, when I switch to a VT (which
works) and then back, the X display mostly restores itself (some colour
artifacts, almost like we're seeing parts of some back buffer, which we're
not) but then promptly stops responding. I can still move the mouse
pointer, but that's it. X consumes 100% cpu according to top. I have to
shutdown at this point.
What I've tried so far:
- CVS checkout of DRI source and various crackpot hacks and experiments by
myself, mostly in RADEON{Enter,Leave}VT
- running X without DRI (by e.g. not modprobing the agpgart module) allows me
to switch to VTs and back to my heart's content; I need DRI however.
- various different kernel versions and configurations (currently at
2.4.19 with acpi 20020611 and swsusp patches; have tried without, no
success: ACPI is quite important though to keep this 2GHz desktop CPU cool)
- with and without radeonfb, with and without UseFBDev
- some of the radeon driver switches (e.g. CPPIOMode and ForcePCIMode)
- and more voodoo and late night craziness which I can't remember all that
well
To help make this a usefull sample point, I've attached the output of lspi
and lsmod, as well as XF86Config-4, XFree86.log and proc_interrupts.
BTW, I see no interrupt assigned to the Radeon, is this normal?
Regards,
Charl
--
charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/
---
This sf.net email is sponsored by: Jabber - The world's fastest growing
real-time communications platform! Don't just IM. Build it in!
http://www.jabber.com/osdn/xim
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeon mmio area size
On Tue, 16 Jul 2002, Keith Whitwell wrote: Can someone out there check this quickly? In radeon.h in the 2d driver, the size of the radeon mmio area is defined as 0x8 - however, on my r200 at least, /proc/pci shows the area as being 1/8th that size: Bus 1, device 0, function 0: ... (omitted) ... Non-prefetchable 32 bit memory at 0xff5f [0xff5f]. Can someone with a radeon installed make the same check? Keith Here's mine [...] Bus 1, device 0, function 0: VGA compatible controller: PCI device 1002:514c (ATI Technologies Inc) (rev 0). IRQ 9. Master Capable. Latency=32. Min Gnt=8. Prefetchable 32 bit memory at 0xd800 [0xdfff]. I/O at 0x9000 [0x90ff]. Non-prefetchable 32 bit memory at 0xe100 [0xe100]. Original ATI 8500, presume it's LE Cheers Mike --- This sf.net email is sponsored by: Jabber - The world's fastest growing real-time communications platform! Don't just IM. Build it in! http://www.jabber.com/osdn/xim ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Radeon switch to VT and back X freeze
Err, I forgot those attachments. Here they are, along with the complete
mail for future reference:
Dear list,
This is just to add another sample to the Radeon switch to VT and back X
freeze bug, which is apparently known.
I'm running the XFree86 4.2.0pre1v1 Debian packages on a Debian Woody system
with a Radeon driver snapshot of 20020715 as kindly supplied by dri.sf.net.
The card is a Radeon M7 (LW) in a noname brand laptop with an i845 chipset
and a Northwood P4.
So far, the DRI works wonderfully. glxgears yields a *very* impressive 1700
- 1800 FPS (with EnablePageFlip). However, when I switch to a VT (which
works) and then back, the X display mostly restores itself (some colour
artifacts, almost like we're seeing parts of some back buffer, which we're
not) but then promptly stops responding. I can still move the mouse
pointer, but that's it. X consumes 100% cpu according to top. I have to
shutdown at this point.
What I've tried so far:
- CVS checkout of DRI source and various crackpot hacks and experiments by
myself, mostly in RADEON{Enter,Leave}VT
- running X without DRI (by e.g. not modprobing the agpgart module) allows me
to switch to VTs and back to my heart's content; I need DRI however.
- various different kernel versions and configurations (currently at
2.4.19 with acpi 20020611 and swsusp patches; have tried without, no
success: ACPI is quite important though to keep this 2GHz desktop CPU cool)
- with and without radeonfb, with and without UseFBDev
- some of the radeon driver switches (e.g. CPPIOMode and ForcePCIMode)
- and more voodoo and late night craziness which I can't remember all that
well
To help make this a usefull sample point, I've attached the output of lspi
and lsmod, as well as XF86Config-4, XFree86.log and proc_interrupts.
BTW, I see no interrupt assigned to the Radeon, is this normal?
Regards,
Charl
--
charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/
00:00.0 Host bridge: Intel Corp. 82845 845 (Brookdale) Chipset Host Bridge (rev 04)
00:01.0 PCI bridge: Intel Corp. 82845 845 (Brookdale) Chipset AGP Bridge (rev 04)
00:1d.0 USB Controller: Intel Corp. 82801CA/CAM USB (Hub #1) (rev 02)
00:1d.1 USB Controller: Intel Corp. 82801CA/CAM USB (Hub #2) (rev 02)
00:1e.0 PCI bridge: Intel Corp. 82801BAM/CAM PCI Bridge (rev 42)
00:1f.0 ISA bridge: Intel Corp. 82801CAM ISA Bridge (LPC) (rev 02)
00:1f.1 IDE interface: Intel Corp. 82801CAM IDE U100 (rev 02)
00:1f.3 SMBus: Intel Corp. 82801CA/CAM SMBus (rev 02)
00:1f.5 Multimedia audio controller: Intel Corp. 82801CA/CAM AC'97 Audio (rev 02)
00:1f.6 Modem: Intel Corp. 82801CA/CAM AC'97 Modem (rev 02)
01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility M7 LW
02:04.0 FireWire (IEEE 1394): Texas Instruments TSB43AB22 1394a-2000 Controller
02:06.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C (rev 10)
02:07.0 CardBus bridge: Texas Instruments PCI1410 PC card Cardbus Controller (rev 01)
Module Size Used byNot tainted
i810_audio 19968 1
ac97_codec 9344 0 [i810_audio]
radeon 96952 2
agpgart20064 3
# XF86Config-4 (XFree86 server configuration file) generated by dexconf, the
# Debian X Configuration tool, using values from the debconf database.
#
# Edit this file with caution, and see the XF86Config-4 manual page.
# (Type man XF86Config-4 at the shell prompt.)
#
# If you want your changes to this file preserved by dexconf, only make changes
# before the ### BEGIN DEBCONF SECTION line above, and/or after the
# ### END DEBCONF SECTION line below.
#
# To change things within the debconf section, run the command:
# dpkg-reconfigure xserver-xfree86
# as root. Also see How do I add custom sections to a dexconf-generated
# XF86Config or XF86Config-4 file? in /usr/share/doc/xfree86-common/FAQ.gz.
Section Files
# FontPathunix/:7100# local font server
# if the local font server has problems, we can fall back on these
FontPath/usr/lib/X11/fonts/misc
FontPath/usr/lib/X11/fonts/cyrillic
FontPath/usr/lib/X11/fonts/100dpi/:unscaled
FontPath/usr/lib/X11/fonts/75dpi/:unscaled
FontPath/usr/lib/X11/fonts/Type1
FontPath/usr/lib/X11/fonts/Speedo
FontPath/usr/lib/X11/fonts/100dpi
FontPath/usr/lib/X11/fonts/75dpi
FontPath/usr/lib/X11/fonts/TrueType
EndSection
Section Module
LoadGLcore
Loadbitmap
Loaddbe
Loadddc
Loaddri
Loadextmod
Loadfreetype
Loadglx
Loadint10
Loadrecord
Loadspeedo
Loadtype1
Loadvbe
EndSection
Section InputDevice
Identifier Generic Keyboard
Driver keyboard
Option CoreKeyboard
Option
Re: [Dri-devel] r128 textures
On Tue, 16 Jul 2002, Henry Worth wrote: Have there been any reports of r128 texture color problems on x86 with recent CVS? Or that it even works? I just updated to today's build and texture colors look fine on r128 in x86. Also, we had reports that the changes made in Mesa on the trunk (which we merged into the mach64 branch) fixed textures on ppc for mach64, which has a choose texture function based on r128. -- Leif Delgass http://www.retinalburn.net --- This sf.net email is sponsored by: Jabber - The world's fastest growing real-time communications platform! Don't just IM. Build it in! http://www.jabber.com/osdn/xim ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: glx programs freezing with radeon
Slava Polyakov wrote: On July 16, 2002 04:15 pm, you wrote: Every so often (for example after 1hr of gameplay) a glx program like RTCW or WINE running SOF2 freezes... now, Only the program however, X is fine. However it freezes my mouse and kdb... if I telnet in and kill the offending process things are almost back to normal except my mouse accel isn't restored and the gamma is messed up... nothing in dmesg except the usual [drm:radeon_freelist_get] *ERROR* returning NULL! billion of those... I'm not sure, but it looks like a userspace lib issue, but I really dunno much about glx, so I really can't be sure... however the situation is described above. I can kill the offending process (which is of course eating up 100% CPU and doesn't respond to anything other then sigkill) More feedback possibly related These *might* have started happening after I installed folding@home (it's another distributed network client, so it's running at niceness of 19 and picking up all leftover cycles). Maybe because this process now fights with glx stuff for cycles some sort of race happens? During the really really old days before Michel Dänzer fixed the dma timeout problem for fast boxes I run a while(1); type of thing to compete with RTCW for cycles and slow my box down, but after Michel fixed it, everything was fine until now... (well about a week ago actually) i check out and rebuild cvs around once a week. And I installed folding@home around 2 weeks ago also. When this happens, can you use gdb to attach to the executable and get a backtrace? Keith --- This sf.net email is sponsored by: Jabber - The world's fastest growing real-time communications platform! Don't just IM. Build it in! http://www.jabber.com/osdn/xim ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] r128 textures
Leif Delgass wrote: On Tue, 16 Jul 2002, Henry Worth wrote: Have there been any reports of r128 texture color problems on x86 with recent CVS? Or that it even works? I just updated to today's build and texture colors look fine on r128 in x86. Also, we had reports that the changes made in Mesa on the trunk (which we merged into the mach64 branch) fixed textures on ppc for mach64, which has a choose texture function based on r128. Since the merge, the radeon PPC fixes added an additional swap in the texture path for BE systems. But, the texutil code already appear to have been endian aware and the radeon patches also appear to be fighting the endiness, and color ordering, neutral formating in tnl_dd_vertex.h by using arrays instead of the named color fields. Since x86 r128 is working, I'm going to prep my patches with the PACK*LE changes reverted. --- This sf.net email is sponsored by: Jabber - The world's fastest growing real-time communications platform! Don't just IM. Build it in! http://www.jabber.com/osdn/xim ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon switch to VT and back X freeze
On Tue, 2002-07-16 at 23:02, Charl P. Botha wrote:
The card is a Radeon M7 (LW) in a noname brand laptop with an i845 chipset
and a Northwood P4.
Interesting, the box I saw the problem on has an Intel 850/820 chipset.
IIRC earlier reports of this problem were from on Athlons though.
So far, the DRI works wonderfully. glxgears yields a *very* impressive 1700
- 1800 FPS (with EnablePageFlip). However, when I switch to a VT (which
works) and then back, the X display mostly restores itself (some colour
artifacts, almost like we're seeing parts of some back buffer, which we're
not) but then promptly stops responding. I can still move the mouse
pointer, but that's it. X consumes 100% cpu according to top. I have to
shutdown at this point.
What I've tried so far:
- CVS checkout of DRI source and various crackpot hacks and experiments by
myself, mostly in RADEON{Enter,Leave}VT
Probably the DMA ring gets stuck and the X server hangs trying to
acquire or fire an indirect buffer. My suspicion is that this is related
to AGP, but I have no evidence to support that. Maybe you can provide
some, see below.
BTW, I see no interrupt assigned to the Radeon, is this normal?
Yes, we don't use it yet.
Option AGPMode 2
Does 1x make a difference?
#Option CPPIOMode true # run CP in PIO instead of BM
# # actually just causes OOPS!
This isn't supported, I guess we should remove that option.
# Option ForcePCIMode On # not supported by DRI yet
The code is there but not enabled on x86 yet. Can you try with it
enabled? You need to define PCIGART_ENABLED both in the DRM and the 2D
driver. It would also be interesting to know how it works besides VT
switching, see that other thread. Beware that it used to be unstable and
may still crash, but I guess you've gotten used to that. ;)
--
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: Jabber - The world's fastest growing
real-time communications platform! Don't just IM. Build it in!
http://www.jabber.com/osdn/xim
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] r128 textures
On Wed, 2002-07-17 at 00:34, Henry Worth wrote: Leif Delgass wrote: On Tue, 16 Jul 2002, Henry Worth wrote: Have there been any reports of r128 texture color problems on x86 with recent CVS? Or that it even works? I just updated to today's build and texture colors look fine on r128 in x86. Also, we had reports that the changes made in Mesa on the trunk (which we merged into the mach64 branch) fixed textures on ppc for mach64, which has a choose texture function based on r128. Since the merge, the radeon PPC fixes added an additional swap in the texture path for BE systems. If I understand correctly, the endianness fixes are the Mesa changes Leif referred to. But, the texutil code already appear to have been endian aware It wasn't. One might argue that it still isn't, but it definitely wasn't before. :) and the radeon patches also appear to be fighting the endiness, and color ordering, neutral formating in tnl_dd_vertex.h by using arrays instead of the named color fields. I don't understand what you're talking about. A lot of my fixes have been exactly to get rid of fixed offsets into char arrays. Since x86 r128 is working, I'm going to prep my patches with the PACK*LE changes reverted. Looking forward to your patches, it's hard for me to understand without seeing the changes you're making to the code. -- 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: Jabber - The world's fastest growing real-time communications platform! Don't just IM. Build it in! http://www.jabber.com/osdn/xim ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: glx programs freezing with radeon
On July 16, 2002 06:19 pm, you wrote: Slava Polyakov wrote: On July 16, 2002 04:15 pm, you wrote: Every so often (for example after 1hr of gameplay) a glx program like RTCW or WINE running SOF2 freezes... now, Only the program however, X is fine. However it freezes my mouse and kdb... if I telnet in and kill the offending process things are almost back to normal except my mouse accel isn't restored and the gamma is messed up... nothing in dmesg except the usual [drm:radeon_freelist_get] *ERROR* returning NULL! billion of those... I'm not sure, but it looks like a userspace lib issue, but I really dunno much about glx, so I really can't be sure... however the situation is described above. I can kill the offending process (which is of course eating up 100% CPU and doesn't respond to anything other then sigkill) More feedback possibly related These *might* have started happening after I installed folding@home (it's another distributed network client, so it's running at niceness of 19 and picking up all leftover cycles). Maybe because this process now fights with glx stuff for cycles some sort of race happens? During the really really old days before Michel Dänzer fixed the dma timeout problem for fast boxes I run a while(1); type of thing to compete with RTCW for cycles and slow my box down, but after Michel fixed it, everything was fine until now... (well about a week ago actually) i check out and rebuild cvs around once a week. And I installed folding@home around 2 weeks ago also. When this happens, can you use gdb to attach to the executable and get a backtrace? Keith Well, this brings up a problem, or more specifically a question, I usually compile stuff without frame pointers, desperate for any bit of speed. However, I can certainly recompile X with frame pointers and I assume that will also recompile all the glx supporting libs (libGL?)... However, the real problem is that it's the software that freezes like say, RTCW (which is a commercial game so it has no debugging syms or framepointers) and sof2... So I'm not really sure what I should be giving you a backtrace of Or even if one is possible since the freeze happens in the program that I'm running, and the only gl software I run long enough are these games. --- This sf.net email is sponsored by: Jabber - The world's fastest growing real-time communications platform! Don't just IM. Build it in! http://www.jabber.com/osdn/xim ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon switch to VT and back X freeze
On Wed, 2002-07-17 at 01:19, Steven Walter wrote: I have a Radeon 7500 QW, and also get the vt-switch bug. I'm running DRI cvs trunk as of a few days ago. Something interesting that I have found is a correlation to the xvidmode extension. With it enabled, the first switch-away/switch-back will cause a hard lock. The screen mostly restores, but even the mouse and keyboard are solidly wedged. With xvidmode disabled, X will lock in the same way after exactly TWO switch-away/switch-backs. Just a curious data point. Interesting though - how do you disable it? Could be the AdjustFrame() call in EnterVT() interfering or something... -- 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: Jabber - The world's fastest growing real-time communications platform! Don't just IM. Build it in! http://www.jabber.com/osdn/xim ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] r128 textures
On 17 Jul 2002, Michel Dänzer wrote: I just updated to today's build and texture colors look fine on r128 in x86. Also, we had reports that the changes made in Mesa on the trunk (which we merged into the mach64 branch) fixed textures on ppc for mach64, which has a choose texture function based on r128. Since the merge, the radeon PPC fixes added an additional swap in the texture path for BE systems. If I understand correctly, the endianness fixes are the Mesa changes Leif referred to. Right. The merge from the trunk to the mach64 branch was done June 26 -- after the endianess fixes. -- Leif Delgass http://www.retinalburn.net --- This sf.net email is sponsored by: Jabber - The world's fastest growing real-time communications platform! Don't just IM. Build it in! http://www.jabber.com/osdn/xim ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon switch to VT and back X freeze
On Wed, Jul 17, 2002 at 01:37:01AM +0200, Michel D?nzer wrote: On Wed, 2002-07-17 at 01:19, Steven Walter wrote: I have a Radeon 7500 QW, and also get the vt-switch bug. I'm running DRI cvs trunk as of a few days ago. Something interesting that I have found is a correlation to the xvidmode extension. With it enabled, the first switch-away/switch-back will cause a hard lock. The screen mostly restores, but even the mouse and keyboard are solidly wedged. With xvidmode disabled, X will lock in the same way after exactly TWO switch-away/switch-backs. Just a curious data point. Interesting though - how do you disable it? Could be the AdjustFrame() call in EnterVT() interfering or something... I disable it by commenting the EnableXVidModeExtension line in XFree86, and optionally adding an explicit DisableXVidModeExtension. The latter doesn't seem to make any difference. -- -Steven In a time of universal deceit, telling the truth is a revolutionary act. -- George Orwell This concept of wuv confuses and infuriates us! -- Lur of Omicron Persei VIII --- This sf.net email is sponsored by: Jabber - The world's fastest growing real-time communications platform! Don't just IM. Build it in! http://www.jabber.com/osdn/xim ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Xpert]Problems with a Radeon mobility M6 andRH 7.3
On Tue, 2002-07-16 at 17:56, José Fonseca wrote: I'm CC'ing to dri-devel as well to get a broaded audience. On Tue, Jul 16, 2002 at 05:28:37PM +0200, dylan wrote: Good plan, The DRM module is not happy and throws a bit of a fit. Here is a small snippet showing the exact response, how would I go about upgrading the drm module or would I have to wait until the 1671 is supported. I am going to try the agp_try_unsupported=1 in the mean time. Thanks again. Jul 16 17:41:26 Coke modprobe: modprobe: Can't locate module char-major-226 Jul 16 17:41:27 Coke modprobe: modprobe: Can't locate module char-major-226 Jul 16 17:41:27 Coke kernel: Linux agpgart interface v0.99 (c) Jeff Hartmann Jul 16 17:41:27 Coke kernel: agpgart: Maximum main memory to use for agp memory: 202M Jul 16 17:41:27 Coke kernel: agpgart: Unsupported Ali chipset (device id: 1671), you might want to try agp_try_unsupported=1. If agp_try_unsupported=1 doesn't work you may be on a world of pain... Jul 16 17:41:27 Coke kernel: [drm] Initialized radeon 1.1.1 20010405 on minor 0 Jul 16 17:41:27 Coke kernel: [drm:radeon_do_init_cp] *ERROR* PCI GART not yet supported for Radeon! PCI could be supported for Radeon. I don't know if this support has been added since 4.2.0. If yes then you could try a binary snapshot from http://dri.sf.net/snapshots . It's there but still only enabled on alpha (and powerpc in DRI CVS) because it's apparently unstable on x86. What happens below shouldn't really happen, no matter what. Indeed. Trace: [d09b4f85] radeon_cp_stop [radeon] 0xf5 Jul 16 17:41:27 Coke kernel: [d09afe14] radeon_ioctl [radeon] 0xe4 Jul 16 17:41:27 Coke kernel: [c0146547] sys_ioctl [kernel] 0x217 Jul 16 17:41:27 Coke kernel: [c0108923] system_call [kernel] 0x33 Jul 16 17:41:27 Coke Hmm. If the AGP initialization fails, RADEONDRICloseScreen() is called, which unconditionally calls RADEONCP_STOP(), which in turn calls the CP stop ioctl. It's not obvious to me where in radeon_cp_stop() it crashes though. I wonder how PCI GART actually works on x86 with the current driver in DRI CVS. On PPC, it's become very stable with AGP GART, which used to be unstable with older versions of the driver. We could get rid of quite some potentially problematic code if we enabled PCI GART everywhere. -- 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: Jabber - The world's fastest growing real-time communications platform! Don't just IM. Build it in! http://www.jabber.com/osdn/xim ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] r128 PPC patches
Attached are patches for r128 on ppc. Rather little change to the r128 code was needed once I gave up on the char arrays for the vertex colors, and embraced the hw specific ordered named fields provided in the *_color_t provided by t_dd_vertex.h. 1) Revert PACK*LE from texutil.c as per previous emails. 2) t_dd_vbtmp.h has color assignments in the emit functions that use char arrays for non-RGBA without attention to endiness. Changed to use the correctly ordered named fields from the t_dd_vertex.h definition of the hw vertex color_t. Added VERTEX_COLOR_T macro so hw driver can pass in its hw vertex *_color_t; so the assignments can be made in correct order. Added macro definition to *_vb.c of the various drivers. 3) Changed r128_tris.c VERT_* macros for t_dd_tritmp.h to use the named fields instead of an char array. 4) Added some casts to r128_ioctl.c to eliminate compile warnings. r128-ppc-diffs.gz Description: GNU Zip compressed data
Re: [Dri-devel] r128 textures
Leif Delgass wrote: On 17 Jul 2002, Michel Dänzer wrote: I just updated to today's build and texture colors look fine on r128 in x86. Also, we had reports that the changes made in Mesa on the trunk (which we merged into the mach64 branch) fixed textures on ppc for mach64, which has a choose texture function based on r128. Since the merge, the radeon PPC fixes added an additional swap in the texture path for BE systems. If I understand correctly, the endianness fixes are the Mesa changes Leif referred to. Right. The merge from the trunk to the mach64 branch was done June 26 -- after the endianess fixes. 1 I can find no extra byte swapping being done to textures in the r128 code and dword swaps at later point in the pipeline would break 16 and 8 bpp textures. 2 The r128 texture code works without PACK*LE works on both LE and BE systems in both 32bpp and 16bpp. None of the code I had to change except the PACK*LE would affect textures. 3 Any change that I can see to make to work with the PACK*LE would have to be conditional on endiness to not break x86. But that would be redundant! 4 Something is wrong, but where? --- This sf.net email is sponsored by: Jabber - The world's fastest growing real-time communications platform! Don't just IM. Build it in! http://www.jabber.com/osdn/xim ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: r128 PPC patches
On Wed, 2002-07-17 at 02:10, Henry Worth wrote: Attached are patches for r128 on ppc. Rather little change to the r128 code was needed once I gave up on the char arrays for the vertex colors, and embraced the hw specific ordered named fields provided in the *_color_t provided by t_dd_vertex.h. 1) Revert PACK*LE from texutil.c as per previous emails. Thank you for breaking the radeon and mach64 drivers on big endian machines. ;) We've got to find a better solution here, I must confess I still don't understand how it can not work with PACK*LE though. Maybe the HOST_BIG_ENDIAN_EN bit in the DP_DATATYPE register (set in R128EngineInit() in the 2D driver) is interfering, causing the texture data to be byte-swapped in the HOST_DATA registers? If so, your changes should not be really correct for 16 bit anyway. I've been there while playing with the various possibilities of fixing endianness in the radeon driver, it looked mostly good but e.g. the floor texture in armagetron showed the problem. 2) t_dd_vbtmp.h has color assignments in the emit functions that use char arrays for non-RGBA without attention to endiness. Changed to use the correctly ordered named fields from the t_dd_vertex.h definition of the hw vertex color_t. Added VERTEX_COLOR_T macro so hw driver can pass in its hw vertex *_color_t; so the assignments can be made in correct order. Added macro definition to *_vb.c of the various drivers. 3) Changed r128_tris.c VERT_* macros for t_dd_tritmp.h to use the named fields instead of an char array. 4) Added some casts to r128_ioctl.c to eliminate compile warnings. These look very good to me, I'll commit them. Leif, can you verify they don't break x86? I'd be very surprised, but it wouldn't be the first time. :) -- 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: Jabber - The world's fastest growing real-time communications platform! Don't just IM. Build it in! http://www.jabber.com/osdn/xim ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: r128 PPC patches
Michel Dänzer wrote: On Wed, 2002-07-17 at 02:10, Henry Worth wrote: Attached are patches for r128 on ppc. Rather little change to the r128 code was needed once I gave up on the char arrays for the vertex colors, and embraced the hw specific ordered named fields provided in the *_color_t provided by t_dd_vertex.h. 1) Revert PACK*LE from texutil.c as per previous emails. Thank you for breaking the radeon and mach64 drivers on big endian machines. ;) We've got to find a better solution here, I must confess I still don't understand how it can not work with PACK*LE though. Maybe the HOST_BIG_ENDIAN_EN bit in the DP_DATATYPE register (set in R128EngineInit() in the 2D driver) is interfering, causing the texture data to be byte-swapped in the HOST_DATA registers? If so, your changes should not be really correct for 16 bit anyway. I've been there while playing with the various possibilities of fixing endianness in the radeon driver, it looked mostly good but e.g. the floor texture in armagetron showed the problem. You're welcome. At least with the mesa demos it works the same in 16 and 32 bpp... I did see some oddness in 16bpp before fixing the copies in the t_dd_vbtmp.h emit funcs. I don't have the HW docs, so someone else will have to address that. Any byteswapping at that level would have to be aware of the texel size or it'd also be swapping sub-32bpp texels out of order. But, if it is due to a hw capability, then the sw arch needs to handle that, i.e. make the PACK*LE configurable. Which would probably mean texutil would need to be compiled at the driver level, rather than the common level. --- This sf.net email is sponsored by: Jabber - The world's fastest growing real-time communications platform! Don't just IM. Build it in! http://www.jabber.com/osdn/xim ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: r128 PPC patches
Michel Dänzer wrote: Thank you for breaking the radeon and mach64 drivers on big endian machines. ;) We've got to find a better solution here, I must confess I still don't understand how it can not work with PACK*LE though. Maybe the HOST_BIG_ENDIAN_EN bit in the DP_DATATYPE register (set in R128EngineInit() in the 2D driver) is interfering, causing the texture data to be byte-swapped in the HOST_DATA registers? If so, your changes should not be really correct for 16 bit anyway. I've been there while playing with the various possibilities of fixing endianness in the radeon driver, it looked mostly good but e.g. the floor texture in armagetron showed the problem. I gave the driver a quick try without the HOST_BIG_ENDIAN_EN bit set and with the PACK*LE macros. And, the 2-d stuff seems to be working and the textures do need the PACK*LE macros. So, perhaps the bit only impacts the DMA blits used to load the texture subimages? If someone with the docs can confirm what that bit is suppose to do, we may get be able to getaway with eliminating that bit. --- This sf.net email is sponsored by: Jabber - The world's fastest growing real-time communications platform! Don't just IM. Build it in! http://www.jabber.com/osdn/xim ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: glx programs freezing with radeon
Slava Polyakov wrote: On July 16, 2002 06:19 pm, you wrote: Slava Polyakov wrote: On July 16, 2002 04:15 pm, you wrote: Every so often (for example after 1hr of gameplay) a glx program like RTCW or WINE running SOF2 freezes... now, Only the program however, X is fine. However it freezes my mouse and kdb... if I telnet in and kill the offending process things are almost back to normal except my mouse accel isn't restored and the gamma is messed up... nothing in dmesg except the usual [drm:radeon_freelist_get] *ERROR* returning NULL! billion of those... I'm not sure, but it looks like a userspace lib issue, but I really dunno much about glx, so I really can't be sure... however the situation is described above. I can kill the offending process (which is of course eating up 100% CPU and doesn't respond to anything other then sigkill) More feedback possibly related These *might* have started happening after I installed folding@home (it's another distributed network client, so it's running at niceness of 19 and picking up all leftover cycles). Maybe because this process now fights with glx stuff for cycles some sort of race happens? During the really really old days before Michel Dänzer fixed the dma timeout problem for fast boxes I run a while(1); type of thing to compete with RTCW for cycles and slow my box down, but after Michel fixed it, everything was fine until now... (well about a week ago actually) i check out and rebuild cvs around once a week. And I installed folding@home around 2 weeks ago also. When this happens, can you use gdb to attach to the executable and get a backtrace? Keith Well, this brings up a problem, or more specifically a question, I usually compile stuff without frame pointers, desperate for any bit of speed. However, I can certainly recompile X with frame pointers and I assume that will also recompile all the glx supporting libs (libGL?)... However, the real problem is that it's the software that freezes like say, RTCW (which is a commercial game so it has no debugging syms or framepointers) and sof2... So I'm not really sure what I should be giving you a backtrace of Or even if one is possible since the freeze happens in the program that I'm running, and the only gl software I run long enough are these games. As long as the driver.so is compiled with debugging you'll be able to get a partial backtrace, which is all you need. Keith --- This sf.net email is sponsored by: Jabber - The world's fastest growing real-time communications platform! Don't just IM. Build it in! http://www.jabber.com/osdn/xim ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: r128 PPC patches
Henry Worth wrote: I gave the driver a quick try without the HOST_BIG_ENDIAN_EN bit set and with the PACK*LE macros. And, the 2-d stuff seems to be working and the textures do need the PACK*LE macros. So, perhaps the bit only impacts the DMA blits used to load the texture subimages? If someone with the docs can confirm what that bit is suppose to do, we may get be able to getaway with eliminating that bit. Found a big pro and con for running without that bit set--- XV! Xine playing a DVD requires 40% less cpu time on dual 450 G4's. That's likely from reduced byte-swapping and would hold the promise of most G3's with Rage 128's finally being able to play DVD's without dropped frames. The con... it's very unstable and subject to server and system hangs. Concurrently trying to move windows is impossibly slow and jerky, and may cause artifacts and momentary (multi-second) hangs. In one case the server and system (telnet session wouldn't respond) hung till I moved the mouse. Trying to run glxgears causes an instant server hang. For comparison, with 4.2.0 I can load up the system with makes and seti's to 99+% and then start xine and glxgears. And while xine is dropping a lot of frames, playback has only a slight flutter and X is still responsive enough to fireup and use mozilla. BTW, I'm in forced PCI mode, which has been needed for XV and DRI to run concurrently, but will have to give AGP mode a try. Looks like some nasty DMA contention problems, perhaps the kernel drivers need some compensating changes? Henry --- This sf.net email is sponsored by: Jabber - The world's fastest growing real-time communications platform! Don't just IM. Build it in! http://www.jabber.com/osdn/xim ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: r128 PPC patches
On Wed, 2002-07-17 at 03:57, Henry Worth wrote: Michel Dänzer wrote: Thank you for breaking the radeon and mach64 drivers on big endian machines. ;) We've got to find a better solution here, I must confess I still don't understand how it can not work with PACK*LE though. Maybe the HOST_BIG_ENDIAN_EN bit in the DP_DATATYPE register (set in R128EngineInit() in the 2D driver) is interfering, causing the texture data to be byte-swapped in the HOST_DATA registers? If so, your changes should not be really correct for 16 bit anyway. I've been there while playing with the various possibilities of fixing endianness in the radeon driver, it looked mostly good but e.g. the floor texture in armagetron showed the problem. I gave the driver a quick try without the HOST_BIG_ENDIAN_EN bit set and with the PACK*LE macros. And, the 2-d stuff seems to be working and the textures do need the PACK*LE macros. So, perhaps the bit only impacts the DMA blits used to load the texture subimages? Possibly. The HOST_DATA registers are used for other stuff but HOST_BIG_ENDIAN_EN seems to be sensitive to the advertised format and the other users maybe set formats which don't cause bytes to get swapped. If someone with the docs can confirm what that bit is suppose to do, we The register reference isn't very clear, it just says the bit causes bytes to be swapped according to the 'pixel width'. No mention where they get swapped (I assume in the HOST_DATA registers) or how the pixel width is determined (I assume from the data type set in the DP_GUI_MASTER_CNTL register). may get be able to getaway with eliminating that bit. I'm convinced that's the only way, as I'll explain in a followup to your other post. But first, I have to get some sleep... -- 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: Jabber - The world's fastest growing real-time communications platform! Don't just IM. Build it in! http://www.jabber.com/osdn/xim ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: r128 PPC patches
On 17 Jul 2002, Michel Dänzer wrote: On Wed, 2002-07-17 at 02:10, Henry Worth wrote: Attached are patches for r128 on ppc. Rather little change to the r128 code was needed once I gave up on the char arrays for the vertex colors, and embraced the hw specific ordered named fields provided in the *_color_t provided by t_dd_vertex.h. 1) Revert PACK*LE from texutil.c as per previous emails. Thank you for breaking the radeon and mach64 drivers on big endian machines. ;) We've got to find a better solution here, I must confess I still don't understand how it can not work with PACK*LE though. Maybe the HOST_BIG_ENDIAN_EN bit in the DP_DATATYPE register (set in R128EngineInit() in the 2D driver) is interfering, causing the texture data to be byte-swapped in the HOST_DATA registers? If so, your changes should not be really correct for 16 bit anyway. I've been there while playing with the various possibilities of fixing endianness in the radeon driver, it looked mostly good but e.g. the floor texture in armagetron showed the problem. I don't have r128 docs, so I'm not sure if it's analogous, but for mach64 we don't set HOST_BIG_ENDIAN_ENABLE in HOST_CNTL, and as far as I know the DDX doesn't either, so that could make the difference. 2) t_dd_vbtmp.h has color assignments in the emit functions that use char arrays for non-RGBA without attention to endiness. Changed to use the correctly ordered named fields from the t_dd_vertex.h definition of the hw vertex color_t. Added VERTEX_COLOR_T macro so hw driver can pass in its hw vertex *_color_t; so the assignments can be made in correct order. Added macro definition to *_vb.c of the various drivers. 3) Changed r128_tris.c VERT_* macros for t_dd_tritmp.h to use the named fields instead of an char array. 4) Added some casts to r128_ioctl.c to eliminate compile warnings. These look very good to me, I'll commit them. Leif, can you verify they don't break x86? I'd be very surprised, but it wouldn't be the first time. :) I'll give these a try once I've updated my tree, I was testing from binaries before. -- Leif Delgass http://www.retinalburn.net --- This sf.net email is sponsored by: Jabber - The world's fastest growing real-time communications platform! Don't just IM. Build it in! http://www.jabber.com/osdn/xim ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: r128 PPC patches
Henry Worth wrote: Henry Worth wrote: I gave the driver a quick try without the HOST_BIG_ENDIAN_EN bit set and with the PACK*LE macros. And, the 2-d stuff seems to be working and the textures do need the PACK*LE macros. So, perhaps the bit only impacts the DMA blits used to load the texture subimages? If someone with the docs can confirm what that bit is suppose to do, we may get be able to getaway with eliminating that bit. Found a big pro and con for running without that bit set--- XV! Ack, I'll have to retract both the pro and con. I forgot that I was working from a fresh src tree that didn't have Michel's indirect buffering and XV dma fixes that are required for stable XV with SMP linuxppc. Stablility with SMP linuxppc kernels requires disabling XV dma and forcing PCI mode. With the patches performance and stability are back where they were before. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
