Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Newsgroups: comp.arch
Subject: Re: Is Intel exceptionally unsuccessful as an architecture designer?
Date: Sat, 21 Sep 2024 17:09:54 -0700
Organization: A noiseless patient Spider
Lines: 45
Message-ID: <vcnn8i$1p6ct$2@dont-email.me>
References: <vcisaf$ulcv$1@dont-email.me>
 <memo.20240920210659.19028C@jgd.cix.co.uk> <vcnm4m$1p6a3$5@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 22 Sep 2024 02:09:55 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="0029950ff4e92ba21a7d99fa35b943c5";
	logging-data="1874333"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+iKsgym5R2OOqtRXippTQSCeOmEQAxEus="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:u2nVDoGY7wn1tCH9VDWyL2NkdQE=
In-Reply-To: <vcnm4m$1p6a3$5@dont-email.me>
Content-Language: en-US
Bytes: 3531

On 9/21/2024 4:50 PM, Lawrence D'Oliveiro wrote:
> On Fri, 20 Sep 2024 21:06 +0100 (BST), John Dallman wrote:
> 
>> All the threads are executing exactly the same instructions,on the same
>> code path.
> 
> Yes, but look at the things that GPUs, for example, typically do: large
> parts of their execution time is in pieces of code called “fragment
> shaders”. In OpenGL, a “fragment” means a “pixel before compositing” --
> one or more “fragments” get composited together to produce a final image
> pixel. They could have just called it a “pixel in an intermediate image
> buffer”, and avoided introducing yet another mysterious-sounding technical
> term.
> 
> There are a lot of memory accesses involved in a typical fragment shader:
> reading from texture buffers, reading/writing other image buffers. Then
> you have things like stencil buffers and depth buffers, that play their
> part in the computation. And geometry buffers, though these tend to be
> smaller. Buffers coming out your ears, basically. So the proportion of
> instructions that access memory is much higher than a typical CPU workload
> -- probably not far short of 100%, certainly in execution time.
> 
> As I recall, DRAM access involves specifying “row” and “column” addresses.
> As I further recall, if the “row” address does not change from one access
> to the next, then you can specify multiple successive “column”-only
> addresses and do faster sequential access to the memory (until you hit the
> end of the row). GPUs would take full advantage of this, and their
> patterns of memory usage should suit it quite well.
> 
> On the other hand, such heavily sequential access has poor caching
> behaviour.
> 
> So you see the difference in memory behaviour between GPUs and CPUs: CPUs
> have (or allow) more complex patterns of memory access, necessitating
> elaborate memory controllers with multiple levels of caching to get the
> necessary performance, while GPUs can make do with much simpler memory
> interfaces that don’t benefit from caching.
> 
> This also complicates any ability to share memory between GPUs and CPUs.
> 
> Which brings us back to the point I made before: CPU RAM on the
> motherboard is typically upgradeable, while GPU RAM comes on the same card
> as the GPU, and is typically not upgradeable.

Add another GPU and cross fire it? ;^)