Re: [Dri-devel] R200-0-1-branch devfs patch.

2002-07-16 Thread Michel Dänzer

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

2002-07-16 Thread José Fonseca

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

2002-07-16 Thread Leif Delgass

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

2002-07-16 Thread José Fonseca

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

2002-07-16 Thread José Fonseca

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

2002-07-16 Thread Keith Whitwell

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

2002-07-16 Thread Keith Whitwell


 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

2002-07-16 Thread Leif Delgass

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

2002-07-16 Thread Keith Whitwell

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

2002-07-16 Thread Marc Poulhiès

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

2002-07-16 Thread Slava Polyakov

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

2002-07-16 Thread Slava Polyakov

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

2002-07-16 Thread Michal Bukovjan

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

2002-07-16 Thread Charl P. Botha

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

2002-07-16 Thread Marc Poulhiès

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

2002-07-16 Thread Al Tobey

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

2002-07-16 Thread Stefan Lange

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

2002-07-16 Thread Charl P. Botha

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

2002-07-16 Thread Michal Kozlowski

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

2002-07-16 Thread Charl P. Botha

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

2002-07-16 Thread Leif Delgass

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

2002-07-16 Thread Keith Whitwell

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

2002-07-16 Thread Henry Worth

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

2002-07-16 Thread Michel Dänzer

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

2002-07-16 Thread Michel Dänzer

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

2002-07-16 Thread Slava Polyakov

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

2002-07-16 Thread Michel Dänzer

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

2002-07-16 Thread Leif Delgass

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

2002-07-16 Thread Steven Walter

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

2002-07-16 Thread Michel Dänzer

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

2002-07-16 Thread Henry Worth


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

2002-07-16 Thread Henry Worth

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

2002-07-16 Thread Michel Dänzer

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

2002-07-16 Thread Henry Worth

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

2002-07-16 Thread Henry Worth

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

2002-07-16 Thread Keith Whitwell

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

2002-07-16 Thread Henry Worth

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

2002-07-16 Thread Michel Dänzer

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

2002-07-16 Thread Leif Delgass

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

2002-07-16 Thread Henry Worth

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