Re: [Dri-devel] mach64-0-0-3-branch multitexture fix
I just downloaded it and was getting good fps. Check ~/.ArmageTronrc and make sure the GL_RENDERER line says Mesa DRI Mach64 Maybe your SDL library isn't using the right libGL? Strange, I have different situation. Yes, armagatron does use the right opengl library. What is your card? What are your fps with/without DRI? Cheers, Sergey PING_CHARITY 0 MAX_IN_RATE 4 MAX_OUT_RATE 4 SERVER_NAME FINISH_TYPE 2 GAME_TYPE 1 AUTO_AIS 1 NUM_AIS 19 MOVIEPACK 1 ZTRICK 0 MOUSE_GRAB 0 WRAP_MENU 0 SPARKS 1 TEXTURES_HI 1 PREDICT_OBJECTS 1 LAG_O_METER 1 INFINITY_PLANE 0 SKY_WOBBLE 1 LOWER_SKY 1 UPPER_SKY 1 DITHER 1 HIGH_RIM 1 FLOOR_DETAIL 1 FLOOR_MIRROR 1 SHOW_FPS 1 TEXT_OUT 1 SMOOTH_SHADING 1 ALPHA_BLEND 0 PERSP_CORRECT 1 POLY_ANITALIAS -1 LINE_ANITALIAS 1 MESSAGE_OF_DAY_4 MESSAGE_OF_DAY_3 MESSAGE_OF_DAY_2 MESSAGE_OF_DAY_1 The server admin was too lazy to set a message of the day... ARMAGETRON_VERSION 0.1.4.9 GL_VENDOR Gareth Hughes GL_RENDERER Mesa DRI Mach64 20020227 [Rage Pro] x86/MMX/SSE GL_VERSION 1.2 Mesa 4.0.2 GL_EXTENSIONS GL_ARB_imaging GL_ARB_multitexture GL_ARB_texture_env_add 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_env_add 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 GL_SGIS_pixel_texture GL_SGIS_texture_edge_clamp TEXTURE_MODE_3 9984 TEXTURE_MODE_2 9984 TEXTURE_MODE_1 9728 TEXTURE_MODE_0 9728 COLOR_R_4 15 COLOR_G_4 15 COLOR_B_4 3 CAMWOBBLE_4 0 AUTO_INCAM_4 0 SPECTATOR_MODE_4 0 INSTANT_CHAT_STRING_4_1 LOL! INSTANT_CHAT_STRING_4_2 :-) INSTANT_CHAT_STRING_4_3 :-( INSTANT_CHAT_STRING_4_4 Well done! INSTANT_CHAT_STRING_4_5 Almost got you... INSTANT_CHAT_STRING_4_6 Hehe! INSTANT_CHAT_STRING_4_7 Got one! INSTANT_CHAT_STRING_4_8 INSTANT_CHAT_STRING_4_9 INSTANT_CHAT_STRING_4_10 INSTANT_CHAT_STRING_4_11 INSTANT_CHAT_STRING_4_12 ALLOW_CAM_4_0 1 ALLOW_CAM_4_1 1 ALLOW_CAM_4_2 1 ALLOW_CAM_4_3 1 ALLOW_CAM_4_4 1 START_FOV_4 90 START_CAM_4 3 CAMCENTER_4 1 PLAYER_4 Player 4 COLOR_R_3 3 COLOR_G_3 3 COLOR_B_3 15 CAMWOBBLE_3 0 AUTO_INCAM_3 0 SPECTATOR_MODE_3 0 INSTANT_CHAT_STRING_3_1 LOL! INSTANT_CHAT_STRING_3_2 :-) INSTANT_CHAT_STRING_3_3 :-( INSTANT_CHAT_STRING_3_4 Well done! INSTANT_CHAT_STRING_3_5 Almost got you... INSTANT_CHAT_STRING_3_6 Hehe! INSTANT_CHAT_STRING_3_7 Got one! INSTANT_CHAT_STRING_3_8 INSTANT_CHAT_STRING_3_9 INSTANT_CHAT_STRING_3_10 INSTANT_CHAT_STRING_3_11 INSTANT_CHAT_STRING_3_12 ALLOW_CAM_3_0 1 ALLOW_CAM_3_1 1 ALLOW_CAM_3_2 1 ALLOW_CAM_3_3 1 ALLOW_CAM_3_4 1 START_FOV_3 90 START_CAM_3 3 CAMCENTER_3 1 PLAYER_3 Player 3 COLOR_R_2 3 COLOR_G_2 15 COLOR_B_2 3 CAMWOBBLE_2 0 AUTO_INCAM_2 0 SPECTATOR_MODE_2 0 INSTANT_CHAT_STRING_2_1 LOL! INSTANT_CHAT_STRING_2_2 :-) INSTANT_CHAT_STRING_2_3 :-( INSTANT_CHAT_STRING_2_4 Well done! INSTANT_CHAT_STRING_2_5 Almost got you... INSTANT_CHAT_STRING_2_6 Hehe! INSTANT_CHAT_STRING_2_7 Got one! INSTANT_CHAT_STRING_2_8 INSTANT_CHAT_STRING_2_9 INSTANT_CHAT_STRING_2_10 INSTANT_CHAT_STRING_2_11 INSTANT_CHAT_STRING_2_12 ALLOW_CAM_2_0 1 ALLOW_CAM_2_1 1 ALLOW_CAM_2_2 1 ALLOW_CAM_2_3 1 ALLOW_CAM_2_4 1 START_FOV_2 90
[Dri-devel] phantom tux in tuxracer with mach64-0-0-3-branch
This is a bug which still hasn't disappeared with the latest updates. In the game the penguin flashes randomly as it slides downhill. He still drawn but just its bright, as a phantom. I've been trying to hunt this down but I still didn't had much success so far. Could someone tell me if this just happens with my card (although I found it strange since the memory shouldn't be a issue since the penguin seems to be drawn in solid color) or not? Another strange thing that happens sometimes is when I first run a OpenGL app the double buffering doesn't work properly, the image is not refreshed properly and things are drawn over the previous frame. When I run again this doesn't happen anymore. This seems that some state vars still aren't being updated properly. José Fonseca ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] phantom tux in tuxracer with mach64-0-0-3-branch
Hi Jose This is a bug which still hasn't disappeared with the latest updates. In the game the penguin flashes randomly as it slides downhill. He still drawn but just its bright, as a phantom. I've been trying to hunt this down but I still didn't had much success so far. Could someone tell me if this just happens with my card (although I found it strange since the memory shouldn't be a issue since the penguin seems to be drawn in solid color) or not? This happens to me, too. Most of the time I cannot see the penguin, but sometimes it is rendered correctly. So in principal the rendering seems to be o.k. An other issue are strange artefacts in Quake3 when you use the plasma gun. When you hit something with the plasma gun, the explosion of the plasma shots looks trange. I guess it should look different, I guess. And there is something whith UT, too. I normally start UT on a second X-server and often I get a schemtic pictures of my other xserver instead of the UT Intro. Sometimes I get the normal intro. If I switch from full screen to window mode and back, it is o.k. And there is also the issue of switching form X to a console and back. X crashes and I have to reboot, if I do that. But I guess this is a known issue and will be solved when the driver is merged with 2d, will it? I am using the latest mach64-0-0-3 branach on a Sony Vaio 212F which has an ATI Rage Mobility P/M. Continue your excellent work! Greetings, Michael ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Restoring DRM Library Device Independence
Alan Hourihane wrote: On Fri, Mar 15, 2002 at 08:38:20AM -0700, Jens Owen wrote: I would like to move the device dependent functionality currently included in the drm library back into the device driver layer. My objective is to make sure new driver suites can be independently released without stepping on any components needed by other driver suites. Currently, libdrm contains a mixture of device independent code and multiple device dependent routines. I'm looking for a clean way to split this functionality and restore libdrm device independent, while still providing a mechanism for device specific IOCTL style support directly in device drivers. Could we simply add a drmIOCTL entry point to the DRM library? Then, the packing and unpacking could be done in the drivers. The Linux and BSD implementations would simply wrap the standard IOCTL and future OS ports of the DRI would have a layer, if needed, for emulating an IOCTL. Jens, This is definately a problem that needs sorting out. We certainly need to put the driver specific calls into the 2D ddx portion, and abstract some form of drmIOCTL for the os-support routines. Please go ahead, and I'll certainly help out with this. Alan, Thanks for the feedback. I plan to proceed on this next week. Maybe you can verify it's portability on the BSD branch after I'm done. Regards, Jens -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] phantom tux in tuxracer
I'm using an older version of the mach64 code, but I also get this. Perhaps there's an issue with the Z buffer or such? I don't know a lot but that sounds probable if it's not being consistently drawn. Rage Mobility P/M here on a Toshiba Satellite 1750CDT. David Bronaugh ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] phantom tux in tuxracer with mach64-0-0-3-branch
On Fri, 22 Mar 2002, José Fonseca wrote: This is a bug which still hasn't disappeared with the latest updates. In the game the penguin flashes randomly as it slides downhill. He still drawn but just its bright, as a phantom. I've been trying to hunt this down but I still didn't had much success so far. Could someone tell me if this just happens with my card (although I found it strange since the memory shouldn't be a issue since the penguin seems to be drawn in solid color) or not? Yes, I have this problem too, but haven't tracked it down yet. I get a similar flicker in gltron with alpha blending, but without the phantom/transparent effect. Another strange thing that happens sometimes is when I first run a OpenGL app the double buffering doesn't work properly, the image is not refreshed properly and things are drawn over the previous frame. When I run again this doesn't happen anymore. This seems that some state vars still aren't being updated properly. I haven't seen this I don't think, but I have seen problems with single-buffering. Bits of old textures/framebuffer appear when running texenv without '-db', for example. I've seen a new problem recently too, in an app I'm working on. I have a rotating surface. When alpha blending is on, if I toggle texturing from enabled to disabled, sometimes the surface disappears, but only when it is on the far half of the rotation cycle. José Fonseca ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel -- Leif Delgass http://www.retinalburn.net ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon AGP?
On Wed, Mar 20, 2002 at 11:27:39PM +, Michael wrote: On Wed, Mar 20, 2002 at 01:51:06PM -0800, Ian Romanick wrote: Michael also implemented agp support for radeon with a similar simplistic strategy, but ran into some issues looking at tcl and/or mesa-4-0. I think these turned out to be artefacts rather than anything serious. In any case I think he decided to wait on some forthcoming reorganization of the texture management code in all the drivers... (nudge nudge, wink wink) Heh...which is actually why I was asking. :) There are a number of code paths in my code that I can't test on the Radeon (one of my two development platforms) without AGP texturing. That's confusing, since 'AGP' is really already there, it's not enabled as such, you just allocate from the RADEON_AGP_HEAP instead of the RADEON_CARD_HEAP. (Confusing because if your code replaces the mm in the radeon driver, you'll be writing the code you're asking to be committed?) The fix for current code (in all trunks afaiaa) is that RADEON_AGP_TEX_OFFSET is 0x0200 and it should be 0x0400 (at least on my radeon - I don't know what that does to 64mb radeons, 7500's, mobilities etc? - the 0x0200 figure is left over from the r128 by the looks of it, so perhaps it is a constant?) Beyond that, there's no magic that I found that needs to be done, so you can ignore the 'fixup agp texture offset' that's in the #if 0 part of radeon_texmem, you just add the mmAlloc offset to the heap offset in the same way card local textures are done. This is the part that needs fixing. Looking back at the mailing list archives, if the code that's '#if 0'ed out is re-enabled, the driver will happily allocate AGP memory and explode. Since this is device-dependent, it doesn't really fall directly into the work that I'm doing now (see below). In any case, I'll find the patch and take a look at it. I mainly wanted to make sure that the version sent out to the list is the latest version. The patch is in the archives of this list so you could grab that (next to nothing has changed in this area in TCL) I can probably dig it up if you can't find it. That said, I've been implementing utah-glx swapping c/w AGP texturing in a way that only the overrun goes into AGP even as these messages arrived. It sounds like you are doing much the same...which is a waste of one of our efforts - are you saying that IBM are letting you release your code now? There was quite a bit if discussion about this at the 3/18 IRC meeting, but I'll recap. I do not have permission to release any code /yet/. We are still going through our internal process to get approval from legal to make source code contributions to the DRI project. That said, I personally believe that it is only a matter of time until this approval is given. I have been working for some weeks on this project, but I have been very quite about what I'm doing. The main reason for my silence is to avoid when can we see your code? type questions, because I would not have any answers. I have been working to factor out the /existing/ texture management code from the existing drivers. I've been using the MGA and Radeon drivers as my proof-of-concept cases. Once that is done, ANYONE can easilly experiment with different texture memory management schemes. -- Tell that to the Marines! ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] MGA filtering question
I don't have the G400 documentation, so I can't just look this up. I'm just
curious, what are TF_{min,mag}filter_cnst supposed to do? I modified the
driver to use them just to see what they did, and it's not exactly clear
what they do! It looks like it just makes the hardware to an unweighted
average between the two (four?) nearest texels...
If that's the case, then is it just a hold over from older Matrox hardware
that couldn't do linear filtering? G100, perhaps?
Just curious...
--
Tell that to the Marines!
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon AGP?
On Fri, Mar 22, 2002 at 02:01:53PM -0800, Ian Romanick wrote: That said, I personally believe that it is only a matter of time until this approval is given. I have been working for some weeks on this project, but I have been very quite about what I'm doing. The main reason for my silence is to avoid when can we see your code? type questions, because I would not have any answers. From where I sit, 'Texture management' is something which starts in Mesa and goes through to the kernel. Personally I'm more interested in what you aren't doing, in that respect, keep what you are doing to yourself by all means :o) I have been working to factor out the /existing/ texture management code from the existing drivers. I've been using the MGA and Radeon drivers as my proof-of-concept cases. Once that is done, ANYONE can easilly experiment with different texture memory management schemes. There just aren't that many schemes Ian, IMHO. x mb of card space, n mb of textures this frame. x n - don't do anything. x n - buy a bigger card, use the slider in the app, use AGP or swap (n-x)mb of textures this frame. Roughly in order of quality/performance. Which textures? NP complete I bet. You have a good general case for most games where MRU probably gets as close to the optimum (n-x), LRU tends to hit n mb and that's probably all that is wrong with the current driver(s). For the non-general case, you're better off being the application. That does miss out a lot of improvements we could do, but it's difficult to surmise whether you are looking at those or not. (Not that I want to sound negative, I look forward to being proved wrong :)) -- Michael. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] phantom tux in tuxracer
First, I would like to thank you all for your replies. On 2002.03.22 19:08 David Bronaugh wrote: I'm using an older version of the mach64 code, but I also get this. Perhaps there's an issue with the Z buffer or such? I don't know a lot but that sounds probable if it's not being consistently drawn. That would be my first guess too if the penguin disapeared completely. Since its bright is still drawn, this means that the Z tests are being done properly. It's the fragment color which aren't being calculated properly. There are several eventual causes that I can think of: - missing/bad update in the alpha blending - missing/bad update in the texture environments - bad color/alpha in the vertex buffer setup (less likely) - missing/bad update in the multitexturing (almost impossible since LIBGL_NO_MULTITEXTURE makes no effect) Rage Mobility P/M here on a Toshiba Satellite 1750CDT. David Bronaugh Unfortunately the tuxracer source code isn't of much help, since the tux geometry is created by an embebed tcl interpreter from a script, so it's not obvious the what's the state when it's being drawn. José Fonseca ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
