Re: [Dri-devel] A few mach64 tests

2002-05-28 Thread José Fonseca

On 2002.05.28 01:10 Leif Delgass wrote:
 ...
 
 On Tue, 28 May 2002, Bernard Cafarelli wrote:
 
  Well, here's my small contribution to the mach64 dev (sorry but I'm FAR
  away beyond you in programming, especially compared to people like
  Jose,Leif or Linus :)).
 
 Well, I _definitely_ wouldn't put myself in the same class as Linus, but
 thanks. :)  The biggest problem is the learning curve required to get
 familiar with the DRI structure, but Jose's Developer FAQ is a great
 starting point.
 
 ...

Leif words are mine too! In any case the most important is have will to 
help, and that you do seem to have!

Regards,

José Fonseca

___

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] A few mach64 tests

2002-05-28 Thread Voyageur

First, thanks for your answers, both of you.
And now, for some updates:

Le Mon, 27 May 2002 20:10:23 -0400 (EDT)
Leif Delgass [EMAIL PROTECTED] a écrit:

 Thanks for the report!  Concerning textures: the AGP texturing code is
 kind of a proof-of-concept and isn't very efficient yet.  We need to work
 on reducing the amount of texture swapping that is happening.  You can try
 AGP 2x, use Option AgpMode 2 in the Device section of XF86Config.  
Ok it works, glxinfo now says:
OpenGL renderer string: Mesa DRI Mach64 20020227 [Rage Pro] AGP 2x x86/MMX/3DNow!
and things don't get worse :)

 Also, I have some code to increase the max texture size exported, but
 usually an app would refuse to run or use smaller textures if that's the
 problem.  I should resurrect that bit of code.  Something you can try to
 get a feel for what's happening with textures:
 
 export this environment var:
 LIBGL_PERFORMANCE_BOXES=1
 
Great option!
...
 
 I'm guessing that in most of the places where you see slowdowns, you'll
 see lots of texture swapping (yellow box) and/or the texture upload bars
 will be long (large texture uploads).  Sound problems could be related to
 this and/or high CPU usage in wait loops? 


 If things get _very_ slow, it's 
 possible that something is requiring software rendering, like GL_BLEND 
 texture environment, but there isn't an easy way to test this, you'd have 
 to look at the app's source or try changing app options.
For doom-legacy, the problem seems indeed to be some software rendering firing up, 
because some rooms are ok, but when there are lights in the room (specular?), it 
really slows down

 
 The first priority is to eliminate lockups.  I haven't tried tuxkart, I'll 
 have to check that out.  Do you see any messages in the system log?  Can 
 you kill the app or kill X?
 
Nothing strange appears in the logs.Ctrl-C in the xterm closes the program (not 
cliking on the cross). The problem seems to be related with catching the mouse. I'll 
check with the new version tomorrow (I have the previous version for now).

As for celestia, the yellow 'swapping' indicator appears just before celestia hangs. 
So it does seem it's trying to load new textures (of Earth).

 As for tuxracer, does it say anything about what it's looking for in the 
 GLX visual that isn't supported?
 
Too bad the problem isn't with version 0.6 (where we could look at the code) but the 
1.1 commercial version. There's no debug (or help option), so there's only the lines:
%%% tuxracer warning: Failed to set video mode Couldn't find matching GLX visual
*** tuxracer error: Couldn't initialize video: Couldn't find matching GLX visual 
(Success)

Also, I never get to see blue bars (ie AGP) with the PERFORMANCE_BOXES option: is it 
normal (agpgart module is loaded), ie local means already loaded in the card memory?

-- 
Bernard Cafarelli
aka Voyageur
ICQ:66024647




Thanks for your answers, both of you.
And now, for some updates:

Le Mon, 27 May 2002 20:10:23 -0400 (EDT)
Leif Delgass [EMAIL PROTECTED] a écrit:

 Thanks for the report!  Concerning textures: the AGP texturing code is
 kind of a proof-of-concept and isn't very efficient yet.  We need to work
 on reducing the amount of texture swapping that is happening.  You can try
 AGP 2x, use Option AgpMode 2 in the Device section of XF86Config.  
Ok it works, glxinfo now says:
OpenGL renderer string: Mesa DRI Mach64 20020227 [Rage Pro] AGP 2x x86/MMX/3DNow!
and things don't get worse :)

 Also, I have some code to increase the max texture size exported, but
 usually an app would refuse to run or use smaller textures if that's the
 problem.  I should resurrect that bit of code.  Something you can try to
 get a feel for what's happening with textures:
 
 export this environment var:
 LIBGL_PERFORMANCE_BOXES=1
 
Great option!
...
 
 I'm guessing that in most of the places where you see slowdowns, you'll
 see lots of texture swapping (yellow box) and/or the texture upload bars
 will be long (large texture uploads).  Sound problems could be related to
 this and/or high CPU usage in wait loops? 


 If things get _very_ slow, it's 
 possible that something is requiring software rendering, like GL_BLEND 
 texture environment, but there isn't an easy way to test this, you'd have 
 to look at the app's source or try changing app options.
For doom-legacy, the problem seems indeed to be some software rendering firing up, 
because some rooms are ok, but when there are lights in the room (specular?), it 
really slows down

 
 The first priority is to eliminate lockups.  I haven't tried tuxkart, I'll 
 have to check that out.  Do you see any messages in the system log?  Can 
 you kill the app or kill X?
 
Nothing strange appears in the logs.Ctrl-C in the xterm closes the program (not 
cliking on the cross). The 

[Dri-devel] A few mach64 tests

2002-05-27 Thread Voyageur

Well, here's my small contribution to the mach64 dev (sorry but I'm FAR away beyond 
you in programming, especially compared to people like Jose,Leif or Linus  :)).

So with mach64-0-0-4-branch checked out and compiled monday morning (french time), a 
Mobility M1 with 8Mo, athlon-4 900Mhz, running at 1024x768:16 most of the time.
To sum it up: nice work! Too bad the new Tuxracer won't work (I was planning to buy 
it). Maybe the big texture problem can be interesting to look up. Now more details and 
some facts:

-lspci says:
01:00.0 VGA compatible controller: ATI Technologies Inc Rage Mobility P/M AGP 2x (rev 
64) (prog-if 00 [VGA])
Subsystem: Compaq Computer Corporation: Unknown device 005f
Flags: bus master, stepping, medium devsel, latency 66, IRQ 9
Memory at f500 (32-bit, non-prefetchable) [size=16M]
I/O ports at 9000 [size=256]
Memory at f410 (32-bit, non-prefetchable) [size=4K]
Expansion ROM at unassigned [disabled] [size=128K]
Capabilities: [50] AGP version 1.0
Capabilities: [5c] Power Management version 1

-glxinfo says:
name of display: :0.0
display: :0  screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.2
server glx extensions:
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context
client glx vendor string: SGI
client glx version string: 1.2
client glx extensions:
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context
GLX extensions:
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context
OpenGL vendor string: Gareth Hughes
OpenGL renderer string: Mesa DRI Mach64 20020227 [Rage Pro] AGP 1x x86/MMX/3DNow!
OpenGL version string: 1.2 Mesa 4.0.2
OpenGL extensions:
GL_ARB_imaging, GL_ARB_multitexture, GL_ARB_transpose_matrix, 
GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_minmax, 
GL_EXT_blend_subtract, GL_EXT_clip_volume_hint, GL_EXT_convolution, 
GL_EXT_compiled_vertex_array, GL_EXT_histogram, GL_EXT_packed_pixels, 
GL_EXT_polygon_offset, GL_EXT_rescale_normal, GL_EXT_texture3D, 
GL_EXT_texture_object, GL_EXT_vertex_array, GL_IBM_rasterpos_clip, 
GL_MESA_window_pos, GL_NV_texgen_reflection, GL_SGI_color_matrix, 
GL_SGI_color_table
glu version: 1.3
glu extensions:
GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess

Visual ID: 23  depth=16  class=TrueColor
bufferSize=16 level=0 renderType=rgba doubleBuffer=1 stereo=0
rgba: redSize=5 greenSize=6 blueSize=5 alphaSize=0
auxBuffers=0 depthSize=16 stencilSize=0
accum: redSize=0 greenSize=0 blueSize=0 alphaSize=0
multiSample=0  multiSampleBuffers=0
visualCaveat=None
Opaque.
Visual ID: 24  depth=16  class=TrueColor
bufferSize=16 level=0 renderType=rgba doubleBuffer=1 stereo=0
rgba: redSize=5 greenSize=6 blueSize=5 alphaSize=0
auxBuffers=0 depthSize=16 stencilSize=8
accum: redSize=0 greenSize=0 blueSize=0 alphaSize=0
multiSample=0  multiSampleBuffers=0
visualCaveat=Slow
Opaque.
Visual ID: 25  depth=16  class=TrueColor
bufferSize=16 level=0 renderType=rgba doubleBuffer=1 stereo=0
rgba: redSize=5 greenSize=6 blueSize=5 alphaSize=0
auxBuffers=0 depthSize=16 stencilSize=0
accum: redSize=16 greenSize=16 blueSize=16 alphaSize=0
multiSample=0  multiSampleBuffers=0
visualCaveat=Slow
Opaque.
Visual ID: 26  depth=16  class=TrueColor
bufferSize=16 level=0 renderType=rgba doubleBuffer=1 stereo=0
rgba: redSize=5 greenSize=6 blueSize=5 alphaSize=0
auxBuffers=0 depthSize=16 stencilSize=8
accum: redSize=16 greenSize=16 blueSize=16 alphaSize=0
multiSample=0  multiSampleBuffers=0
visualCaveat=Slow
Opaque.
Visual ID: 27  depth=16  class=DirectColor
bufferSize=16 level=0 renderType=rgba doubleBuffer=1 stereo=0
rgba: redSize=5 greenSize=6 blueSize=5 alphaSize=0
auxBuffers=0 depthSize=16 stencilSize=0
accum: redSize=0 greenSize=0 blueSize=0 alphaSize=0
multiSample=0  multiSampleBuffers=0
visualCaveat=None
Opaque.
Visual ID: 28  depth=16  class=DirectColor
bufferSize=16 level=0 renderType=rgba doubleBuffer=1 stereo=0
rgba: redSize=5 greenSize=6 blueSize=5 alphaSize=0
auxBuffers=0 depthSize=16 stencilSize=8
accum: redSize=0 greenSize=0 blueSize=0 alphaSize=0
multiSample=0  multiSampleBuffers=0
visualCaveat=Slow
Opaque.
Visual ID: 29  depth=16  class=DirectColor
bufferSize=16 level=0 renderType=rgba doubleBuffer=1 stereo=0
rgba: redSize=5 greenSize=6 blueSize=5 alphaSize=0
auxBuffers=0 depthSize=16 stencilSize=0
accum: redSize=16 greenSize=16 blueSize=16 alphaSize=0
multiSample=0  multiSampleBuffers=0
visualCaveat=Slow
Opaque.
Visual ID: 2a  depth=16  class=DirectColor
bufferSize=16 level=0 renderType=rgba doubleBuffer=1 stereo=0
rgba: redSize=5 greenSize=6 blueSize=5 alphaSize=0
auxBuffers=0 depthSize=16 stencilSize=8
accum: redSize=16 greenSize=16 blueSize=16 

Re: [Dri-devel] A few mach64 tests

2002-05-27 Thread Leif Delgass

Thanks for the report!  Concerning textures: the AGP texturing code is
kind of a proof-of-concept and isn't very efficient yet.  We need to work
on reducing the amount of texture swapping that is happening.  You can try
AGP 2x, use Option AgpMode 2 in the Device section of XF86Config.  
Also, I have some code to increase the max texture size exported, but
usually an app would refuse to run or use smaller textures if that's the
problem.  I should resurrect that bit of code.  Something you can try to
get a feel for what's happening with textures:

export this environment var:
LIBGL_PERFORMANCE_BOXES=1

You'll get some colored boxes and bars in the upper left corner of 
the GL window:

From left to right: 
- A red box means glFinish was called to wait for rendering to complete. 
- A short bar showing approx. ratio of AGP/local textures used for a frame 
(AGP - blue, local - purple) - based on number of textures bound to the 
texture units, not size. 
- A yellow box means texture(s) were swapped during the frame 
- Then a split bar for texture uploads, AGP and local (same colors as
above), based on size of the uploads. 
- On another row, a pink-ish bar for number of DMA buffers used.  Note 
that many buffers are sent partially filled, so this is only an 
approximation of the size of data.

I'm guessing that in most of the places where you see slowdowns, you'll
see lots of texture swapping (yellow box) and/or the texture upload bars
will be long (large texture uploads).  Sound problems could be related to
this and/or high CPU usage in wait loops?  If things get _very_ slow, it's 
possible that something is requiring software rendering, like GL_BLEND 
texture environment, but there isn't an easy way to test this, you'd have 
to look at the app's source or try changing app options.

The first priority is to eliminate lockups.  I haven't tried tuxkart, I'll 
have to check that out.  Do you see any messages in the system log?  Can 
you kill the app or kill X?

As for tuxracer, does it say anything about what it's looking for in the 
GLX visual that isn't supported?

On Tue, 28 May 2002, Bernard Cafarelli wrote:

 Well, here's my small contribution to the mach64 dev (sorry but I'm FAR
 away beyond you in programming, especially compared to people like
 Jose,Leif or Linus :)).

Well, I _definitely_ wouldn't put myself in the same class as Linus, but
thanks. :)  The biggest problem is the learning curve required to get
familiar with the DRI structure, but Jose's Developer FAQ is a great
starting point.
 
 So with mach64-0-0-4-branch checked out and compiled monday morning
 (french time), a Mobility M1 with 8Mo, athlon-4 900Mhz, running at
 1024x768:16 most of the time. To sum it up: nice work! Too bad the new
 Tuxracer won't work (I was planning to buy it). Maybe the big texture
 problem can be interesting to look up. Now more details and some facts:
 
 -lspci says: 01:00.0 VGA compatible controller: ATI Technologies Inc
 Rage Mobility P/M AGP 2x (rev 64) (prog-if 00 [VGA])
   Subsystem: Compaq Computer Corporation: Unknown device 005f
   Flags: bus master, stepping, medium devsel, latency 66, IRQ 9
   Memory at f500 (32-bit, non-prefetchable) [size=16M]
   I/O ports at 9000 [size=256]
   Memory at f410 (32-bit, non-prefetchable) [size=4K]
   Expansion ROM at unassigned [disabled] [size=128K]
   Capabilities: [50] AGP version 1.0
   Capabilities: [5c] Power Management version 1
 
 -glxinfo says:
 name of display: :0.0
 display: :0  screen: 0
 direct rendering: Yes
 server glx vendor string: SGI
 server glx version string: 1.2
 server glx extensions:
 GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context
 client glx vendor string: SGI
 client glx version string: 1.2
 client glx extensions:
 GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context
 GLX extensions:
 GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context
 OpenGL vendor string: Gareth Hughes
 OpenGL renderer string: Mesa DRI Mach64 20020227 [Rage Pro] AGP 1x x86/MMX/3DNow!
 OpenGL version string: 1.2 Mesa 4.0.2
 OpenGL extensions:
 GL_ARB_imaging, GL_ARB_multitexture, GL_ARB_transpose_matrix, 
 GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_minmax, 
 GL_EXT_blend_subtract, GL_EXT_clip_volume_hint, GL_EXT_convolution, 
 GL_EXT_compiled_vertex_array, GL_EXT_histogram, GL_EXT_packed_pixels, 
 GL_EXT_polygon_offset, GL_EXT_rescale_normal, GL_EXT_texture3D, 
 GL_EXT_texture_object, GL_EXT_vertex_array, GL_IBM_rasterpos_clip, 
 GL_MESA_window_pos, GL_NV_texgen_reflection, GL_SGI_color_matrix, 
 GL_SGI_color_table
 glu version: 1.3
 glu extensions:
 GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess
 
 Visual ID: 23  depth=16  class=TrueColor
 bufferSize=16 level=0 renderType=rgba doubleBuffer=1 stereo=0
 rgba: redSize=5 greenSize=6 blueSize=5 alphaSize=0
 auxBuffers=0 depthSize=16 stencilSize=0
 accum: