DRI on radeon 9500 using too wide memory bus?

Reid Linnemann lreid at cs.okstate.edu
Thu Mar 13 21:45:40 UTC 2008


Written by Reid Linnemann on 03/13/08 00:58>>
> I've had DRI running on a radeon 9500 for a while now, and at some point
> in time tracking 6-STABLE and continuing now on 7-STABLE I've started
> seeing rendering artifacts in gl in the form of a cross-hatch pattern of
> pixels that don't get filled. At first I figured the card was failing,
> but I remembered a fact about the 9500 that made me doublethink that.
> 
> The radeon 9500 is an r300 chipset, and differs from the 9700 only in
> the width of the memory bus (128 bit vs 256 bit) and possibly clock
> speed. If memory serves, the chip itself had the capacity to address 256
> bits, but most 9500s just went out the door with 128 bit memory. I
> remember at one point in time trying out a hack to the 9500 driver that
> enabled the 256 bit bus to see if I had a rebadged 9700, and had similar
> artifacts.
> 
> So I decided to peruse my X logs, and sure enough I see:
> (--) RADEON(0): Mapped VideoRAM: 131072 kByte (256 bit DDR SDRAM)
> 
> Is it possible that the radeon driver is using the 256 bus? Is there a
> way to force it to use a 128 bit bus? Has anyone else seen this?
> 
> Thanks,
> Reid

On further investigation, I tried forcing the driver to switch to a 128
bit bus by setting the R300_MEM_NUM_CHANNELS_MASK bits on
RADEON_MEM_CNTL to 0x1, but the problem did not go away.

I'll try describing it a little better.. only with gl acceleration, the
entire gl context appears to have criss-crossing lines 4 pixels wide
that are randomly filled correctly or black, so that they form roughly a
chain link fence pattern of trash on the gl context. Anyone have an idea?


More information about the freebsd-questions mailing list