DRI on radeon 9500 using too wide memory bus?

[Reid Linnemann]

Written by Tijl Coosemans on 03/14/08 06:59>>
> On Thursday 13 March 2008 22:45:35 Reid Linnemann wrote:
>> 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?
>> 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?
> 
> I can't help you with this, but I'm thinking you'll have a higher
> chance getting an answer on some DRI/DRM mailinglist. You could also
> ask the port maintainers (x11@). Some of them are also active
> developers on DRI, and the r300 driver, or at least used to be in the
> past.

I did turn to the dri-users list, and I found I remembered the 9500
quirks wrong. Some of the 9500's were shipped with full r300 chips that
just had half functional pixel pipelines, and the driver disabled the
other half. Since that time, ATI has replaced the 9500 line with the
9600 (based on the rv350 chip), and wiped the 9500 from the historical
record. The actual problem I was experiencing was in tiling for
rasterization, because the developer documentation (and hence the r300
driver) specifies that 1 pipe should be enabled for the rv3xx series and
2 pipes should be enabled for the r3xx series, ignoring the 9500
anomaly. I couldn't even find mention of the 9500 on ati.amd.com in its
discontinued cards; only the 9500 pro is mentioned and it had a fully
functioning r300 chip, though with a narrower 128 bit memory bus.

Anyway, I fixed the problem with a simple patch I've attached. This is
only a bandaid patch though, there is apparently code in the assembly
line for the r300 dri that more intelligently decides how many pipes to
enable.