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 1GCeBB-00072R-LY for garchives@archives.gentoo.org; Mon, 14 Aug 2006 15:16:38 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.7/8.13.6) with SMTP id k7EFDg1d030049; Mon, 14 Aug 2006 15:13:42 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 k7EFDein025405 for ; Mon, 14 Aug 2006 15:13:41 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 k7EHiEMK030001 for ; Mon, 14 Aug 2006 10:44:14 -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 k7EFDdkX45906794 for ; Mon, 14 Aug 2006 08:13:39 -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 k7EFDcEn101866 for ; Mon, 14 Aug 2006 08:13:38 -0700 (PDT) Received: (from rsanders@localhost) by conejo.engr.sgi.com (SGI-8.12.11.20060308/8.12.11/Submit) id k7EFDck5102933 for gentoo-amd64@lists.gentoo.org; Mon, 14 Aug 2006 08:13:38 -0700 (PDT) Date: Mon, 14 Aug 2006 08:13:38 -0700 From: Bob Sanders To: gentoo-amd64@lists.gentoo.org Subject: Re: [gentoo-amd64] Re: Re: More ATi driver madness Message-ID: <20060814151338.GA102938@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> 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: b809b543-0cfd-423a-87b5-a56494a1f541 X-Archives-Hash: 66e9edaf7299aeeb13c3c17de225a6c9 Duncan, mused, then expounded: > > As for AMD, here's what I skipped over in the previous post. They've > already teamed up with various third parties to develop and sell physics > and floating point processors slotted into additional CPU sockets, linked > directly to the multi-core CPUs via Cohesive HyperTransport. The next > step is doing the same thing with full video processors, a decent portion > of which are physics processors anyway. There are however a couple issues > with the idea, including the fact that getting video folks to commit to an > AMD specific platform when they already have PCI-E would have been rather > difficult. This is supposedly one of the big reasons they bought ATI -- > to give AMD the where-with-all to follow up on that idea. Sorry, the conclusion is very likely wrong. True AMD wants several things that ATI brings to the table. But, there is little chance of Gfx being integrated fully into the cpu or even into a socket via a HyperTransport link. It's just too costly and the performance, for all but UMA (Unified Memory Archittecture) memory interface would suffer greatly. It's also one of the reasons AMD is adding a PCIe interface onto their cpus - the 1207 pin Socket F (is that the correct socket?) models, later next year. 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. True, it's possible to put low-end, UMA based, graphics into a socket, but that's not really a long-term goal. Rather, just an interesting Engineering exercise. Plus, in laptops, where it would be best, the socket cost - both dollars and size, negates any benefit of moving away from it existing on the southbridge where it is today. > Now, in ordered > to fully populate the ecosystem, they'll /have/ to open things up. Keep > in mind that Intel is designing similar stuff with it's integrated > solutions, and if AMD didn't get in the game, it wouldn't be long until > they were no more relevant than Via in the x86 CPU market. Both AMD and Intel are moving, but not in the direction of more complexity. They are moving to simpler parallel execution units - like the parallel Gfx pipes found on GPU chips today, only for generic computing. All this time, cpus have had a very diffcult time moving from serial processing and the efforts for massivly parallel units have not faired well - Sun's last UltrsSparc. At the same time Gfx systems have become more and more parallel, and with the push from the late 3DLabs, have become more like generic, programable, compute blocks, though still diffcult to access from main menory. > > So... I think AMD/ATI /could/ open their video specs. However, it's still > an open question of whether they /will/, tho I think the chances are > pretty good, as Intel will have them between a rock and a hard place if > they don't. > Uh, no. 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. Both ATI and Nvidia have IP in their hardware that came from outside of those companies. Opening up their drivers exposes this IP and it's not theirs to give away. And given that some IP was sold outright to Microsoft, even if SGI were to open up the Gfx IP that is licensed, some would still be held up in Redmond, as would any implementation in hardware that insures decent performance with DirectX 9 and 10. So outside of the binary blobs that hide the IP, like Nvidia implements today, there will be little change in drivers from Nvidia. With luck AMD will get ATI to at least get their Linux drivers into a mroe suitable form on par with Nvidia. > (My sources for much of this were articles at ArsTechnica and the > Register, in turn quoting trade mags and industry analysts, plus AMD's own > PR.) > While ArsTechnica tends to be fairly reliable, I've found stories from the Register to be very, very, wrong - the assumptions were way off base or the reporter got the entire story wrong because they ignored documented history. I'd be very wary of believing a story in the Register without cross checking it with independent sources. Sometimes the Register will get one sentence in the story correct. Sometimes, the entire story is made up from that one sentence. Bob - -- gentoo-amd64@gentoo.org mailing list