Re: radeon big endian patch

2005-02-13 Thread Benjamin Herrenschmidt
On Sat, 2005-02-12 at 23:56 -0500, Michel Dänzer wrote:
 On Sun, 2005-02-13 at 15:16 +1100, Benjamin Herrenschmidt wrote:
  
  Those are still incorrect as they totally lack memory barriers...
 
 INREG() doesn't (or does it?), and it's the only one used by the 3D
 drivers.

Hrm.. in fact, you are always writing to indirect buffers here,  right ?

If this is true, all you need is a barrier between the last store to it
and whatever store makes the buffer visible to the chip. If you use only
uncached access (like AGP GART), then only an eieio is necessary, but if
you use PCI GART which works with a cacheable mapping in main memory,
you probably need a full sync.




---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95alloc_id396op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: radeon big endian patch

2005-02-13 Thread Michel Dänzer
On Mon, 2005-02-14 at 09:07 +1100, Benjamin Herrenschmidt wrote:
 On Sat, 2005-02-12 at 23:56 -0500, Michel Dnzer wrote:
  On Sun, 2005-02-13 at 15:16 +1100, Benjamin Herrenschmidt wrote:
   
   Those are still incorrect as they totally lack memory barriers...
  
  INREG() doesn't (or does it?), and it's the only one used by the 3D
  drivers.
 
 Hrm.. in fact, you are always writing to indirect buffers here,  right ?
 
 If this is true, all you need is a barrier between the last store to it
 and whatever store makes the buffer visible to the chip. If you use only
 uncached access (like AGP GART), then only an eieio is necessary, 

Yes, the DRM does this, always has...

 but if you use PCI GART which works with a cacheable mapping in main 
 memory, you probably need a full sync.

Hasn't seemed necessary all these years.


-- 
Earthling Michel Dnzer  | Debian (powerpc), X and DRI developer
Libre software enthusiast|   http://svcs.affero.net/rm.php?r=daenzer


---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95alloc_id396op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: radeon big endian patch

2005-02-13 Thread Benjamin Herrenschmidt
On Sun, 2005-02-13 at 19:25 -0500, Michel Dänzer wrote:
 On Mon, 2005-02-14 at 09:07 +1100, Benjamin Herrenschmidt wrote:
  On Sat, 2005-02-12 at 23:56 -0500, Michel Dänzer wrote:
   On Sun, 2005-02-13 at 15:16 +1100, Benjamin Herrenschmidt wrote:

Those are still incorrect as they totally lack memory barriers...
   
   INREG() doesn't (or does it?), and it's the only one used by the 3D
   drivers.
  
  Hrm.. in fact, you are always writing to indirect buffers here,  right ?
  
  If this is true, all you need is a barrier between the last store to it
  and whatever store makes the buffer visible to the chip. If you use only
  uncached access (like AGP GART), then only an eieio is necessary, 
 
 Yes, the DRM does this, always has...
 
  but if you use PCI GART which works with a cacheable mapping in main 
  memory, you probably need a full sync.
 
 Hasn't seemed necessary all these years.

Because you were lucky enough :) But CPUs like the 970 are much more
aggressive with re-ordering of stores and speculation of loads...

Ben.




---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95alloc_id396op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


radeon big endian patch

2005-02-12 Thread Jerome Glisse
Hi,

Could anyone apply this patch if it looks good.
This correct the problem many ppc user have
using the Mesa-dri cvs which does not do the
swapping for bendian.

The code came from Michel, i am only doing
the patch and the #ifdef things :)

Jerome Glisse


mesa_bendian
Description: Binary data


Re: radeon big endian patch

2005-02-12 Thread Michel Dänzer
On Sat, 2005-02-12 at 13:03 +0100, Jerome Glisse wrote:
 
 Could anyone apply this patch if it looks good.
 This correct the problem many ppc user have
 using the Mesa-dri cvs which does not do the
 swapping for bendian.
 
 The code came from Michel, i am only doing
 the patch and the #ifdef things :)

How about something like this instead?


-- 
Earthling Michel Dnzer  | Debian (powerpc), X and DRI developer
Libre software enthusiast|   http://svcs.affero.net/rm.php?r=daenzer
Index: src/mesa/drivers/dri/radeon/server/radeon_macros.h
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/radeon/server/radeon_macros.h,v
retrieving revision 1.2
diff -p -u -r1.2 radeon_macros.h
--- src/mesa/drivers/dri/radeon/server/radeon_macros.h	6 Aug 2003 18:11:00 -	1.2
+++ src/mesa/drivers/dri/radeon/server/radeon_macros.h	12 Feb 2005 17:40:48 -
@@ -40,28 +40,22 @@
 #ifndef _RADEON_MACROS_H_
 #define _RADEON_MACROS_H_
 
-
+#include mmio.h
 
 #  define MMIO_IN8(base, offset) \
 	*(volatile unsigned char *)(((unsigned char*)(base)) + (offset))
-#  define MMIO_IN16(base, offset) \
-	*(volatile unsigned short *)(void *)(((unsigned char*)(base)) + (offset))
 #  define MMIO_IN32(base, offset) \
-	*(volatile unsigned int *)(void *)(((unsigned char*)(base)) + (offset))
+	read_MMIO_LE32(RADEONMMIO, addr)
 #  define MMIO_OUT8(base, offset, val) \
 	*(volatile unsigned char *)(((unsigned char*)(base)) + (offset)) = (val)
-#  define MMIO_OUT16(base, offset, val) \
-	*(volatile unsigned short *)(void *)(((unsigned char*)(base)) + (offset)) = (val)
 #  define MMIO_OUT32(base, offset, val) \
-	*(volatile unsigned int *)(void *)(((unsigned char*)(base)) + (offset)) = (val)
+	*(volatile unsigned int *)(void *)(((unsigned char*)(base)) + (offset)) = CPU_TO_LE32(val)
 
 
 /* Memory mapped register access macros */
 #define INREG8(addr)MMIO_IN8(RADEONMMIO, addr)
-#define INREG16(addr)   MMIO_IN16(RADEONMMIO, addr)
 #define INREG(addr) MMIO_IN32(RADEONMMIO, addr)
 #define OUTREG8(addr, val)  MMIO_OUT8(RADEONMMIO, addr, val)
-#define OUTREG16(addr, val) MMIO_OUT16(RADEONMMIO, addr, val)
 #define OUTREG(addr, val)   MMIO_OUT32(RADEONMMIO, addr, val)
 
 #define ADDRREG(addr)   ((volatile GLuint *)(pointer)(RADEONMMIO + (addr)))
Index: src/mesa/drivers/dri/common/mmio.h
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/common/mmio.h,v
retrieving revision 1.2
diff -p -u -r1.2 mmio.h
--- src/mesa/drivers/dri/common/mmio.h	14 Dec 2004 09:11:52 -	1.2
+++ src/mesa/drivers/dri/common/mmio.h	12 Feb 2005 17:40:48 -
@@ -38,12 +38,11 @@
 static __inline__ u_int32_t
 read_MMIO_LE32( volatile void * base, unsigned long offset )
 {
-   volatile void * p = ((volatile char *) base) + offset;
u_int32_t val;
-   
+
__asm__ __volatile__( lwbrx	%0, %1, %2 ; eieio
 			 : =r (val)
-			 : b (base), r (offset), m (p) );
+			 : b (base), r (offset) );
return val;
 }
 


Re: radeon big endian patch

2005-02-12 Thread Benjamin Herrenschmidt
On Sat, 2005-02-12 at 12:42 -0500, Michel Dänzer wrote:
 On Sat, 2005-02-12 at 13:03 +0100, Jerome Glisse wrote:
  
  Could anyone apply this patch if it looks good.
  This correct the problem many ppc user have
  using the Mesa-dri cvs which does not do the
  swapping for bendian.
  
  The code came from Michel, i am only doing
  the patch and the #ifdef things :)
 
 How about something like this instead?

Those are still incorrect as they totally lack memory barriers...

Ben.




---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95alloc_id396op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: radeon big endian patch

2005-02-12 Thread Michel Dänzer
On Sun, 2005-02-13 at 15:16 +1100, Benjamin Herrenschmidt wrote:
 
 Those are still incorrect as they totally lack memory barriers...

INREG() doesn't (or does it?), and it's the only one used by the 3D
drivers.


-- 
Earthling Michel Dnzer  | Debian (powerpc), X and DRI developer
Libre software enthusiast|   http://svcs.affero.net/rm.php?r=daenzer


---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95alloc_id396op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel