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

Reply via email to