Hi Alex, I just got your cards. :) I'll try to get a Savage branch up and running on my home computer as soon as possible. It may take until the weekend, though. I'm pretty busy.
Some more comments inline ... On Tue, 13 Jan 2004 09:58:48 -0800 (PST) Alex Deucher <[EMAIL PROTECTED]> wrote: > > --- Felix K_hling <[EMAIL PROTECTED]> wrote: > > On Mon, 12 Jan 2004 18:17:15 -0800 (PST) > > Alex Deucher <[EMAIL PROTECTED]> wrote: > > > > > I just fixed 3D at 32 bpp on savage4 and commited the changes. It > > > ended up being a define with the wrong bits set. I get between 280 > > and > > > 300 fps in glxgears on savage4 at 32 bpp and around 600 at 16 bpp. > > > textures still aren't quite right on savage4. I suspect textures > > need > > > to be setup slightly differently due to the differences in the > > bitmap > > > descriptors between architectures. or perhaps the tiling regs... > > > > Whoops, forgot to mention I rewrote the mode and setup function specifc > for savage4 because nether the m7 one nor the twister one was quite > right. I think architecture-wise the savage4 is in between. > > > I see some texture problems too, but they don't show up in all > > applications. It looks like some low resolution mipmap levels are > > broken. Is this what you're seeing too? > > What I'm seeing is what looks like alternate parts of the texture > shifted either too high or too low. the texture should look like this: > > 1111111111 > 2222222222 > 3333333333 > > but instead looks like this: > > 1 1 1 1 1 > 1212121212 > 2323232323 > 3 3 3 3 3 > > for things like the fish and trees in tuxracer. The ground and ice and > tux look ok. Chromium BSU looks similar, but shifted parts are much > narrower (bigger textures perhaps). I just installed tuxracer. On my Prosavage textures look ok. Looking at savagetex.c the texture memory seems to be tiled. Maybe the code in there is too specific for ProSavage and needs some tweaking for older chips. I'll look into this when I have the Savage4 card and driver working. > > > > > If you want to play a bit more with the Savage IX, the Utah driver > > submits the last vertex of triangles twice. Maybe this is needed to > > get > > any output on these chips. > > I think the older cards need some changes in how the tiling registers > are set up in savage_dri.c as well. the stride is calculated > differently on the older savages (at least according to the 2D driver). > > Also I'm not real familiar with the 3D side, I think something like > this would be good on the DRI wiki as well. what does each of these > files do? I have a good idea on most, but others...not so much. Plus > how they all fit together. if someone can help me fill it in (and > provide better descriptions) I'll post it on dri wiki. I'm going to take care of the 3D side but documenting this may be a good idea anyway. Most of this is true for several other drivers. > > savage_3d_reg.h - 3D register and macro defines Maybe we should summarize savage_3d_reg.h and savage_bci.h in one header file with hardware-specific definitions. > savagedma.h, savagedma.c - DMA stuff This could move to savageioctl.[ch] at some point. > savagetex.h, savagetex.c - textures > savage_xmesa.c - coordination with 2d? More or less. These deal with screen and context management. The name is historical. There used to be a number of callbacks whose names started with XMesa. They were called directly by Mesa. The interface has changed in Mesa 4.0. Now there is an API record that specifies these driver entry points. In some drivers (radeon, r200, r128) these functions are in <driver>_screen.[ch] and <driver>_context.[ch]. > savage_bci.h - bci related defines and macros > savagespan.h, savagespan.c Access to spans of the frame buffer, used for software rasterization fallbacks. > savagecontext.h - 3D context handling Only the data structures, the code lives in savage_xmesa.c. > savage_init.h - card setup Don't know where this name comes from. It's quite a mix. It defines a few data structures (savageScreenPrivage and savageRegion). It defines macros for locking and unlocking, and a few prototypes of functions in different .c-files. > savagetris.h, savagetris.c - triangle setup? More than just triangles. It draws all primitives using some templates in mesa/tnl_dd. All primitives are mapped to the ones supported directly by the hardware. At the highest level whole Mesa vertex buffers are rendered. It is not the most efficient way of rendering because all strips and fans are decomposed into individual triangles. So lots of duplicte vertices are emitted to the hardware. At some point we may implement our own render stage that takes advantages of hardware strips and fans. r128 and mga used to have *_fastpath.[ch] files in Mesa 3 that did just that. So did the savage driver. These were not ported to Mesa 4 in any of these drivers. Maybe it's not such a big performance win in practice. > savagestate.h, savagestate.c - managing the 3D state in hardware > savagedd.h, savagedd.c - ? Some selection of device driver functions. I don't know why they are collected in this file. Maybe a historical leftover. The radeon drivers don't have it anymore. It's pretty short in the other drivers I looked at. > savageioctl.h, savageioctl.c - ioctls for use with the DRM That's true for most drivers, but not the savage one. ATM the hardware is accessed directly from the Mesa driver through memory mappings and the BCI. If covers things like emitting hardware state, flushing, buffer swapping and clearing. > savagevb.h, savagevb.c - ? Vertex setup. Determines which components are needed for the current state and generates appropriate hardware vertices from Mesa vertices. For the D3D-like vertex formats there are templates in mesa/tnl_dd. Regards, Felix ------------ __\|/__ ___ ___ ------------------------- Felix ___\_e -_/___/ __\___/ __\_____ You can do anything, Kühling (_____\Ä/____/ /_____/ /________) just not everything [EMAIL PROTECTED] \___/ \___/ U at the same time. ------------------------------------------------------- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
