Re: [Dri-devel] mach64 blend
On Tue, Feb 04, 2003 at 09:51:30PM -0500, Leif Delgass wrote: On Wed, 5 Feb 2003, Arkadi Shishlov wrote: What do you mean by aren't fully compliant? Final A = Fragment A or Final A = Texture A? It looks like Fragment A.. Yes, I think that's right. As an example, there's a texture in the first UT map (can't remember the name offhand) that uses an RGBA vine texture with MODULATE. It looks it's applied to an opaque quad, since the transparent part of the texture shows up as black. Now I think it is texture alpha. Quite pointless to have RGBA texture without ability to use it alpha channel. http://idea.hosting.lv/a/tmp/quakeforge-mach64-blend.jpg It is GL_MODULATE, no lighting, GL_RGBA texture, glBlend(alpha, one_minus_alpha). Looking at screenshot the first that come in mind - mach64 doesn't do linear filtering for magnification. arkadi. --- 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
Re: [Dri-devel] mach64 blend
On Thu, 6 Feb 2003 00:44:12 +0200 Arkadi Shishlov [EMAIL PROTECTED] wrote: Now I think it is texture alpha. Quite pointless to have RGBA texture without ability to use it alpha channel. http://idea.hosting.lv/a/tmp/quakeforge-mach64-blend.jpg Hows Quakeforge comming, btw - it'd be nice to play it on my Radeon 9000. fun game. --- 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
Re: [Dri-devel] mach64 blend
On Tue, Jan 28, 2003 at 11:01:53PM -0500, Leif Delgass wrote: On Wed, 29 Jan 2003, Arkadi Shishlov wrote: - '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 What do you mean by aren't fully compliant? Final A = Fragment A or Final A = Texture A? It looks like Fragment A.. arkadi. --- 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
Re: [Dri-devel] mach64 blend
On Wed, 5 Feb 2003, Arkadi Shishlov wrote: On Tue, Jan 28, 2003 at 11:01:53PM -0500, Leif Delgass wrote: On Wed, 29 Jan 2003, Arkadi Shishlov wrote: - '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 What do you mean by aren't fully compliant? Final A = Fragment A or Final A = Texture A? It looks like Fragment A.. Yes, I think that's right. As an example, there's a texture in the first UT map (can't remember the name offhand) that uses an RGBA vine texture with MODULATE. It looks it's applied to an opaque quad, since the transparent part of the texture shows up as black. -- 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
Re: [Dri-devel] mach64 blend
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_REPLACEGL_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_REPLACEGL_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
