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 f5000000 (32-bit, non-prefetchable) [size=16M] > I/O ports at 9000 [size=256] > Memory at f4100000 (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 alphaSize=0 > multiSample=0 multiSampleBuffers=0 > visualCaveat=Slow > Opaque. > > -glxgears: as fast (ok ok a little faster in fact) than softMesa > 1386 frames in 5.0 seconds = 277.200 FPS > 1421 frames in 5.0 seconds = 284.200 FPS > 1403 frames in 5.0 seconds = 280.600 FPS > 1365 frames in 5.0 seconds = 273.000 FPS > 1347 frames in 5.0 seconds = 269.400 FPS > > -other mesa demos: no problem (for those that can run ie mesa function > supported by mach64) > > - openuniverse: on average 36-40 frames/sec, drops to ~23fps near big > planets (mars,...) except earth (hi res+clouds...) where it drops to 0.2 > and almost hangs. Textures too big maybe? > > - celestia (1.2.0, 1.2.4 won't compile): no fps but quite smooth with > most planets, but getting close to Earth will just hang the program > (again textures too big?) Also it reports: Simultaneous textures > supported: 2 at start > > -gltron: all options on (including trilinear filtering) > 640x480: average fps between 20 and 35, lowest fps 15 > 800x600: average fps around 20, lowest 12 (and very playable) > 1024x768: sound not 'smooth' anymore, average fps 12, lowest 6 > something strange (at least for me): if I switch to a 4-views screen (1 > per player) the sound is smooth again (of course the fps won't improve). > > -doom legacy (opengl mode): I had forgotten about this one, but the > behaviour is strange. Everything runs smooth (where did they hide the > fps counter?) but when getting into new rooms, it will go really slow > for a few seconds, and then run fast again (even with many things to > draw in the room) > > -glean: sorry wasn't able to compile it > > -tuxkart: smooth when it works but still hangs after a few seconds > > -Cannonsmash: no problems in fullscreen normal details, but there's much > echo in the sound > > -BZFlag: no problems, quite fast (but simple graphics...) > > -Terminus: quite nice, even with many graphic options > > -Xscreensaver-gl: all very smooth, including the more complex molecule viewers > > - Tuxracer opensource (0.6): no problem, still a little slower than with > utah-glx drivers. Around 10fps, sound not smooth sometimes. > > - Tuxracer-demo (1.1) won't launch: > %%% 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) > and then back to the shell. Strange definition of Success isn't it? > > -- > Hope this helps, > Bernard Cafarelli > aka Voyageur > ICQ:66024647 > > -- Leif Delgass http://www.retinalburn.net _______________________________________________________________ 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
