From: Felix <fx...@gm...> - 2004-01-15 19:26:08
|
Thanks for your explanation. I think I'm beginning to understand. To get this straight, access to the frame buffer by the 2D engine, 3D engine and the CPU all go through bitmap descriptors which can translated from/to tiled/linear adresses. The format is somehow specified by the tiled surface registers. Now 2D goes through GBD and 3D through PBD. Which BD is responsible for CPU access? Your earlier questions seemed to indicate that it depends on whether the 2D or the 3D driver is accessing it. How is that possible? /Felix On Wed, 14 Jan 2004 14:39:41 -0800 (PST) Alex Deucher <ag...@ya...> wrote: > I fixed the pitch in savagespan today. my assumption was right. see > more below. >=20 > Alex >=20 > --- Felix K_hling <fx...@gm...> wrote: [snip] >=20 > 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: >=20 > OUTREG(0x48C40, value|(pSAVAGEDRI->frontOffset >> 5) ); /* front */=20 > OUTREG(0x48C44, value|(pSAVAGEDRI->backOffset >> 5) ); /* back */ > OUTREG(0x48C48, value|(pSAVAGEDRI->depthOffset >> 5) ); /* depth */ >=20 >=20 > >=20 > > More comments inline ... > >=20 > > On Wed, 14 Jan 2004 08:06:24 -0800 (PST) > > Alex Deucher <ag...@ya...> wrote: > >=20 > > > Felix, > > >=20 > > > 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 > >=20 > > 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. >=20 > in that case they would need to go through the PBD. >=20 > >=20 > > > 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. > > >=20 > > > 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.=20 > > 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. > >=20 > > 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. > >=20 >=20 > It is used by the 2D driver if you are using tiling for 2D. 3D always > needs it. >=20 > > >=20 > > > Does this make sense? > >=20 > > Probably, I just can't grasp all of it yet. ;-) > >=20 > > >=20 > > > Alex > > >=20 > > [snip] > >=20 > > ------------ __\|/__ ___ ___ =20 > > ------------------------- > > Felix ___\_e -_/___/ __\___/ __\_____ You can do anything, > > K_hling (_____\_/____/ /_____/ /________) just not everything > > fx...@gm... \___/ \___/ U at the same time. >=20 >=20 > __________________________________ > Do you Yahoo!? > Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes > http://hotjobs.sweepstakes.yahoo.com/signingbonus ------------ __\|/__ ___ ___ ------------------------- Felix ___\_e -_/___/ __\___/ __\_____ You can do anything, K=FChling (_____\=C4/____/ /_____/ /________) just not everything fx...@gm... \___/ \___/ U at the same time. |