How GPUs Work • Hacker News Board

Re: How GPUs Work

#51

Post by dfox » Tue, Dec 16, 2014, 12:13 PM UTC

abecedarius wrote: post #46

dfox wrote: post #43

Earlier quoted context omitted.

Significant part of functionality of moder GPU is in software that abstracts away differences between different models and generations, from this point of view it does not make much sense to document actual interface between software and hardware. Other thing is that complexity of this software abstraction layer is comparable to the GPU itself and manufacturers do not expect that somebody would want to implement all…

You could make the same arguments against documenting the machine code of a CPU.

For CPU, there is no another processor that can run all the abstraction software so it has to be done in hardware or in software in a way that is transparent to user (microcode, Transmeta-style JIT...).

Re: How GPUs Work

#52

Post by fat0wl » Tue, Dec 16, 2014, 2:15 PM UTC

tmurray wrote: post #18

fat0wl wrote: post #14

I'm really sorry I will try to dig up the source myself, but I've read basically the opposite argument in a few technical papers -- that GPU is NOT as fast as claimed for many classic test algorithms (actual speed-up is more like factor of 2 than 10) and that the performance gap between traditional CPUs and GPUs is actually lessening. I'm going to read this article anyway to hear their take & for the learning experie…

disclaimer: I work in this space and have done so for a while, including previously on CUDA and on Titan. GPUs for general purpose computation were never 100x faster than CPUs like people claimed in 2008 or so. They're just not. That was basically NV marketing mixed with a lot of people publishing some pretty bad early work on GPUs. Lots of early papers that fanned GPU hype followed the same basic form: "We have this…

ah, yes. :) very nice detailed summary of some of the issues in this sect of "academia" (I put that in quotes only because all the research seems to be co-written by corps).

I am into audio DSP & am planning to port a couple of audio algorithms (lots of FFT & linear algebra) to run on GPU but haven't even gotten to it because I considered it a pre-mature optimization to this point. I'm sure it would improve performance, but nowhere near what GPU advocates would claim.

My biggest reason? "PCIe transfer time to/from GPU", plus it would be unoptimized GPU code. Once you read a few of these papers it becomes painfully obvious that a lot of tuning goes into the GPU algorithms that offer anything more than a low single-digit factor of speedup. It's still very significant (cutting a 3 hour algorithm down to 1 would be huge) but if you're in an early stage of research it may be a toss-up over whether its better to just tune the algorithm itself / run computations overnight rather than going through the trouble of writing a GPU-based POC. Maybe if you have 1 or 2 under your belt its not such a big deal but for most of the researchers I know GPU algorithm rewrites would not be trivial. (I've been doing enterprise Java coding for about 2 years now so the idea isn't so intimidating now, but in a past life of mucking around with Matlab scripts I'm sure it would have been daunting).

Re: How GPUs Work

#53

Post by abecedarius » Tue, Dec 16, 2014, 11:07 PM UTC

dfox wrote: post #51

abecedarius wrote: post #46

Earlier quoted context omitted.

You could make the same arguments against documenting the machine code of a CPU.

For CPU, there is no another processor that can run all the abstraction software so it has to be done in hardware or in software in a way that is transparent to user (microcode, Transmeta-style JIT...).

That's an implementation detail: the manufacturer supplies the system software, and by this argument you're not supposed to care where it runs.

Re: How GPUs Work

#54

Post by sklogic » Wed, Dec 17, 2014, 1:58 AM UTC

dfox wrote: post #43

userbinator wrote: post #40

One thing that's always put me off from studying GPUs in detail is the proprietariness of everything; with few exceptions (Intel being one of them recently, and surprisingly enough Broadcom for the RPi), there's no detailed datasheet or low-level programming information publicly available for modern GPUs, and what is available is still not all that complete. Contrast this with CPUs where a lot of them have full, high…

Significant part of functionality of moder GPU is in software that abstracts away differences between different models and generations, from this point of view it does not make much sense to document actual interface between software and hardware. Other thing is that complexity of this software abstraction layer is comparable to the GPU itself and manufacturers do not expect that somebody would want to implement all…

I would have been delighted to know the FPGA bitstream formats, place&route is certainly hard, but not at all impossible.

And some of the GPU vendors are publishing their datasheets specifically in a hope that an alternative open source driver stack will appear.