Am Don, 2002-06-27 um 00.43 schrieb Brian Paul: > >>Most of the DRI drivers have a per-context field called 'Fallback'. > >>It's a bitmask which records various reasons why we need to fallback > >>to software rendering. In the case of the mga (G400) driver you'll > >>see these flags in mgacontext.h: > >> > >>#define MGA_FALLBACK_TEXTURE 0x1 > >>#define MGA_FALLBACK_DRAW_BUFFER 0x2 > >>#define MGA_FALLBACK_READ_BUFFER 0x4 > >>#define MGA_FALLBACK_LOGICOP 0x8 > >>#define MGA_FALLBACK_RENDERMODE 0x10 > >>#define MGA_FALLBACK_STENCIL 0x20 > >>#define MGA_FALLBACK_DEPTH 0x40 > >> > >>If you search the code, you'll find where we set these flags by > >>calling mgaFallback() (via the FALLBACK() macro). You could put > >>a printf in there to print the bit value and get an idea of what's > >>slowing you down. > > > > > > Ok, I did a printf there and switch MGA_DEBUG on. Now I need a bit help > > with the analyse of the output... > > > > mgaFallback: bit:1 mode:0 > > > > Looks like this is a call from mgaUpdateTextureState. Since mode is 0 > > the fallback flag is unset? > > > > FLUSH_BATCH in mgaReadDepthPixels_16 > > FLUSH_BATCH in mgaWriteDepthPixels_16 > > FLUSH_BATCH in mgaWriteRGBAPixels_565 > > FLUSH_BATCH in mgaDDBindTexture > > FLUSH_BATCH in mgaDDUpdateHwState > > FLUSH_BATCH in mgaFallback > > FALLBACK: GL_DECAL RGBA texture, unit=0 > > FLUSH_BATCH in mgaReadDepthPixels_16 > > FLUSH_BATCH in mgaWriteDepthPixels_16 > > FLUSH_BATCH in mgaWriteRGBAPixels_565 > > > > This looks more interesting to me. Is there a problem with RGBA > > textures? > > Without looking at the code, my guess is that the GL_DECAL env mode > with an RGBA texture probably isn't implemented in hardware. Hardware > from that era often had limitations that prevented some combinations > of texture env modes and texture formats from being done in hardware. > > If you look at the mga code you'll probably find a comment and more > info. Yes, I found that comment. So I switched off the one GL_DECAL instuction in the program source code and started it again... No speed improvements.
The debug messages showed that there is no total rasterization fallback. So I switch on more debug messages and found out, that _swrast_Triangle is used quite often. And that is the case if (DD_TRI_SMOOTH || DD_TRI_UNFILLED) is set. Disabling all "glEnable(GL_*_SMOOTH)", glShadeModel (GL_FLAT) and made glPolygonMode to use always GL_FILL for front and back brought a big speed improvement (but much slower than the nvidia card). Is there a detailed list of GL commands that results in software rendering (total or only for that command) available? In http://www.xfree86.org/4.2.0/DRI10.html#35 is a refer to files in lib/GL/mesa/src/drv/mga/DOCS but I couldn't find them. Have they moved to another place? And a last question. Is anybody working on the mga driver? I found a few FIXME comments :) Bye, Michael ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek No, I will not fix your computer. http://thinkgeek.com/sf _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
