Re: r300 on a powerbook (ppc)
We know this issue, i will submit a patch latter. This is very simple, in radeon_macro.h of Mesa cvs there is no swapping for big endian. While the dri included with Xorg use the xorg macro to access reg and thus have swapping. If you wish just change the radeon_macro.h so it does the 32LENDIAN to 32BENDIAN conv. Jerome Glisse On Sat, 12 Feb 2005 16:55:55 +1100, Paul Mackerras [EMAIL PROTECTED] wrote: I have been trying the r300 driver on my aluminium powerbook (1.5GHz G4 with radeon M10 (NP)). When I run a GL program such as glxgears, it draws a window complete with frame but then renders the image into a region vertically below the window. Somehow the base address being used to compute framebuffer addresses for 3D primitives is wrong. Which register is that base address stored in? Thanks, Paul. --- 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_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
radeon big endian patch
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: EDID describing subpixel ordering
On Fri, 11 Feb 2005, Jon Smirl wrote: Microsoft is developing a proposal to VESA to allow the identification of these characteristics in the monitor EDID (Extended Display Ok, this may be totally uncalled for/unfair/whatever and way off-topic but here goes... I hope nobody minds me asking. This proposal that microsoft develops, is it free for anyone to use? Inquiring (suspicious) minds wants to know... :-) Best regards Peter K, paranoid. --- 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_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: savage-20050205-linux snapshot - problems
Am Donnerstag, den 10.02.2005, 07:21 +0100 schrieb [EMAIL PROTECTED]: On Monday 07 February 2005 15:33, Felix K=FChling wrote: Am Montag, den 07.02.2005, 15:12 +0100 schrieb=20 [EMAIL PROTECTED]: Hardware: Toshiba Libretto L2 Tm5600 with: :00:04.0 VGA compatible controller: S3 Inc. 86C270-294=3D20 Savage/IX-MV (rev 13) (prog-if 00 [VGA]) Subsystem: Toshiba America Info Systems: Unknown device 0001 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-=3D Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=3D3Dmedium TAbort- =3D TAbort- MAbort- SERR- PERR- Latency: 248 (1000ns min, 63750ns max), cache line size 08 Interrupt: pin A routed to IRQ 11 Region 0: Memory at e000 (32-bit, non-prefetchable) [size=3D3D128=3D M] Expansion ROM at 000c [disabled] [size=3D3D64K] Capabilities: available only to root Software: Gentoo current with Gentoo supplied X Window System Version 6.8.1.903 (6.8.=3D 2 RC 3) Release Date: 25 January 2005 X Protocol Version 11, Revision 0, Release 6.8.1.903 Build Operating System: Linux 2.4.29-rc3-mhf239 i686 [ELF]=3D20 Current Operating System: Linux mhfl4 2.4.29-rc3-mhf239 #2 Tue Jan 18 17:43=3D :33 CET 2005 i686 Build Date: 05 February 2005 Installed snapshot from savage-20050205-linux.i386.tar.bz2. On starting X: [snip] So, driver in snapshot still reports 1.0. Seems to be quite old (2001). The new Savage DRM 2.0.0 (in fact 2.2.0 by now) is only available for Linux 2.6.=20 Tested with 2.6.11-rc3. DRM functional with glxgears. tuxkart and tuxracer work most the time but sometimes=20 painting occurs outside of games window. Parts of the image=20 appear (sometime mirrored) outside game window or random=20 patterns appear. I can't reproduce this on my Savage/IX. Someone else reported problems with 2.6.11-rc3, something like it wouldn't even load the DRM modules. Maybe something's broken with current DRM on Linux 2.6.11-rc3. If this problem persists with the latest snapshot (tomorrow's should have my latest fixes) could you try if it works with a stock 2.6.10 kernel (you'd have to recompile the DRM for it)? Cursor and numeric display in game window=20 appear as random patterns. I just fixed another bug in texture tiling on Savage/IX. Though it only affected the road-texture in Tuxkart for me. Most textures were looking correctly. If you still get broken textures with tomorrow's snapshot then it might be a difference between our chip revisions (sigh). Sometimes above games mess up the screen but restart Game a=20 few times fixes it. Can't reproduce this either. =46lighgear messes up the entire screen and would never work. BTW, the games work on i810 HW with 2.6.11-rc3. Since Linux 2.4 is no longer=20 open for new features there is not much point back-porting it to Linux 2.4.=20 See=20 http://dri.freedesktop.org/wiki/S3Savage for more information about the savage driver status. I just added a note about Linux 2.4 to that page. Sorry, have not found any reference to 2.4 being unsupported=20 on that page.=20 Are there any test programs available to systematically test=20 DRM/GL functionality? Regards Michael -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- 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: r300 on a powerbook (ppc)
Hi Jerome, As a hack, couldn't we redefine this macro within R300 driver ? Just put in somewhere in r300_context.h for example. If it makes things working for PPC folks it would be great :) best Vladimir Dergachev On Sat, 12 Feb 2005, Jerome Glisse wrote: We know this issue, i will submit a patch latter. This is very simple, in radeon_macro.h of Mesa cvs there is no swapping for big endian. While the dri included with Xorg use the xorg macro to access reg and thus have swapping. If you wish just change the radeon_macro.h so it does the 32LENDIAN to 32BENDIAN conv. Jerome Glisse On Sat, 12 Feb 2005 16:55:55 +1100, Paul Mackerras [EMAIL PROTECTED] wrote: I have been trying the r300 driver on my aluminium powerbook (1.5GHz G4 with radeon M10 (NP)). When I run a GL program such as glxgears, it draws a window complete with frame but then renders the image into a region vertically below the window. Somehow the base address being used to compute framebuffer addresses for 3D primitives is wrong. Which register is that base address stored in? Thanks, Paul. --- 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_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- 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_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r2xx|r1xx] readpixels-3 and pntparam_1 - Progress?
Roland Scheidegger schrieb: As for pntparam, I couldn't get it really working, and in this form it's overkill for what works (larger point sizes). I'm not so sure it's worth the trouble of whipping up a simpler patch which would only contain that, since only aliased larger point sizes are working, but everyone uses antialiased points... Maybe I'll try it later again. Roland The popular wings3d subdivision modeller uses aliased points. When in vertex editing mode vertices are higlighted by points, selected vertices with points of a different color. Without bigger point sices it is very difficult to see wich vertices are selected at high screen resolutions. Philipp --- 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_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 2529] New: ATI radeon M7 causes unusable video if switching between X and vt
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=2529 Summary: ATI radeon M7 causes unusable video if switching between X and vt Product: DRI Version: XOrg CVS Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: DRM modules AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: [EMAIL PROTECTED] I've noticed that after a suspend to ram or disk I can't switch between X and vt if I suspend on vt, on resume switching to X causes hags on video ( I still can use ssh not connect thru net) if I suspend on X, on resmue X works but if I switch on vt and then back to X I've the same effect as above... I watched some code and I've found a possible solution: on radeon_cp.c around line 1343 radeon_do_engine_reset( dev ); /* this let a DRI X server to work */ +radeon_acknowledge_irqs( dev_priv ); +radeon_do_cp_start( dev_priv ); +radeon_emit_irq( dev ); DRM_DEBUG(radeon_do_resume_cp() complete\n); and this let X work fine... $ uname -a Linux phoenix 2.6.10-gentoo-r7 #9 Sat Feb 12 02:25:55 CET 2005 i686 Mobile Intel(R) Pentium(R) 4 - M CPU 1.90GHz GenuineIntel GNU/Linux Contect me if you need any other infos.. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- 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_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon big endian patch
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: r300 on a powerbook (ppc)
Yes as a hack we could redefine this. I will check if there is no direct include of radeon_macro somewhere else. I was still wondering does texture mapping work on x86 (haven't got one near me to test) ? (with lastest cvs (say 5 min or so :)) I haven't checked deeply this as i am working on correctting the hostdata_blt of 2D driver. So here on PPC i got noise for texture (nehe lesson 6,7,8 glexcess) On Sat, 12 Feb 2005 12:03:59 -0500 (EST), Vladimir Dergachev [EMAIL PROTECTED] wrote: Hi Jerome, As a hack, couldn't we redefine this macro within R300 driver ? Just put in somewhere in r300_context.h for example. If it makes things working for PPC folks it would be great :) best Vladimir Dergachev On Sat, 12 Feb 2005, Jerome Glisse wrote: Jerome Glisse --- 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_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 on a powerbook (ppc)
On Sat, 12 Feb 2005, Jerome Glisse wrote: Yes as a hack we could redefine this. I will check if there is no direct include of radeon_macro somewhere else. I was still wondering does texture mapping work on x86 (haven't got one near me to test) ? (with lastest cvs (say 5 min or so :)) I haven't checked deeply this as i am working on correctting the hostdata_blt of 2D driver. Yep, texture mapping works - you can even play quake.. best Vladimir Dergachev So here on PPC i got noise for texture (nehe lesson 6,7,8 glexcess) On Sat, 12 Feb 2005 12:03:59 -0500 (EST), Vladimir Dergachev [EMAIL PROTECTED] wrote: Hi Jerome, As a hack, couldn't we redefine this macro within R300 driver ? Just put in somewhere in r300_context.h for example. If it makes things working for PPC folks it would be great :) best Vladimir Dergachev On Sat, 12 Feb 2005, Jerome Glisse wrote: Jerome Glisse --- 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_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 on a powerbook (ppc)
On Sat, 2005-02-12 at 21:00 +0100, Jerome Glisse wrote: Yes as a hack we could redefine this. Please, let's get a proper fix into Mesa instead. Have you tried my cleaned up patch? -- 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: r300 on a powerbook (ppc)
On Sat, 12 Feb 2005 15:04:29 -0500, Michel Dänzer [EMAIL PROTECTED] wrote:
On Sat, 2005-02-12 at 21:00 +0100, Jerome Glisse wrote:
Yes as a hack we could redefine this.
Please, let's get a proper fix into Mesa instead. Have you tried my
cleaned up patch?
Not right now, gmail seems buggy with your mail (i can't dl
your patch don't know why, first time i see a such stupid trouble
with gmail). I get it with mailing list archive.
You made a little cut paste error :
+ read_MMIO_LE32(base, offset)
insted of :
+ read_MMIO_LE32(RADEONMMIO, addr)
No ?
The corrected patch work. I attach it. If you could push
it to mesa cvs :)
So Vlad texture are working on x86, looks like i will have to
track down why we have only noise over here :(
Jerome Glisse
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(base, offset)
# 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: r300 on a powerbook (ppc)
Still for the same reason... With previous cvs texture were working. Thus a change somewhere broke it on ppc. I will find the devil responsible for that and blame him ;) Btw by setting RADEON_DEBUG to 1 and DEBUG_TEXTURE to 1 i should see debug msg (i set environement variable) or must i set them hard in some header ? Jerome Glisse --- 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_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon big endian patch
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
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
