Michael Schlueter wrote: > 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?
The DRI User Guide (on the website) has some information about what's done in hardware vs. software for most drivers, but it's not deeply detailed. If you need high-performance GL_LINE or GL_POINT-mode polygons, you're often better-off writing your own rendering loop using glBegin(GL_POINTS or GL_LINES) instead of glPolygonMode. > 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 :) I don't think anyone's actively working on it. -Brian ------------------------------------------------------- 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
