I fixed the pitch in savagespan today. my assumption was right. see more below.
Alex --- Felix Kühling <[EMAIL PROTECTED]> wrote: > Alex, > > honestly I don't understand much of what you were writing about > tiling > registers, PBDs, GBDs and so on. I don't have much experience with > low > level aspects of graphics engines. The last one I programmed on the > register level was an original VGA under DOS many years ago. ;-) I'm > a > bit confused that 2D and 3D engines can have different notions of > tiling > of video memory without one of them showing corrupt output. They are > both rendering to the same frame buffer memory, aren't they? Could > you > give me some basic explanation of how this works and maybe clear up > some > fundamental misunderstandings (as far as my statements reveal them)? I can't say I'm an expert either. my understanding is that there is a framebuffer (I think in linear format) and it is accessed by 3 bitmap descriptors (global, primary, and secondary - 0x816c-0x817f). each bitmap descriptor (BD) has 2 32 bit halfs: a low and a high part. The low part is the offset of the start of the framebuffer, the high part defines the descriptor: bpp, stride, BCI enabled, size, linear/tile format, etc. (incidently, the bitfields of the BDs and tiling regs seem to have changed between families, hence my recent fixes). right now 2D uses the global BD and 3D uses the primary BD. All 2D and 3D drawing commands need to go through a BD to get to the framebuffer. they need to specify a BD as a destination. Stuff can get to the framebuffer either linearly or tiled depending on the setup of the BD. The hardware must translate whatever format comes into the BDs to the proper format in the framebuffer for display on your monitor. Hence you can mix linear and tiled. If you use a tiled format you also need to set up a tiled surface register (0x48C40-0x48C50). this may be what does the translation from tiled to framebuffer happens since linear just works, thus the final framebuffer is probably linear. I'm not entirely sure as of yet how the tiled surface regs are associated with a particular BD. Maybe it doesn't matter. I dunno. For tiled surface regs you need to specify the framebuffer offset, bpp, tiled width, etc. The tiled surface regs have to be set up to match the tile format, etc. from the tiled BD that is using it. I think tiled surface regs are also used for textures, but I'm not sure how that works yet. if you look in savage_dri.c tiled surface 0 is used for front buffer, 1 for back, and 2 for depth: OUTREG(0x48C40, value|(pSAVAGEDRI->frontOffset >> 5) ); /* front */ OUTREG(0x48C44, value|(pSAVAGEDRI->backOffset >> 5) ); /* back */ OUTREG(0x48C48, value|(pSAVAGEDRI->depthOffset >> 5) ); /* depth */ > > More comments inline ... > > On Wed, 14 Jan 2004 08:06:24 -0800 (PST) > Alex Deucher <[EMAIL PROTECTED]> wrote: > > > Felix, > > > > Last night I did some thinging about the pitch and linear vs. > tiled > > mode. To be honest, I don't think it matters. 2D uses the GBD and > can > > be tiled or linear. 3D uses the PBD and has to be tiled. Since > they > > are using different BDs, it shouldn't matter whether 2D is tiled or > > not. for savagespan, we should use the tiled pitch whether or not > 2D > > is tiled because they are writing to different BDs. I think the > reason > > linear provides a small speed boost is because in linear mode, 2D > does > > not require the use of a tiling reg. that frees tiling reg 0 > > completely for use by the 3D engine whereas before it had to share > it > > with the 2D side. one thing I'm not clear on is the pitch in > > savagespan. that's for sw fallbacks right? are swfallbacks > handled by > > the 2D driver? should the destination for those be the GBD (2D) or > the > > They are handled by the 3D driver. That's when it needs the span > functions. I havn't looked into the details, but I think the 3D > driver > needs to flush all drawing operations and wait for the 3D engine to > go > idle. Then it can directly access the frame buffer through the span > functions. in that case they would need to go through the PBD. > > > PBD (3D)? that would determine which pitch we need. I presume the > PBD > > since that is the destination for other 3D stuff (also in > savage_dri.c > > the XAA fucntions in there write to the PBD rather than the GBD as > the > > regular 2D accel functions do) and 2D accel can write to either BD > you > > just have to set the destination right. > > > > The utah driver used Tim's 2D driver which used linear mode for 2D. > it > > just calcuated it's pitch based on the PBD in the 3D driver. > perhaps > > if we add a new item, psav->ul3DAperturePitch and calculate it the > way > > ulAperturePitch is for tiled mode whether or not we are using tiled > for > > 2D it should work and pitch shold be right whether or not 2D is > tiled. > > Hmm, I think psav->ulAperturePitch isn't used in the 2D driver. It's > only use is when it is passed to the 3D driver in > SAVAGEDRIScreenInit. > It is used by the 2D driver if you are using tiling for 2D. 3D always needs it. > > > > Does this make sense? > > Probably, I just can't grasp all of it yet. ;-) > > > > > Alex > > > [snip] > > ------------ __\|/__ ___ ___ > ------------------------- > 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
