41–50 of 54 posts
The 8800GTX was the first GPU I every bought back in 2007 (obviously I'm not very old). Now 7 years later, its funny how dated the render on "Figure 2." is.
I wish there was a good book on GPU architecture and even micro-architecture. I just like reading about this stuff and how they work.
If you're interested in the architecture of a GPU this Berkeley ParLab presentation by Andy Glew from 2009 covers the basics of how the compute cores in modern GPUs handle threading. It's a subtle, but powerful, difference from SIMD or vector machines.
http://parlab.eecs.berkeley.edu/sites/all/parlab/files/20090...
If you want to get into the details of how a GPU interfaces with the system and OS software, which is almost an entirely other animal, you may want to look at the Nouveau project to get oriented.
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…
Earlier quoted context omitted.
What are you meaning by general-purpose here? Do you not have to use a different programming model anymore?
I'd sum it up like this: GPGPU can be made to run any computational code - this doesn't mean that it's necessarily faster though (otherwise we could just forget about CPUs couldn't we?). A few things need to be true in order for GPUs to execute something with a speedup compared to CPU: 1) Code needs to have at least 1k, better 10k+ parallel 'threads'. 2) These threads should be largely data parallel (branching is pos…
3) Some GPUs have MMUs (and share their paging with the host CPUs)
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…
http://developer.amd.com/sdks/AMDAPPSDK/assets/AMD_Southern_...
http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2013/...
http://www.amd.com/Documents/GCN_Architecture_whitepaper.pdf
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…
Earlier quoted context omitted.
I'd sum it up like this: GPGPU can be made to run any computational code - this doesn't mean that it's necessarily faster though (otherwise we could just forget about CPUs couldn't we?). A few things need to be true in order for GPUs to execute something with a speedup compared to CPU: 1) Code needs to have at least 1k, better 10k+ parallel 'threads'. 2) These threads should be largely data parallel (branching is pos…
2) Some GPUs do not penalise branching 3) Some GPUs have MMUs (and share their paging with the host CPUs)
3) By MMUs do you mean unified memory? Well yes, but for now this is so slow that you don't really want to use it. This might change on Power systems with nvlink and for Knights Landing generation Intel accelerators, but that's still in the future / not publicly available.
Earlier quoted context omitted.
2) Some GPUs do not penalise branching 3) Some GPUs have MMUs (and share their paging with the host CPUs)
2) You mean Xeon Phi / Knights Corner? Yes, I wouldn't call these GPUs though, they have to be regarded a bit differently. They have quite a few problems in other areas btw., so far the results of theses systems are not very promising. 3) By MMUs do you mean unified memory? Well yes, but for now this is so slow that you don't really want to use it. This might change on Power systems with nvlink and for Knights Landin…
Earlier quoted context omitted.
Take a look at, say, Raspberry Pi: 24GFLOP for 1/2W. You won't get this for any number of mobile CPU cores.
but that's GLES 2.0, which is significantly less flexible than the kinds of GPUs we're discussing here and is not even in the same ballpark as a CPU (and almost certainly significantly less strict in terms of floating point precision than a GLES 3 device).
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…
https://www.flickr.com/photos/73923873@N05/sets/721576287942...
http://www.edaboard.com/thread236934.html
http://hackaday.com/2012/10/08/stm32-driving-a-pcie-video-ca...
Standalone code running on _not plugged into anything_ Radeon HD2400
authors blog: http://www.pixel.io/blog/ he never released any source, actually he had something posted to github, but made repo private