From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1GCgIV-00071t-Qk for garchives@archives.gentoo.org; Mon, 14 Aug 2006 17:32:20 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.7/8.13.6) with SMTP id k7EHUOEY008976; Mon, 14 Aug 2006 17:30:24 GMT Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by robin.gentoo.org (8.13.7/8.13.6) with ESMTP id k7EHUK7M005330 for ; Mon, 14 Aug 2006 17:30:21 GMT Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id k7EK0tFg010723 for ; Mon, 14 Aug 2006 13:00:55 -0700 Received: from conejo.engr.sgi.com (conejo.engr.sgi.com [163.154.22.110]) by cthulhu.engr.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k7EHUJkX45945558 for ; Mon, 14 Aug 2006 10:30:19 -0700 (PDT) Received: from conejo.engr.sgi.com (localhost [127.0.0.1]) by conejo.engr.sgi.com (SGI-8.12.11.20060308/8.12.11) with ESMTP id k7EHUIEf001996 for ; Mon, 14 Aug 2006 10:30:18 -0700 (PDT) Received: (from rsanders@localhost) by conejo.engr.sgi.com (SGI-8.12.11.20060308/8.12.11/Submit) id k7EHUIKZ001995 for gentoo-amd64@lists.gentoo.org; Mon, 14 Aug 2006 10:30:18 -0700 (PDT) Date: Mon, 14 Aug 2006 10:30:18 -0700 From: Bob Sanders To: gentoo-amd64@lists.gentoo.org Subject: Re: [gentoo-amd64] Re: Re: Re: More ATi driver madness Message-ID: <20060814173018.GA1887@sgi.com> Mail-Followup-To: gentoo-amd64@lists.gentoo.org References: <200608121101.38860.mhaney@ercbroadband.org> <200608130038.56469.volker.armin.hemmann@tu-clausthal.de> <200608131915.18375.volker.armin.hemmann@tu-clausthal.de> <20060814151338.GA102938@sgi.com> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-amd64@gentoo.org Reply-to: gentoo-amd64@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: SGI, Mountain View, California, U.S.A. User-Agent: Mutt/1.5.11 X-Archives-Salt: 503114ce-4816-4f98-b3a4-e959803ccf4b X-Archives-Hash: aca51feb02d250880221e90e5d58ce86 Duncan, mused, then expounded: > Bob Sanders posted 20060814151338.GA102938@sgi.com, > excerpted below, on Mon, 14 Aug 2006 08:13:38 -0700: > > > Gfx, especially 3D, is about memory bandwidth. Move the memory out > > of direct contact with the gpu chip - say via a socket, and it's > > necessary to drop the frequency that the memory interface runs at. > > It's basic electronics - add more capacitaince and inductance, and > > the speed of the interface goes down. > > Two factors in counter-point. We're talking FB-DIMM tech time this comes > out, and this will be using upgrades to the same memory controller on the > CPU (only in this case GPU) AMD is already using to maintain its lead in > multi-socket performance against Intel (even while Intel's Core-Duo has > caught up at the low single-socket end). > Problems with this approach - it takes 4 FB-DIMMs to a special northbridge for Intel to acieve 21.5 GB/s bandwidth to the cpu in a Woodcrest based server. And that's a fair chunk of change for the northbridge and dimms. Plus the increased latency. Btw - the current DDR-2 controller in the AMD Socket AM-2s can talk to FB-DIMMs. It's not allowed to yet, probably not tweaked up right and AMD like to take things slowly so that risk is minimized - one or two things at a time. But the current memory controller should work with FB-DIMMs. While 21.5 GB/s may seem fast, that's the peak speed, not the sustained bandwidth. Effective bandwidth is going to be less. And it's a lot cheaper to build a dedicated PCIe card with memory than to even purchase one stick of FB-DIMM memory. Even with just 2 DIMMS, DDR-2 or FB-DIMMS, the memory bandwidth peaks around 10.5 GB/s with a sustained bandwidth of around 8 GB/s. Still less than the 12.8 GB/s an Nvidia 600GS card attains while retailing for $109. > > Remember, Intel doesn't make real 3D Gfx chips. Unlike, Nvidia and > > Ati, Intel does most of it's 3D processing in software. Thus opening up > > the chips specs and driver has little impact on any IP outside of Intel as > > it doesn't expose any IP that might belong to Micrsoft or SGI. > > Does <> will do. With aeroglass driving dx10 requirements, the low end of > the gfx market is about to get very legacy, very fast. Their new chips > do more in hardware because they must, due to the performance > requirements. That's the reason Intel's latest free driver release made > the headlines in the FLOSS world -- it's the first time we've had full > sources to something that capable. > Based on all I've read, what I'm putting forth is strictly my take on the situation. No source to go to, just speculation. What Intel is doing is stopping Gfx development any laying off most of it's Gfx Engineering staff. They are outsourcing most of the IP development by licensing cores from Imagination Technologies - the PowerVR SGX, that has been widely reported, but not explicitly confirmed (unless I missed it). As the SDK for the PowerVR is already publically available, all Intel did was go and say - all this old crap we made and are abandoning, well - here are the specs for it. And since the new cores already have an open api and sdk, we'll just "say" we're opening the development to the Open Source Community, because, well, it already is. Great Marketing move. Of course I could be wrong on this, but time will tell. Bob - -- gentoo-amd64@gentoo.org mailing list