--- Felix Kühling <[EMAIL PROTECTED]> wrote: > 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.
Cool. no worries :) > > 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. > I'll take a look at the texture code as well. It's hard (for me at least) to translate what's going on in the 3D driver with what's being sent to the hardware. I guess I'm just used to OUTREG(reg, val) so the whole bci thing is a little hard to follow. it could be that there are places in the 3D driver where the tiling and bitmap regs are re-written and filled in the wrong way like they were in savage_dri.c in the 2D driver. On that note, I fixed up the 2D driver to hopefully set up the tiling regs and bitmap regs correctly for all chipsets. I sent a more detailed email earlier, but my message seems to have been blocked by the dri-devel moderator (in fact all of mine are being blocked at the moment, not sure why). I also enabled 3D on most chips to facilitate testing. > > > > > > > > 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. > Thanks Felix, this helps alot. Alex > Regards, > Felix > > ------------ __\|/__ ___ ___ > ------------------------- > Felix ___\_e -_/___/ __\___/ __\_____ You can do anything, > Kühling (_____\Ä/____/ /_____/ /________) just not everything > [EMAIL PROTECTED] \___/ \___/ U at the same time. __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus ------------------------------------------------------- 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
