--- Felix Kühling <[EMAIL PROTECTED]> wrote: > 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.
Format (tiled/linear) is specified in the BDs. tiling regs are only used with tiled BDs. I'm not sure how a tiling reg is associated with a BD, I suspect you just have to match the framebuffer offsets. The tiling regs deal with the conversion between tiled mode and the linear mode of the framebuffer. > 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? I'm not 100% sure. that's just my understand from hacking on it. It doesn't matter who uses which BD (I think...although looking at the source, 2D might have to use the GBD). I'm guessing 3D uses the PBD because in savage_dri.c:SavageSelectBuffer() the front/back/depth buffers get written to the PBD(0x8170-0x8174). that still leaves the SBD which as far as I can see is unused. I think in theory anyone (2D, 3D, CPU) can write to any BD it as long as it is selected as the destination of that operation. you can even set one BD as a source and another as a destination I think. Perhaps Tim can clarify this. Alex > > /Felix > > On Wed, 14 Jan 2004 14:39:41 -0800 (PST) > Alex Deucher <[EMAIL PROTECTED]> wrote: > > > I fixed the pitch in savagespan today. my assumption was right. > see > > more below. > > > > Alex > > > > --- Felix K_hling <[EMAIL PROTECTED]> wrote: > [snip] > > > > 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 > > > ------------ __\|/__ ___ ___ > ------------------------- > 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 ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
