libdrm CVS build error for some days

[Dieter Nützel]

kernel openSUSE 10.3 2.6.22.19-0.1-default

/opt/drm ./configure --prefix=/usr

[-]

checking whether the g++ linker (/usr/i586-suse-linux/bin/ld) supports shared 
libraries... yes
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
appending configuration tag F77 to libtool
checking for gcc... (cached) gcc
checking whether we are using the GNU C compiler... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gcc option to accept ISO C89... (cached) none needed
checking dependency style of gcc... (cached) gcc3
checking for ANSI C header files... (cached) yes
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... 64
./configure: line 20465: syntax error near unexpected token `PTHREADSTUBS,'
./configure: line 20465: `PKG_CHECK_MODULES(PTHREADSTUBS, pthread-stubs)'


Thanks,
Dieter

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK  win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: libdrm CVS build error for some days

[Dieter Nützel]

Am Dienstag, 28. Oktober 2008 schrieb Dan Nicholson:
 On Tue, Oct 28, 2008 at 8:44 AM, Dieter Nützel [EMAIL PROTECTED] wrote:
  kernel openSUSE 10.3 2.6.22.19-0.1-default
 
  /opt/drm ./configure --prefix=/usr
 
  [-]
 
  checking whether the g++ linker (/usr/i586-suse-linux/bin/ld) supports
  shared libraries... yes
  checking dynamic linker characteristics... GNU/Linux ld.so
  checking how to hardcode library paths into programs... immediate
  appending configuration tag F77 to libtool
  checking for gcc... (cached) gcc
  checking whether we are using the GNU C compiler... (cached) yes
  checking whether gcc accepts -g... (cached) yes
  checking for gcc option to accept ISO C89... (cached) none needed
  checking dependency style of gcc... (cached) gcc3
  checking for ANSI C header files... (cached) yes
  checking for special C compiler options needed for large files... no
  checking for _FILE_OFFSET_BITS value needed for large files... 64
  ./configure: line 20465: syntax error near unexpected token
  `PTHREADSTUBS,' ./configure: line 20465: `PKG_CHECK_MODULES(PTHREADSTUBS,
  pthread-stubs)'

 Do you have pkg-config installed? Can aclocal find pkg.m4 (should be
 in /usr/share/aclocal)?

All there:

/home/nuetzel l /usr/share/aclocal/pkg.m4
-rw-r--r-- 1 root root 5232 21. Sep 2007  /usr/share/aclocal/pkg.m4

diff with older libdrm said that this token is _new_:

PTHREADSTUBS

-Dieter

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK  win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: libdrm CVS build error for some days

[Dieter Nützel]

Am Dienstag, 28. Oktober 2008 schrieb Dan Nicholson:
 On Tue, Oct 28, 2008 at 9:07 AM, Dieter Nützel [EMAIL PROTECTED] wrote:
  Am Dienstag, 28. Oktober 2008 schrieb Dan Nicholson:
  On Tue, Oct 28, 2008 at 8:44 AM, Dieter Nützel [EMAIL PROTECTED] 
wrote:
   kernel openSUSE 10.3 2.6.22.19-0.1-default
  
   /opt/drm ./configure --prefix=/usr
  
   [-]
  
   checking whether the g++ linker (/usr/i586-suse-linux/bin/ld) supports
   shared libraries... yes
   checking dynamic linker characteristics... GNU/Linux ld.so
   checking how to hardcode library paths into programs... immediate
   appending configuration tag F77 to libtool
   checking for gcc... (cached) gcc
   checking whether we are using the GNU C compiler... (cached) yes
   checking whether gcc accepts -g... (cached) yes
   checking for gcc option to accept ISO C89... (cached) none needed
   checking dependency style of gcc... (cached) gcc3
   checking for ANSI C header files... (cached) yes
   checking for special C compiler options needed for large files... no
   checking for _FILE_OFFSET_BITS value needed for large files... 64
   ./configure: line 20465: syntax error near unexpected token
   `PTHREADSTUBS,' ./configure: line 20465:
   `PKG_CHECK_MODULES(PTHREADSTUBS, pthread-stubs)'
 
  Do you have pkg-config installed? Can aclocal find pkg.m4 (should be
  in /usr/share/aclocal)?
 
  All there:
 
  /home/nuetzel l /usr/share/aclocal/pkg.m4
  -rw-r--r-- 1 root root 5232 21. Sep 2007  /usr/share/aclocal/pkg.m4
 
  diff with older libdrm said that this token is _new_:
 
  PTHREADSTUBS

 Did you regenerate configure? The PKG_CHECK_MODULES macro is not being
 substituted for you.

Uh, argh,...
...a man get OLD!

/opt/drm ./autogen.sh

did it.

Thanks,
Dieter

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK  win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [r300] fog enabled = implementation error: radeon_program_pair.c

[Dieter Nützel]

Am Donnerstag, 25. September 2008 schrieb Corbin Simpson:
 Dieter Nützel wrote:
  example:
 
  Tunnel V1.5
  Written by David Bucciarelli ([EMAIL PROTECTED])
  Mesa 7.3-devel implementation error:
  radeon_program_pair.c::allocate_input_registers(): Don't know how to
  handle inputs 0x8
 
 
  Please report at bugzilla.freedesktop.org
  pc=0*
  Hardware program
  
  NODE 0: alu_offset: 0, tex_offset: 0, alu_end: -1, tex_end: -1, flags:
  
  *WARN_ONCE***
 ** File r300_render.c function r300Fallback line 366
  Software fallback:!fp-translated
  *
 ** Mesa 7.3-devel implementation error:
  radeon_program_pair.c::allocate_input_registers(): Don't know how to
  handle inputs 0x8

 You're on an RS690, right?

No, stupid RV350 AS [Radeon 9550] as most 'old' people here know...

 Current fog handling is lackluster at best. I've tried a few different
 times to improve it, but it defies simple solutions. Maybe I'll try
 again in a bit.

Yes, please!

Haven't much time lately, two children, wife, big garden (very big with own 
forrest)...;-)

Thanks!
Dieter

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK  win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [r300] fog enabled = implementation error: radeon_program_pair.c

[Dieter Nützel]

Am Donnerstag, 25. September 2008 schrieb Michel Dänzer:
 On Thu, 2008-09-25 at 01:24 +0200, Dieter Nützel wrote:
  example:
 
  Tunnel V1.5
  Written by David Bucciarelli ([EMAIL PROTECTED])
  Mesa 7.3-devel implementation error:
  radeon_program_pair.c::allocate_input_registers(): Don't know how to
  handle inputs 0x8
 
 
  Please report at bugzilla.freedesktop.org
  pc=0*
  Hardware program
  
  NODE 0: alu_offset: 0, tex_offset: 0, alu_end: -1, tex_end: -1, flags:
  
  *WARN_ONCE***
 ** File r300_render.c function r300Fallback line 366
  Software fallback:!fp-translated
  *
 ** Mesa 7.3-devel implementation error:
  radeon_program_pair.c::allocate_input_registers(): Don't know how to
  handle inputs 0x8

 According to git bisect:

 19d77d6cfa384142cc6ab4d9b3db4b28cefb6f19 is first bad commit
 commit 19d77d6cfa384142cc6ab4d9b3db4b28cefb6f19
 Author: Brian [EMAIL PROTECTED]
 Date:   Tue Sep 18 19:29:26 2007 -0600

 temporarily set the FRAG_BIT_FOGC bit in InputsRead when fog is enabled
 (cherry picked from commit 63be96bdc7e9f388a5c49295bd7e150462fd003a)


 The attached patch gets tunnel running here, but it still complains:

Wow, here too. - Very fast fix.

 *WARN_ONCE*
 File r300_state.c function r300SetupRSUnit line 1756
 Don't know how to satisfy InputsRead=0x0008
 ***

dito

 I think FRAG_BIT_FOGC needs to be handled in a couple of other places as
 well, but I'll leave that to Corbin or Nicolai or so. :)

Thanks!
Dieter

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK  win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [r300] fog enabled = implementation error: radeon_program_pair.c

[Dieter Nützel]

Am Donnerstag, 25. September 2008 schrieb Dieter Nützel:
 Am Donnerstag, 25. September 2008 schrieb Michel Dänzer:
  On Thu, 2008-09-25 at 01:24 +0200, Dieter Nützel wrote:
   example:
  
   Tunnel V1.5
   Written by David Bucciarelli ([EMAIL PROTECTED])
   Mesa 7.3-devel implementation error:
   radeon_program_pair.c::allocate_input_registers(): Don't know how to
   handle inputs 0x8
  
  
   Please report at bugzilla.freedesktop.org
   pc=0*
   Hardware program
   
   NODE 0: alu_offset: 0, tex_offset: 0, alu_end: -1, tex_end: -1, flags:
   
   *WARN_ONCE*
  ** ** File r300_render.c function r300Fallback line 366
   Software fallback:!fp-translated
   ***
  ** ** Mesa 7.3-devel implementation error:
   radeon_program_pair.c::allocate_input_registers(): Don't know how to
   handle inputs 0x8
 
  According to git bisect:
 
  19d77d6cfa384142cc6ab4d9b3db4b28cefb6f19 is first bad commit
  commit 19d77d6cfa384142cc6ab4d9b3db4b28cefb6f19
  Author: Brian [EMAIL PROTECTED]
  Date:   Tue Sep 18 19:29:26 2007 -0600
 
  temporarily set the FRAG_BIT_FOGC bit in InputsRead when fog is
  enabled (cherry picked from commit
  63be96bdc7e9f388a5c49295bd7e150462fd003a)
 
 
  The attached patch gets tunnel running here, but it still complains:

 Wow, here too. - Very fast fix.

  *WARN_ONCE***
 ** File r300_state.c function r300SetupRSUnit line 1756
  Don't know how to satisfy InputsRead=0x0008
  *
 **

 dito

  I think FRAG_BIT_FOGC needs to be handled in a couple of other places as
  well, but I'll leave that to Corbin or Nicolai or so. :)

But wait, have a look at '~/mesa/progs/redbook/fog'.
There isn't normal fog, now.
Open it as a full screen window.

-Dieter

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK  win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

[r300] Anyone working on line smoothing?

[Dieter Nützel]

Need it badly for my favored xscreensaver mode noof or KDE's 'Euphorie'...

progs/redbook xscreensaver-demo
*WARN_ONCE*
File r300_render.c function r300Fallback line 387
Software fallback:ctx-Line.SmoothFlag
***

Thanks,
Dieter

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK  win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

[r300] fog enabled = implementation error: radeon_program_pair.c

[Dieter Nützel]

example:

Tunnel V1.5
Written by David Bucciarelli ([EMAIL PROTECTED])
Mesa 7.3-devel implementation error: 
radeon_program_pair.c::allocate_input_registers(): Don't know how to handle 
inputs 0x8


Please report at bugzilla.freedesktop.org
pc=0*
Hardware program

NODE 0: alu_offset: 0, tex_offset: 0, alu_end: -1, tex_end: -1, flags: 

*WARN_ONCE*
File r300_render.c function r300Fallback line 366
Software fallback:!fp-translated
***
Mesa 7.3-devel implementation error: 
radeon_program_pair.c::allocate_input_registers(): Don't know how to handle 
inputs 0x8

[-]

Thanks,
Dieter

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK  win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: DRI2 direct rendering

[Dieter Nützel]

Am Montag, 31. März 2008 schrieb Kristian Høgsberg:
 Hi,

 I just committed the last big chunk of DRI2 work, the direct rendering
 support.

dri2.c:40:23: error: dri2proto.h: Datei oder Verzeichnis nicht gefunden

/opt/mesa find -name dri2proto.h

Nothing!

Thanks,
Dieter

-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [texture_from_pixmap.c] glXBindTexImageEXT undefined

[Dieter Nützel]

Am Montag, 28. Mai 2007 schrieb Brian Paul:
 Dieter Nützel wrote:
  progs/xdemos time nice +19 make
  gcc -I../../include -Wall -Wmissing-prototypes -std=c99 -ffast-math -O
  -march=athlon-mp -fomit-frame-pointer -m3dnow -msse -mmmx
  -mfpmath=sse,387  -m32 -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
  -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_POSIX_MEMALIGN -DUSE_X86_ASM
  -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM texture_from_pixmap.c
  -L../../lib -lglut -lGLU -lGL -lm -o
  texture_from_pixmap
  /tmp/cc089W35.o: In function `main':
  texture_from_pixmap.c:(.text+0x811): undefined reference to
  `glXBindTexImageEXT'
  collect2: ld returned 1 exit status
  make: *** [texture_from_pixmap] Fehler 1
 
  My glx.h has it.
  Latest glxproto.h CVS not.

 As long as you've got the latest Mesa sources,

I have. Latest Mesa git 7.1, DRM git (installed).

OpenGL vendor string: DRI R300 Project
OpenGL renderer string: Mesa DRI R300 20060815 AGP 4x x86/MMX+/3DNow!+/SSE TCL
OpenGL version string: 1.3 Mesa 7.1

 and everything compiled 
 OK,

It does and works, so far.

 this shouldn't be happening. 

But...;-)

 You could run 'nm' on libGL.so and see that glXBindTexImageEXT is defined.

progs/xdemos time nice +19 make -j10
gcc -I../../include -Wall -Wmissing-prototypes -std=c99 -ffast-math -O 
-march=athlon-mp -fomit-frame-pointer -m3dnow -msse -mmmx -mfpmath=sse,387  
-m32 -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 -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS 
-DHAVE_POSIX_MEMALIGN -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM 
texture_from_pixmap.c -L../../lib -lglut -lGLU -lGL -lm -o 
texture_from_pixmap
/tmp/ccA6P9wF.o: In function `main':
texture_from_pixmap.c:(.text+0x811): undefined reference to 
`glXBindTexImageEXT'
collect2: ld returned 1 exit status
make: *** [texture_from_pixmap] Fehler 1
0.376u 0.048s 0:00.43 95.3% 0+0k 0+0io 0pf+0w

progs/xdemos nm /opt/mesa/lib/libGL.so.1.2 | grep glXBindTexImageEXT
0001b0a4 t __glXBindTexImageEXT

progs/xdemos nm /usr/lib/libGL.so.1.2 | grep glXBindTexImageEXT
0001b0a4 t __glXBindTexImageEXT


But what is this?
If I set 'setenv LIBGL_ALWAYS_INDIRECT' (tcsh) I get:

OpenGL vendor string: Tungsten Graphics, Inc.
OpenGL renderer string: Mesa DRI R300 20060815 AGP 4x x86/MMX+/3DNow!+/SSE TCL
OpenGL version string: 1.3 Mesa 6.5.1

Shouldn't it OpenGL 2.1 like ~mesa/docs/relnotes-7.1.html stated?

-Dieter

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

[texture_from_pixmap.c] glXBindTexImageEXT undefined

[Dieter Nützel]

progs/xdemos time nice +19 make
gcc -I../../include -Wall -Wmissing-prototypes -std=c99 -ffast-math -O 
-march=athlon-mp -fomit-frame-pointer -m3dnow -msse -mmmx -mfpmath=sse,387  
-m32 -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 -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS 
-DHAVE_POSIX_MEMALIGN -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM 
texture_from_pixmap.c -L../../lib -lglut -lGLU -lGL -lm -o 
texture_from_pixmap
/tmp/cc089W35.o: In function `main':
texture_from_pixmap.c:(.text+0x811): undefined reference to 
`glXBindTexImageEXT'
collect2: ld returned 1 exit status
make: *** [texture_from_pixmap] Fehler 1

My glx.h has it.
Latest glxproto.h CVS not.

Thanks,
Dieter

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [r300] VBO broken by changes in mesa

[Dieter Nützel]

Am Dienstag, 21. November 2006 19:22 schrieb Rune Petersen:
 Keith Whitwell wrote:
  Rune Petersen wrote:
  Keith Whitwell wrote:
  I've fixed some typo's in this code - with luck this should be solved
  now?
 
  sorry no...
 
  If you can't find in the next day, would you mind disabling it for 6.5.2
  release?
 
  OK, I've made some progress on the i915 at least, can you retry over
  there?

 It now works for me, thank you.

In short, me too (r200, celestia).

Thanks,
Dieter

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [r200] bug in Mesa CVS glut code (GCC-4.1) '-fno-strict-aliasing' needed? - SOLVED

[Dieter Nützel]

Am Sonntag, 29. Oktober 2006 04:16 schrieb Dieter Nützel:
 Am Donnerstag, 26. Oktober 2006 16:12 schrieb Dieter Nützel:
  SuSE 10.1
  GCC-4.1
  latest Mesa CVS
  lates git DRM
 
  Worked all some days ago.

 All goes fine if I revert to Mesa CVS

 Tag:  D2006.10.11.02.49.05

 Nothing to do with '-fno-strict-aliasing'.

It's SOLVED with checkout taken on Sunday, 06.11.2006.

-Dieter

  progs/demos ./tunnel
  Tunnel V1.5
  Written by David Bucciarelli ([EMAIL PROTECTED])
  Speicherschutzverletzung (core dumped)

 tunnel, tunnel2, engine, etc.

  (gdb) bt
  #0  0x in ?? ()
  #1  0xb7912132 in _mesa_Bitmap (width=5, height=8, xorig=0, yorig=0,
  xmove=5, ymove=0,
  bitmap=0xb7ebecbex\204\204\204\204\204\204\204\020
  ((DDD\202\202\)
  at main/drawpix.c:348
  #2  0xb7ea9f65 in glutBitmapCharacter (font=0x804edf8, c=84) at
  glut_bitmap.c:47
  #3  0x08049e12 in printstring (font=0x804edf8,
  string=0x804b278 Tunnel V1.5 Written by David Bucciarelli
  ([EMAIL PROTECTED]))
  at tunnel.c:288
  #4  0x0804a13a in draw () at tunnel.c:445
  #5  0xb7ead9bd in processWindowWorkList (window=0x8058258) at
  glut_event.c:1302
  #6  0xb7eae51d in glutMainLoop () at glut_event.c:1349
  #7  0x08049a6a in main (ac=1, av=0xbfd45ba4) at tunnel.c:532

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [r200] bug in Mesa CVS glut code (GCC-4.1) '-fno-strict-aliasing' needed?

[Dieter Nützel]

Am Donnerstag, 26. Oktober 2006 16:12 schrieb Dieter Nützel:
 SuSE 10.1
 GCC-4.1
 latest Mesa CVS
 lates git DRM

 Worked all some days ago.

All goes fine if I revert to Mesa CVS

Tag:D2006.10.11.02.49.05

Nothing to do with '-fno-strict-aliasing'.

 progs/demos ./tunnel
 Tunnel V1.5
 Written by David Bucciarelli ([EMAIL PROTECTED])
 Speicherschutzverletzung (core dumped)

tunnel, tunnel2, engine, etc.

 (gdb) bt
 #0  0x in ?? ()
 #1  0xb7912132 in _mesa_Bitmap (width=5, height=8, xorig=0, yorig=0,
 xmove=5, ymove=0,
 bitmap=0xb7ebecbex\204\204\204\204\204\204\204\020
 ((DDD\202\202\)
 at main/drawpix.c:348
 #2  0xb7ea9f65 in glutBitmapCharacter (font=0x804edf8, c=84) at
 glut_bitmap.c:47
 #3  0x08049e12 in printstring (font=0x804edf8,
 string=0x804b278 Tunnel V1.5 Written by David Bucciarelli
 ([EMAIL PROTECTED]))
 at tunnel.c:288
 #4  0x0804a13a in draw () at tunnel.c:445
 #5  0xb7ead9bd in processWindowWorkList (window=0x8058258) at
 glut_event.c:1302
 #6  0xb7eae51d in glutMainLoop () at glut_event.c:1349
 #7  0x08049a6a in main (ac=1, av=0xbfd45ba4) at tunnel.c:532

Cheers,
Dieter

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

[r200] bug in Mesa CVS glut code (GCC-4.1) '-fno-strict-aliasing' needed?

[Dieter Nützel]

SuSE 10.1
GCC-4.1
latest Mesa CVS
lates git DRM

Worked all some days ago.

progs/demos ./tunnel
Tunnel V1.5
Written by David Bucciarelli ([EMAIL PROTECTED])
Speicherschutzverletzung (core dumped)

Reading symbols from /usr/X11R6/lib/modules/dri/r200_dri.so...
done.
Loaded symbols for /usr/X11R6/lib/modules/dri/r200_dri.so
Reading symbols from /usr/lib/libexpat.so.1...done.
Loaded symbols for /usr/lib/libexpat.so.1
Reading symbols from /usr/lib/libtxc_dxtn.so...done.
Loaded symbols for /usr/lib/libtxc_dxtn.so
#0  0x in ?? ()

(gdb) bt
#0  0x in ?? ()
#1  0xb7912132 in _mesa_Bitmap (width=5, height=8, xorig=0, yorig=0, xmove=5, 
ymove=0,
bitmap=0xb7ebecbex\204\204\204\204\204\204\204\020
((DDD\202\202\)
at main/drawpix.c:348
#2  0xb7ea9f65 in glutBitmapCharacter (font=0x804edf8, c=84) at 
glut_bitmap.c:47
#3  0x08049e12 in printstring (font=0x804edf8,
string=0x804b278 Tunnel V1.5 Written by David Bucciarelli 
([EMAIL PROTECTED]))
at tunnel.c:288
#4  0x0804a13a in draw () at tunnel.c:445
#5  0xb7ead9bd in processWindowWorkList (window=0x8058258) at 
glut_event.c:1302
#6  0xb7eae51d in glutMainLoop () at glut_event.c:1349
#7  0x08049a6a in main (ac=1, av=0xbfd45ba4) at tunnel.c:532

(gdb) info registers
eax0x1d6470
ecx0x5  5
edx0x15e350
ebx0x806db28134667048
esp0xbfd4581c   0xbfd4581c
ebp0xb7ebecbe   0xb7ebecbe
esi0x8  8
edi0x5  5
eip0x0  0
eflags 0x210213 2163219
cs 0x73 115
ss 0x7b 123
ds 0x7b 123
es 0x7b 123
fs 0x0  0
gs 0x33 51

(gdb) list
471 idle(void)
472 {
473glutPostRedisplay();
474 }
475
476
477
478 int
479 main(int ac, char **av)
480 {

Thanks,
Dieter

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

[r300] in r300_render.c ‘r300’ undeclared

[Dieter Nützel]

In file included from r300_render.c:60:
r300_emit.h: In function ‘fire_AOS’:
r300_emit.h:244: warning: assignment from incompatible pointer type
r300_render.c: In function ‘fire_EB’:
r300_render.c:257: warning: assignment from incompatible pointer type
r300_render.c:264: warning: assignment from incompatible pointer type
r300_render.c: In function ‘r300_run_vb_render’:
r300_render.c:346: warning: assignment from incompatible pointer type
r300_render.c:349: warning: assignment from incompatible pointer type
r300_render.c:362: warning: assignment from incompatible pointer type
r300_render.c:365: warning: assignment from incompatible pointer type
r300_render.c: In function ‘r300Fallback’:
r300_render.c:398: error: ‘r300’ undeclared (first use in this function)
r300_render.c:398: error: (Each undeclared identifier is reported only once
r300_render.c:398: error: for each function it appears in.)
make[5]: *** [r300_render.o] Fehler 1
make[5]: Leaving directory `/opt/Mesa/src/mesa/drivers/dri/r300'

Cheers,
Dieter

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Test for postmaster n/t

[Dieter Nützel]

Sorry, my last mail to the list was rejected 'cause I haven't had 
a 'postmaster'.

-Dieter


--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [r200_sanity.c] compilation error

[Dieter Nützel]

Am Dienstag, 30. Mai 2006 03:00 schrieb Roland Scheidegger:
 Dieter Nützel wrote:
  Am Dienstag, 30. Mai 2006 00:33 schrieben Sie:
  Dieter Nützel wrote:
  Latest Mesa and DRM CVS:

  r200_sanity.c: In function ‘r200SanityCmdBuffer’:
  r200_sanity.c:1422: error: ‘RADEON_CMD_VECLINEAR’ undeclared (first use
  in this function)
  r200_sanity.c:1422: error: (Each undeclared identifier is reported only
  once r200_sanity.c:1422: error: for each function it appears in.)
  make[6]: *** [r200_sanity.o] Fehler 1
  make[6]: Leaving directory `/opt/Mesa/src/mesa/drivers/dri/r200'
 
  Yes, this is caused by preparation for hw vertex programs on r200. You
  need a new libdrm (actually, all you need is a new radeon_drm.h) from
  drm cvs.
 
  Oh, shit.
  I had latest DRM code but haven't compiled it for some time...;-)
  Works.
  What should I test?

 Nothing yet as the code in cvs does pretty much nothing for now. The
 rest is not yet in cvs mostly due to really ugly hacks I needed but
 don't have an explanation for. If you're interested you could try the
 attached patch and try doom3 with the r200 render path

Now, after 'all' is in CVS:

Which term?
r200 didn't work
arb (default) works
arb2 didn't tried

 (I actually just 
 hope it works the same with r200 as with rv250), you still need to
 enable arb_vertex_program manually with driconf.

If I do this doom3 hangs.

Celestia 1.3.2 and 1.4.1 hangs system when I switch to wireframe mode but 
works _accelerated_ otherwise. - GREAT!

 The attached patch is 
 basically the same as the earlier one, but without the changes already
 commited to cvs.

  BTW Doom3 do not work any longer on my wife's machine.
  It hangs in 'starting sequence'.
  Log available.
  Duron 1800 (3DNow!, SSE1), 512 MB, r200 (my 'old' one), SuSE 10.0 +
  latest Mesa/DRM.
  What pre-load should I try.
  Worked some months ago.

 Not sure what could be wrong - if that's just the game which hangs (i.e.
 you can still kill it) and you've redirected the output make sure you
 don't forget to specify +set in_tty 0 at the commandline when starting
 doom3, otherwise the game will always stop at initializing menus.

Helped.

Cheers,
   Dieter

PS Hello list, I've back, again;-)


--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [r300][patch] retry when busy

[Dieter Nützel]

Am Dienstag, 30. Mai 2006 14:33 schrieb Roland Scheidegger:
 Michel Dänzer wrote:
  On Tue, 2006-05-30 at 02:42 +0200, Roland Scheidegger wrote:
  Looks like quite some more work is needed to detect real lockups but not
just randomly reseting the chip when there is none (which can itself
  lead to lockups IME).
 
  Maybe, or maybe it's just a matter of sticking RADEONCP_STOP()s in the
  right places, ala https://bugs.freedesktop.org/show_bug.cgi?id=1889 .

 Since the box is down, I assume this only refers to the lockups which
 can be caused by reseting the engine?
 In any case, I can't see a good reason why you'd want to reset the chip
 when it has, in fact, not locked up.
 I've done some quick test hack (attached) which did fix the problem with
 gltestperf for me (system was really unresponsive during the benchmark,
 though), together with that EBUSY fix.
 Apparently, on my box, the FIFO wait time is probably a bit short
 (roughly 0.7 seconds), maybe something with a real timebase should be
 used rather than just 2 million INREGS?
 For determining if the chip has locked up I just used the ZPASS_DATA reg
 (assuming that as long as the chip outputs fragments it has not locked
 up - of course you could hack up some gl test program where all
 fragments fail the z test, but I'm not sure there's a better reg to
 monitor activity - ring ptr might be another possibility, but I think
 this can point at the same location for a long time too (for instance
 when drawing using the idx buf command).

Progress?

-Dieter


--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

[r300] with (to) old drm: 'no fbconfigs'

[Dieter Nützel]

progs/demos setenv LIBGL_DEBUG
progs/demos ./gears
libGL error:
R300 DRI driver expected DRM version 1.20.x but got version 1.19.0
libGL warning: 3D driver returned no fbconfigs.
libGL error: InitDriver failed
libGL error: reverting to (slow) indirect rendering

OK, this is clear, but...

Linux version 2.6.5-7.155.29-smp ([EMAIL PROTECTED]) (gcc-Version 3.3.1 (SuSE 
Linux)) #1 SMP Fri Jun 10 23:02:03 CEST 2005

Sorry, I need this kernel for the time being
But DRM CVS worked before (some weeks ago).

Now I get:
  CC [M]  /opt/drm/linux-core/radeon_drv.o
/opt/drm/linux-core/radeon_drv.c:43: error: parse error before int
/opt/drm/linux-core/radeon_drv.c:43: Warnung: type defaults to `int' in 
declaration of `module_param_named'
/opt/drm/linux-core/radeon_drv.c:43: Warnung: function declaration isn't a 
prototype
/opt/drm/linux-core/radeon_drv.c:43: Warnung: data definition has no type or 
storage class
make[2]: *** [/opt/drm/linux-core/radeon_drv.o] Fehler 1
make[1]: *** [_module_/opt/drm/linux-core] Fehler 2
make[1]: Leaving directory `/usr/src/linux-2.6.5-7.155.29'
make: *** [modules] Fehler 2

Dave, drm_compat.h update needed?

Thanks,
Dieter


---
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://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

[DRM] Next drm_compat.h update needed ;-)

[Dieter Nützel]

make DRM_MODULES=radeon.o modules
make[1]: Entering directory `/opt/drm/linux-core'
make -C /lib/modules/2.6.5-7.155.29-smp/source  SUBDIRS=`pwd` DRMSRCDIR=`pwd` 
modules
make[2]: Entering directory `/usr/src/linux-2.6.5-7.155.29'
  CC [M]  /opt/drm/linux-core/radeon_drv.o
/opt/drm/linux-core/radeon_drv.c:43: error: parse error before int
/opt/drm/linux-core/radeon_drv.c:43: Warnung: type defaults to `int' in 
declaration of `module_param_named'
/opt/drm/linux-core/radeon_drv.c:43: Warnung: function declaration isn't a 
prototype
/opt/drm/linux-core/radeon_drv.c:43: Warnung: data definition has no type or 
storage class
make[3]: *** [/opt/drm/linux-core/radeon_drv.o] Fehler 1
make[2]: *** [_module_/opt/drm/linux-core] Fehler 2
make[2]: Leaving directory `/usr/src/linux-2.6.5-7.155.29'
make[1]: *** [modules] Fehler 2
make[1]: Leaving directory `/opt/drm/linux-core'
make: *** [radeon.o] Fehler 2


[linux-core/radeon_drv.c]
int radeon_no_wb;

MODULE_PARM_DESC(no_wb, Disable AGP writeback for scratch registers\n);
module_param_named(no_wb, radeon_no_wb, int, 0444);
[-]

SuSE 10.0 with 2.6.13-8 works OK.

Greetings,
Dieter


---
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

[r200] SuSE 10.0 (RC1) without latest MesaCVS hangs in gl-117

[Dieter Nützel]

Hello Stefan,

I have SuSE 10.0 betaX latest RC1 running for several weeks with r200 (2D and 
3D ) and RV350 (9550, 2D only).

Included gl-117 hangs with released Xorg/DRM/Mesa driver when the mouse cursor 
moves over a menu option.

With latest DRM CVS and Mesa CVS on-top of the released Xorg version it works 
GREAT.

Greetings,
Dieter


---
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

[DRM] Is my kernel (SuSE 2.6.5-7.155.29-smp) to old?

[Dieter Nützel]

Worked for ages.
What shall I do, since I have a brand new Radeon 9550?
Yes, my system would be updated to SuSE 10.0 (2.6.13+), soon.

-Dieter

drm/linux-core time make radeon.o
make DRM_MODULES=radeon.o modules
make[1]: Entering directory `/opt/drm/linux-core'
make -C /lib/modules/2.6.5-7.155.29-smp/source  SUBDIRS=`pwd` DRMSRCDIR=`pwd` 
modules
make[2]: Entering directory `/usr/src/linux-2.6.5-7.155.29'
  CC [M]  /opt/drm/linux-core/drm_sysfs.o
/opt/drm/linux-core/drm_sysfs.c:130: Warnung: implicit declaration of function 
`__ATTR'
/opt/drm/linux-core/drm_sysfs.c:130: error: `dri_library_name' undeclared here 
(not in a function)
/opt/drm/linux-core/drm_sysfs.c:130: Warnung: missing braces around 
initializer
/opt/drm/linux-core/drm_sysfs.c:130: Warnung: (near initialization for 
`class_device_attrs[0]')
/opt/drm/linux-core/drm_sysfs.c:130: error: initializer element is not 
constant
/opt/drm/linux-core/drm_sysfs.c:130: error: (near initialization for 
`class_device_attrs[0].attr.name')
/opt/drm/linux-core/drm_sysfs.c:131: error: initializer element is not 
constant
/opt/drm/linux-core/drm_sysfs.c:131: error: (near initialization for 
`class_device_attrs[0].attr')
/opt/drm/linux-core/drm_sysfs.c:131: error: initializer element is not 
constant
/opt/drm/linux-core/drm_sysfs.c:131: error: (near initialization for 
`class_device_attrs[0]')
make[3]: *** [/opt/drm/linux-core/drm_sysfs.o] Fehler 1
make[2]: *** [_module_/opt/drm/linux-core] Fehler 2
make[2]: Leaving directory `/usr/src/linux-2.6.5-7.155.29'
make[1]: *** [modules] Fehler 2
make[1]: Leaving directory `/opt/drm/linux-core'
make: *** [radeon.o] Fehler 2
0.403u 0.149s 0:00.56 96.4% 0+0k 0+0io 0pf+0w

-- 
Dieter Nützel
@home: Dieter () nuetzel-hh ! de

-- 
Dieter Nützel
@home: Dieter () nuetzel-hh ! de


---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42 plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [DRM] Is my kernel (SuSE 2.6.5-7.155.29-smp) to old?

[Dieter Nützel]

Am Sonntag, 25. September 2005 04:52 schrieb Dave Airlie:
 On Sun, 25 Sep 2005, Dieter Nützell wrote:
  Worked for ages.
  What shall I do, since I have a brand new Radeon 9550?
  Yes, my system would be updated to SuSE 10.0 (2.6.13+), soon.

 Can you try it now , I added __ATTR to the backwards compat header file...

Where?

drmP.h is new, but...

drm/linux-core l drmP.h
-rw-r--r--1 nuetzel  users   35882 2005-09-25 06:26 drmP.h

/opt/drm grep -r 'ATTR' *
linux-core/drm_sysfs.c:static CLASS_ATTR(version, S_IRUGO, version_show, 
NULL);
linux-core/drm_sysfs.c: __ATTR(dri_library_name, S_IRUGO, show_dri, NULL),
grep: Warnung: linux-core/linux: Rekursive Verzeichnisschleife.

linux-core/r300_reg.h:#define R300_VPI_IN_REG_CLASS_ATTRIBUTE(1  0)
shared-core/r300_reg.h:#define R300_VPI_IN_REG_CLASS_ATTRIBUTE(1  0)

 it should build I think..

Not, yet.
Error is same as before.

Thanks,
Dieter


---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42 plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [DRM] Is my kernel (SuSE 2.6.5-7.155.29-smp) to old?

[Dieter Nützel]

Am Sonntag, 25. September 2005 07:19 schrieb Dave Airlie:
   Can you try it now , I added __ATTR to the backwards compat header
   file...
 
  Where?

 Sorry it should be in drm_compat.h now.. I hadn't noticed the commit
 failed because my tree wasn't up to date..

OK, built.

[drm] Initialized drm 1.0.0 20040925
PCI: Unable to reserve mem region #1:[EMAIL PROTECTED] for device :01:05.0
[drm] Initialized radeon 1.19.0 20050911 on minor 0: ATI Technologies Inc 
RV350 AS [Radeon 9600 AS]
[drm] Used old pci detect: framebuffer loaded

But:
(WW) RADEON(0): Enabling DRM support

*** Direct rendering support is highly experimental for Radeon 9500
*** and newer cards. In fact, the only thing you could probably use
***  it for is better 2d acceleration. The 3d mesa driver is not
*** provided in this tree. A very experimental (and incomplete)
*** version is available from http://r300.sourceforge.net
*** This message has been last modified on 12/12/04.

(II) RADEON(0): Direct rendering disabled

Now, I have to learn how to configure it.

-Dieter

-- 
Dieter Nützel
@home: Dieter () nuetzel-hh ! de


---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42 plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

'OcclusionTest' is missing (r200, i915, etc.), since last checkin

[Dieter Nützel]

i830_metaops.c: In function `i830TryTextureDrawPixels':
i830_metaops.c:628: error: structure has no member named `OcclusionTest'
make[6]: *** [i830_metaops.o] Fehler 1
make[6]: Leaving directory `/opt/Mesa/src/mesa/drivers/dri/i915'

-DGLX_DIRECT_RENDERING -DHAVE_ALIAS r200_pixel.c -o r200_pixel.o
r200_pixel.c: In function `check_color_per_fragment_ops':
r200_pixel.c:97: error: structure has no member named `OcclusionTest'
make[6]: *** [r200_pixel.o] Fehler 1

Thanks,
Dieter

Now, with wife AND daughter! ;-)))


---
SF.Net email is Sponsored by the Better Software Conference  EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile  Plan-Driven Development * Managing Projects  Teams * Testing  QA
Security * Process Improvement  Measurement * http://www.sqe.com/bsce5sf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: 'OcclusionTest' is missing (r200, i915, etc.), since last checkin

[Dieter Nützel]

Am Donnerstag, 25. August 2005 21:37 schrieb Brian Paul:
 Dieter Nützel wrote:
  i830_metaops.c: In function `i830TryTextureDrawPixels':
  i830_metaops.c:628: error: structure has no member named `OcclusionTest'
  make[6]: *** [i830_metaops.o] Fehler 1
  make[6]: Leaving directory `/opt/Mesa/src/mesa/drivers/dri/i915'
 
  -DGLX_DIRECT_RENDERING -DHAVE_ALIAS r200_pixel.c -o r200_pixel.o
  r200_pixel.c: In function `check_color_per_fragment_ops':
  r200_pixel.c:97: error: structure has no member named `OcclusionTest'
  make[6]: *** [r200_pixel.o] Fehler 1

 Fixed.

Thanks.

SMP (quake3-smp) is broken for several months, now.
futex problem.

@ Ian.
I thought you had something (occlusion) in the pipe.

  Now, with wife AND daughter! ;-)))

 Congratulations!

You read very 'carefully' ;-)

Thank you very much!

-Dieter

With even fewer sleep


---
SF.Net email is Sponsored by the Better Software Conference  EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile  Plan-Driven Development * Managing Projects  Teams * Testing  QA
Security * Process Improvement  Measurement * http://www.sqe.com/bsce5sf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

[r200] 'texwrap' sigfaults during pressing 'b'

[Dieter Nützel]

progs/tests ./texwrap
Texture Border Size = 1
Speicherschutzverletzung (core dumped)
progs/tests l core
-rw---1 nuetzel  users 6156288 2005-06-05 17:59 core

Loaded symbols for /usr/lib/libtxc_dxtn.so
Reading symbols from /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2...done.
Loaded symbols for /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2
#0  0x405f4d2a in update_input_ptrs (ctx=0x0, start=0) at tnl/t_vertex.c:386
386   a[j].inputptr = ((GLubyte *)vptr-data) + start * vptr-stride;
(gdb) bt
#0  0x405f4d2a in update_input_ptrs (ctx=0x0, start=0) at tnl/t_vertex.c:386
#1  0x405f4dd6 in _tnl_build_vertices (ctx=0x805f490, start=0, end=0,
newinputs=4294967295) at tnl/t_vertex.c:408
#2  0x405e985e in run_render (ctx=0x805f490, stage=0x81fc864)
at tnl/t_vb_render.c:295
#3  0x405e0961 in _tnl_run_pipeline (ctx=0x805f490) at tnl/t_pipeline.c:159
#4  0x405570df in r200WrapRunPipeline (ctx=0x805f490) at r200_state.c:2316
#5  0x40600b88 in _tnl_flush_vtx (ctx=0x805f490) at tnl/t_vtx_exec.c:277
#6  0x405fc424 in _tnl_FlushVertices (ctx=0x805f490, flags=1)
at tnl/t_vtx_api.c:842
#7  0x4056a213 in r200FlushVertices (ctx=0x805f490, flags=1)
at r200_swtcl.c:903
#8  0x40661b7f in _mesa_set_enable (ctx=0x805f490, cap=3553, state=0 '\0')
at main/enable.c:610
#9  0x40662f37 in _mesa_Disable (cap=0) at main/enable.c:1058
#10 0x08049228 in Display () at texwrap.c:172
#11 0x4004a0b3 in processWindowWorkList (window=0x80536c0)
at glut_event.c:1297
#12 0x4004a12d in __glutProcessWindowWorkLists () at glut_event.c:1344
#13 0x4004a17d in glutMainLoop () at glut_event.c:1365
#14 0x080496a8 in main (argc=1, argv=0xbfffefc4) at texwrap.c:301
(gdb) info registers
eax0x0  0
ecx0x0  0
edx0x0  0
ebx0x0  0
esp0xbfffec10   0xbfffec10
ebp0xbfffec38   0xbfffec38
esi0x81fdf6c136306540
edi0x81fdf58136306520
eip0x405f4d2a   0x405f4d2a
eflags 0x10246  66118
cs 0x73 115
ss 0x7b 123
ds 0x7b 123
es 0x7b 123
fs 0x0  0
gs 0x33 51

Thanks,
Dieter


---
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

[r200] quake3-smp hangs in futex (current Mesa DRI not SMP ready?)

[Dieter Nützel]

games/quake3 ltrace ./quake3-smp.x86
.
.
.
memcpy(0x08938ad6, GL_SUN_slice_accum, 18)  = 0x08938ad6
memcpy(0x0892d1b8, GL_ARB_depth_texture GL_ARB_draw..., 3026) = 0x0892d1b8
free(0x08937f18)  = void
pthread_mutex_unlock(0x44b9dce4, 129, 0xbfffe2d4, 0xbfffe2d8, 0) = 0
memset(0xbfffe380, '\000', 188)   = 0xbfffe380
--- SIGINT (Interrupt) ---
+++ killed by SIGINT +++



games/quake3 strace ./quake3-smp.x86
.
.
.
brk(0x8cc3000)  = 0x8cc3000
brk(0)  = 0x8cc3000
brk(0x8ce7000)  = 0x8ce7000
mmap2(NULL, 495616, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x4968c000
gettimeofday({1117990206, 773019}, NULL) = 0
futex(0x892d060, FUTEX_WAIT, 2, NULL

Thanks,
Dieter


---
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

[r200] CFT - broken since merge 21th to 22/23 of April

[Dieter Nützel]

Textures in gears, ipers, etc. pp.
quake3: black window

/opt/Mesa ut2003_demo
fcntl: Invalid argument
fcntl: Invalid argument

Backtrace:
[ 1]  ./Core.so [0x40a0978a]
[ 2]  [0xe420]
[ 3]  /usr/X11R6/lib/modules/dri/r200_dri.so(_tnl_run_pipeline+0x2d) 
[0x4505da05]
[ 4]  /usr/X11R6/lib/modules/dri/r200_dri.so [0x44fda09f]
[ 5]  /usr/X11R6/lib/modules/dri/r200_dri.so [0x450f55e3]
[ 6]  /usr/X11R6/lib/modules/dri/r200_dri.so(_tnl_DrawRangeElements+0x13d) 
[0x450f5a1a]
[ 7]  /usr/X11R6/lib/modules/dri/r200_dri.so [0x45057918]
[ 8]  
/opt/games/ut2003_demo/System/OpenGLDrv.so(DrawPrimitive__22FOpenGLRenderInterface14EPrimitiveType+0x373)
 
[0x437ffaeb]
[ 9]  
./Engine.so(Render__12FBspDrawListP15FLevelSceneNodeP16FRenderInterface+0x43e) 
[0x40357532]
[10]  ./Engine.so(RenderLevel__FP15FLevelSceneNodeP16FRenderInterface+0x229b) 
[0x4036aedf]
[11]  ./Engine.so(Render__15FLevelSceneNodeP16FRenderInterface+0x7a2) 
[0x4034d38a]
[12]  ./Engine.so(Render__16FPlayerSceneNodeP16FRenderInterface+0x330) 
[0x403524ec]
[13]  ./Engine.so(Draw__11UGameEngineP9UViewportiPUcPi+0x3fe) [0x4028a08a]
[14]  /opt/games/ut2003_demo/System/SDLDrv.so(Repaint__12USDLViewporti+0x33) 
[0x437c093b]
[15]  /opt/games/ut2003_demo/System/SDLDrv.so(Tick__10USDLClient+0x85) 
[0x437bf365]
[16]  ./Engine.so(Tick__11UGameEnginef+0x31bd) [0x402912e1]
[17]  ./ut2003-bin(SDL_SetVideoMode+0x969) [0x8051b1d]
[18]  ./ut2003-bin(main+0x328c) [0x8058b2c]
[19]  /lib/tls/libc.so.6(__libc_start_main+0xe0) [0x40bb44a0]
[20]  ./ut2003-bin(GetFullName__C7UObjectPw+0x7d) [0x80512d1]
Signal: SIGSEGV [segmentation fault]
Aborting.
Speicherschutzverletzung

/opt/Mesa ut2004demo
Signal: SIGSEGV [segmentation fault]
Aborting.


Crash information will be saved to your logfile.

Developer Backtrace:
Log: [ 1]  ./ut2004-bin [0x869e38c]
Log: [ 2]  [0xe420]
Log: [ 3]  /usr/X11R6/lib/modules/dri/r200_dri.so(_tnl_run_pipeline+0x2d 
[0x44644a05]
Log: [ 4]  /usr/X11R6/lib/modules/dri/r200_dri.so [0x445c109f]
Log: [ 5]  /usr/X11R6/lib/modules/dri/r200_dri.so [0x446dc5e3]
Log: [ 6]
  /usr/X11R6/lib/modules/dri/r200_dri.so(_tnl_DrawRangeElements+0x13d)
[0x446dca1a]
Log: [ 7]  /usr/X11R6/lib/modules/dri/r200_dri.so [0x4463e918]


But quake3-smp, UT2k3/4 didn't even worked with 21th version and before.

-Dieter

diff -r Mesa/src/mesa/tnl/t_array_api.c Mesa-21-04/src/mesa/tnl/t_array_api.c
93a94,96
if (tnl-pipeline.build_state_changes)
   _tnl_validate_pipeline( ctx );

104c107,120
tnl-Driver.RunPipeline( ctx );


diff -r Mesa/src/mesa/drivers/dri/r200/r200_tcl.c 
Mesa-21-04/src/mesa/drivers/dri/r200/r200_tcl.c
387c387
r200EmitArrays( ctx, tnl-render_inputs );
---
r200EmitArrays( ctx, stage-inputs );
410a411,473
 static void r200_check_tcl_render( GLcontext *ctx,
  struct tnl_pipeline_stage *stage )
 {
r200ContextPtr rmesa = R200_CONTEXT(ctx);
GLuint inputs = VERT_BIT_POS;
GLuint unit;

/* Validate state:
 */
if (rmesa-NewGLState)
   r200ValidateState( ctx );

if (ctx-RenderMode == GL_RENDER) {
   /* Make all this event-driven:
*/
   if (ctx-Light.Enabled) {
inputs |= VERT_BIT_NORMAL;

if (1 || ctx-Light.ColorMaterialEnabled) {
   inputs |= VERT_BIT_COLOR0;
}
   }
   else {
inputs |= VERT_BIT_COLOR0;

if (ctx-_TriangleCaps  DD_SEPARATE_SPECULAR) {
   inputs |= VERT_BIT_COLOR1;
}
   }

   if ( ctx-Fog.FogCoordinateSource == GL_FOG_COORD ) {
inputs |= VERT_BIT_FOG;
   }

   for (unit = 0 ; unit  ctx-Const.MaxTextureUnits; unit++) {
if (ctx-Texture.Unit[unit]._ReallyEnabled) {
   if (rmesa-TexGenNeedNormals[unit]) {
  inputs |= VERT_BIT_NORMAL;
   }
   inputs |= VERT_BIT_TEX(unit);
}
   }

   stage-inputs = inputs;
   stage-active = 1;
}
else
   stage-active = 0;
 }

 static void r200_init_tcl_render( GLcontext *ctx,
   struct tnl_pipeline_stage *stage )
 {
stage-check = r200_check_tcl_render;
stage-check( ctx, stage );
 }

 static void dtr( struct tnl_pipeline_stage *stage )
 {
(void)stage;
 }


416,419c479,489
NULL,  /*  private */
NULL,
NULL,
NULL,
---
(_DD_NEW_SEPARATE_SPECULAR |
 _NEW_LIGHT|
 _NEW_TEXTURE|
 _NEW_FOG|
 _NEW_RENDERMODE), /* re-check (new inputs) */
0, /* re-run (always runs) */
GL_TRUE,   /* active */
0, 0,  /* inputs (set in check_render), outputs */
0, NULL,   /* changed_inputs, private */
dtr,   /* destructor */
r200_init_tcl_render,  /* check - initially set to alloc data */
Binrdateien Mesa/src/mesa/drivers/dri/r200/r200_tcl.o and 
Mesa-21-04/src/mesa/drivers/dri/r200/r200_tcl.o sind verschieden.
Binrdateien 

Re: [Mesa3d-dev] update on GL_EXT_framebuffer_object work

[Dieter Nützel]

Am Montag, 2. Mai 2005 16:56 schrieb Brian Paul:
 This weekend I finished updating the DRI drivers to work with the new
 framebuffer/renderbuffer changes.  My DRI test system is terribly out
 of date so I haven't run any tests.  I'm tempted to just check in the
 changes now and help people fix any problems that arise, rather than
 spend a few days updating my test box.  I think the code changes are
 pretty safe though.

 I'm going to be out of town next week so I should either check in
 things today or wait 2 weeks.  I'd rather do it sooner than later, and
 work through any breakage right away.

 Are there any questions or concerns?

Do you know that r200, at least do NOT work right, today?

Texture problems. (maybe tnl related)
NO old bigger apps works.
Q3A, Doom3, celestia, etc...

Appeared after the latest major merge.

Do you had a look at Roland's dri_span41.diff and Felix's older spantmp2.h 
optimization?

Both worked for me. Even together. But I didn't see the speedup which Felix 
hoped for.

no_rast=true gave me indirect rendering all the time.

-Dieter


---
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [r200] Since your latest merge I only get indirect

[Dieter Nützel]

Am Sonntag, 17. April 2005 21:40 schrieb Ian Romanick:
 Dieter Ntzel wrote:
  cvs update -D '4 days ago' fix it.
 
  Maybe there is a brand new TLS patch for X.org CVS anywhere?

 The TLS support is only built if you add '-DGLX_USE_TLS' to your
 compiler flags.  The prefered way to do that is
 ARCH_FLAGS='-DGLX_USE_TLS make linux-dri' or something.  If you haven't
 added that to your compiler flags, it shouldn't change anything.

 How are you building?  Are you using the libGL built in Mesa with the
 drivers built there?  Just libGL?  Just the drivers?

OK, this one is SOLVED.
I had relict from your older patches in one of my makefiles.

But, bad texture problems, now.
Flickering, wrong rendering and much to dark. (src/mesa/tnl?)
Most worse with 'Highlight' (gloss)

-Dieter


---
SF.Net email is sponsored by: Tell us your software development plans!
Take this survey and enter to win a one-year sub to SourceForge.net
Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start!  http://www.idcswdc.com/cgi-bin/survey?id5hix
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [r200] Since your latest merge I only get indirect

[Dieter Nützel]

Am Sonntag, 17. April 2005 21:40 schrieb Ian Romanick:
 Dieter Ntzel wrote:
  cvs update -D '4 days ago' fix it.
 
  Maybe there is a brand new TLS patch for X.org CVS anywhere?

 The TLS support is only built if you add '-DGLX_USE_TLS' to your
 compiler flags.  The prefered way to do that is
 ARCH_FLAGS='-DGLX_USE_TLS make linux-dri' or something.  If you haven't
 added that to your compiler flags, it shouldn't change anything.

 How are you building?  Are you using the libGL built in Mesa with the
 drivers built there?  Just libGL?  Just the drivers?

OK, this one is SOLVED.
I had relict from your older patches in one of my makefiles.

But, bad texture problems, now.
Flickering, wrong rendering and much to dark. (src/mesa/tnl?)
Most worse with 'Highlight' (gloss)

-Dieter
attachment: gears.png

[r200] Since your latest merge I only get indirect

[Dieter Nützel]

cvs update -D '4 days ago' fix it.

Maybe there is a brand new TLS patch for X.org CVS anywhere?

Thanks,
Dieter


---
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: [r200] Mesa CVS changes after 23.05 broke direct rendering (shader)

[Dieter Nützel]

Am Montag, 28. Mrz 2005 20:03 schrieb Dieter Ntzel:
 Happy Easter!

 -Dieter


This one helps

http://sourceforge.net/mailarchive/forum.php?thread_id=6901710forum_id=5154

-Dieter


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

[r200] Mesa CVS changes after 23.05 broke direct rendering (shader)

[Dieter Nützel]

Happy Easter!

-Dieter


---
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: [r200] 'readpix' sigfault back trace SSE/MMX is culprit

[Dieter Nützel]

Am Dienstag, 1. März 2005 19:46 schrieb Roland Scheidegger:
 Dieter Nützel wrote:
 Looking a bit at this, this seems to be caused because the number of
 pixels to read can be less than zero after CLIPSPAN (don't know if
 that's a bug in itself or not).
 
  That was my first thought, too (moving the window out to the left...) ;-)
 
 This is no problem for the generic read (since the for loop will just
 terminate instantly), but the mmx/sse/sse2 optimized routines only test
 if it's 0 pixels to read, and don't bail out if it's less than zero. I
 haven't looked closely what exactly will happen (i.e. the loops may
 never terminate at all), but this certainly seems like a bad thing...

 Here's a one-liner fix, which will cause CLIPSPAN hopefully never return
 a negative n1. Seems to work here.
 Ian, what do you think? Would it be better to have the optimized
 read/write functions deal with negative values instead?

Ian,

any thoughts?

Thanks,
Dieter


---
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: dri span patches...

[Dieter Nützel]

Am Donnerstag, 3. März 2005 20:36 schrieb Roland Scheidegger:
 Dieter Nützel wrote:
  Am Donnerstag, 3. März 2005 4:48 schrieb Roland Scheidegger:
  Roland Scheidegger wrote: here's a patch which mainly does 3
  things: - convert sis, mach64, and radeon to spantmp2. The sis and
  mach64 drivers got a slight change, previously you could not read
  back alpha values (always 0xff) and I don't think there was a good
  reason for that?
 
  Roland,
 
  do you had a look on Felix's spantmp2.diff, too.
 
  http://marc.theaimsgroup.com/?l=dri-develm=110600974029291w=2

 I have missed that completely. Should be possible to work together with
 this patch just fine, though patch might disagree.

  BTW Can you please send me a private copy of dri-span3.diff, again.
  There are many ugly =3D characters in the archived version.

 You'll even get a newer version, Alan pointed out some subtle issues
 with the macro expansion (one of the reasons I don't particularly like
 macros...). Instead of fixing all GET_SRC/DST_PTR macros, I got rid of
 them too, since they were identical again in all drivers which use
 spantmp2 (except unichrome which uses different pitches for reading and
 drawing, it keeps its macros).

Sorry,

you lost spantmp_common.h in dri_span4.diff.

/opt/Mesa grep -r spantmp_common.h *
src/mesa/drivers/dri/common/stenciltmp.h:#include spantmp_common.h
src/mesa/drivers/dri/common/depthtmp.h:#include spantmp_common.h
src/mesa/drivers/dri/common/spantmp.h:#include spantmp_common.h
src/mesa/drivers/dri/common/spantmp2.h:#include spantmp_common.h
src/mesa/drivers/dri/common/spantmp2.h.orig:#include spantmp_common.h
/opt/Mesa find -name spantmp_common.h

-Dieter


---
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: dri span patches...

[Dieter Nützel]

Am Donnerstag, 3. März 2005 4:48 schrieb Roland Scheidegger:
 Roland Scheidegger wrote:
 here's a patch which mainly does 3 things: - convert sis, mach64,
 and radeon to spantmp2. The sis and mach64 drivers got a slight
 change, previously you could not read back alpha values (always
 0xff) and I don't think there was a good reason for that?

Roland,

do you had a look on Felix's spantmp2.diff, too.

http://marc.theaimsgroup.com/?l=dri-develm=110600974029291w=2

I have it running with r200 (32 bpp) but do not see big changes (slowdown or 
speedup).

BTW Can you please send me a private copy of dri-span3.diff, again.
There are many ugly =3D characters in the archived version.

-Dieter


---
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: [r200] 'readpix' sigfault back trace SSE/MMX is culprit

[Dieter Nützel]

Am Dienstag, 1. Mrz 2005 18:06 schrieb Roland Scheidegger:
 Dieter Ntzel wrote:
  Am Mittwoch, 16. Februar 2005 21:27 schrieb Dieter Ntzel:
 
  Any change that someone look into this?
 
  Ian, it seems that's related to your new SSE/MMX code.
 
  Thanks,
  Dieter
 
 Move window 'out' to the left.
 
 NO sigfault with MESA_NO_SSE and MESA_NO_MMX.
 
 With MMX:
 #0  0x406a92b5 in _generic_read_RGBA_span_BGRA_REV_MMX ()
from /usr/X11R6/lib/modules/dri/r200_dri.so
 #1  0x405655af in r200ReadRGBASpan_ARGB_MMX (ctx=0x7fffb862, n=194,
 x=5, y=229, rgba=0x45024008) at spantmp2.h:415

 Looking a bit at this, this seems to be caused because the number of
 pixels to read can be less than zero after CLIPSPAN (don't know if
 that's a bug in itself or not).

That was my first thought, too (moving the window out to the left...) ;-)

 This is no problem for the generic read (since the for loop will just
 terminate instantly), but the mmx/sse/sse2 optimized routines only test
 if it's 0 pixels to read, and don't bail out if it's less than zero. I
 haven't looked closely what exactly will happen (i.e. the loops may
 never terminate at all), but this certainly seems like a bad thing...

;-)

Thanks,
Dieter



---
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: [r200] 'readpix' sigfault back trace SSE/MMX is culprit

[Dieter Nützel]

Am Mittwoch, 16. Februar 2005 21:27 schrieb Dieter Ntzel:

Any change that someone look into this?

Ian, it seems that's related to your new SSE/MMX code.

Thanks,
Dieter


 Move window 'out' to the left.

 NO sigfault with MESA_NO_SSE and MESA_NO_MMX.

 With MMX:
 #0  0x406a92b5 in _generic_read_RGBA_span_BGRA_REV_MMX ()
from /usr/X11R6/lib/modules/dri/r200_dri.so
 (gdb) list
 262
 263TempImage = (GLubyte *) malloc(ImgWidth * ImgHeight * 4 *
 sizeof(GLubyte));
 264assert(TempImage);
 265 }
 266
 267
 268 int
 269 main( int argc, char *argv[] )
 270 {
 271GLboolean ciMode = GL_FALSE;
 (gdb) bt
 #0  0x406a92b5 in _generic_read_RGBA_span_BGRA_REV_MMX ()
from /usr/X11R6/lib/modules/dri/r200_dri.so
 #1  0x405655af in r200ReadRGBASpan_ARGB_MMX (ctx=0x7fffb862, n=194,
 x=5, y=229, rgba=0x45024008) at spantmp2.h:415
 #2  0x40602944 in read_fast_rgba_pixels (ctx=0x8060928, x=5, y=20,
 width=2147465314, height=188, format=6408, type=5121,
 pixels=0x7fffb862, packing=0x45048000) at swrast/s_readpix.c:288
 #3  0x406029f5 in read_rgba_pixels (ctx=0x8060928, x=5, y=20, width=194,
 height=188, format=6408, type=5121, pixels=0x45024008,
 packing=0xbfffeb30) at swrast/s_readpix.c:324
 #4  0x40603237 in _swrast_ReadPixels (ctx=0x8060928, x=5, y=20, width=194,
 height=188, format=6408, type=5121, packing=0xbfffeb30,
 pixels=0x45024008) at swrast/s_readpix.c:556
 #5  0x405552e5 in r200ReadPixels (ctx=0x8060928, x=5, y=20, width=194,
 height=188, format=6408, type=5121, pack=0x8073c24, pixels=0x45024008)
 at r200_pixel.c:281
 #6  0x4064bd44 in _mesa_ReadPixels (x=2147465314, y=2147465314, width=194,
 height=188, format=2147465314, type=2147465314, pixels=0x7fffb862)
 at main/drawpix.c:171
 #7  0x0804942f in Display () at readpix.c:141
 #8  0x40045f8e in processWindowWorkList () from /usr/lib/libglut.so.3
 #9  0x4004601a in __glutProcessWindowWorkLists () from
 /usr/lib/libglut.so.3 #10 0x4004608b in glutMainLoop () from
 /usr/lib/libglut.so.3
 #11 0x080499e7 in main (argc=1, argv=0xbfffedf4) at readpix.c:287
 (gdb) info registers
 eax0x7fffb862   2147465314
 ecx0x45048000   1157922816
 edx0xfe12   -494
 ebx0x4091c140   1083294016
 esp0xbffe69e8   0xbffe69e8
 ebp0xbffe6a28   0xbffe6a28
 esi0x2ee750
 edi0x0  0
 eip0x406a92b5   0x406a92b5
 eflags 0x10212  66066
 cs 0x73 115
 ss 0x7b 123
 ds 0x7b 123
 es 0x7b 123
 fs 0x0  0
 gs 0x33 51


 With SSE:
 #0  0x406a931d in _generic_read_RGBA_span_BGRA_REV_SSE ()
from /usr/X11R6/lib/modules/dri/r200_dri.so
 (gdb) list
 262
 263TempImage = (GLubyte *) malloc(ImgWidth * ImgHeight * 4 *
 sizeof(GLubyte));
 264assert(TempImage);
 265 }
 266
 267
 268 int
 269 main( int argc, char *argv[] )
 270 {
 271GLboolean ciMode = GL_FALSE;
 (gdb) bt
 #0  0x406a931d in _generic_read_RGBA_span_BGRA_REV_SSE ()
from /usr/X11R6/lib/modules/dri/r200_dri.so
 #1  0xff131f11 in ?? ()
 (gdb) info registers
 eax0xff4d4d4d   -11711155
 ecx0x4504826c   1157923436
 edx0x0  0
 ebx0x407f7404   1082094596
 esp0xbffe69e0   0xbffe69e0
 ebp0xbffe69f0   0xbffe69f0
 esi0xfddf   -545
 edi0x0  0
 eip0x406a931d   0x406a931d
 eflags 0x10203  66051
 cs 0x73 115
 ss 0x7b 123
 ds 0x7b 123
 es 0x7b 123
 fs 0x0  0
 gs 0x33 51

-- 
Dieter Ntzel
@home: Dieter.Nuetzel () hamburg ! de


---
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: When will we see radeon_textiling4_drm.diff committed?

[Dieter Nützel]

Am Mittwoch, 2. Mrz 2005 18:10 schrieb Roland Scheidegger:
 Dieter Ntzel wrote:
  DRM CVS

 All texture tiling related patches (drm/dri) have been commited some
 weeks ago.

Urgs,

I had frozen my tree...

update -A bring it back on shape. ;-)

Sorry,
Dieter


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

[r200] gltestperf - some progress

[Dieter Nützel]

progs/demos ./gltestperf
GLTest v1.0
Written by David Bucciarelli
Benchmark: 0
Elapsed time for the calibration test (29567): 2.00
Selected number of benchmark iterations: 73917
Elapsed time for run 0: 1.621000
Elapsed time for run 1: 1.616000
Elapsed time for run 2: 1.61
Elapsed time for run 3: 1.603000
Elapsed time for run 4: 1.605000
Simple Points
22032803.306113 Pnts/sec

Benchmark: 1
Smooth Lines
Current size: 480
Elapsed time for the calibration test (1746): 2.001000
Selected number of benchmark iterations: 4362
Elapsed time for run 0: 4.465000
Elapsed time for run 1: 4.486000
Elapsed time for run 2: 4.471000
Elapsed time for run 3: 4.468000
Elapsed time for run 4: 4.485000
SIZE=480 = 467914.124514 Lins/sec
Current size: 250
Elapsed time for the calibration test (5658): 2.00
Selected number of benchmark iterations: 14145
Elapsed time for run 0: 3.927000
Elapsed time for run 1: 3.941000
Elapsed time for run 2: 3.929000
Elapsed time for run 3: 3.939000
Elapsed time for run 4: 3.941000
SIZE=250 = 898361.418096 Lins/sec
Current size: 100
Elapsed time for the calibration test (22957): 2.00
Selected number of benchmark iterations: 57392
Elapsed time for run 0: 2.531000
Elapsed time for run 1: 2.518000
Elapsed time for run 2: 2.522000
Elapsed time for run 3: 2.528000
Elapsed time for run 4: 2.52
SIZE=100 = 2274451.875047 Lins/sec
Current size: 50
Elapsed time for the calibration test (49328): 2.00
Selected number of benchmark iterations: 123320
Elapsed time for run 0: 1.346000
Elapsed time for run 1: 1.35
Elapsed time for run 2: 1.331000
Elapsed time for run 3: 1.33
Elapsed time for run 4: 1.329000
SIZE=050 = 4616421.297949 Lins/sec
Current size: 25
Elapsed time for the calibration test (65210): 2.00
Selected number of benchmark iterations: 163025
Elapsed time for run 0: 0.869000
Elapsed time for run 1: 0.865000
Elapsed time for run 2: 0.867000
Elapsed time for run 3: 0.866000
Elapsed time for run 4: 0.865000
SIZE=025 = 4706264.776240 Lins/sec


Benchmark: 2
ZSmooth Triangles
Current size: 480
Elapsed time for the calibration test (345): 2.002000
Selected number of benchmark iterations: 861
Elapsed time for run 0: 6.726000
Elapsed time for run 1: 6.73
Elapsed time for run 2: 6.727000
Elapsed time for run 3: 6.73
Elapsed time for run 4: 6.728000
SIZE=480 = 12284.766240 Tris/sec
Current size: 250
Elapsed time for the calibration test (2275): 2.00
Selected number of benchmark iterations: 5687
Elapsed time for run 0: 2.321000
Elapsed time for run 1: 2.321000
Elapsed time for run 2: 2.321000
Elapsed time for run 3: 2.323000
Elapsed time for run 4: 2.321000
SIZE=250 = 122511.843106 Tris/sec
Current size: 100
Elapsed time for the calibration test (23053): 2.00
Selected number of benchmark iterations: 57632
Elapsed time for run 0: 0.785000
Elapsed time for run 1: 0.785000
Elapsed time for run 2: 0.786000
Elapsed time for run 3: 0.784000
Elapsed time for run 4: 0.782000
SIZE=100 = 1468955.061911 Tris/sec
Current size: 50
Elapsed time for the calibration test (57636): 2.00
Selected number of benchmark iterations: 144090
Elapsed time for run 0: 0.579000
Elapsed time for run 1: 0.581000
Elapsed time for run 2: 0.58
Elapsed time for run 3: 0.578000
Elapsed time for run 4: 0.582000
SIZE=050 = 2484310.331211 Tris/sec
Current size: 25
Elapsed time for the calibration test (70233): 2.00
Selected number of benchmark iterations: 175582
Elapsed time for run 0: 0.312000
Elapsed time for run 1: 0.31
Elapsed time for run 2: 0.31
Elapsed time for run 3: 0.311000
Elapsed time for run 4: 0.31
SIZE=025 = 2828925.903531 Tris/sec


Benchmark: 3
ZSmooth Tex Blend Triangles
Current size: 480
Elapsed time for the calibration test (317): 2.005000
Selected number of benchmark iterations: 790
Elapsed time for run 0: 10.813000
Elapsed time for run 1: 10.816000
Elapsed time for run 2: 10.815000
Elapsed time for run 3: 10.813000
Elapsed time for run 4: 10.815000
SIZE=480 = 7012.914787 Tris/sec
Current size: 250
Elapsed time for the calibration test (1511): 2.00
Selected number of benchmark iterations: 3777
Elapsed time for run 0: 4.988000
Elapsed time for run 1: 4.989000
Elapsed time for run 2: 4.989000
Elapsed time for run 3: 4.99
Elapsed time for run 4: 4.989000
SIZE=250 = 37853.277191 Tris/sec
Current size: 100
Elapsed time for the calibration test (12275): 2.00
Selected number of benchmark iterations: 30687
Elapsed time for run 0: 1.348000
Elapsed time for run 1: 1.348000
Elapsed time for run 2: 1.349000
Elapsed time for run 3: 1.346000
Elapsed time for run 4: 1.346000
SIZE=100 = 455522.039438 Tris/sec
Current size: 50
Elapsed time for the calibration test (43712): 2.00
Selected number of benchmark iterations: 109280
Elapsed time for run 0: 0.681000
Elapsed time for run 1: 0.679000
Elapsed time for run 2: 0.682000
Elapsed time for run 3: 0.678000
Elapsed time for run 4: 0.677000
SIZE=050 = 1608635.833258 Tris/sec
Current size: 25
Elapsed time for 

Re: [r200] 'readpix' sigfault back trace SSE/MMX is culprit

[Dieter Nützel]

Am Dienstag, 1. März 2005 19:46 schrieb Roland Scheidegger:
 Dieter Nützel wrote:
 Looking a bit at this, this seems to be caused because the number of
 pixels to read can be less than zero after CLIPSPAN (don't know if
 that's a bug in itself or not).
 
  That was my first thought, too (moving the window out to the left...) ;-)
 
 This is no problem for the generic read (since the for loop will just
 terminate instantly), but the mmx/sse/sse2 optimized routines only test
 if it's 0 pixels to read, and don't bail out if it's less than zero. I
 haven't looked closely what exactly will happen (i.e. the loops may
 never terminate at all), but this certainly seems like a bad thing...

 Here's a one-liner fix, which will cause CLIPSPAN hopefully never return
 a negative n1. Seems to work here.
 Ian, what do you think? Would it be better to have the optimized
 read/write functions deal with negative values instead?

Works, even without UNLOCK_HARDWARE changes ;-)

Cheers,
Dieter


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

When will we see radeon_textiling4_drm.diff committed?

[Dieter Nützel]

DRM CVS

Thanks,
Dieter


---
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: [R200] Nearly all xscreensavers GL flicker

[Dieter Nützel]

Am Freitag, 25. Februar 2005 16:47 schrieb Adam Jackson:
 On Thursday 24 February 2005 13:27, Marcello Maggioni wrote:
  With XSCREENSAVER alone it effectively runs without problems , but I
  wonder why ...
 
  There's a logical explanation for this?? O_o

 Yeah.  KDE's screensaver module probably opens its own fullscreen window
 and tells the screensaver to draw on that.  Since the window is already
 created the screensaver can't change its visual, which means if the window
 was created in a single buffer visual you're stuck.

So someone should send a bug report to fix that before KDE 3.4 arise...;-)

Greetings,
Dieter


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

[r200] 'texdown' - 'b' sigfault back trace

[Dieter Nützel]

Reading symbols from /usr/X11R6/lib/modules/dri/r200_dri.so...done.
Loaded symbols for /usr/X11R6/lib/modules/dri/r200_dri.so
Reading symbols from /usr/X11R6/lib/libexpat.so.0...done.
Loaded symbols for /usr/X11R6/lib/libexpat.so.0
Reading symbols from /usr/lib/libtxc_dxtn.so...done.
Loaded symbols for /usr/lib/libtxc_dxtn.so
Reading symbols from /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2...done.
Loaded symbols for /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2
#0  _tnl_build_vertices (ctx=0x8060928, start=0, end=0, newinputs=0)
at tnl/t_vertex.c:1379
1379 a[j].inputstride = vptr-stride;
(gdb) list
1374  const GLuint count = vtx-attr_count;
1375  GLuint j;
1376
1377  for (j = 0; j  count; j++) {
1378 GLvector4f *vptr = VB-AttribPtr[a[j].attrib];
1379 a[j].inputstride = vptr-stride;
1380 a[j].inputptr = ((GLubyte *)vptr-data) + start * 
vptr-stride;
1381 a[j].emit = a[j].insert[vptr-size - 1];
1382  }
1383
(gdb) info registers
eax0x0  0
ecx0x0  0
edx0x0  0
ebx0x81f7b34136280884
esp0xbfffe650   0xbfffe650
ebp0xbfffe678   0xbfffe678
esi0x0  0
edi0x81f6658136275544
eip0x405e9e85   0x405e9e85
eflags 0x10293  66195
cs 0x73 115
ss 0x7b 123
ds 0x7b 123
es 0x7b 123
fs 0x0  0
gs 0x33 51


Even with

option name=tcl_mode value=0 /

Or

MESA_ALWAYS_INDIRECT
R200_NO_TCL
R200_NO_VTXFMT

Cheers,
Dieter


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

[r200] 'readpix' sigfault back trace SSE/MMX is culprit

[Dieter Nützel]

Move window 'out' to the left.

NO sigfault with MESA_NO_SSE and MESA_NO_MMX.

With MMX:
#0  0x406a92b5 in _generic_read_RGBA_span_BGRA_REV_MMX ()
   from /usr/X11R6/lib/modules/dri/r200_dri.so
(gdb) list
262
263TempImage = (GLubyte *) malloc(ImgWidth * ImgHeight * 4 * 
sizeof(GLubyte));
264assert(TempImage);
265 }
266
267
268 int
269 main( int argc, char *argv[] )
270 {
271GLboolean ciMode = GL_FALSE;
(gdb) bt
#0  0x406a92b5 in _generic_read_RGBA_span_BGRA_REV_MMX ()
   from /usr/X11R6/lib/modules/dri/r200_dri.so
#1  0x405655af in r200ReadRGBASpan_ARGB_MMX (ctx=0x7fffb862, n=194, x=5,
y=229, rgba=0x45024008) at spantmp2.h:415
#2  0x40602944 in read_fast_rgba_pixels (ctx=0x8060928, x=5, y=20,
width=2147465314, height=188, format=6408, type=5121, pixels=0x7fffb862,
packing=0x45048000) at swrast/s_readpix.c:288
#3  0x406029f5 in read_rgba_pixels (ctx=0x8060928, x=5, y=20, width=194,
height=188, format=6408, type=5121, pixels=0x45024008, packing=0xbfffeb30)
at swrast/s_readpix.c:324
#4  0x40603237 in _swrast_ReadPixels (ctx=0x8060928, x=5, y=20, width=194,
height=188, format=6408, type=5121, packing=0xbfffeb30, pixels=0x45024008)
at swrast/s_readpix.c:556
#5  0x405552e5 in r200ReadPixels (ctx=0x8060928, x=5, y=20, width=194,
height=188, format=6408, type=5121, pack=0x8073c24, pixels=0x45024008)
at r200_pixel.c:281
#6  0x4064bd44 in _mesa_ReadPixels (x=2147465314, y=2147465314, width=194,
height=188, format=2147465314, type=2147465314, pixels=0x7fffb862)
at main/drawpix.c:171
#7  0x0804942f in Display () at readpix.c:141
#8  0x40045f8e in processWindowWorkList () from /usr/lib/libglut.so.3
#9  0x4004601a in __glutProcessWindowWorkLists () from /usr/lib/libglut.so.3
#10 0x4004608b in glutMainLoop () from /usr/lib/libglut.so.3
#11 0x080499e7 in main (argc=1, argv=0xbfffedf4) at readpix.c:287
(gdb) info registers
eax0x7fffb862   2147465314
ecx0x45048000   1157922816
edx0xfe12   -494
ebx0x4091c140   1083294016
esp0xbffe69e8   0xbffe69e8
ebp0xbffe6a28   0xbffe6a28
esi0x2ee750
edi0x0  0
eip0x406a92b5   0x406a92b5
eflags 0x10212  66066
cs 0x73 115
ss 0x7b 123
ds 0x7b 123
es 0x7b 123
fs 0x0  0
gs 0x33 51


With SSE:
#0  0x406a931d in _generic_read_RGBA_span_BGRA_REV_SSE ()
   from /usr/X11R6/lib/modules/dri/r200_dri.so
(gdb) list
262
263TempImage = (GLubyte *) malloc(ImgWidth * ImgHeight * 4 * 
sizeof(GLubyte));
264assert(TempImage);
265 }
266
267
268 int
269 main( int argc, char *argv[] )
270 {
271GLboolean ciMode = GL_FALSE;
(gdb) bt
#0  0x406a931d in _generic_read_RGBA_span_BGRA_REV_SSE ()
   from /usr/X11R6/lib/modules/dri/r200_dri.so
#1  0xff131f11 in ?? ()
(gdb) info registers
eax0xff4d4d4d   -11711155
ecx0x4504826c   1157923436
edx0x0  0
ebx0x407f7404   1082094596
esp0xbffe69e0   0xbffe69e0
ebp0xbffe69f0   0xbffe69f0
esi0xfddf   -545
edi0x0  0
eip0x406a931d   0x406a931d
eflags 0x10203  66051
cs 0x73 115
ss 0x7b 123
ds 0x7b 123
es 0x7b 123
fs 0x0  0
gs 0x33 51

-Dieter


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

[r200] doom3-demo do NOT work anylonger

[Dieter Nützel]

Maybe GL_ATI_fragment_shader?

Same setup worked before 'texture|color tiling ' etc.
But XFree86 + Mesa DRI ;-)

-Dieter


Running in restricted demo mode.

- Initializing Decls -
--
--- Initializing renderSystem 
using ARB renderSystem
renderSystem initialized.
--
5151 strings read from strings/english.lang
Couldn't open journal files
couldn't exec editor.cfg
execing default.cfg
execing DoomConfig.cfg
couldn't exec autoexec.cfg
5151 strings read from strings/english.lang
- Initializing Sound System --
sound system initialized.
--
- R_InitOpenGL -
dlopen(libGL.so.1)
Open X display
Initializing OpenGL display
Using XFree86-VidModeExtension Version 2.2
DGA DirectVideo Mouse (Version 2.0) initialized
XFree86-VidModeExtension: Ignored on non-fullscreen
Using 8/8/8 Color bits, 8 Alpha bits, 24 depth, 8 stencil display.
GL_RENDERER: Mesa GLX Indirect
GL_EXTENSIONS: GL_ARB_depth_texture GL_ARB_imaging GL_ARB_multitexture 
GL_ARB_point_parameters GL_ARB_point_sprite GL_ARB_shadow 
GL_ARB_shadow_ambient GL_ARB_texture_border_clamp GL_ARB_texture_cube_map 
GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_crossbar 
GL_ARB_texture_env_dot3 GL_ARB_texture_mirrored_repeat 
GL_ARB_transpose_matrix GL_ARB_window_pos GL_EXT_abgr GL_EXT_bgra 
GL_EXT_blend_color GL_EXT_blend_func_separate GL_EXT_blend_logic_op 
GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_clip_volume_hint 
GL_EXT_copy_texture GL_EXT_draw_range_elements GL_EXT_fog_coord 
GL_EXT_multi_draw_arrays GL_EXT_packed_pixels GL_EXT_point_parameters 
GL_EXT_polygon_offset GL_EXT_rescale_normal GL_EXT_secondary_color 
GL_EXT_separate_specular_color GL_EXT_shadow_funcs GL_EXT_stencil_two_side 
GL_EXT_stencil_wrap GL_EXT_subtexture GL_EXT_texture GL_EXT_texture3D 
GL_EXT_texture_edge_clamp GL_EXT_texture_env_add GL_EXT_texture_env_combine 
GL_EXT_texture_env_dot3 GL_EXT_texture_lod_bias GL_EXT_texture_object 
GL_EXT_texture_rectangle GL_EXT_vertex_array GL_APPLE_packed_pixels 
GL_ATI_texture_env_combine3 GL_ATI_texture_mirror_once 
GL_ATIX_texture_env_combine3 GL_IBM_texture_mirrored_repeat 
GL_INGR_blend_func_separate GL_MESA_pack_invert GL_MESA_ycbcr_texture 
GL_NV_blend_square GL_NV_point_sprite GL_NV_texgen_reflection 
GL_NV_texture_rectangle GL_SGIS_generate_mipmap GL_SGIS_texture_border_clamp 
GL_SGIS_texture_edge_clamp GL_SGIS_texture_lod GL_SGIX_depth_texture 
GL_SGIX_shadow GL_SGIX_shadow_ambient GL_SUN_multi_draw_arrays

--- Input Initialization ---
XKB extension: compile time 0x1:0x0, runtime 0x1:0x0: OK
XKB extension present on server ( 0x1:0x0 )

--- OSS Sound Initialization ---
opened sound device '/dev/dsp'
/dev/dsp - bit rate: 16, channels: 2, frequency: 44100

...using GL_ARB_multitexture
...using GL_ARB_texture_env_combine
...using GL_ARB_texture_cube_map
...using GL_ARB_texture_env_dot3
...using GL_ARB_texture_env_add
X..GL_ARB_texture_non_power_of_two not found
X..GL_ARB_texture_compression not found
X..GL_EXT_texture_filter_anisotropic not found
...using GL_EXT_texture_lod
...using GL_1.4_texture_lod_bias
X..GL_EXT_shared_texture_palette not found
...using GL_EXT_texture3D
...using GL_EXT_stencil_wrap
X..GL_NV_register_combiners not found
...using GL_EXT_stencil_two_side
X..GL_ATI_fragment_shader not found
X..GL_ATI_text_fragment_shader not found
X..GL_ARB_vertex_buffer_object not found
X..GL_ARB_vertex_program not found
X..GL_ARB_fragment_program not found
X..EXT_depth_bounds_test not found
-- R_NV20_Init --
Not available.
--- R200_Init ---
Not available.
-- R_ARB2_Init --
Not available.
-- R_Exp_Init ---
Disabled at compile time.
-
- R_ReloadARBPrograms -
glprogs/test.vfp: GL_VERTEX_PROGRAM_ARB not available
glprogs/test.vfp: GL_FRAGMENT_PROGRAM_ARB not available
glprogs/interaction.vfp: GL_VERTEX_PROGRAM_ARB not available
glprogs/interaction.vfp: GL_FRAGMENT_PROGRAM_ARB not available
glprogs/bumpyEnvironment.vfp: GL_VERTEX_PROGRAM_ARB not available
glprogs/bumpyEnvironment.vfp: GL_FRAGMENT_PROGRAM_ARB not available
glprogs/ambientLight.vfp: GL_VERTEX_PROGRAM_ARB not available
glprogs/ambientLight.vfp: GL_FRAGMENT_PROGRAM_ARB not available
glprogs/shadow.vp: GL_VERTEX_PROGRAM_ARB not available
glprogs/R200_interaction.vp: GL_VERTEX_PROGRAM_ARB not available
glprogs/nv20_bumpAndLight.vp: GL_VERTEX_PROGRAM_ARB not available
glprogs/nv20_diffuseColor.vp: GL_VERTEX_PROGRAM_ARB not available
glprogs/nv20_specularColor.vp: GL_VERTEX_PROGRAM_ARB not available
glprogs/nv20_diffuseAndSpecularColor.vp: GL_VERTEX_PROGRAM_ARB not available
glprogs/environment.vfp: GL_VERTEX_PROGRAM_ARB not available
glprogs/environment.vfp: GL_FRAGMENT_PROGRAM_ARB not available
---

Re: [r200] doom3-demo do NOT work anylonger

[Dieter Nützel]

Am Mittwoch, 16. Februar 2005 21:36 schrieb Dieter Ntzel:
 Maybe GL_ATI_fragment_shader?

 --
 - R_InitOpenGL -
 dlopen(libGL.so.1)
 Open X display
 Initializing OpenGL display
 Using XFree86-VidModeExtension Version 2.2
 DGA DirectVideo Mouse (Version 2.0) initialized
 XFree86-VidModeExtension: Ignored on non-fullscreen
 Using 8/8/8 Color bits, 8 Alpha bits, 24 depth, 8 stencil display.
 GL_RENDERER: Mesa GLX Indirect

Arghhh,

why MESA indirect???

-Dieter


---
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: [r200] doom3-demo do NOT work anylonger

[Dieter Nützel]

Am Mittwoch, 16. Februar 2005 22:26 schrieb Roland Scheidegger:
 Dieter Ntzel wrote:
  Am Mittwoch, 16. Februar 2005 21:36 schrieb Dieter Ntzel:
 Maybe GL_ATI_fragment_shader?
 
 
 --
 - R_InitOpenGL -
 dlopen(libGL.so.1)
 Open X display
 Initializing OpenGL display
 Using XFree86-VidModeExtension Version 2.2
 DGA DirectVideo Mouse (Version 2.0) initialized
 XFree86-VidModeExtension: Ignored on non-fullscreen
 Using 8/8/8 Color bits, 8 Alpha bits, 24 depth, 8 stencil display.
 GL_RENDERER: Mesa GLX Indirect
 
  Arghhh,
 
  why MESA indirect???

 This happens with the Mesa-built libGL.so, since doom3 does not load
 libGL with RTLD_GLOBAL. This is reportedly fixed in the newer version of
 the demo, alternatively you can put something like
 LD_PRELOAD=/usr/lib/libGL.so in the doom startup script.

OK, yes.

Nice fps, now.

But I need your hack. = recompile, soon ;-)

BTW Your hack for /usr/X11R6/lib/xscreensaver/flipscreen3d -geometry  1024
do NOT work anylonger.

Thanks,
Dieter


---
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: [r200] doom3-demo do NOT work anylonger

[Dieter Nützel]

Am Mittwoch, 16. Februar 2005 22:43 schrieb Dieter Ntzel:
 Am Mittwoch, 16. Februar 2005 22:26 schrieb Roland Scheidegger:
  Dieter Ntzel wrote:
   Am Mittwoch, 16. Februar 2005 21:36 schrieb Dieter Ntzel:
  Maybe GL_ATI_fragment_shader?
  
  
  --
  - R_InitOpenGL -
  dlopen(libGL.so.1)
  Open X display
  Initializing OpenGL display
  Using XFree86-VidModeExtension Version 2.2
  DGA DirectVideo Mouse (Version 2.0) initialized
  XFree86-VidModeExtension: Ignored on non-fullscreen
  Using 8/8/8 Color bits, 8 Alpha bits, 24 depth, 8 stencil display.
  GL_RENDERER: Mesa GLX Indirect
  
   Arghhh,
  
   why MESA indirect???
 
  This happens with the Mesa-built libGL.so, since doom3 does not load
  libGL with RTLD_GLOBAL. This is reportedly fixed in the newer version of
  the demo, alternatively you can put something like
  LD_PRELOAD=/usr/lib/libGL.so in the doom startup script.

 OK, yes.

 Nice fps, now.

 But I need your hack. = recompile, soon ;-)

Works.
Only a little 'shadow' in the middle of the screen.
I talking about this one:

r200_texstate.reallyuglydoom3hack

Index: r200_texstate.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r200/r200_texstate.c,v
retrieving revision 1.18
diff -u -r1.18 r200_texstate.c
--- r200_texstate.c 18 Oct 2004 00:00:41 -  1.18
+++ r200_texstate.c 7 Dec 2004 23:00:16 -
@@ -984,10 +984,12 @@
   rmesa-TexGenNeedNormals[unit] = GL_TRUE;
   tgi |= R200_TEXGEN_INPUT_SPHEREinputshift;
   /* GL_SPHERE_MAP doesn't appear to work. */
-  return GL_FALSE;
+/*  return GL_FALSE;*/

case 0:
   /* All texgen units were disabled, so just pass coords through. */
+  /* CHECK THIS it should not be necessary I believe
+(since all coords should be masked by tgcm), but it is!!! */
   tgi |= unit  inputshift;
   break;

@@ -999,7 +1001,7 @@
 texUnit-GenModeS);
   return GL_FALSE;
}
-
+   tgcm = 0;
rmesa-TexGenEnabled |= R200_TEXGEN_TEXMAT_0_ENABLE  unit;
rmesa-TexGenCompSel |= R200_OUTPUT_TEX_0  unit;

 BTW Your hack for /usr/X11R6/lib/xscreensaver/flipscreen3d -geometry  1024
 do NOT work anylonger.

And here:

--- src/mesa/drivers/dri/r200/r200_context.c2005-02-14 14:53:45.0 
+0100
+++ src/mesa/drivers/dri/r200/r200_context.c.Dieter 2005-02-08 
21:50:39.0 +0100
@@ -365,6 +365,11 @@
 12,
 GL_FALSE );

+/* adjust max texture size a bit. Hack, but I really want to use larger 
textures
+   which will work just fine in 99.99% of all cases, especially with 
texture
+   compression... */
+   if (ctx-Const.MaxTextureLevels  12) ctx-Const.MaxTextureLevels += 1;
+
ctx-Const.MaxTextureMaxAnisotropy = 16.0;

/* No wide points.


Have fun.

-Dieter


---
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: [r200] Mesa CVS text and texture bug

[Dieter Nützel]

Am Montag, 14. Februar 2005 21:49 schrieb Michel Dnzer:
 On Mon, 2005-02-14 at 20:06 +0100, Dieter Ntzel wrote:
  dmesg show this:
  agpgart: Found an AGP 2.0 compliant device at :00:00.0.
  agpgart: Putting AGP V2 device at :00:00.0 into 2x mode
  agpgart: Putting AGP V2 device at :01:05.0 into 2x mode
 
  glxinfo
  OpenGL vendor string: Tungsten Graphics, Inc.
  OpenGL renderer string: Mesa DRI R200 20041207 AGP 4x
  x86/MMX+/3DNow!+/SSE TCL OpenGL version string: 1.3 Mesa 6.3
 
  So only AGPGART output is wrong?

 Rather the other way around. Usually, this means either the AGP bridge
 or the card don't actually support more than 2x.

You are right.

AMD 768MPX support AGP Pro.
= max 4x

My r200
= max 2x (?)

But lspci -vv looks wrong.
See the AMD docs.
http://www.msi-computer.de/produkte/main_idx_view.php?Prod_id=191
I see 4x max in the BIOS.

00:00.0 Host bridge: Advanced Micro Devices [AMD] AMD-760 MP [IGD4-2P] System 
Controller (rev 11)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium TAbort- 
TAbort- MAbort+ SERR- PERR-
Latency: 32
Region 0: Memory at f000 (32-bit, prefetchable) [size=64M]
Region 1: Memory at f9061000 (32-bit, prefetchable) [size=4K]
Region 2: I/O ports at ec00 [disabled] [size=4]
Capabilities: [a0] AGP version 2.0
Status: RQ=16 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 
64bit- FW- AGP3- Rate=x1,x2
Command: RQ=1 ArqSz=0 Cal=0 SBA+ AGP+ GART64- 64bit- FW- 
Rate=x2

00:01.0 PCI bridge: Advanced Micro Devices [AMD] AMD-760 MP [IGD4-2P] AGP 
Bridge (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B-
Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium TAbort- 
TAbort- MAbort- SERR- PERR-
Latency: 32
Bus: primary=00, secondary=01, subordinate=01, sec-latency=32
I/O behind bridge: c000-cfff
Memory behind bridge: f400-f5ff
Prefetchable memory behind bridge: e800-efff
BridgeCtl: Parity- SERR+ NoISA+ VGA+ MAbort- Reset- FastB2B-

01:05.0 VGA compatible controller: ATI Technologies Inc Radeon R200 QL [Radeon 
8500 LE] (prog-if 00 [VGA])
Subsystem: C.P. Technology Co. Ltd: Unknown device 2034
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping+ SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- 
TAbort- MAbort- SERR- PERR-
Latency: 32 (2000ns min), cache line size 08
Interrupt: pin A routed to IRQ 17
Region 0: Memory at e800 (32-bit, prefetchable) [size=128M]
Region 1: I/O ports at c000 [size=256]
Region 2: Memory at f500 (32-bit, non-prefetchable) [size=64K]
Expansion ROM at unassigned [disabled] [size=128K]
Capabilities: [58] AGP version 2.0
Status: RQ=48 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 
64bit- FW+ AGP3- Rate=x1,x2
Command: RQ=16 ArqSz=0 Cal=0 SBA+ AGP+ GART64- 64bit- FW- 
Rate=x2
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-

Michel,

what about the Celestia text bug.
Seems to be appear only with 'small' text.

http://www.nuetzel-hh.de/public/Celestia-Mesa-CSV-r200.png

LIBGL_ALWAYS_INDIRECT is fine.

Thanks,
Dieter


---
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: [r200] Mesa CVS text and texture bug

[Dieter Nützel]

Am Freitag, 11. Februar 2005 23:12 schrieb Roland Scheidegger:
 Dieter Ntzel wrote:
  I get this even with X.org CVS.
  The texture problem is not persistent but the text 'of by oen or two'.
 
  http://www.nuetzel-hh.de/public/Celestia-Mesa-CSV-r200.png

 What version of Celestia is this? I get neither of these bugs here
 (celestia 1.3.0).

1.3.2 (latest release from August 2004, self compiled)

Mesa (LIBGL_ALWAYS_INDIRECT) works OK.

BTW There is _BIG_ regression with quake3 (quake3-smp)!

quake3-smp went down from ~198 - ~142 fps (with and without HIGH textures)

!!! Most worse with SMP. !!!

Do you have any texture load changes committed on Thursday to Friday?

-Dieter


---
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: [r200] Mesa CVS text and texture bug

[Dieter Nützel]

Am Montag, 14. Februar 2005 14:37 schrieb Dieter Ntzel:
 Am Freitag, 11. Februar 2005 23:12 schrieb Roland Scheidegger:
  Dieter Ntzel wrote:
   I get this even with X.org CVS.
   The texture problem is not persistent but the text 'of by oen or two'.

 BTW There is _BIG_ regression with quake3 (quake3-smp)!

 quake3-smp went down from ~198 - ~142 fps (with and without HIGH textures)

 !!! Most worse with SMP. !!!

 Do you have any texture load changes committed on Thursday to Friday?

This on is SOLVED!

It was due to SuSE's CKRM_CPU_SCHEDULE scheduler.

Back to Linux's 'normal' one solve it.

quake3-smp
~198 fps 2. high
~193 fps HIGH

640x480 window on 1280x1024x24/32.

1024x768 window give ~100 fps, again.

-Dieter


---
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: [r200] Mesa CVS text and texture bug

[Dieter Nützel]

Am Montag, 14. Februar 2005 19:40 schrieb Roland Scheidegger:
 Dieter Ntzel wrote:
  This on is SOLVED!
 
  It was due to SuSE's CKRM_CPU_SCHEDULE scheduler.
 
  Back to Linux's 'normal' one solve it.
 
  quake3-smp
  ~198 fps 2. high
  ~193 fps HIGH
 
  640x480 window on 1280x1024x24/32.
 
  1024x768 window give ~100 fps, again.

 This is interesting, though. The use of a different scheduler should
 probably not have such a huge impact on performance (if no other cpu or
 io-heavy processes are running).
 Are you using pageflip?

All time long.

 If no the r200CopyBuffer calls sched_yield() 
 which potentially could cause such a difference. But if you're using
 pageflip I'm not sure why there would be such a drastic difference.

What next? ;-)

What about AGP 1x, 2x, 4x, etc.?

I have auto in my BIOS settings.

Section Device
  BoardNameRadeon 8500 QL
  BusID1:5:0
  Driver   radeon
  Identifier   Device[0]
  Option   EnablePageflip
  Option   DPMS
  OptionAGPFastWrite 1
  OptionAGPMode 4
  Screen   0
  Option   Rotate on
  VendorName   ATI
EndSection

dmesg show this:
agpgart: Found an AGP 2.0 compliant device at :00:00.0.
agpgart: Putting AGP V2 device at :00:00.0 into 2x mode
agpgart: Putting AGP V2 device at :01:05.0 into 2x mode

glxinfo
OpenGL vendor string: Tungsten Graphics, Inc.
OpenGL renderer string: Mesa DRI R200 20041207 AGP 4x x86/MMX+/3DNow!+/SSE TCL
OpenGL version string: 1.3 Mesa 6.3

So only AGPGART output is wrong?

How have you tested local (texdown)?

Best here is:
64 x 256 Border 0 (1 give sig fault, but was OK several months ago)
Format: GL_RGB
Type: GL_UNSIGNED_SHORT_5_6_6
IntFormat: GL_RGB
Bias: No
TexSubImage: Yes (!)

= 373.289 MB/second

Border _doubled_ it in the past.

-Dieter


---
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: [r200] Mesa CVS text and texture bug

[Dieter Nützel]

Am Montag, 14. Februar 2005 20:06 schrieb Dieter Ntzel:
 Am Montag, 14. Februar 2005 19:40 schrieb Roland Scheidegger:
  Dieter Ntzel wrote:
   This on is SOLVED!
  
   It was due to SuSE's CKRM_CPU_SCHEDULE scheduler.
  
   Back to Linux's 'normal' one solve it.
  
   quake3-smp
   ~198 fps 2. high
   ~193 fps HIGH
  
   640x480 window on 1280x1024x24/32.
  
   1024x768 window give ~100 fps, again.
 
  This is interesting, though. The use of a different scheduler should
  probably not have such a huge impact on performance (if no other cpu or
  io-heavy processes are running).
  Are you using pageflip?

 All time long.

  If no the r200CopyBuffer calls sched_yield()
  which potentially could cause such a difference. But if you're using
  pageflip I'm not sure why there would be such a drastic difference.

 What next? ;-)

 What about AGP 1x, 2x, 4x, etc.?

 I have auto in my BIOS settings.

 Section Device
   BoardNameRadeon 8500 QL
   BusID1:5:0
   Driver   radeon
   Identifier   Device[0]
   Option   EnablePageflip
   Option   DPMS
   OptionAGPFastWrite 1
   OptionAGPMode 4
   Screen   0
   Option   Rotate on
   VendorName   ATI
 EndSection

 dmesg show this:
 agpgart: Found an AGP 2.0 compliant device at :00:00.0.
 agpgart: Putting AGP V2 device at :00:00.0 into 2x mode
 agpgart: Putting AGP V2 device at :01:05.0 into 2x mode

 glxinfo
 OpenGL vendor string: Tungsten Graphics, Inc.
 OpenGL renderer string: Mesa DRI R200 20041207 AGP 4x x86/MMX+/3DNow!+/SSE
 TCL OpenGL version string: 1.3 Mesa 6.3

 So only AGPGART output is wrong?

 How have you tested local (texdown)?

 Best here is:
 64 x 256 Border 0 (1 give sig fault, but was OK several months ago)
 Format: GL_RGB
 Type: GL_UNSIGNED_SHORT_5_6_6
 IntFormat: GL_RGB
 Bias: No
 TexSubImage: Yes (!)

 = 373.289 MB/second

 Border _doubled_ it in the past.

Reading symbols from /usr/X11R6/lib/modules/dri/r200_dri.so...done.
Loaded symbols for /usr/X11R6/lib/modules/dri/r200_dri.so
Reading symbols from /usr/X11R6/lib/libexpat.so.0...done.
Loaded symbols for /usr/X11R6/lib/libexpat.so.0
Reading symbols from /usr/lib/libtxc_dxtn.so...done.
Loaded symbols for /usr/lib/libtxc_dxtn.so
Reading symbols from /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2...done.
Loaded symbols for /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2
#0  0x405e9dc5 in _tnl_build_vertices ()
   from /usr/X11R6/lib/modules/dri/r200_dri.so
(gdb) bt
#0  0x405e9dc5 in _tnl_build_vertices ()
   from /usr/X11R6/lib/modules/dri/r200_dri.so
#1  0x405e3513 in run_render () from /usr/X11R6/lib/modules/dri/r200_dri.so
#2  0x405d36f2 in _tnl_run_pipeline ()
   from /usr/X11R6/lib/modules/dri/r200_dri.so
#3  0x40550b0f in r200WrapRunPipeline ()
   from /usr/X11R6/lib/modules/dri/r200_dri.so
#4  0x405f25cb in _tnl_flush_vtx () 
from /usr/X11R6/lib/modules/dri/r200_dri.so
#5  0x405ed7e5 in _tnl_FlushVertices ()
   from /usr/X11R6/lib/modules/dri/r200_dri.so
#6  0x40563b73 in r200FlushVertices ()
   from /usr/X11R6/lib/modules/dri/r200_dri.so
#7  0x405b960f in _mesa_TexSubImage2D ()
   from /usr/X11R6/lib/modules/dri/r200_dri.so
#8  0x0804932c in MeasureDownloadRate () at texdown.c:158
#9  0x08049675 in Display () at texdown.c:256
#10 0x40045f8e in processWindowWorkList () from /usr/lib/libglut.so.3
#11 0x4004601a in __glutProcessWindowWorkLists () from /usr/lib/libglut.so.3
#12 0x4004608b in glutMainLoop () from /usr/lib/libglut.so.3
#13 0x08049b21 in main (argc=1, argv=0xbfffee44) at texdown.c:384

-Dieter


---
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: [r200] Mesa CVS text and texture bug

[Dieter Nützel]

Am Montag, 14. Februar 2005 19:40 schrieb Roland Scheidegger:
 Dieter Ntzel wrote:
  This on is SOLVED!
 
  It was due to SuSE's CKRM_CPU_SCHEDULE scheduler.
 
  Back to Linux's 'normal' one solve it.
 
  quake3-smp
  ~198 fps 2. high
  ~193 fps HIGH
 
  640x480 window on 1280x1024x24/32.
 
  1024x768 window give ~100 fps, again.

 This is interesting, though. The use of a different scheduler should
 probably not have such a huge impact on performance (if no other cpu or
 io-heavy processes are running).
 Are you using pageflip? If no the r200CopyBuffer calls sched_yield()
 which potentially could cause such a difference. But if you're using
 pageflip I'm not sure why there would be such a drastic difference.

Try latencytest0.42-png.

Especially have a look at top scheduler numbers.

-Dieter


---
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: [r200] Mesa CVS text and texture bug

[Dieter Nützel]

Am Freitag, 11. Februar 2005 22:55 schrieb Dieter Ntzel:
 I get this even with X.org CVS.
 The texture problem is not persistent but the text 'of by oen or two'.

 http://www.nuetzel-hh.de/public/Celestia-Mesa-CSV-r200.png

Texture bug is due to texture units.
It arise with texture_units  4.
= to few texture memory?

Text corruption still there.

-Dieter


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

[r2xx|r1xx] readpixels-3 and pntparam_1 - Progress?

[Dieter Nützel]

r100-readpixels-3.patch (Stephane)
r200_pntparam_1.diff (Roland)

I'm ran with both.
Should they merged?

BTW readpix sigfault is still there. (with and without both patches)

X.org CVS do NOT show this bug.

SunWave1 progs/demos# ./readpix
GL_VERSION = 1.3 Mesa 6.3
GL_RENDERER = Mesa DRI R200 20041207 AGP 4x x86/MMX+/3DNow!+/SSE TCL
GL_OES_read_format supported.  Using type / format = 0x1401 / 0x1908
Loaded 194 by 188 image
Speicherschutzverletzung (core dumped)

Reading symbols from /usr/X11R6/lib/modules/dri/r200_dri.so...done.
Loaded symbols for /usr/X11R6/lib/modules/dri/r200_dri.so
Reading symbols from /usr/X11R6/lib/libexpat.so.0...done.
Loaded symbols for /usr/X11R6/lib/libexpat.so.0
Reading symbols from /usr/lib/libtxc_dxtn.so...done.
Loaded symbols for /usr/lib/libtxc_dxtn.so
Reading symbols from /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2...done.
Loaded symbols for /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2
#0  0x406a911d in _generic_read_RGBA_span_BGRA_REV_SSE ()
   from /usr/X11R6/lib/modules/dri/r200_dri.so
(gdb) bt
#0  0x406a911d in _generic_read_RGBA_span_BGRA_REV_SSE ()
   from /usr/X11R6/lib/modules/dri/r200_dri.so
#1  0xff131f11 in ?? ()
(gdb) list
262
263TempImage = (GLubyte *) malloc(ImgWidth * ImgHeight * 4 * 
sizeof(GLubyte));
264assert(TempImage);
265 }
266
267
268 int
269 main( int argc, char *argv[] )
270 {
271GLboolean ciMode = GL_FALSE;

-Dieter


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

[Dieter Nützel]

Am Dienstag, 18. Januar 2005 11:33 schrieb Keith Whitwell:
 Jacek Rosik wrote:
  Hi,
 
  In radeonUpdateWindow and radeonUpdateViewportOffset functions in
  radeon_state.c `tx' and `ty' values are calculated differently. In
  UpdateWindow SUBPIXEL_X|Y values are added and in UpdateViewportOffset
  it's not and compared to values which might have been calculated in
  former function. The same goes for r200 driver.
 
  BTW: What is SUBPIXEL_X|Y exactly used for?

 Adjusting pixel centers to match the GL spec.  They should be added in
 both places.

Will someone check this in, then:

--- src/mesa/drivers/dri/r200/r200_state.c  2005-02-08 20:51:47.615514221 
+0100
+++ src/mesa/drivers/dri/r200/r200_state.c.Dieter   2005-02-08 
18:39:58.0 +0100
@@ -1656,8 +1656,8 @@
GLfloat yoffset = (GLfloat)dPriv-y + dPriv-h;
const GLfloat *v = ctx-Viewport._WindowMap.m;

-   GLfloat tx = v[MAT_TX] + xoffset;
-   GLfloat ty = (- v[MAT_TY]) + yoffset;
+   GLfloat tx = v[MAT_TX] + xoffset + SUBPIXEL_X;
+   GLfloat ty = (- v[MAT_TY]) + yoffset + SUBPIXEL_Y;

if ( rmesa-hw.vpt.cmd[VPT_SE_VPORT_XOFFSET] != *(GLuint *)tx ||
rmesa-hw.vpt.cmd[VPT_SE_VPORT_YOFFSET] != *(GLuint *)ty )


--- src/mesa/drivers/dri/radeon/radeon_state.c  2005-02-08 21:43:59.808223366 
+0100
+++ src/mesa/drivers/dri/radeon/radeon_state.c.Dieter   2005-01-28 
19:24:00.0 +0100
@@ -1522,8 +1522,8 @@
GLfloat yoffset = (GLfloat)dPriv-y + dPriv-h;
const GLfloat *v = ctx-Viewport._WindowMap.m;

-   GLfloat tx = v[MAT_TX] + xoffset;
-   GLfloat ty = (- v[MAT_TY]) + yoffset;
+   GLfloat tx = v[MAT_TX] + xoffset + SUBPIXEL_X;
+   GLfloat ty = (- v[MAT_TY]) + yoffset + SUBPIXEL_Y;

if ( rmesa-hw.vpt.cmd[VPT_SE_VPORT_XOFFSET] != *(GLuint *)tx ||
rmesa-hw.vpt.cmd[VPT_SE_VPORT_YOFFSET] != *(GLuint *)ty )


Thanks,
Dieter


---
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: Texture heap preference in driAllocateTexture

[Dieter Nützel]

Am Montag, 24. Januar 2005 02:34 schrieb Felix Kühling:
 Hi,

 After converting the Savage driver to use Ian's common texmem code I
 noticed a performance regression in Torcs. It's trashing textures a lot
 where it was running very smoothly before. I believe this is due to a
 different texture heap preference. If I reverse the preference I get
 back to the performance I had with my own texture memory management.

Do you have a hint to reverse it for radeon/r200?

I'll gave it a try then.

Thanks,
Dieter


---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag--drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: radeon tiling again...

[Dieter Nützel]

Am Freitag, 21. Januar 2005 21:03 schrieb Roland Scheidegger:
 Ok, new version is up here:
 http://homepage.hispeed.ch/rscheidegger/dri_experimental/radeon_tiling_drm9
.diff
 http://homepage.hispeed.ch/rscheidegger/dri_experimental/radeon_tiling_ddx9
.diff
 http://homepage.hispeed.ch/rscheidegger/dri_experimental/radeon_tiling_dri9
.diff

 This one now uses the new surface ioctl from Stephane (included in the
 tiling drm patch for both core and old drm). Other than that, not much
 has changed. I hope this is the final version now...
 Mergedfb + pageflip fix is now separate (attached), you need to apply
 this before the tiling ddx patch. It is untested however.

Hello Roland,

do I need libGL.so.x.x from Mesa CVS, too?

I get sigfault in swrast with version 9 (linux-dri-x86, r200_dri.so) and some 
VTK apps. After I'm finally up and running X.org CVS ontop of SuSE 9.0 my 
viewport problems with VTK (window resize) are solved.

GREAT work!

quake3-smp ~190 fps (640x480 window on 1280x1024x24/32)

Reading symbols from /usr/X11R6/lib/modules/dri/r200_dri.so...done.
Loaded symbols for /usr/X11R6/lib/modules/dri/r200_dri.so
#0  0x40b7b484 in _swrast_use_read_buffer (ctx=0x80ae9b0) at s_buffers.c:274
274swrast-CurrentBufferBit = ctx-Pixel._ReadSrcMask;
(gdb) list
269 _swrast_use_read_buffer( GLcontext *ctx )
270 {
271SWcontext *swrast = SWRAST_CONTEXT(ctx);
272
273/* Do this so the software-emulated alpha plane span functions 
work!*/
274swrast-CurrentBufferBit = ctx-Pixel._ReadSrcMask;
275/* Tell the device driver where to read/write spans */
276swrast-Driver.SetBuffer(ctx, ctx-ReadBuffer, 
swrast-CurrentBufferBit);
277 }
278
(gdb) info registers
eax0x0  0
ecx0x0  0
edx0x80ae9b0134932912
ebx0x809cdc0134860224
esp0xbfffe2e0   0xbfffe2e0
ebp0xbfffe2f8   0xbfffe2f8
esi0x80ae9b0134932912
edi0x0  0
eip0x40b7b484   0x40b7b484
eflags 0x10282  66178
cs 0x73 115
ss 0x7b 123
ds 0x7b 123
es 0x7b 123
fs 0x0  0
gs 0x33 51
(gdb) bt
#0  0x40b7b484 in _swrast_use_read_buffer (ctx=0x80ae9b0) at s_buffers.c:274
#1  0x40b836ba in _swrast_CopyConvolutionFilter2D (ctx=0x80ae9b0,
target=34336, internalFormat=0, x=134932912, y=-1073748672,
width=134932912, height=-1073748744) at s_imaging.c:120
#2  0x40aefa68 in alloc_shared_state (ctx=0x80ae9b0) at context.c:853
#3  0x40af02f2 in _mesa_initialize_context (ctx=0x80ae9b0, visual=0x809b3b8,
share_list=0x0, driverFunctions=0xbfffe540, driverContext=0x80a92e8)
at context.c:1452
#4  0x40af0447 in _mesa_create_context (visual=0x809b3b8, share_list=0x0,
driverFunctions=0xbfffe540, driverContext=0x80a92e8) at context.c:1532
#5  0x41a50ae1 in r200CreateContext (glVisual=0x809b3b8,
driContextPriv=0x809cda0, sharedContextPrivate=0x0) at r200_context.c:291
#6  0x41a500ce in driCreateNewContext (dpy=0x808cbb8, modes=0x809b3b8,
render_type=0, sharedPrivate=0x0, pctx=0x809e3a4)
at ../common/dri_util.c:1061
#7  0x40a6ec6d in DriverCreateContextWrapper (psc=0x809afb8, dpy=0x808cbb8,
vis=0x809dc90, shared=0x0, ctx=0x809e3a4, modes=0x809b3b8, render_type=0)
at glxcmds.c:137
#8  0x40a6f15f in CreateContext (dpy=0x808cbb8, vis=0x809dc90, fbconfig=0x0,
shareList=0x0, allowDirect=1, contextID=0, use_glx_1_3=0, renderType=0)
at glxcmds.c:463
#9  0x40a6f3b9 in glXCreateContext (dpy=0x808cbb8, vis=0x809dc90,
shareList=0x0, allowDirect=1) at glxcmds.c:541
#10 0x4027f723 in vtkXOpenGLRenderWindow::WindowInitialize() ()
   from ./libvtkRendering.so
#11 0x4027fb89 in vtkXOpenGLRenderWindow::Initialize() ()
   from ./libvtkRendering.so
#12 0x40280180 in vtkXOpenGLRenderWindow::Start() () from ./libvtkRendering.so
#13 0x40263960 in vtkXRenderWindowInteractor::Initialize() ()
   from ./libvtkRendering.so
#14 0x40088b33 in vtkParallelRenderManager::StartInteractor() ()
   from ./libvtkParallel.so
#15 0x08049aac in process(vtkMultiProcessController*, void*) ()
#16 0x400c32d3 in vtkThreadedController::Start(int) () 
from ./libvtkParallel.so
#17 0x400c310e in vtkThreadedController::vtkThreadedControllerStart(void*) ()
   from ./libvtkParallel.so
#18 0x412b8bd8 in vtkMultiThreader::SingleMethodExecute() ()
   from ./libvtkCommon.so
#19 0x400c34a1 in vtkThreadedController::SingleMethodExecute() ()
   from ./libvtkParallel.so
#20 0x08049b91 in main ()

-Dieter


---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag--drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
--
___
Dri-devel mailing list

Do xorg/xc CVS work for anyone?

[Dieter Nützel]

With Mesa CVS (6.3) or without (6.2.1 under xorg/xc/extras/Mesa/)
it didn't compile.

Mesa CVS hangs in shader (but I'm working on this; I used Mesa CVS all day 
long before) and pdx.freedesktop.org/cvs/xorg stops in bufferobj.c:

extras/Mesa/src/mesa -I../../../../lib/GL/dri   
-I/tmp/INSTALL/SOURCE/dri-trunk/xorg/xc/extras/Mesa/include 
-I../../../../lib/GL/include  -I../../../.. -I../../../../exports/include 
-I/usr/X11R6/include  -Dlinux -D__i386__ -D_POSIX_C_SOURCE=199309L  
  
-D_POSIX_SOURCE -D_XOPEN_SOURCE
-D_BSD_SOURCE -D_SVID_SOURCE
 -D_GNU_SOURCE-DFUNCPROTO=15 -DNARROWPROTO 
-DXTHREADS  -D_REENTRANT -DXUSE_MTSAFE_API-DMALLOC_0_RETURNS_NULL 
-DGLXEXT -DXF86DRI -DGLX_DIRECT_RENDERING -DGLX_USE_DLOPEN -DGLX_USE_MESA
bufferobj.c
bufferobj.c:397: error: conflicting types for `_mesa_validate_pbo_access'
bufferobj.h:84: error: previous declaration of `_mesa_validate_pbo_access'
bufferobj.c: In function `_mesa_validate_pbo_access':
bufferobj.c:408: Warnung: passing arg 1 of `_mesa_image_address' makes integer 
from pointer without a cast
bufferobj.c:408: Warnung: passing arg 3 of `_mesa_image_address' makes pointer 
from integer without a cast
bufferobj.c:408: error: too few arguments to function `_mesa_image_address'
bufferobj.c:412: Warnung: passing arg 1 of `_mesa_image_address' makes integer 
from pointer without a cast
bufferobj.c:412: Warnung: passing arg 3 of `_mesa_image_address' makes pointer 
from integer without a cast
bufferobj.c:412: error: too few arguments to function `_mesa_image_address'
bufferobj.c: In function `_mesa_DeleteBuffersARB':
bufferobj.c:602: error: structure has no member named `DeletePending'
bufferobj.c:603: error: structure has no member named `DeletePending'
bufferobj.c: In function `_mesa_IsBufferARB':
bufferobj.c:693: error: structure has no member named `DeletePending'
make[6]: *** [bufferobj.o] Fehler 1

Thanks,
Dieter


---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag--drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: Do xorg/xc CVS work for anyone?

[Dieter Nützel]

Am Freitag, 21. Januar 2005 19:43 schrieb Adam Jackson:
 On Friday 21 January 2005 13:11, Dieter Nützel wrote:
  With Mesa CVS (6.3) or without (6.2.1 under xorg/xc/extras/Mesa/)
  it didn't compile.
 
  Mesa CVS hangs in shader (but I'm working on this; I used Mesa CVS all
  day long before) and pdx.freedesktop.org/cvs/xorg stops in bufferobj.c:

Compilation problems were due some old mixed Makefiles from Mesa CVS.

  extras/Mesa/src/mesa -I../../../../lib/GL/dri
  -I/tmp/INSTALL/SOURCE/dri-trunk/xorg/xc/extras/Mesa/include

   ^^^

 This looks extremely suspicious.  Imake paths are normally relative to the
 project root.

I set it in host.cf but commenting was better...;-)

 http://freedesktop.org/cgi-bin/viewcvs.cgi/xorg/xc/extras/Mesa/src/mesa/mai
n/bufferobj.h?annotate=1.1.1.1
 http://freedesktop.org/cgi-bin/viewcvs.cgi/mesa/Mesa/src/mesa/main/bufferob
j.h?annotate=1.11

 So, I don't know what you're doing, but it's wrong.

See above.

 http://dri.freedesktop.org/wiki/Building

pdx.freedesktop.org/cvs/xorg ? ;-)

But all radeon/r200 stuff is oudated.

No Hyper-Z, S3TC (force),...

Next step is Mesa CVS integration.

Thanks,
Dieter


---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag--drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: IGP320M HyperZ Texture bugs

[Dieter Nützel]

Am Mittwoch, 1. Dezember 2004 02:48 schrieb [EMAIL PROTECTED]:
 Hi Roland,

 If you move glxgears down below about half of the screen you won't see
 anything anymore. Within the top half it looks about the same, although
 moving it from left to right can cause parts to appear or disappear.
 I'll check the offsets tonight.

Soo, you are at 'my' r200 observation;-)
But at the bottom there are some pixels not all vanished.
Moving left to right or the like show sometimes some parts.

Disabling RADEON_Z_HIERARCHY_ENABLE bring all lines to life.

/*  if (rmesa-r200Screen-chipset  R200_CHIPSET_REAL_R200)
 rmesa-hw.ctx.cmd[CTX_RB3D_ZSTENCILCNTL] |= 
RADEON_Z_HIERARCHY_ENABLE; */

I'm in preparation of a new Mesa/DRI CVS copy with 
hyperz-dri-7.patch
hyperz-drm-15.patch
r100-readpixels-3.patch
r200_pntparam_1.diff
because all went well (with the above change), but quake3 (quake3-smp) start 
with only black window. Maybe this is TLS related, which I have in for 
several months, now.

-Dieter

PS Roland, do you need current r200 'pictures'?


---
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://productguide.itmanagersjournal.com/
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: R100 readpixels acceleration

[Dieter Nützel]

Am Mittwoch, 1. Dezember 2004 16:55 schrieb Brian Paul:
 Stephane Marchesin wrote:
  Ok, here is a new patch.

 Looks OK.  Someone with a Radeon card should test this with the
 Mesa/progs/demos/readpix.c demo.  Drag the readpix window off the
 left/right/bottom/top edges of the screen and make sure things look
 OK.  Be sure to test both the front and back color buffers ('f' key).

r200 (but with HyperZ):

Move it to the left...
progs/demos ./readpix

GL_VERSION = 1.3 Mesa 6.3
GL_RENDERER = Mesa DRI R200 20041007 AGP 4x x86/MMX+/3DNow!+/SSE TCL
GL_OES_read_format supported.  Using type / format = 0x1401 / 0x1908
Loaded 194 by 188 image
Speicherschutzverletzung
progs/demos
progs/demos ./readpix
GL_VERSION = 1.3 Mesa 6.3
GL_RENDERER = Mesa DRI R200 20041007 AGP 4x x86/MMX+/3DNow!+/SSE TCL
GL_OES_read_format supported.  Using type / format = 0x1401 / 0x1908
Loaded 194 by 188 image
Speicherschutzverletzung

And redraw is sometimes broken or missing.

I've tried with r100-readpixels-2.patch and r100-readpixels-3.patch, now.

'gloss' is fine even if it was NOT related ;-)

But quake3 (quake3-smp) start with only black window.

-Dieter


---
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://productguide.itmanagersjournal.com/
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: IGP320M HyperZ Texture bugs

[Dieter Nützel]

Am Mittwoch, 1. Dezember 2004 17:13 schrieb Rogier Stam:
 Dieter Nützel wrote:
 Am Mittwoch, 1. Dezember 2004 02:48 schrieb 
[EMAIL PROTECTED]:
 Hi Roland,
 
 If you move glxgears down below about half of the screen you won't see
 anything anymore. Within the top half it looks about the same, although
 moving it from left to right can cause parts to appear or disappear.
 I'll check the offsets tonight.
 
 Soo, you are at 'my' r200 observation;-)
 But at the bottom there are some pixels not all vanished.
 Moving left to right or the like show sometimes some parts.
 
 Disabling RADEON_Z_HIERARCHY_ENABLE bring all lines to life.
 
 /*  if (rmesa-r200Screen-chipset  R200_CHIPSET_REAL_R200)
  rmesa-hw.ctx.cmd[CTX_RB3D_ZSTENCILCNTL] |=
 RADEON_Z_HIERARCHY_ENABLE; */
 
 I'm in preparation of a new Mesa/DRI CVS copy with
 hyperz-dri-7.patch
 hyperz-drm-15.patch
 r100-readpixels-3.patch
 r200_pntparam_1.diff
 because all went well (with the above change), but quake3 (quake3-smp)
  start with only black window. Maybe this is TLS related, which I have in
  for several months, now.
 
 -Dieter
 
 PS Roland, do you need current r200 'pictures'?

 Actually, Roland had a suggestion regarding seting the tileoffset from
 *16 to *32. This helps a bit in my case. I suggest you also try this
 one. Maybe it will help for you too. It doesn't fix the entire problem,
 but it does make it better. Note that I also tried *24, *40, *48, *64
 and *128. *32 gives the most stable and also in picture the best result.
 The others definetly don't improve things...

I'm playing with it, but all other then 16 (as far as i am ;-) give your 
described results.

Could you try this (from Roland, too) in the meantime.
I running my r200 with it since drm-15 came out.

--- radeon_state.c.orig 2004-11-11 22:08:37.0 +0100
+++ radeon_state.c.aktuell  2004-11-13 14:08:32.0 +0100
@@ -894,7 +894,8 @@
}
else {
/* FIXME : reverse engineer that for Rx00 cards */
-   clearmask = (0xff22)|(0xff6)| 0x003f003f;
+   /* clearmask = (0xff22)|(0xff6)| 0x003f003f; */
+   clearmask = 0x0;

-Dieter


---
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://productguide.itmanagersjournal.com/
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: IGP320M HyperZ Texture bugs

[Dieter Nützel]

Am Mittwoch, 1. Dezember 2004 19:09 schrieb Dieter Nützel:
 Am Mittwoch, 1. Dezember 2004 17:13 schrieb Rogier Stam:
  Dieter Nützel wrote:
  Am Mittwoch, 1. Dezember 2004 02:48 schrieb

 [EMAIL PROTECTED]:
  Hi Roland,
  
  If you move glxgears down below about half of the screen you won't see
  anything anymore. Within the top half it looks about the same, although
  moving it from left to right can cause parts to appear or disappear.
  I'll check the offsets tonight.
  
  Soo, you are at 'my' r200 observation;-)
  But at the bottom there are some pixels not all vanished.
  Moving left to right or the like show sometimes some parts.
  
  Disabling RADEON_Z_HIERARCHY_ENABLE bring all lines to life.
  
  /*  if (rmesa-r200Screen-chipset  R200_CHIPSET_REAL_R200)
   rmesa-hw.ctx.cmd[CTX_RB3D_ZSTENCILCNTL] |=
  RADEON_Z_HIERARCHY_ENABLE; */
  
  I'm in preparation of a new Mesa/DRI CVS copy with
  hyperz-dri-7.patch
  hyperz-drm-15.patch
  r100-readpixels-3.patch
  r200_pntparam_1.diff
  because all went well (with the above change), but quake3 (quake3-smp)
   start with only black window. Maybe this is TLS related, which I have
   in for several months, now.
  
  -Dieter
  
  PS Roland, do you need current r200 'pictures'?
 
  Actually, Roland had a suggestion regarding seting the tileoffset from
  *16 to *32. This helps a bit in my case. I suggest you also try this
  one. Maybe it will help for you too. It doesn't fix the entire problem,
  but it does make it better. Note that I also tried *24, *40, *48, *64
  and *128. *32 gives the most stable and also in picture the best result.
  The others definetly don't improve things...

 I'm playing with it, but all other then 16 (as far as i am ;-) give your
 described results.

 Could you try this (from Roland, too) in the meantime.
 I running my r200 with it since drm-15 came out.

 --- radeon_state.c.orig 2004-11-11 22:08:37.0 +0100
 +++ radeon_state.c.aktuell  2004-11-13 14:08:32.0 +0100
 @@ -894,7 +894,8 @@
 }
 else {
 /* FIXME : reverse engineer that for Rx00 cards */
 -   clearmask = (0xff22)|(0xff6)| 0x003f003f;
 +   /* clearmask = (0xff22)|(0xff6)| 0x003f003f; */
 +   clearmask = 0x0;

Now,

I've tested with the above and

   OUT_RING( tileoffset * 16 );

8-17 (all steps), even 32 do NOT work.

ONLY 16 works.

-Dieter


---
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://productguide.itmanagersjournal.com/
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Mesa3d-dev] Mesa CVS is back

[Dieter Nützel]

Am Montag, 22. November 2004 17:44 schrieb Brian Paul:
 Eric Anholt wrote:
  Mesa CVS is back in place thanks to Keith.  Now someone needs to review
  dri/drm for changes.
 
  /me returns to homework

 Is anyone having luck accessing the repository?  I can't.

Me.

I could do a clean Mesa and DRI 'cvs update' and compilation finished.

Works as before.

-Dieter



---
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://productguide.itmanagersjournal.com/
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: new hyperz patch

[Dieter Nützel]

 Am Freitag, 12. November 2004 00:06 schrieb Dieter Nützel:
  Am Donnerstag, 11. November 2004 22:30 schrieb Roland Scheidegger:
   Dieter Nützel wrote:
Let me try on r200 ;-)
   
Some feedback for Roland's hyperz-dri-7.patch and
hyperz-drm-14.patch. = rv path on my r200.
 
  Now with hyperz-drm-15.patch.
 
First I've change only drm. -0x1002 0x514C CHIP_R200 ATI Radeon QL
R200 8500 LE +0x1002 0x514C CHIP_R200|CHIP_IS_RV ATI Radeon QL R200
8500 LE
 
 Now, even AS R200 ;-)
 (Backed this out, too.)
 
   You shouldn't need this change in theory, as it should have no effect if
   hierarchical-z isn't used. You probably can't change only the CHIP_IS_RV
   bit, you need to change dri to not use hierarchical-z at the same time.
 
  Backed it out.
 
+/*  if (rmesa-r200Screen-chipset 
R200_CHIPSET_REAL_R200) +
rmesa-hw.ctx.cmd[CTX_RB3D_ZSTENCILCNTL] |=
RADEON_Z_HIERARCHY_ENABLE;*/ }
 
 Let this in.
 
   ok. That really shows that non-rv cards can be treated the same as rv
   cards, if hierarchical-z is just disabled. If we can't figure out how to
   get hierarchical-z working, this might be an option (it should also
   simplify things quite a bit, since hierarchical-z can have issues with
   some apps if they change z-test or something like that).
 
  Nothing changed, here.
 
= * NO 'black horizontal lines' anylonger. - GREAT * but some speed
regression, of course
  
   but it's still faster than without hyperz, yes?
 
  Sure;-)
 
   It's of course expected
   that it is slower than when you got black stripes (since that's because
   the depth buffer wasn't cleared, so lots of incoming fragments are just
   discarded even though they shouldn't be discarded).
 
  black, is black,... ;-)
 
   What did you get when using the normal path for your card? No pattern?
 
  I have to try, again, when I've time, again.
 
 r200
 RV path and R200 (?)
 
 Plus
 
 --- radeon_state.c.orig 2004-11-11 22:08:37.0 +0100
 +++ radeon_state.c  2004-11-13 14:08:32.245758629 +0100
 @@ -894,7 +894,8 @@
 }
 else {
 /* FIXME : reverse engineer that for Rx00 cards */
 -   clearmask = (0xff22)|(0xff6)| 0x003f003f;
 +   /* clearmask = (0xff22)|(0xff6)| 0x003f003f; */
 +   clearmask = 0x0;
 }
 
 BEGIN_RING( 8 );
 
 All fine (with both paths), except of your stencil NWN pattern with 
 doom3-demo, here.
 
 But if I enable RADEON_Z_HIERARCHY_ENABLE in 
 src/mesa/drivers/dri/r200/r200_state_init.c, again I get the black lines 
 _and_ more corruptions if I move the 3D window to the bottom (or I have a 
 vertical big window).

Ups, ipers-bottom.png shouldn't go to dri-devel. --- Sorry!
And I've forgotten 'gears-bottom'.

-Dieter
attachment: gears-bottom.png

Re: new hyperz patch

[Dieter Nützel]

Am Donnerstag, 11. November 2004 21:39 schrieb Stephane Marchesin:
 Roland Scheidegger wrote:
  Roland Scheidegger wrote:
  In fact, that was already discussed briefly at irc. For now it just
  seemed more important to get it working on more cards and fix the
  rendering problems than to worry about minor issues like multiple
  rendering apps :). I did get clearing only the needed tiles working
  (minus some off-by-one issues currently) though at least on my rv250
  (with a 32x8 z pixel granularity however - for clearing the hardware
  seems to work on 8x2 4x4 macro tiles, it looks like it might be
  even possible to get granularity down to 4x4 for clearing, at least
  on my card).
 
  Ok, here's the version which clears only the required tiles (with a
  32x8 z-pixel granularity).
  Works on rv250. It is almost certain to not work on non-rv cards (see
  code comments). I don't know if it works on rv100 cards, while the
  macro-tile size should be identical, the macro-tile shape may be not.
  Feedback might be helpful, especially if a pattern is visible which
  tiles are cleared and which not.
  No new dri patch, use the old one.
  Problems when only z or stencil buffer is cleared are unchanged (will
  probably look at it next),

 You need to call the standard clear routine when bpp is 32 and the
 visual has a stencil and only one of the stencil or depth is cleared.
 All the other cases can be handled without a fallback.

  as is the problem with stencil/z readback (probably won't look at it
  soon...).

 I'm working on a patch that will merge hyperz and tiling and
 incidentally fix this.
 It'll also take care of disabling hyperz when there are multiple windows.

Let me try on r200 ;-)

Some feedback for Roland's hyperz-dri-7.patch and hyperz-drm-14.patch.
= rv path on my r200.

First I've change only drm.

--- drm_pciids.txt.r200 2004-11-11 13:10:28.0 +0100
+++ drm_pciids.txt  2004-11-11 19:16:58.0 +0100
@@ -38,7 +38,7 @@
 0x1002 0x5149 CHIP_R200 ATI Radeon QI R200
 0x1002 0x514A CHIP_R200 ATI Radeon QJ R200
 0x1002 0x514B CHIP_R200 ATI Radeon QK R200
-0x1002 0x514C CHIP_R200 ATI Radeon QL R200 8500 LE
+0x1002 0x514C CHIP_R200|CHIP_IS_RV ATI Radeon QL R200 8500 LE
 0x1002 0x514D CHIP_R200 ATI Radeon QM R200 9100
 0x1002 0x514E CHIP_R200 ATI Radeon QN R200 8500 LE
 0x1002 0x514F CHIP_R200 ATI Radeon QO R200 8500 LE

--- radeon_state.c.r200 2004-11-11 13:10:28.0 +0100
+++ radeon_state.c  2004-11-11 19:22:06.0 +0100
@@ -916,7 +916,7 @@

ADVANCE_RING();

-   if ((!
(dev_priv-flagsCHIP_IS_RV))(dev_priv-microcode_version==UCODE_R200))
+   if 
((dev_priv-flagsCHIP_IS_RV)(dev_priv-microcode_version==UCODE_R200))
/* r100 and cards without hierarchical z-buffer have no 
high-level z-buffer */
{
BEGIN_RING( 4 );

Full speed and mostly all corruptions fixed, except of the 'black horizontal 
lines'.


Then I've changed

--- src/mesa/drivers/dri/r200/r200_state_init.c.r2002004-11-10 
14:53:54.0 +0100
+++ src/mesa/drivers/dri/r200/r200_state_init.c 2004-11-11 19:08:06.621588463 
+0100
@@ -466,8 +466,8 @@
if (rmesa-using_hyperz) {
   rmesa-hw.ctx.cmd[CTX_RB3D_ZSTENCILCNTL] |= RADEON_Z_COMPRESSION_ENABLE 
|
  RADEON_Z_DECOMPRESSION_ENABLE;
-  if (rmesa-r200Screen-chipset  R200_CHIPSET_REAL_R200)
-rmesa-hw.ctx.cmd[CTX_RB3D_ZSTENCILCNTL] |= 
RADEON_Z_HIERARCHY_ENABLE;
+/*  if (rmesa-r200Screen-chipset  R200_CHIPSET_REAL_R200)
+rmesa-hw.ctx.cmd[CTX_RB3D_ZSTENCILCNTL] |= 
RADEON_Z_HIERARCHY_ENABLE;*/
}

rmesa-hw.ctx.cmd[CTX_PP_CNTL] = (R200_ANTI_ALIAS_NONE

=
* NO 'black horizontal lines' anylonger. - GREAT
* but some speed regression, of course
* Roland's depth/stencil problem with doom3-demo (_same_ pattern) 

  Here is a picture of depth/stencil problems in nwn:
  http://homepage.hispeed.ch/rscheidegger/dri_experimental/nwn_hyperz.png
  - I do not really know if this is caused by this clearing problem
  (warning, 1MB picture), but it definitely looks like a z-buffer problem.
  Stencil/Depth readback still don't work.

* quake3-smp at ~170 fps (down from ~206 with r2xx bugs)

-Dieter


---
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588alloc_id=12065op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: new hyperz patch

[Dieter Nützel]

Am Donnerstag, 11. November 2004 22:30 schrieb Roland Scheidegger:
 Dieter Nützel wrote:
  Let me try on r200 ;-)
 
  Some feedback for Roland's hyperz-dri-7.patch and
  hyperz-drm-14.patch. = rv path on my r200.

Now with hyperz-drm-15.patch.

  First I've change only drm. -0x1002 0x514C CHIP_R200 ATI Radeon QL
  R200 8500 LE +0x1002 0x514C CHIP_R200|CHIP_IS_RV ATI Radeon QL R200
  8500 LE


 You shouldn't need this change in theory, as it should have no effect if
 hierarchical-z isn't used. You probably can't change only the CHIP_IS_RV
 bit, you need to change dri to not use hierarchical-z at the same time.

Backed it out.

  +/*  if (rmesa-r200Screen-chipset 
  R200_CHIPSET_REAL_R200) +
  rmesa-hw.ctx.cmd[CTX_RB3D_ZSTENCILCNTL] |=
  RADEON_Z_HIERARCHY_ENABLE;*/ }

 ok. That really shows that non-rv cards can be treated the same as rv
 cards, if hierarchical-z is just disabled. If we can't figure out how to
 get hierarchical-z working, this might be an option (it should also
 simplify things quite a bit, since hierarchical-z can have issues with
 some apps if they change z-test or something like that).

Nothing changed, here.

  = * NO 'black horizontal lines' anylonger. - GREAT * but some speed
  regression, of course

 but it's still faster than without hyperz, yes?

Sure;-)

Now I get:

quake3-smp, 640x480 window on 1280x1024x24 (32) desktop

180 fps
182 fps
180 fps

progs/demos ./gears
16881 frames in  5.000 seconds = 3376.200 FPS
17437 frames in  5.000 seconds = 3487.400 FPS
17438 frames in  5.000 seconds = 3487.600 FPS
17357 frames in  5.000 seconds = 3471.400 FPS
17446 frames in  5.000 seconds = 3489.200 FPS
17455 frames in  5.000 seconds = 3491.000 FPS
17460 frames in  5.000 seconds = 3492.000 FPS
17458 frames in  5.000 seconds = 3491.600 FPS

Changed to fullscreen (window)

2122 frames in  5.000 seconds = 424.400 FPS
1821 frames in  5.000 seconds = 364.200 FPS
1822 frames in  5.002 seconds = 364.254 FPS
1822 frames in  5.001 seconds = 364.327 FPS
1822 frames in  5.002 seconds = 364.254 FPS


progs/demos ./gloss
2321 frames in 5.001 seconds = 464.107 FPS
2438 frames in 5.002 seconds = 487.405 FPS
2436 frames in 5 seconds = 487.2 FPS
2440 frames in 5 seconds = 488 FPS
2441 frames in 5.002 seconds = 488.005 FPS

Was ~400 without hyperz

 It's of course expected 
 that it is slower than when you got black stripes (since that's because
 the depth buffer wasn't cleared, so lots of incoming fragments are just
 discarded even though they shouldn't be discarded).

black, is black,... ;-)

 What did you get when using the normal path for your card? No pattern?

I have to try, again, when I've time, again.

-Dieter


---
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_idU88alloc_id065op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: hyperz for r200 class cards

[Dieter Nützel]

Am Samstag, 6. November 2004 01:39 schrieb Stephane Marchesin:
 Dieter Nützel wrote:
 Am Donnerstag, 4. November 2004 23:09 schrieb Roland Scheidegger:
 (sorry for sending this first to the wrong list. replies should be in
 dri-devel, not mesa3d-dev.)
 
 Here's an updated version of the patch, which should work on more cards.
 Specifically, it works on my rv250, rv280 and 9100igp should probably
 work too. Not so sure about r200, only if you're lucky...
 
 I had to revert this line, to see something (r200):
 
 --- radeon_state.c.orig 2004-11-05 23:29:41.0 +0100
 +++ radeon_state.c  2004-11-06 01:04:51.325423262 +0100
 @@ -981,7 +981,7 @@
  * rendering a quad into just those buffers.  Thus, we have to
  * make sure the 3D engine is configured correctly.
  */
 -   else if ((dev_priv-microcode_version == UCODE_R200) 
 +   if ( (dev_priv-microcode_version==UCODE_R200) 
 (flags  (RADEON_DEPTH | RADEON_STENCIL))) {
 
 int tempPP_CNTL;

 You shouldn't revert this line.
 Basically, this is is the test that chooses between doing a fast zclear
 and a standard zclear.
 But you don't want to do both.

 That was a mistake in my first patch. The second one has this change.

I see, even the speed! ;-)

 Now, I have 'only' the black lines (gears, gloss, etc.).
 But isosurf it mostly fine?! --- Depth???
 See isosurface1.
 
 But if the 3D window is vertically to high or if I move a small window to
  the bottom of the screen, then there is additional pixel (texture)
  corruption. See isosurface2

 Same problem as the last one, I think.

Could it be stencil (buffer) related in some way?

Have a look at ~/progs/tests/stencil_wrap.

/opt/Mesa progs/tests/stencil_wrap
GL_RENDERER = Mesa DRI R200 20041007 AGP 4x x86/MMX+/3DNow!+/SSE TCL
GL_VERSION = 1.3 Mesa 6.3

All 5 squares should be the same color.
Stencil bits = 8, maximum stencil value = 0x00ff

The _right_ two boxes are broken.

 Some things are still broken, notably apps which use stencil buffer
 (nwn, doomIII). I think there could be an issue when clearing stencil or
 z-buffer separately, or maybe something else (dinoshade at least seems
 to work).
 
 Here, too.
 
 But I saw something semilar (depth corruption?) with viewperf before
  HyperZ.

Have anyone looked into this?


 Also, if another window is moved on top of the glxgears window so it
 covers part of the glxgears window then rendering is very broken -
 mostly just black, that seriously seems to break z buffer clearing.
 
 Nothing, here. (With my change).

 That's because only the first box is cleared. This can be easily fixed.

Stephane, any screws where I could play as a start?

-Dieter


---
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_idU88alloc_id065op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: Two module_param problems with Linux 2.6.4

[Dieter Nützel]

Am Freitag, 29. Oktober 2004 16:38 schrieb Jon Smirl:
 On Fri, 29 Oct 2004 01:54:21 +0200, Dieter Nützel

 [EMAIL PROTECTED] wrote:
  Am Donnerstag, 28. Oktober 2004 12:42 schrieb Felix Kühling:
   Two small problems I had with Linux 2.6.4:
  
1. In order to make drm_stub.c compile without errors I had to
   #include linux/moduleparam explicitly.
 
  You mean:
 
  --- linux-core/drm_stub.c   2004-10-28 17:44:45.192753118 +0200
  +++ linux-core/drm_stub.c.new   2004-10-28 17:43:35.379578727 +0200
  @@ -35,6 +35,7 @@
 
   #include drmP.h
   #include drm_core.h
  +#include linux/moduleparam.h
 
   unsigned int cards_limit = 16; /* Enough for one machine */
   unsigned int drm_debug = 0;/* 1 to enable debug output */

 I just added the include.

Thanks!

And what about the spinlock/rwlock initialization?
Was '[PATCH 9/23] Lock initializer unifying Batch 2 (DRM)'.

I have it in (only the first part, drm_drv.h) and it works , of course.

-Dieter


---
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_idU88alloc_id065op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: Two module_param problems with Linux 2.6.4

[Dieter Nützel]

Am Donnerstag, 28. Oktober 2004 12:42 schrieb Felix Kühling:
 Two small problems I had with Linux 2.6.4:

  1. In order to make drm_stub.c compile without errors I had to
 #include linux/moduleparam explicitly.

You mean:

--- linux-core/drm_stub.c   2004-10-28 17:44:45.192753118 +0200
+++ linux-core/drm_stub.c.new   2004-10-28 17:43:35.379578727 +0200
@@ -35,6 +35,7 @@

 #include drmP.h
 #include drm_core.h
+#include linux/moduleparam.h

 unsigned int cards_limit = 16; /* Enough for one machine */
 unsigned int drm_debug = 0;/* 1 to enable debug output */

;-)

Works for me (r200, dual Athlon MP).
SuSE Kernel 2.6.5-7.108-smp (.111).


  2. drm_compat.h defines an empty module_param if it's undefined.
 It should do the same for module_param_named.

Cheers,
Dieter


---
This Newsletter Sponsored by: Macrovision
For reliable Linux application installations, use the industry's leading
setup authoring tool, InstallShield X. Learn more and evaluate
today. http://clk.atdmt.com/MSI/go/ins003001msi/direct/01/
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Mesa3d-dev] Doom3 works on R200!

[Dieter Nützel]

Am Sonntag, 24. Oktober 2004 19:38 schrieb Bernardo Innocenti:
 Dave Airlie wrote:
 r200 render path looks really A LOT better, unfortunately the open-source
 driver doesn't implement the required extensions (some bits of
  documentation are missing afaik, and even if not (I have no idea what's
  in the documentation or not) it would probably quite a bit of work as
  core mesa doesn't support them neither (mostly
  ATI_(text_)fragment_shader).
 
  Well I've started it, but it'll take me a while to finish off the
  software implementation, Eric thinks he can do the hardware side (I think
  I can probably do it as well.. but I'll try and get the software side
  working first hopefully...)

 Thank you for doing this work.  We really need to get the open-source
 ATI driver on par with the propretary driver (both feature-wise and
 performance-wise).

But sadly we will NEVER match it.

NO SmoothVision, HyperZ docu ever

 Even though I just have a Radeon 9200, I'm very excited about the
 ongoning R300 effort and with there was a similar project for NVidia
 cards too.

Above applies here, too. - Sorry.

The situation seems to be much worse in the future.
Bad IP (TRIPS, etc.) madness due to USA-law.

-Dieter


---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Mesa3d-dev] Doom3 works on R200!

[Dieter Nützel]

Am Sonntag, 24. Oktober 2004 20:20 schrieb Philipp Klaus Krause:
 Thank you for doing this work.  We really need to get the open-source
 ATI driver on par with the propretary driver (both feature-wise and
 performance-wise).
 
  But sadly we will NEVER match it.
 
  NO SmoothVision, HyperZ docu ever

 The nonfree xig driver has been developed without HyperZ docs and
 outperforms fglrx.

Are you sure.
I thought Xig had it all before.

Do you have actual numbers?
Haven't looked at them for very long time, but I bought the first version of 
there X server 1994 (?) for mga.

 Even though I just have a Radeon 9200, I'm very excited about the
 ongoning R300 effort and with there was a similar project for NVidia
 cards too.
 
  Above applies here, too. - Sorry.
 
  The situation seems to be much worse in the future.
  Bad IP (TRIPS, etc.) madness due to USA-law.

 True. ATI no longer releases docs. 3dlabs no longer does. Nvidia never
 did. Intel requires an NDA now.
 If there weren't all those patents out there we might just try to
 develop a free graphics chip.

;-)

Greetings,
Dieter


---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Mesa3d-dev] Doom3 works on R200!

[Dieter Nützel]

Am Sonntag, 24. Oktober 2004 20:10 schrieb Bernardo Innocenti:

CC trimmed.

 Dieter Nützel wrote:
 Thank you for doing this work.  We really need to get the open-source
 ATI driver on par with the propretary driver (both feature-wise and
 performance-wise).
 
  But sadly we will NEVER match it.
 
  NO SmoothVision, HyperZ docu ever

 Do you really need the datasheet to get these to work?  Some
 time ago I disassembled ATI's fglrx kernel module and their
 DRI module.

 The asm output looks quite readable: you can see symbol names
 and accesses to PCI registers (base ptr + offset).

A bad original for DRI;-)

 I'm not familiar with 3D hardware, but my rough guess is that
 you could easily guess what the registers if you know what the
 GL extensions are supposed to do and see what values are
 written in registers.

Some are on it for ages, but.

 IANAL, but reverse engineering is perfectly legal here in Europe
 and probably even in the USA if your goal is achieving
 compatibility.

If we didn't get another IP right (software patents, which we didn't have 
today, even if the EPÜ/EPC did it falsely the US-way) in Europe.

BTW
Which is the official Italian standpoint.
European Commision Draft or Parliament (later is against)?

 Even though I just have a Radeon 9200, I'm very excited about the
 ongoning R300 effort and with there was a similar project for NVidia
 cards too.
 
  Above applies here, too. - Sorry.
 
  The situation seems to be much worse in the future.
  Bad IP (TRIPS, etc.) madness due to USA-law.

 This is certaily bad, but not as bad as being unable to develop
 the driver at all.  You may implement patented algorithms and
 restrict its use in some countries.

 I can freely use the S3TC extension here because it's not (yet)
 patentable.

Yes, but IS falsely by the EPÜ/EPC...

...and solved with Roland's work;-)

 Any US developer could write it and even compile it, 
 as long as he doesn't sell it in his country.

Somewhat to simple I think.

Greetings,
Dieter

PS Fight for the European Parliament's draft!
PPS We had Thursday some very good results in our parlament.
http://www.heise.de/newsticker/meldung/52417


---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Mesa3d-dev] Doom3 works on R200!

[Dieter Nützel]

Am Sonntag, 24. Oktober 2004 20:45 schrieb Philipp Klaus Krause:
 Dieter Nützel schrieb:
 The nonfree xig driver has been developed without HyperZ docs and
 outperforms fglrx.
 
  Are you sure.
  I thought Xig had it all before.
 
  Do you have actual numbers?
  Haven't looked at them for very long time, but I bought the first version
  of there X server 1994 (?) for mga.

 Roland made a comparison a year ago:
 http://homepage.hispeed.ch/rscheidegger/atilinux_oct03/ati_linux_comp_oct03
.html Xig even outperforms the ATI windows drivers.

Ah, OK I know that ones, but know the side effects, too.
No standard xv, etc.

-Dieter


---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: Problem with remap_pfn_range on older 2.6.8 kernels.

[Dieter Nützel]

Am Samstag, 23. Oktober 2004 08:59 schrieb Dave Airlie:
 try it now .. I've just checked in a compat fix.. hopefully it works...

 Dave.

  CC [M]  /opt/drm/linux-core/drm_stub.o
/opt/drm/linux-core/drm_stub.c:50: error: parse error before int
make[3]: *** [/opt/drm/linux-core/drm_stub.o] Fehler 1
make[2]: *** [_module_/opt/drm/linux-core] Fehler 2
make[2]: Leaving directory `/usr/src/linux-2.6.5-7.108'
make[1]: *** [modules] Fehler 2
make[1]: Leaving directory `/opt/drm/linux-core'
make: *** [radeon.o] Fehler 2
7.862u 2.181s 0:37.11 27.0% 0+0k 0+0io 92pf+0w

-Dieter


 On Fri, 22 Oct 2004, Mike Mestnik wrote:
  A recent DRM checkin Bring in patch from kernel for remap_pfn_range
  only workes if your 2.6 kernel has remap_pfn_range, unlike Debain's
  2.6.8-1-k7.


---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: Problem with remap_pfn_range on older 2.6.8 kernels.

[Dieter Nützel]

Am Samstag, 23. Oktober 2004 11:08 schrieb Mike Mestnik:
 --- Dieter Nützel [EMAIL PROTECTED] wrote:
  Am Samstag, 23. Oktober 2004 08:59 schrieb Dave Airlie:
   try it now .. I've just checked in a compat fix.. hopefully it
 
  works...
 
   Dave.
 
CC [M]  /opt/drm/linux-core/drm_stub.o
  /opt/drm/linux-core/drm_stub.c:50: error: parse error before int
  make[3]: *** [/opt/drm/linux-core/drm_stub.o] Fehler 1
  make[2]: *** [_module_/opt/drm/linux-core] Fehler 2
  make[2]: Leaving directory `/usr/src/linux-2.6.5-7.108'
  make[1]: *** [modules] Fehler 2
  make[1]: Leaving directory `/opt/drm/linux-core'
  make: *** [radeon.o] Fehler 2
  7.862u 2.181s 0:37.11 27.0% 0+0k 0+0io 92pf+0w

 I didn't realy look to se if the build faild thought I don't think it did.
 Now I get (WW) RADEON(0): [agp] AGP not available even thought it's
 loaded as b4.

 eeprom  7816  0
 radeon 79744  0
 drm68260  1 radeon
 i2c_algo_bit9800  1 radeon
 amd_k7_agp  7820  1
 agpgart34536  1 amd_k7_agp

With OLD code (-D '12 hours ago') I have (on SuSE 2.6.5-7.108 (.111), dual 
Athlon SMP):

radeon 79744  1
drm70560  2 radeon
i2c_algo_bit9800  1 radeon
w83781d32896  0
i2c_sensor  2944  1 w83781d
i2c_isa 2112  0
i2c_amd756  6596  0
i2c_core   25348  5 
i2c_algo_bit,w83781d,i2c_sensor,i2c_isa,i2c_amd756
amd76x_pm   4832  0
hw_random   5716  0
amd_k7_agp  7692  1
agpgart32940  2 amd_k7_agp


/opt/Mesa sensors
w83627hf-isa-0290
Adapter: ISA adapter
VCore 1:   +1.73 V  (min =  +1.74 V, max =  +1.94 V)
VCore 2:   +2.50 V  (min =  +1.74 V, max =  +1.94 V)
+3.3V: +3.33 V  (min =  +3.14 V, max =  +3.46 V)
+5V:   +4.89 V  (min =  +4.73 V, max =  +5.24 V)
+12V: +12.22 V  (min = +10.82 V, max = +13.19 V)
-12V: -12.44 V  (min = -13.18 V, max = -10.88 V)
-5V:   -5.15 V  (min =  -5.25 V, max =  -4.75 V)
V5SB:  +5.35 V  (min =  +4.73 V, max =  +5.24 V)
VBat:  +3.42 V  (min =  +2.40 V, max =  +3.60 V)
U160: 2311 RPM  (min = 1500 RPM, div = 4)
CPU 0:3461 RPM  (min = 3000 RPM, div = 2)
CPU 1:3199 RPM  (min = 3000 RPM, div = 2)
System:  +33°C  (high =   +40°C, hyst =   +37°C)   sensor = thermistor
CPU 1: +39.0°C  (high =   +52°C, hyst =   +47°C)   sensor = transistor
CPU 0: +36.5°C  (high =   +52°C, hyst =   +47°C)   sensor = transistor
vid:  +1.850 V  (VRM Version 8.2)
alarms:
beep_enable:
  Sound alarm disabled

;-)

-Dieter


---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: Problem with remap_pfn_range on older 2.6.8 kernels.

[Dieter Nützel]

Am Samstag, 23. Oktober 2004 11:16 schrieb Dieter Nützel:
 Am Samstag, 23. Oktober 2004 11:08 schrieb Mike Mestnik:
  --- Dieter Nützel [EMAIL PROTECTED] wrote:
   Am Samstag, 23. Oktober 2004 08:59 schrieb Dave Airlie:
try it now .. I've just checked in a compat fix.. hopefully it
  
   works...
  
Dave.
  
 CC [M]  /opt/drm/linux-core/drm_stub.o
   /opt/drm/linux-core/drm_stub.c:50: error: parse error before int
   make[3]: *** [/opt/drm/linux-core/drm_stub.o] Fehler 1
   make[2]: *** [_module_/opt/drm/linux-core] Fehler 2
   make[2]: Leaving directory `/usr/src/linux-2.6.5-7.108'
   make[1]: *** [modules] Fehler 2
   make[1]: Leaving directory `/opt/drm/linux-core'
   make: *** [radeon.o] Fehler 2
   7.862u 2.181s 0:37.11 27.0% 0+0k 0+0io 92pf+0w
 
  I didn't realy look to se if the build faild thought I don't think it
  did. Now I get (WW) RADEON(0): [agp] AGP not available even thought
  it's loaded as b4.
 
  eeprom  7816  0
  radeon 79744  0
  drm68260  1 radeon
  i2c_algo_bit9800  1 radeon
  amd_k7_agp  7820  1
  agpgart34536  1 amd_k7_agp

 With OLD code (-D '12 hours ago') I have (on SuSE 2.6.5-7.108 (.111), dual
 Athlon SMP):

OK, this have to be -D '18 hours ago'.

Even without undefined symbol 'remap_pfn_range'.

-Dieter


---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: R200, DRI : lockup with CVS and UT (original), FireGL 8800

[Dieter Nützel]

Am Freitag, 22. Oktober 2004 02:38 schrieb khaqq:
 Hello,

 After realizing that the R200 driver bundled with xorg 6.8 wasn't
 stable, I installed the CVS of DRI (as of 2 hours ago).

A little more precise system specs, please.
OK, below ;-)

 The problem *was* :
 random lockups / freezes when playing UT (original one)

Do you mean the old (first) one (No 2k3/2k4)?
I (we) havent't tested that for ages.

 or Q3A (latest patch) ;

1.32b-3 (2.10.2003)?

I'll have to update to 1.32b-3, all former test were on 1.32b.
Didn't know there were an new one.

 those lockups happen within 30 seconds of starting 
 any of these games.
 Using driconf and :
 * disabling entirely TCL (software)
 * setting frame throttling to Usleeps
 * VSync to OFF
 * Number of texture units to 2
 actually helps alleviate the problem (I get lockups every 10 minutes or
 so).

 I then applied Mr Scheidegger 's patch at :

Rolands...;-)

 https://freedesktop.org/bugzilla/show_bug.cgi?id=814
 eventhough the problem was thought to be corrected in current CVS.

 Lo and behold, I know could play for about 10 minutes with both
 Bypass MESA's pipeline with state-based code generation and
 Software interrupts enabled ; better visuals, and faster.
 That said, UT locked up after 12 minutes (DM-Morpheus).
 I still haven't been able to pinpoint a common denominator for the
 crashes.
 It seems to me that the patch from Mr Scheidegger is still needed,
 because I already have dbg = 0x6; in r200_texstate.c ; but that's not
 enough, I fear :/

dbg = 0x06; :-)

Weird.

 The whole PC is known to be reliable, it's able to do 4 hours of 3DMark
 2001SE benchmark-looping in 1280x1024x32 mode, so I don't think
 there is a hardware problem.

Sorry, but this say 'nothing' (on Linux).
Try memtest-3.0 for min. 24 hours. ;-)

 relevant Hardware specs :
 PIII/933 coppermine
 asus tusl2-c / i815ep agp4x

Try with
AGPMode 2

Maybe without fast write, too.
AGPFastWrite 0

/etc/X11/XF86Config
Or where ever it is.

 2x256MB PC133 Crucial, tested recently for defects with memtest

How long? (see above)

 ATI FireGL 8800/128MB

X log?

 relevant software specs :
 linux kernel 2.6.9 (vanilla)
 quite up-to-date gentoo system with xorg-6.8.0-r1

Standard drm module (Gentoo)?

-Dieter


---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: drm trouble

[Dieter Nützel]

Am Donnerstag, 21. Oktober 2004 20:15 schrieb Roland Scheidegger:
 Jon Smirl wrote:
  I fixed up every error path that I can think of in the radeon i2c
  code. It's checked into CVS. Let me know if I've fixed the problem. I
  still haven't figure out how to reproduce it so I'm just fixing
  everything that could possibly be wrong.

 Yes, that seems to have fixed it. I can no longer trigger kernel oopses
 with unloading radeon and other i2c modules (knock on wood...).

I can second that (first time) ;-)

dual Athlon MP 1900+
r200
SuSE 2.6.5-7.108 (.111)

Cheers,
Dieter


---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: lnux-core DRM version

[Dieter Nützel]

Am Donnerstag, 21. Oktober 2004 22:32 schrieb Jon Smirl:
 Can everyone give the linux-core DRM version more testing. I think we
 have the compatibilty with vesafb ironed out now. I also added some
 fixes so that the radeon driver can tolerate non-functional i2c ports
 without failing.

What about a r200/r300 debug option for hardware reset?

See attached patch for linux-2.6.

-Dieter
diff -ru drm.orig/linux/drm_drv.h drm/linux/drm_drv.h
--- drm.orig/linux/drm_drv.h	2004-10-21 13:00:19.227349340 +0200
+++ drm/linux/drm_drv.h	2004-10-09 09:00:44.0 +0200
@@ -158,6 +158,8 @@
 
 #define DRIVER_IOCTL_COUNT	DRM_ARRAY_SIZE( DRM(ioctls) )
 
+static void drm_lock_watchdog( unsigned long __data );
+
 static int DRM(setup)( drm_device_t *dev )
 {
 	int i;
@@ -261,6 +263,7 @@
 
 	down( dev-struct_sem );
 	del_timer( dev-timer );
+	del_timer_sync( dev-lock.watchdog );
 
 	if ( dev-devname ) {
 		DRM(free)( dev-devname, strlen( dev-devname ) + 1,
@@ -371,6 +374,7 @@
 	if ( dev-lock.hw_lock ) {
 		dev-sigdata.lock = dev-lock.hw_lock = NULL; /* SHM removed */
 		dev-lock.filp = NULL;
+		dev-lock.dontbreak = 1;
 		wake_up_interruptible( dev-lock.lock_queue );
 	}
 	up( dev-struct_sem );
@@ -463,6 +467,10 @@
 		goto error_out_unreg;
 	}
 
+	init_timer( dev-lock.watchdog );
+	dev-lock.watchdog.data = (unsigned long) dev;
+	dev-lock.watchdog.function = drm_lock_watchdog;
+
 	dev-device = MKDEV(DRM_MAJOR, dev-minor );
 
 	DRM_INFO( Initialized %s %d.%d.%d %s on minor %d: %s\n,
@@ -811,6 +819,11 @@
 		if (dev-fn_tbl.release)
 			dev-fn_tbl.release(dev, filp);
 
+		/* Avoid potential race where the watchdog callback is still
+		 * running when filp is freed.
+		 */
+del_timer_sync( dev-lock.watchdog );
+
 		DRM(lock_free)( dev, dev-lock.hw_lock-lock,
 _DRM_LOCKING_CONTEXT(dev-lock.hw_lock-lock) );
 
@@ -833,6 +846,7 @@
 			}
 			if ( DRM(lock_take)( dev-lock.hw_lock-lock,
 	 DRM_KERNEL_CONTEXT ) ) {
+dev-lock.dontbreak = 1;
 dev-lock.filp	= filp;
 dev-lock.lock_time = jiffies;
 atomic_inc( dev-counts[_DRM_STAT_LOCKS] );
@@ -984,6 +998,40 @@
 	return retcode;
 }
 
+
+/**
+ * Lock watchdog callback function.
+ *
+ * Whenever a privileged client must sleep on the lock waitqueue
+ * in the LOCK ioctl, the watchdog timer is started.
+ * When the UNLOCK ioctl is called, the timer is stopped.
+ *
+ * When the watchdog timer expires, the process holding the lock
+ * is killed. Privileged clients set lock.dontbreak and are exempt
+ * from this rule.
+ */
+static void drm_lock_watchdog( unsigned long __data )
+{
+	drm_device_t *dev = (drm_device_t *)__data;
+	drm_file_t *priv;
+	
+	if ( !dev-lock.filp ) {
+		DRM_DEBUG( held by kernel\n );
+		return;
+	}
+	
+	if ( dev-lock.dontbreak ) {
+		DRM_DEBUG( privileged lock\n );
+		return;
+	}
+	
+	priv = dev-lock.filp-private_data;
+	DRM_DEBUG( Kill pid=%d\n, priv-pid );
+	
+	kill_proc( priv-pid, SIGKILL, 1 );
+}
+
+
 /** 
  * Lock ioctl.
  *
@@ -1003,6 +1051,7 @@
 DECLARE_WAITQUEUE( entry, current );
 drm_lock_t lock;
 int ret = 0;
+	int privileged = capable( CAP_SYS_ADMIN );
 
 	++priv-lock_count;
 
@@ -1033,6 +1082,7 @@
 		}
 		if ( DRM(lock_take)( dev-lock.hw_lock-lock,
  lock.context ) ) {
+			dev-lock.dontbreak = privileged;
 			dev-lock.filp  = filp;
 			dev-lock.lock_time = jiffies;
 			atomic_inc( dev-counts[_DRM_STAT_LOCKS] );
@@ -1040,6 +1090,14 @@
 		}
 		
 		/* Contention */
+
+		if ( privileged ) {
+			if ( !timer_pending( dev-lock.watchdog ) ) {
+DRM_DEBUG( Starting lock watchdog\n );
+mod_timer( dev-lock.watchdog, jiffies + 5 * HZ );
+			}
+		}
+
 		schedule();
 		if ( signal_pending( current ) ) {
 			ret = -ERESTARTSYS;
@@ -1104,8 +1162,12 @@
 		return -EINVAL;
 	}
 
+	DRM_DEBUG( \n );
+
 	atomic_inc( dev-counts[_DRM_STAT_UNLOCKS] );
 
+	del_timer_sync( dev-lock.watchdog );
+
 	if (dev-fn_tbl.kernel_context_switch_unlock)
 		dev-fn_tbl.kernel_context_switch_unlock(dev);
 	else
diff -ru drm.orig/linux/drmP.h drm/linux/drmP.h
--- drm.orig/linux/drmP.h	2004-10-21 13:00:19.230348746 +0200
+++ drm/linux/drmP.h	2004-10-09 21:34:06.0 +0200
@@ -403,6 +403,8 @@
 	struct file   *filp;	/** File descr of lock holder (0=kernel) */
 	wait_queue_head_t lock_queue;	/** Queue of blocked processes */
 	unsigned long	  lock_time;	/** Time of last lock in jiffies */
+	struct timer_list watchdog;	/** Watchdog timer to kill runaway processes */
+	int   dontbreak;	/** Even watchdog honours the current lock */
 } drm_lock_data_t;
 
 /**

Re: R200 ReadPixels optimization

[Dieter Nützel]

Am Dienstag, 12. Oktober 2004 20:24 schrieb Ian Romanick:
 Dieter Nützel wrote:
  NONE of your three versions gave me direct rendering?!
  I've tested with and without your TLS-patch (progress?).
 
  The symbols are in.
  DRI-Mesa/Patches nm /usr/X11R6-NO-TLS/lib/modules/dri/r200_dri.so | grep
  r200ReadRGBASpan_ARGB
  00175714 t r200ReadRGBASpan_ARGB
  00175be4 t r200ReadRGBASpan_ARGB_MMX
  00175ad4 t r200ReadRGBASpan_ARGB_SSE
  001759c4 t r200ReadRGBASpan_ARGB_SSE2
 
  But
  DRI-Mesa/Patches nm /usr/X11R6-NO-TLS/lib/modules/dri/r200_dri.so | grep
  _generic_read_RGBA_span_BGRA
   U _generic_read_RGBA_span_BGRA_REV_MMX
   U _generic_read_RGBA_span_BGRA_REV_SSE
   U _generic_read_RGBA_span_BGRA_REV_SSE2
 
  I'm on XFree86 DRI CVS build as long as my distro based on it;-)

 You'll have to update the Imakefiles to build in DRI CVS.  The problem
 is that it's not linking (or compiling) ../common/read_rgba_span_x86.o.

Got it with DRI and Mesa CVS on XFree86.

--- xc/lib/GL/mesa/x86/Imakefile.inc2004-10-18 20:29:09.824517266 +0200
+++ xc/lib/GL/mesa/x86/Imakefile.inc.Dieter 2004-10-18 18:13:42.0 
+0200
@@ -8,6 +8,7 @@

 MESA_X86_SRCS = $(MESAX86BUILDDIR)common_x86.c \
$(MESAX86BUILDDIR)common_x86_asm.S \
+   $(MESAX86BUILDDIR)read_rgba_span_x86.S \
$(MESAX86BUILDDIR)glapi_x86.S \
$(MESAX86BUILDDIR)x86.c \
$(MESAX86BUILDDIR)x86_cliptest.S \
@@ -18,6 +19,7 @@
 #ifdef NeedToLinkMesaSrc
 LinkSourceFile(common_x86.c, $(MESASRCDIR)/src/mesa/x86)
 LinkSourceFile(common_x86_asm.S, $(MESASRCDIR)/src/mesa/x86)
+LinkSourceFile(read_rgba_span_x86.S, $(MESASRCDIR)/src/mesa/x86)
 LinkSourceFile(glapi_x86.S, $(MESASRCDIR)/src/mesa/x86)
 LinkSourceFile(x86.c, $(MESASRCDIR)/src/mesa/x86)
 LinkSourceFile(x86_cliptest.S, $(MESASRCDIR)/src/mesa/x86)
@@ -28,6 +30,7 @@

 MESA_X86_OBJS = $(MESAX86BUILDDIR)common_x86.o \
$(MESAX86BUILDDIR)common_x86_asm.o \
+   $(MESAX86BUILDDIR)read_rgba_span_x86.o \
$(MESAX86BUILDDIR)x86.o \
$(MESAX86BUILDDIR)x86_cliptest.o \
$(MESAX86BUILDDIR)x86_xform2.o \
@@ -37,6 +40,7 @@
 #if defined(DoSharedLib)  DoSharedLib
 MESA_X86_UOBJS = $(MESAX86BUILDDIR)unshared/common_x86.o \
$(MESAX86BUILDDIR)common_x86_asm.o \
+   $(MESAX86BUILDDIR)unshared/read_rgba_span_x86.o \
$(MESAX86BUILDDIR)unshared/x86.o \
$(MESAX86BUILDDIR)x86_cliptest.o \
$(MESAX86BUILDDIR)x86_xform2.o \
@@ -48,6 +52,7 @@

 MESA_X86_DOBJS = $(MESAX86BUILDDIR)debugger/common_x86.o \
$(MESAX86BUILDDIR)common_x86_asm.o \
+   $(MESAX86BUILDDIR)debugger/read_rgba_span_x86.o \
$(MESAX86BUILDDIR)debugger/x86.o \
$(MESAX86BUILDDIR)x86_cliptest.o \
$(MESAX86BUILDDIR)x86_xform2.o \
@@ -56,6 +61,7 @@

 MESA_X86_POBJS = $(MESAX86BUILDDIR)profiled/common_x86.o \
$(MESAX86BUILDDIR)common_x86_asm.o \
+   $(MESAX86BUILDDIR)profiled/read_rgba_span_x86.o \
$(MESAX86BUILDDIR)profiled/x86.o \
$(MESAX86BUILDDIR)x86_cliptest.o \
$(MESAX86BUILDDIR)x86_xform2.o \

-Dieter


---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: R200 Projective texturing and texgen

[Dieter Nützel]

Am Montag, 11. Oktober 2004 14:36 schrieb Marcello Maggioni:
 On Sun, 10 Oct 2004 23:27:38 +0200, Dieter Nützel
 [EMAIL PROTECTED] wrote:

  UT2003
  Some broken textures on the walls and floors (Temple of Anubis).
  'shock rifle' is OK
  'Exit' dito.

- Exit IS broken.

  UT2004
  Working. I've seen no corrupted textures.
  'shock rifle' is OK
  'Exit' dito.

- Exit IS broken.

[MUCH TOFU deleted] !!!

 You mean Shock Rifle is ok without dbg = 0x6; or you mean with it?

dbg = 0x06; (!!!) is standard (and _included_ in r200-projtex-6.diff);-)))

-Dieter


---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: Can't apply S3TC patch anymore with current Mesa

[Dieter Nützel]

Am Freitag, 8. Oktober 2004 15:29 schrieb Marcello Maggioni:
 Like the Subject says I can't apply S3TC patch anymore to current Mesa
 tree (works with yesterday tree) .

'Cause it is IN...?! ;-)))

 You've worked hard guys in one day ;)

Compiling...

Regards,
   Dieter


---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: Can't apply S3TC patch anymore with current Mesa

[Dieter Nützel]

Am Freitag, 8. Oktober 2004 16:34 schrieb Marcello Maggioni:
 On Fri, 8 Oct 2004 16:12:44 +0200, Dieter Nützel

 [EMAIL PROTECTED] wrote:
  Am Freitag, 8. Oktober 2004 15:29 schrieb Marcello Maggioni:
   Like the Subject says I can't apply S3TC patch anymore to current Mesa
   tree (works with yesterday tree) .
 
  'Cause it is IN...?! ;-)))
 
   You've worked hard guys in one day ;)
 
  Compiling...
 
  Regards,
 Dieter

 Anyway , with current MESA I haven't the message that claims that DXTn
 compression is enabled and UT2004 has that problem ( I've tried many
 combinations , and USE_EXTERNAL_DXTN_LIB=1 is set in linux-dri
 config file ) .

Yes, there is something wrong (in the driconf logic).

Have s3tc 'on' for all apps.
setenv USE_EXTERNAL_DXTN_LIB 1

driconf
device screen=0 driver=r200
application name=all
option name=force_s3tc_enable value=true /
/application
application name=doom3-demo
option name=tcl_mode value=0 /
/application
/device
/driconf

But it do not work.

 DXTn library is installed .

dito

quake3-smp.log:
...GL_S3_s3tc not found
compressed textures: disabled

When I set 'setenv force_s3tc_enable 1' quake3-smp do NOT start anymore.

ATTENTION: default value of option force_s3tc_enable overridden by 
environment.
Fatal error in __driConfigOptions line 75, column 0: illegal default value: 1.

-Dieter


---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: Can't apply S3TC patch anymore with current Mesa

[Dieter Nützel]

Am Freitag, 8. Oktober 2004 17:37 schrieb Felix Kühling:
 On Fri, 8 Oct 2004 17:10:35 +0200
 Dieter Nützel [EMAIL PROTECTED] wrote:

 [snip]

  When I set 'setenv force_s3tc_enable 1' quake3-smp do NOT start anymore.
 
  ATTENTION: default value of option force_s3tc_enable overridden by
  environment.
  Fatal error in __driConfigOptions line 75, column 0: illegal default
  value: 1.

 That's because 1 is indeed illegal for boolean options such as
 force_s3tc_enable. Legal values are true and false.

OK, but do not help ;-)

Maybe this the broken? (Taken from Roland's patch):

 * GL_EXT_texture_compression_s3tc support.
  */

+#if defined(XFree86LOADER)  defined(IN_MODULE)
+#define USE_EXTERNAL_DXTN_LIB 0
+#else
+#define USE_EXTERNAL_DXTN_LIB 1
+#endif

Now, we have:

#ifndef USE_EXTERNAL_DXTN_LIB
#define USE_EXTERNAL_DXTN_LIB 0
#endif

-Dieter



---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: Can't apply S3TC patch anymore with current Mesa

[Dieter Nützel]

Am Freitag, 8. Oktober 2004 17:10 schrieb Dieter Nützel:
 Am Freitag, 8. Oktober 2004 16:34 schrieb Marcello Maggioni:
  On Fri, 8 Oct 2004 16:12:44 +0200, Dieter Nützel
 
  [EMAIL PROTECTED] wrote:
   Am Freitag, 8. Oktober 2004 15:29 schrieb Marcello Maggioni:
Like the Subject says I can't apply S3TC patch anymore to current
Mesa tree (works with yesterday tree) .
  
   'Cause it is IN...?! ;-)))
  
You've worked hard guys in one day ;)
  
   Compiling...
  
   Regards,
  Dieter
 
  Anyway , with current MESA I haven't the message that claims that DXTn
  compression is enabled and UT2004 has that problem ( I've tried many
  combinations , and USE_EXTERNAL_DXTN_LIB=1 is set in linux-dri
  config file ) .

 Yes, there is something wrong (in the driconf logic).

 Have s3tc 'on' for all apps.
 setenv USE_EXTERNAL_DXTN_LIB 1

More:

UT2003 print this:

INSTALL/SOURCE ut2003_demo 
[1] 31140
INSTALL/SOURCE fcntl: Invalid argument
fcntl: Invalid argument
Disabling HW TCL support

UT2004, too:

INSTALL/SOURCE ut2004demo 
[1] 31246
INSTALL/SOURCE Disabling HW TCL support

Hints?

-dieter


---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: Can't apply S3TC patch anymore with current Mesa

[Dieter Nützel]

Am Freitag, 8. Oktober 2004 17:53 schrieb Dieter Nützel:
 Am Freitag, 8. Oktober 2004 17:10 schrieb Dieter Nützel:
  Am Freitag, 8. Oktober 2004 16:34 schrieb Marcello Maggioni:
   On Fri, 8 Oct 2004 16:12:44 +0200, Dieter Nützel
  
   [EMAIL PROTECTED] wrote:
Am Freitag, 8. Oktober 2004 15:29 schrieb Marcello Maggioni:
 Like the Subject says I can't apply S3TC patch anymore to current
 Mesa tree (works with yesterday tree) .

 More:

 UT2003 print this:

 INSTALL/SOURCE ut2003_demo 
 [1] 31140
 INSTALL/SOURCE fcntl: Invalid argument
 fcntl: Invalid argument
 Disabling HW TCL support

 UT2004, too:

 INSTALL/SOURCE ut2004demo 
 [1] 31246
 INSTALL/SOURCE Disabling HW TCL support

Argh, Felix,

what is here wrong?

It is due to disabled TCL for doom3!

When I delete doom3 settings from drirc

driconf
device screen=0 driver=r200
application name=all
option name=force_s3tc_enable value=true /
/application
/device
/driconf

TCL is back.

UT2k3  2k4 tested.

-Dieter


---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: Can't apply S3TC patch anymore with current Mesa

[Dieter Nützel]

Am Freitag, 8. Oktober 2004 17:41 schrieb Dieter Nützel:
 Am Freitag, 8. Oktober 2004 17:37 schrieb Felix Kühling:
  On Fri, 8 Oct 2004 17:10:35 +0200
  Dieter Nützel [EMAIL PROTECTED] wrote:
 
  [snip]
 
   When I set 'setenv force_s3tc_enable 1' quake3-smp do NOT start
   anymore.
  
   ATTENTION: default value of option force_s3tc_enable overridden by
   environment.
   Fatal error in __driConfigOptions line 75, column 0: illegal default
   value: 1.
 
  That's because 1 is indeed illegal for boolean options such as
  force_s3tc_enable. Legal values are true and false.

 OK, but do not help ;-)

 Maybe this the broken? (Taken from Roland's patch):

  * GL_EXT_texture_compression_s3tc support.
   */

 +#if defined(XFree86LOADER)  defined(IN_MODULE)
 +#define USE_EXTERNAL_DXTN_LIB 0
 +#else
 +#define USE_EXTERNAL_DXTN_LIB 1
 +#endif

 Now, we have:

 #ifndef USE_EXTERNAL_DXTN_LIB
 #define USE_EXTERNAL_DXTN_LIB 0
 #endif

Found Mesa Error with DOOM3.

using ARB_vertex_buffer_object memory
using ARB renderSystem
Mesa 6.3 implementation error: external dxt library not available
Please report to the Mesa bug database at www.mesa3d.org
Mesa 6.3 implementation error: external dxt library not available
Please report to the Mesa bug database at www.mesa3d.org

/home/nuetzel l /usr/lib/libtxc_dxtn.so
-rwxr-xr-x1 root root19623 2004-06-24 
20:17 /usr/lib/libtxc_dxtn.so

-Dieter


---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: Can't apply S3TC patch anymore with current Mesa

[Dieter Nützel]

Am Freitag, 8. Oktober 2004 18:24 schrieb Felix Kühling:
 On Fri, 8 Oct 2004 18:09:29 +0200
 Dieter Nützel [EMAIL PROTECTED] wrote:

 [snip]

   INSTALL/SOURCE ut2004demo 
   [1] 31246
   INSTALL/SOURCE Disabling HW TCL support
 
  Argh, Felix,
 
  what is here wrong?

 The problem is that the name-attribute is just a descriptive string of
 your application. Use the executable-attribute to set the name of the
 executable. Without that attribute your doom3-demo section applies to
 all applications. Example (assuming the executable is really called
 doom3-demo):

 application name=doom3-demo executable=doom3-demo
 option name=tcl_mode value=0 /
 /application

 Or if you're using driconf, don't forget to fill in the Executable
 field. (Happened to me too, a couple of times ;-)

*LOL* ;-)))

Thanks,
Dieter


---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: Can't apply S3TC patch anymore with current Mesa

[Dieter Nützel]

Am Freitag, 8. Oktober 2004 18:56 schrieb Marcello Maggioni:

 Deiter,

?;-)

 are you able to run Doom3 on your 8500 board? 

Yes, see here:
http://marc.theaimsgroup.com/?l=dri-develm=109714730107167w=2

But Roland has problems:
http://marc.theaimsgroup.com/?l=dri-develm=109700495010472w=2

 WARNING: vertex array range in virtual memory (SLOW)
 signal caught: Segmentation fault
 si_code 1
 Trying to exit gracefully..

http://marc.theaimsgroup.com/?l=dri-develm=10970001965w=2

Maybe you haven't a NPTL/TLS (glibc) System?
I have Ian's TLS patch applied (Ian, any updates?).

SuSE 9.0 _with_
latest 9.1 release kernel 2.6.5-7.108-smp (self compiled)
glibc-2.3.3-73 (!!!) NPTL/TLS

-Dieter


---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: Can't apply S3TC patch anymore with current Mesa

[Dieter Nützel]

OK, I have a fix.

 Now, we have:

 #ifndef USE_EXTERNAL_DXTN_LIB
 #define USE_EXTERNAL_DXTN_LIB 0
 #endif

--- src/mesa/main/texcompress_s3tc.c.orig   2004-10-08 15:12:34.0 
+0200
+++ src/mesa/main/texcompress_s3tc.c2004-10-08 19:54:43.0 +0200
@@ -29,7 +29,11 @@
  */

 #ifndef USE_EXTERNAL_DXTN_LIB
+#if defined(XFree86LOADER)  defined(IN_MODULE)
 #define USE_EXTERNAL_DXTN_LIB 0
+#else
+#define USE_EXTERNAL_DXTN_LIB 1
+#endif
 #endif

 #include glheader.h

Works, with UT2k3  UT2k4, DOOM3, Q3A, etc.

Now, let's get to the TCL DOOM3 issues (dark lines across the textures)...

-Dieter


---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: Can't apply S3TC patch anymore with current Mesa

[Dieter Nützel]

Am Freitag, 8. Oktober 2004 20:13 schrieb Marcello Maggioni:
 On Fri, 08 Oct 2004 19:18:30 +0200, Roland Scheidegger

 [EMAIL PROTECTED] wrote:
  Marcello Maggioni wrote:
   I get :
   WARNING: vertex array range in virtual memory (SLOW)
   signal caught: Segmentation fault
   si_code 1
   Trying to exit gracefully..
   Shutting down sound hardware
 
  You don't list what you got as renderer, but this sounds to me like you
  got indirect rendering. You need to use LD_PRELOAD=/usr/lib/libGL.so to
  get it work, since doom3 dlopens libGL.so without RTLD_GLOBAL which will
  cause all Mesa-built dri drivers to fail.
 
  Roland

 Ok, With Roland suggestion Doom3 works , but I have textures on people
 not very good . It's only a problem of mine or is common? I had to
 disable TCL to make the texture visible :)

Read the list/whole thread (as I posted to you)!

http://marc.theaimsgroup.com/?l=dri-develm=109700382719233w=2

Cheers,
Dieter


---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: Kernel Oopses in recent DRMs

[Dieter Nützel]

Am Donnerstag, 7. Oktober 2004 02:00 schrieb Jon Smirl:
 This should fix it. I'm I'll check it in after I reboot and test it.
 It didn't occur to me that DRM(global) could be freed while the loop
 is in progress.

 I need to remember to keep testing everything with framebuffer loaded
 and again without it loaded.

 [EMAIL PROTECTED] drm-bk]$ bk -r diffs -u
 = linux/drm_drv.h 1.21 vs edited =
 --- 1.21/linux/drm_drv.h2004-09-21 20:29:48 -04:00
 +++ edited/linux/drm_drv.h  2004-10-06 19:56:06 -04:00
 @@ -664,7 +664,7 @@
 DRM_DEBUG( \n );
 if (DRM(fb_loaded)) {
 if (DRM(global)) {
 -   for (i = 0; i  DRM(global)-cards_limit; i++) {
 +   for (i = 0; DRM(global)  (i 
 DRM(global)-cards_limit); i++) {
 minor = DRM(global)-minors[i];
 dev = minor-dev;
 DRM_DEBUG(fb loaded release minor
 %d\n, dev-minor);

Good catch!

I had hangs during shutdown sometimes...

radeon.ko

 Unable to handle kernel NULL pointer dereference at virtual address 
  printing eip:
 fabfd6fe
 *pde = 
 Oops:  [#1]
 PREEMPT SMP
 CPU:1
 EIP:0060:[__crc_posix_unblock_lock+493335/1053176]Tainted: G  U
 EIP:0060:[fabfd6fe]Tainted: G  U
 EFLAGS: 00010206   (2.6.5-7.108-smp)
 EIP is at drm_exit+0x4e/0x100 [radeon]
 eax:    ebx: f3bbe180   ecx: f7fff0c0   edx: c100
 esi: f425c000   edi: 000c   ebp: 0001   esp: c44c1f38
 ds: 007b   es: 007b   ss: 0068
 Process rmmod (pid: 4099, threadinfo=c44c task=ee3ae820)
 Stack: c02e9430 fff0 0880 fac09c00 c02e98d8  0880 
c0142280
c44c  fac09c00 0880 c44c1f5c c44c 65646172 
40006e6f
40019000 c44c1f98 40417fff c180c040 f3abadd8 f3aba88c 40019000 
c180c040
 Call Trace:
  [sys_delete_module+352/512] sys_delete_module+0x160/0x200
  [c0142280] sys_delete_module+0x160/0x200
  [sysenter_past_esp+82/113] sysenter_past_esp+0x52/0x71
  [c010841d] sysenter_past_esp+0x52/0x71

 Code: 3b 28 73 5e 8b 58 04 01 fb f6 05 80 9d c0 fa 01 8b 73 04 74

FIXED, now.

Thanks,
Dieter


---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: projtex on r200, texturing problem

[Dieter Nützel]

Am Mittwoch, 29. September 2004 17:26 schrieb Andreas Stenglein:
 maybe this help a bit.. but I think its not a full fix.

Not full for Celestia 'Earth - ISS' (few textures are still flickering, 
Eric?) and xscreensaver's 'pipe' angles are not full rendered.

-Dieter

 Index: Mesa/src/mesa/drivers/dri/r200/r200_context.h
 ===
 RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r200/r200_context.h,v
 retrieving revision 1.21
 diff -u -r1.21 r200_context.h
 --- Mesa/src/mesa/drivers/dri/r200/r200_context.h   22 Sep 2004
 06:27:02 -  1.21 +++ Mesa/src/mesa/drivers/dri/r200/r200_context.h 
  29 Sep 2004 16:09:16 - @@ -677,6 +677,11 @@
  */
 GLboolean needproj;

 +   /**
 +* Q-coord is used for projective texturing.  BIT 0..5 = TMU 0..5
 +*/
 +   GLuint projtex;
 +
 struct r200_dma_region indexed_verts;
  };

 Index: Mesa/src/mesa/drivers/dri/r200/r200_swtcl.c
 ===
 RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r200/r200_swtcl.c,v
 retrieving revision 1.15
 diff -u -r1.15 r200_swtcl.c
 --- Mesa/src/mesa/drivers/dri/r200/r200_swtcl.c 17 Aug 2004 01:41:32 - 
 1.15 +++ Mesa/src/mesa/drivers/dri/r200/r200_swtcl.c 29 Sep 2004
 16:09:18 - @@ -89,6 +89,7 @@
 GLuint index = tnl-render_inputs;
 int fmt_0 = 0;
 int fmt_1 = 0;
 +   int projtex = 0;
 int offset = 0;


 @@ -150,15 +151,17 @@
 /* r200 doesn't like 4D texcoords (is that true?):
  */
 if (sz != 4) {
 -  emit = EMIT_1F + (sz - 1);
 +  emit = EMIT_1F + (sz - 1);  /* EMIT_SZ(sz) */
 }
 else {
sz = 3;
 -  emit = EMIT_3F_XYW;
 +  emit = EMIT_3F_XYW;  /* emit Q-Coord ? (projtex) */
 +  projtex |= 1  i;
 }

 fmt_1 |= sz  (3 * i);
 -   EMIT_ATTR( _TNL_ATTRIB_TEX0+i, EMIT_SZ(sz), 0 );
 +   EMIT_ATTR( _TNL_ATTRIB_TEX0+i, emit, 0 );
 +/* EMIT_ATTR( _TNL_ATTRIB_TEX0+i, EMIT_SZ(sz), 0 ); */
  }
}
 }
 @@ -166,11 +169,13 @@


 if ( (rmesa-hw.vtx.cmd[VTX_VTXFMT_0] != fmt_0)
 -   || (rmesa-hw.vtx.cmd[VTX_VTXFMT_1] != fmt_1) ) {
 +   || (rmesa-hw.vtx.cmd[VTX_VTXFMT_1] != fmt_1)
 +   || (rmesa-swtcl.projtex != projtex) ) {
R200_NEWPRIM(rmesa);
R200_STATECHANGE( rmesa, vtx );
rmesa-hw.vtx.cmd[VTX_VTXFMT_0] = fmt_0;
rmesa-hw.vtx.cmd[VTX_VTXFMT_1] = fmt_1;
 +  rmesa-swtcl.projtex= projtex;

rmesa-swtcl.vertex_size =
   _tnl_install_attrs( ctx,

 Index: Mesa/src/mesa/drivers/dri/r200/r200_texstate.c
 ===
 RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r200/r200_texstate.c,v
 retrieving revision 1.13
 diff -u -r1.13 r200_texstate.c
 --- Mesa/src/mesa/drivers/dri/r200/r200_texstate.c  24 Sep 2004
 04:20:58 -  1.13 +++ Mesa/src/mesa/drivers/dri/r200/r200_texstate.c
  29 Sep 2004 16:09:19 - @@ -266,6 +266,9 @@
 (log2Width  R200_FACE_WIDTH_4_SHIFT) |
 (log2Height  R200_FACE_HEIGHT_4_SHIFT));
 }
 +   else if (tObj-Target == GL_TEXTURE_2D) {
 +  t-pp_txformat_x |= R200_TEXCOORD_PROJ;
 +   }

 t-pp_txsize = (((tObj-Image[0][t-base.firstLevel]-Width - 1)  0)
 | ((tObj-Image[0][t-base.firstLevel]-Height - 1)  16));


---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel