On 10/23/06, Phillip Ezolt <[EMAIL PROTECTED]> wrote: > Alex, > > > The radeon driver doesn't really mess with the memory controller > > registers. It relies on the bios/chip defaults. I'm not even sure > > messing with the MC stuff on the XPRESS chips will help. We're just > > guessing here. > > Ok. Well, I might run into a problem later on using the BIOS settings, but > I should be good for now. > > The latest and greatest ATI fglrx (8.29.6) drivers will just hang when using > I use them on my laptop. I emailed ATI about this, and they said that it is > an HP problem. (Thanks, ATI.) > > However, I do have the an older version of the driver ( 8.24.X) which does > work WITH DRI. So, even if the support isn't perfect, if I can get the > opensource drivers to work AT LEAST as well the 8.24.X drivers, I'll be very > happy. > > > > > No one with databooks has added them to the driver yet. It looks like > > fglrx always bumps up the display priority in > > R300_MC_INIT_MISC_LAT_TIMER. We do the same thing, but > only if you > > specify displaypriority "high". see RADEONInitDispBandwidth(). > > Perhaps we should alway bump teh priority in teh open driver as well. > > Also the AGP stuff is not set up the same since by default the DRI is > > not enabled on XPRESS chips. Plus I think they are PCIE based anyway. > > If you want to test the opensource 3D driver, you'll have to enable it > > in the DDX (xf86-video-ati) and remove the checks from the 3D driver > > (r300 in mesa) that keep it from loading on XPRESS hardware. > > Ok. I'm going to try to get the latest Xserver/Mesa/DRM thing built and > running. I'm probably be heads down a little bit trying to get all of the > pieces compiled and running. There's plenty of guides on the net, so I > should be fine. > > (I've used jhbuild to check out X server, DRM, Mesa. For some reason it > didn't check out and build the ati driver. The Xorg server also complains > about some other missing modules. In any event, I'll figure it out, but > it'll keep me busy.)
Let me know if you run into any problems. > > > I'm not sure what the default settings of the registers are off hand. > > It probably varies from card to card. Also from the documentation I > > have the MC registers start at index 0x18 and go to 0x2F (each one is > > 32 bits). That may explain the zeros you were seeing. > > What's strange is that ALL of the indexes (0 to 0x3f) print out zeros. > Maybe I'll just try to iterate through the 0x18-0x2F range and see if > anything is different. It could also be that the XPRESS chips have a different memory controller altogether (although this is somewhat doubtful). > > > As for the MC > > INDEX reg, I don't know that it retains the index on read back. I > > wouldn't worry about that. > > Ok. cool. > > > > > The memory controller handles all memory (FB and AGP/PCI/PCIE) related > > activities on the radeon. The GPU is basicaly a specialized mini CPU. > > Different parts of the chip vie for access to memory (display > > controllers, pixel pipelines, etc.). The MC configuration registers > > allow you to tweak the controller (everything from latencies, timing, > > cache control, DRAM driving strength, etc. It's fairly complicated, > > and I think is generally best left to the bios. I'd be careful > > changing the MC regs unless you are reasonably sure what you are > > doing. I take no responsibility for anyone who hoses their hardware. > > Ok. You've scared me off. ;-) I'll try to avoid screwing with it if > possible. > > > > > Give it a shot and see what happens. I've heard reports of users > > having success with the the DRI using fglrx and setting the FB size in > > the bios to a reasonably large level. > > I do have DRI working w/fglrx, it is with an older driver ( 8.24), but I > hope it is enough to figure out > (Getting DRI to work was an effort in itself... New stuff (8.29.X) is > broken, and the old stuff (8.24.X) needed to be hacked to work with my > recent FC5 kernel.) > > FWIW, I set the local memory to 128M (That's also the amount of graphics > memory I had.) to get it to work. (I haven't tried other values yet..) > > > If you can get the DRI going > > with fglrx, you might just want to dump the regular MMIO regs and we > > can see if anything interesting jumps out at us. > > I've already run radeon dump on the fglrx w/DRI configuration. The results > are attached. (Both my Xorg.0.log file and the radeon dump itself. ) > > Unfortunately, it doesn't appear to give nice register names w/values, but > maybe the dump will be of some use to you. FWIW, radeontool (http://gitweb.freedesktop.org/?p=users/airlied/radeontool.git;a=summary) will give you a nicer (though more limited) dump. > > > You might also want > > to try some of the radeon command buffer dumpers from the old r300 > > project with fglrx. I'm not sure anyone has looked at those since DRI > > support for XPRESS chips was added to fglrx. It would be alot easier > > to not have to mess with the MC regs. > > I assume that you mean 'glxtest' for the command dumper. I'll check it out > of CVS and play with it. Let us know how it goes! Alex > Cheers, > --Phil > > > ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 -- _______________________________________________ Dri-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
