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 problem seems to be related with "catching" the mouse. I'll
check with the new version (I have the previous version for now).
> 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)
--
Bernard Cafarelli
aka Voyageur
ICQ:66024647
00000000.mimetmp
Description: PGP signature
msg04884/pgp00000.pgp
Description: PGP signature
