On 11/21/06, Roland Scheidegger <> 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).

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?

> The hypermemory whitepaper gives more details:
> Several
> people have said that "Hypermemory" is just a fancy algorithm to move
>  from graphics card memory to main memory.  From my reading of that
> white paper, there is actually more to it.. they have an auxiliary
> memory channel.  It's hard to tell exactly what it is or how to
> control it. The paper has a fair amount of marketing speak, but look
>  at the diagram on page 7.. And especially when they talk about the
> auxiliary memory channel.
I'm not quite convinced this "auxiliary memory channel" really exists.
Might be just the ability to access memory directly due to the pcie
address remapper it has.

Ok. That's what these slides seem to say:
However, the whitepaper says:

"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.

(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).

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... ;-) )
(I don't have access to the log files for these right now, but if you're interested, I can send them later tonight. )

> Anyway.
> My Xorg.0.log is attached.  It is a little chatty because I have
> RADEON_DEBUG enabled.
> (NOTE: There's one problem I know about.. I don't have in
>  the right place.  However, having this missing shouldn't hang the
> box.)
It's probably a good idea to NOT have it there for now - it's completely
optional, xorg itself won't touch it (except aiglx).

Ok.  Cool.  I won't worry about it then.