date:20051202

Re: [Mesa3d-dev] mesa-6.4.1 fails to compile on amd64

2005-12-02 Thread Thomas Hellström


Brian Paul wrote:


Tomas Carnecky wrote:

x86_64-pc-linux-gnu-gcc -c -I. -I../../../include 
-I../../../include/GL/internal -I../../../src/mesa/main 
-I../../../src/mesa/glapi -I../../../src/mesa/drivers/dri/common 
`pkg-config --cflags libdrm` -I/usr/X11R6/include -Wall -march=k8 -O2 
-pipe -fPIC -m64 -D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L 
-D_SVID_SOURCE -D_BSD_SOURCE -D_GNU_SOURCE -DPTHREADS 
-DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING 
-DHAVE_ALIAS -DXF86VIDMODE -D_REENTRANT -UIN_DRI_DRIVER 
-DUSE_X86_64_ASM -std=c99 -ffast-math  -D_POSIX_SOURCE 
-D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE -D_GNU_SOURCE 
-DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER 
-DGLX_DIRECT_RENDERING -DHAVE_ALIAS -DXF86VIDMODE -D_REENTRANT 
-UIN_DRI_DRIVER ../../../src/mesa/x86-64/glapi_x86-64.S -o 
../../../src/mesa/x86-64/glapi_x86-64.o
../../../src/mesa/x86-64/glapi_x86-64.S:32:22: assyntax.h: No such 
file or directory

../../../src/mesa/x86-64/glapi_x86-64.S: Assembler messages:
../../../src/mesa/x86-64/glapi_x86-64.S:85: Error: junk at end of 
line, first unrecognized character is `('
../../../src/mesa/x86-64/glapi_x86-64.S:86: Error: unrecognized 
symbol type 
../../../src/mesa/x86-64/glapi_x86-64.S:86: Error: junk at end of 
line, first unrecognized character is `('
../../../src/mesa/x86-64/glapi_x86-64.S:87: Error: invalid character 
'(' in mnemonic
../../../src/mesa/x86-64/glapi_x86-64.S:119: Error: expected comma 
after name `GLNAME' in .size directive
../../../src/mesa/x86-64/glapi_x86-64.S:122: Error: junk at end of 
line, first unrecognized character is `('
../../../src/mesa/x86-64/glapi_x86-64.S:123: Error: unrecognized 
symbol type 
../../../src/mesa/x86-64/glapi_x86-64.S:123: Error: junk at end of 
line, first unrecognized character is `('
../../../src/mesa/x86-64/glapi_x86-64.S:124: Error: invalid character 
'(' in mnemonic
../../../src/mesa/x86-64/glapi_x86-64.S:148: Error: expected comma 
after name `GLNAME' in .size directive
../../../src/mesa/x86-64/glapi_x86-64.S:151: Error: junk at end of 
line, first unrecognized character is `('



If you copy assyntax.h into the x86-64 directory you can get past 
that.  Ian's fixed this in CVS.


Another problem you might find is references to redhat system headers 
in the 'depend' files.  The makefile rules for building the tarballs 
should have prevented that but I think something went wrong.  If you 
rm the depend files you'll be OK.




and this goes on forever...

another (possible) bug:

x86_64-pc-linux-gnu-gcc -c -I. -I../../../include 
-I../../../include/GL/internal -I../../../src/mesa/main 
-I../../../src/mesa/glapi -I../../../src/mesa/drivers/dri/common 
`pkg-config --cflags libdrm` -I/usr/X11R6/include -Wall -march=k8 -O2 
-pipe -fPIC -m64 -D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L 
-D_SVID_SOURCE -D_BSD_SOURCE -D_GNU_SOURCE -DPTHREADS 
-DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING 
-DHAVE_ALIAS -DXF86VIDMODE -D_REENTRANT -UIN_DRI_DRIVER 
-DUSE_X86_64_ASM -std=c99 -ffast-math  -D_POSIX_SOURCE 
-D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE -D_GNU_SOURCE 
-DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER 
-DGLX_DIRECT_RENDERING -DHAVE_ALIAS -DXF86VIDMODE -D_REENTRANT 
-UIN_DRI_DRIVER XF86dri.c -o XF86dri.o

XF86dri.c: In function `XF86DRIOpenConnection':
XF86dri.c:204: warning: left shift count = width of type
XF86dri.c: In function `XF86DRIGetDeviceInfo':
XF86dri.c:566: warning: left shift count = width of type



system is: Linux eiger 2.6.14.2 #6 SMP PREEMPT Tue Nov 29 23:10:16 
GMT 2005 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ 
AuthenticAMD GNU/Linux



Yeah, I think code at lines 204 and 566 is bogus.

In drm.h:

#if defined(__linux__)
typedef unsigned int drm_handle_t;
#else
typedef unsigned long drm_handle_t; /** To mapped regions */
#endif

But in XF86dri.c we have:

*hSAREA = rep.hSAREALow;
#ifdef LONG64
*hSAREA |= ((drm_handle_t)rep.hSAREAHigh)  32;
#endif

I think this would be better and more robust:

*hSAREA = rep.hSAREALow;
if (sizeof(drm_handle_t) == 8) {
   *hSAREA |= ((drm_handle_t) rep.hSAREAHigh)  32;
}

Any comments from the DRI/DRM guys?


I have been looking at the code as it is present also in the via XvMC libs.
Seems like the correct solution.

/Thomas


-Brian


---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log 
files

for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel






---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX

Re: [PATCH] add -DIN_DRI_DRIVER to xorg-6.9 build [was Re: problem found with new xorg-6.9RC2 on savage with DRI enabled]

2005-12-02 Thread Sergio Monteiro Basto

On Mon, 2005-11-21 at 19:15 +0100, Roland Scheidegger wrote:
 
  Xorg build also misses -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 
  -DHAVE_ALIAS Ian, and those ones are needed ?
 Can't comment on the others (though usually care must be taken with the
 threading stuff!), but not having -DUSE_EXTERNAL_DXTN_LIB=1 will
 obviously cause it to not support s3tc with the external library (I had
 already filed a bug about this,
 https://bugs.freedesktop.org/show_bug.cgi?id=5057).
 

have you any sampler where I can test s3tc on my r200 ?
I having been trying test it  with nfsu2 game but it is cracked and
doesn't start.  

  As side note I haven't the minimum idea, what side effect this could 
  cause on non Linux or BSD systems.
 Since the code in question is only built on systems which support dri,
 there shouldn't be any problems I suspect. The glx server code is built
 elsewhere (and as a side note, it can't use -DUSE_EXTERNAL_DXTN_LIB=1,
 at least last time I tried it was not possible to use the dl functions
 directly).

 Roland
-- 
Sérgio M.B.


smime.p7s
Description: S/MIME cryptographic signature

X700 support.

2005-12-02 Thread Adam K Kirchhoff



FYI, I'm attaching two very small patches that get the r300 driver 
working with my AGP X700 card.


Adam

Index: shared-core/drm_pciids.txt
===
RCS file: /cvs/dri/drm/shared-core/drm_pciids.txt,v
retrieving revision 1.29
diff -r1.29 drm_pciids.txt
23a24
 0x1002 0x5E4B CHIP_R420 ATI Radeon RV410 X700PRO
Index: src/mesa/drivers/dri/radeon/radeon_chipset.h
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/radeon/radeon_chipset.h,v
retrieving revision 1.1
diff -r1.1 radeon_chipset.h
38a39
 #define PCI_CHIP_RV410_5E4B 0x5E4B
121a123
CHIP_FAMILY_RV410,
Index: src/mesa/drivers/dri/radeon/radeon_screen.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/radeon/radeon_screen.c,v
retrieving revision 1.47
diff -r1.47 radeon_screen.c
576a577
case PCI_CHIP_RV410_5E4B:

Re: [Mesa3d-dev] mesa-6.4.1 fails to compile on amd64

2005-12-02 Thread Brian Paul


Thomas Hellström wrote:

Thomas Hellström wrote:

Brian Paul wrote:



Yeah, I think code at lines 204 and 566 is bogus.

In drm.h:

#if defined(__linux__)
typedef unsigned int drm_handle_t;
#else
typedef unsigned long drm_handle_t; /** To mapped regions */
#endif

But in XF86dri.c we have:

*hSAREA = rep.hSAREALow;
#ifdef LONG64
*hSAREA |= ((drm_handle_t)rep.hSAREAHigh)  32;
#endif

I think this would be better and more robust:

*hSAREA = rep.hSAREALow;
if (sizeof(drm_handle_t) == 8) {
   *hSAREA |= ((drm_handle_t) rep.hSAREAHigh)  32;
}

Any comments from the DRI/DRM guys?

I have been looking at the code as it is present also in the via XvMC 
libs.

Seems like the correct solution.

/Thomas



Hmm, apparently I was a bit quick on the answer there. While the 
generated code should be correct, the compiler isn't smart enough to 
silence the warning. In fact, this should generate a warning even on 32 
bit code.


I need to do the following to make it quiet:

#ifdef LONG64
   if (sizeof(drm_handle_t) == 8) {
   *hFrameBuffer |= ((unsigned long)rep.hFrameBufferHigh)  32;
   }
#endif


I already checked in a fix.  I just use a variable initialized to 32 
to avoid the warning.


-Brian


---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37alloc_id865op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Mesa3d-dev] mesa-6.4.1 fails to compile on amd64

2005-12-02 Thread Thomas Hellström


Thomas Hellström wrote:


Brian Paul wrote:


Tomas Carnecky wrote:

x86_64-pc-linux-gnu-gcc -c -I. -I../../../include 
-I../../../include/GL/internal -I../../../src/mesa/main 
-I../../../src/mesa/glapi -I../../../src/mesa/drivers/dri/common 
`pkg-config --cflags libdrm` -I/usr/X11R6/include -Wall -march=k8 
-O2 -pipe -fPIC -m64 -D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L 
-D_SVID_SOURCE -D_BSD_SOURCE -D_GNU_SOURCE -DPTHREADS 
-DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING 
-DHAVE_ALIAS -DXF86VIDMODE -D_REENTRANT -UIN_DRI_DRIVER 
-DUSE_X86_64_ASM -std=c99 -ffast-math  -D_POSIX_SOURCE 
-D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE -D_GNU_SOURCE 
-DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER 
-DGLX_DIRECT_RENDERING -DHAVE_ALIAS -DXF86VIDMODE -D_REENTRANT 
-UIN_DRI_DRIVER ../../../src/mesa/x86-64/glapi_x86-64.S -o 
../../../src/mesa/x86-64/glapi_x86-64.o
../../../src/mesa/x86-64/glapi_x86-64.S:32:22: assyntax.h: No such 
file or directory

../../../src/mesa/x86-64/glapi_x86-64.S: Assembler messages:
../../../src/mesa/x86-64/glapi_x86-64.S:85: Error: junk at end of 
line, first unrecognized character is `('
../../../src/mesa/x86-64/glapi_x86-64.S:86: Error: unrecognized 
symbol type 
../../../src/mesa/x86-64/glapi_x86-64.S:86: Error: junk at end of 
line, first unrecognized character is `('
../../../src/mesa/x86-64/glapi_x86-64.S:87: Error: invalid character 
'(' in mnemonic
../../../src/mesa/x86-64/glapi_x86-64.S:119: Error: expected comma 
after name `GLNAME' in .size directive
../../../src/mesa/x86-64/glapi_x86-64.S:122: Error: junk at end of 
line, first unrecognized character is `('
../../../src/mesa/x86-64/glapi_x86-64.S:123: Error: unrecognized 
symbol type 
../../../src/mesa/x86-64/glapi_x86-64.S:123: Error: junk at end of 
line, first unrecognized character is `('
../../../src/mesa/x86-64/glapi_x86-64.S:124: Error: invalid 
character '(' in mnemonic
../../../src/mesa/x86-64/glapi_x86-64.S:148: Error: expected comma 
after name `GLNAME' in .size directive
../../../src/mesa/x86-64/glapi_x86-64.S:151: Error: junk at end of 
line, first unrecognized character is `('




If you copy assyntax.h into the x86-64 directory you can get past 
that.  Ian's fixed this in CVS.


Another problem you might find is references to redhat system headers 
in the 'depend' files.  The makefile rules for building the tarballs 
should have prevented that but I think something went wrong.  If you 
rm the depend files you'll be OK.




and this goes on forever...

another (possible) bug:

x86_64-pc-linux-gnu-gcc -c -I. -I../../../include 
-I../../../include/GL/internal -I../../../src/mesa/main 
-I../../../src/mesa/glapi -I../../../src/mesa/drivers/dri/common 
`pkg-config --cflags libdrm` -I/usr/X11R6/include -Wall -march=k8 
-O2 -pipe -fPIC -m64 -D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L 
-D_SVID_SOURCE -D_BSD_SOURCE -D_GNU_SOURCE -DPTHREADS 
-DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING 
-DHAVE_ALIAS -DXF86VIDMODE -D_REENTRANT -UIN_DRI_DRIVER 
-DUSE_X86_64_ASM -std=c99 -ffast-math  -D_POSIX_SOURCE 
-D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE -D_GNU_SOURCE 
-DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER 
-DGLX_DIRECT_RENDERING -DHAVE_ALIAS -DXF86VIDMODE -D_REENTRANT 
-UIN_DRI_DRIVER XF86dri.c -o XF86dri.o

XF86dri.c: In function `XF86DRIOpenConnection':
XF86dri.c:204: warning: left shift count = width of type
XF86dri.c: In function `XF86DRIGetDeviceInfo':
XF86dri.c:566: warning: left shift count = width of type



system is: Linux eiger 2.6.14.2 #6 SMP PREEMPT Tue Nov 29 23:10:16 
GMT 2005 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ 
AuthenticAMD GNU/Linux




Yeah, I think code at lines 204 and 566 is bogus.

In drm.h:

#if defined(__linux__)
typedef unsigned int drm_handle_t;
#else
typedef unsigned long drm_handle_t; /** To mapped regions */
#endif

But in XF86dri.c we have:

*hSAREA = rep.hSAREALow;
#ifdef LONG64
*hSAREA |= ((drm_handle_t)rep.hSAREAHigh)  32;
#endif

I think this would be better and more robust:

*hSAREA = rep.hSAREALow;
if (sizeof(drm_handle_t) == 8) {
   *hSAREA |= ((drm_handle_t) rep.hSAREAHigh)  32;
}

Any comments from the DRI/DRM guys?

I have been looking at the code as it is present also in the via XvMC 
libs.

Seems like the correct solution.

/Thomas


Hmm, apparently I was a bit quick on the answer there. While the 
generated code should be correct, the compiler isn't smart enough to 
silence the warning. In fact, this should generate a warning even on 32 
bit code.


I need to do the following to make it quiet:

#ifdef LONG64
   if (sizeof(drm_handle_t) == 8) {
   *hFrameBuffer |= ((unsigned long)rep.hFrameBufferHigh)  32;
   }
#endif






-Brian


---
This SF.net email is sponsored by: Splunk Inc. Do you grep through 
log files

for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as

[Bug 5037] r300 driver misrenders celestia textures

2005-12-02 Thread bugzilla-daemon

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=5037  
 

[EMAIL PROTECTED] changed:

   What|Removed |Added

Version|6.4 |CVS


  
 
 
--   
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.


---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: X700 support.

2005-12-02 Thread Brian Paul


Adam K Kirchhoff wrote:


FYI, I'm attaching two very small patches that get the r300 driver 
working with my AGP X700 card.


Checked in.

-Brian



---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: X700 support.

2005-12-02 Thread Eric Anholt

On Fri, 2005-12-02 at 15:11 -0500, Adam K Kirchhoff wrote:
 FYI, I'm attaching two very small patches that get the r300 driver 
 working with my AGP X700 card.
 
 Adam

Committed, thanks.  Note that for the future, unified diffs (diff -u)
are much preferred.

-- 
Eric Anholt [EMAIL PROTECTED]
http://people.freebsd.org/~anholt/  [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part

Re: [PATCH] add -DIN_DRI_DRIVER to xorg-6.9 build [was Re: problem found with new xorg-6.9RC2 on savage with DRI enabled]

2005-12-02 Thread Roland Scheidegger


Sergio Monteiro Basto wrote:
Xorg build also misses -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 
-DHAVE_ALIAS Ian, and those ones are needed ?


Can't comment on the others (though usually care must be taken with
the threading stuff!), but not having -DUSE_EXTERNAL_DXTN_LIB=1
will obviously cause it to not support s3tc with the external
library (I had already filed a bug about this, 
https://bugs.freedesktop.org/show_bug.cgi?id=5057).





have you any sampler where I can test s3tc on my r200 ? I having been
trying test it  with nfsu2 game but it is cracked and doesn't start.

for software compression (and hw decompression), quake3 (and other games 
using the same engine) is a good test (you can actually see some slight 
artifacts in the main game menu due to the compression 
(r_ext_compressed_textures 1), though it is smart enough to only use it 
if the extension is available.


Roland



---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Mesa3d-dev] mesa-6.4.1 fails to compile on amd64

Re: [PATCH] add -DIN_DRI_DRIVER to xorg-6.9 build [was Re: problem found with new xorg-6.9RC2 on savage with DRI enabled]

X700 support.

Re: [Mesa3d-dev] mesa-6.4.1 fails to compile on amd64

Re: [Mesa3d-dev] mesa-6.4.1 fails to compile on amd64

[Bug 5037] r300 driver misrenders celestia textures

Re: X700 support.

Re: X700 support.

Re: [PATCH] add -DIN_DRI_DRIVER to xorg-6.9 build [was Re: problem found with new xorg-6.9RC2 on savage with DRI enabled]

9 matches

Site Navigation

Mail list logo

Footer information