On Wed, 29 Jan 2003, Arkadi Shishlov wrote: > Hi. > I'm working on QuakeForge engine, and some things related to transparency > (player damage blood) and 'dynamic lighting' (grenade explosion) are very > slow. Quake3 runs faster in mean time.
Quake3 has some "hacks" built in to work around the mach64's limitations. I think it looks for "Rage Pro" in the Renderer string to enable them. > I want to investigate problem further on Quake side, but I want to be sure > I understood mach64 limitation correctly from what I've read at > http://www.retinalburn.net/linux/dri_status.html > - glEnable(GL_FOG) and glEnable(GL_BLEND) cannot be enabled at the same time. Correct. Enabling fog when blending is enabled will have no effect (there's no software fallback). Enabling blending when fog is enabled will disable fog. So fog should not cause any slowdowns as a result of falling back to software. > - 'Texture environment modes: GL_BLEND is done in software..' - mean > glTexEnv(GL_BLEND) is software. GL_DECAL is hw accelerated. > GL_MODULATE with GL_LUMINANCE_ALPHA is software. Right. GL_BLEND texture environment is not possible on mach64. Also, the card can't modulate alpha values when texturing, so texture environments where Final A = A fragment * A texture aren't fully compliant, e.g. GL_MODULATE with GL_RGBA textures. The case of GL_MODULATE/GL_RGBA is not done as a fallback since it's very common. Hardware accelerated: -------------------- environment texture base format GL_DECAL any valid format - GL_RGB, GL_RGBA GL_REPLACE GL_LUMINANCE, GL_RGB, GL_RGBA GL_MODULATE GL_LUMINANCE, GL_RGB, GL_RGBA(not fully compliant) Software fallbacks: ------------------ environment texture base format GL_BLEND any GL_REPLACE GL_ALPHA, GL_LUMINANCE_ALPHA, GL_INTENSITY GL_MODULATE GL_ALPHA, GL_LUMINANCE_ALPHA, GL_INTENSITY And of course anything more recent than these core environments isn't supported, e.g ADD, COMBINE, etc. > cvs co -r mach64-0-0-5-branch xc/xc/lib/GL/mesa/src/drv/mach64 > are the right files to investigate for additional limitations? Yes. Look at mach64UpdateTextureEnv in mach64_texstate.c for the above and mach64_state.c for fog, blending and other state. > BTW, when particular operation is implemented in software but require some > on-screen content, driver copy already rendered chunk from framebuffer, pass > it to Mesa, then copy back? To be honest, I don't know the gory details of the Mesa software rasterizer yet, but any primitives needing a texture application that can't be done in hardware would be completely software rendered and written to the framebuffer, I think. -- Leif Delgass http://www.retinalburn.net ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel