Re: [Dri-devel] Savage4 update

[Alex D. <ag...@ya...>]

--- Felix Kühling <fx...@gm...> 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 <ag...@ya...> wrote:
> 
> > 
> > --- Felix K_hling <fx...@gm...> wrote:
> > > On Mon, 12 Jan 2004 18:17:15 -0800 (PST)
> > > Alex Deucher <ag...@ya...> 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
>  fx...@gm...       \___/   \___/   U        at the same time.


__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus