Phillip Ezolt wrote: > Roland, > > On 11/21/06, *Roland Scheidegger* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > Phillip Ezolt wrote: >> It does get recognized as PCI. However, I had to force it PCIE. >> (using Option "BusType" "PCIE"). These cards are >> definately PCIE, so the original detection was wrong. >> >> I wonder if the MC_AGP_LOCATION register means something different >> on the 200M. These cards have an extra PCIE component which is >> supposed to shuffle graphics stuff to and from the memory. (This >> is in addition to the normal channels to and from the graphics >> card..) > I'd be surprised if it's really different. I'd suspect that addresses > within the AGP space just go untranslated to the bus without address > translation as they did with other chips (with the chipset being > responsible for translation). In any case, setting this up without > RADEON_AGP_BASE likely makes little sense. I'm not sure why fglrx > configures a 128MB window there. Maybe the chipset actually does some > kind of agp gart remapping when set up correctly. > > > Hmm. Maybe I just stumbled upon something good by accident. Like I > said in the original email, there are still problems (garbage on the > top half of the screen, and the hang). It's a bit weird. Maybe this is how the uma+sideport setting works.
> Should I read the value of "RADEON_AGP_BASE" when I have the working > 8.24.8 driver and try to set that as well in the DRM module? You can't just change that in the drm I think. > "This PCI Express auxiliary memory channel is effectively a 64-bit > memory channel with access to system memory. This means that a VPU > equipped with a 64-bit local graphics memory bus and a PCI Express > auxiliary memory channel has an effective 128-bit memory bus." > > So, it looks as if there is at least two channels out of the card > when it has hypermemory. I think this is really only true for the xpress200 igps with local ram in interleaved mode. I've never seen anything indicating that the "normal" chips are actually able to split data like that - though careful placing of some buffers in system ram and some other buffers in local ram might indeed increase available bandwidth a bit slightly. But there isn't really any additional "memory channel" involved in this case, it's just the ability of the gpu's memory controller to read from system ram directly, which it has had since ages... > (Gee, ATI, specs would be nice..) > > You don't have a xpress200 with local ram (sideport), right? I think > something strange is going on with that agp location stuff. > > > My laptop has 128M of sideport memory, and I have the BIOS configured > so there is 128M of sideport + 128M of UMA memory. (for a total of > 256M). Ah! Is that interleaved or not? This setup is likely more complicated to configure correctly than just using sideport (or uma) alone. I could be wrong though, with some luck the chip / bios handles this fully transparent on its own. > Interestingly, the fgrlx v8.24.8 driver (the one that works...), only > detects 128M of memory. > > The fglrx v8.28.8 driver (which DOESN'T work... It hangs shortly > after start up), detects 256M of memory, and has a different value > for the MC_AGP_LOCATION. > > So, I'm guessing, that the v8.24.8 driver is probably exclusively > using either the UMA or Sideport memory (and working correctly..). I > don't know which (and I don't know how to figure it out... ;-) ) This sounds like a very reasonable assumption. I think you should play around with the bios settings and see what happens. Roland ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
