From owner-freebsd-questions@FreeBSD.ORG Fri Mar 14 11:59:57 2008 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6462106566C for ; Fri, 14 Mar 2008 11:59:57 +0000 (UTC) (envelope-from tijl@ulyssis.org) Received: from cavuit02.kulnet.kuleuven.be (cavuit02.kulnet.kuleuven.be [134.58.240.44]) by mx1.freebsd.org (Postfix) with ESMTP id 79D078FC18 for ; Fri, 14 Mar 2008 11:59:57 +0000 (UTC) (envelope-from tijl@ulyssis.org) Received: from smtps01.kuleuven.be (smtpshost01.kulnet.kuleuven.be [134.58.240.74]) by cavuit02.kulnet.kuleuven.be (Postfix) with ESMTP id 7F3BB51C006; Fri, 14 Mar 2008 12:59:42 +0100 (CET) Received: from kalimero.kotnet.org (unknown [10.4.16.222]) by smtps01.kuleuven.be (Postfix) with ESMTP id 62F7F31E703; Fri, 14 Mar 2008 12:59:42 +0100 (CET) Received: from kalimero.kotnet.org (kalimero.kotnet.org [127.0.0.1]) by kalimero.kotnet.org (8.14.2/8.14.2) with ESMTP id m2EBxQxP002241; Fri, 14 Mar 2008 12:59:27 +0100 (CET) (envelope-from tijl@ulyssis.org) X-Kuleuven: This mail passed the K.U.Leuven mailcluster From: Tijl Coosemans To: Reid Linnemann Date: Fri, 14 Mar 2008 12:59:23 +0100 User-Agent: KMail/1.9.7 References: <47D8C274.5030107@cs.okstate.edu> <47D9A07F.5040108@cs.okstate.edu> In-Reply-To: <47D9A07F.5040108@cs.okstate.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200803141259.25941.tijl@ulyssis.org> X-KULeuven-Information: Katholieke Universiteit Leuven X-KULeuven-Scanned: Found to be clean X-Spam-Status: not spam, SpamAssassin (not cached, score=-49.9, required 5, autolearn=disabled, KUL_SMTPS -50.00, RDNS_NONE 0.10) X-KULeuven-Envelope-From: tijl@ulyssis.org Cc: freebsd-questions@freebsd.org Subject: Re: DRI on radeon 9500 using too wide memory bus? X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2008 11:59:57 -0000 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.