Date: Tue, 18 Mar 2008 08:17:30 -0500 From: Reid Linnemann <lreid@cs.okstate.edu> To: Tijl Coosemans <tijl@ulyssis.org> Cc: freebsd-questions@freebsd.org Subject: Re: DRI on radeon 9500 using too wide memory bus? Message-ID: <47DFC0EA.3080200@cs.okstate.edu> In-Reply-To: <200803141259.25941.tijl@ulyssis.org> References: <47D8C274.5030107@cs.okstate.edu> <47D9A07F.5040108@cs.okstate.edu> <200803141259.25941.tijl@ulyssis.org>
next in thread | previous in thread | raw e-mail | index | archive | help
This is a multi-part message in MIME format. --------------080309050607030707040708 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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. --------------080309050607030707040708--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47DFC0EA.3080200>