Talk:General-purpose computing on graphics processing units
From Wikipedia, the free encyclopedia
| This is the talk page for discussing improvements to the General-purpose computing on graphics processing units article. This is not a forum for general discussion of the subject of the article. |
Article policies
|
| Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
 | This  level-5 vital article is rated C-class on Wikipedia's content assessment scale.It is of interest to the following WikiProjects: | ||||||||||
| |||||||||||
 | This article was nominated for merging with General-purpose computing on graphics processing units (hardware) on 03:52, 14 August 2025 (UTC). The result of the discussion (permanent link) was merge. |
 | On 14 August 2025, it was proposed that this article be moved from General-purpose computing on graphics processing units (software) to General-purpose computing on graphics processing units. The result of the discussion was moved. |
Updated
Updated the page to include a basic overview of GPGPU - history and techniques, as well as some more applications. More detail could be added to all the techniques, and the data structures need to be expanded. Applications could also be added and more detail about important/common ones could be added. Echeslack 19:01, 13 December 2005 (UTC)
I noticed there's plenty of detail for stream processing. I believe some of this should actually be moved to the ad-hoc article. Streams, kernels, flow control, map, scatter/gather and such seems to be good candidates. I'll take a memo about this. MaxDZ8 talk 09:07, 9 May 2006 (UTC)
Data types
8 bits per pixel - Palette mode, where each value is an index into a table with the real color value specified in one of the other formats. Possibly 2 bits for red, 3 bits for green, and 3 bits for blue.
this bit allocation does not make sense for pallete mode. Should we remove that phrase? --Diego 14:38, 13 June 2006 (UTC)
I rephrased it. Joe 09:22 June 29 2011
- I'd also contest that the bit allocation is inaccurate. Given the sensitivity of the human eye to different colours, it's far more likely that any fixed bit-per-channel allocation would be 3-3-2, with blue only having 4 levels (2 bits) and the other two components having 8. Though in practice, isn't a 216 colour evenly-spread "web safe"-type scheme (6 levels per channel with no direct correlation between channels and bits) more common in the fairly rare examples of a 3D accelerator outputting in less than 15 bpp but not using a completely custom (eg as found in Quake et al) palette? 193.63.174.211 (talk) 13:37, 11 January 2012 (UTC)
Languages
what about creating a section containing OpenGL Shading Language and related?
- There's a page on shading languages which would need some work. I think it would be better to put the thing there.
- MaxDZ8 talk 21:53, 13 June 2006 (UTC)
- Well, gpgpu have been using glsl much more than hlsl, so it's a bit strange that it isn't mentioned at all. —Preceding unsigned comment added by 128.39.210.208 (talk) 12:32, 23 April 2010 (UTC)
how does this all relate to OpenCL etc - the article seems overly full of references to Microsoft's DirectX when there are other competing technologies out there. [edit] APIs — Preceding unsigned comment added by 78.150.136.155 (talk) 11:58, 15 July 2011 (UTC)
Programmability
"The programmability of the pipelines have trended according the Microsoft’s DirectX specification, with DirectX8 introducing Shader Model 1.1, DirectX8.1 Pixel Shader Models 1.2, 1.3 and 1.4, and DirectX9 defining Shader Model 2.x and 3.0. " This sentence make no sense what so ever, 'trended' is a strange verb to use here (or indeed anywhere) and the rest is non grammatical anyhow. Did the author want to say something like "have followed the DirectX specification?".
how does this all relate to OpenCL etc - the article seems overly full of references to Microsoft's DirectX when there are other competing technologies out there.
Long story short: CL is the newcomer to all of this and there's no chance (or very little chance) to rephrase the above without referencing to D3D or some DirectX ecosystem. Direct3D is the only API I know with clear and (often) explicit definition of the concepts referred in the above statements. Writing the same in terms of OpenGL would be possible but extremely verbose in the best case and just plain out impossible in some other cases (such as single-float blending, of which GL had no notion at all last time I checked). When it comes to OpenCL the situation is slightly better (I have been told so) but in the end, its approach it's very similar to GL and has no chance to scale back to anything that is not at least Shader Model 4 (maybe 3) in functionality. — Preceding unsigned comment added by MaxDZ8 (talk • contribs) 14:37, 25 July 2011 (UTC)
- What I take from that phrase is that graphics chip / card manufacturers have concentrated on adding features to their GPUs - both those useful for GLGPU, and for "normal" graphics - that move them further up the DirectX version ladder, sometimes at the expense of the features which don't. It improves both their saleability, compatibility and longevity. So to get an idea of what features next years' GPUs may have, take a look at Microsoft's DirectX roadmap... 193.63.174.211 (talk) 13:40, 11 January 2012 (UTC)
APIs
Move
I disagree with the move proposal; GPGPU is more than just a subset of stream processing. Also, the stream processing article is too long, and should probably have pages broken out of it, instead of having more content merged into it. —Disavian (talk/contribs) 01:57, 6 November 2006 (UTC)
Conditionally support. Not the whole article shall be merged. The section on kernels, for example, should. The section on data types should not.
MaxDZ8 talk 08:15, 6 November 2006 (UTC)
I concur. However, some of this article should be moved out. A lot of this article is talking about various normal functions of the GPU which have little or nothing to do with GPGPU. This requires a more general treatment, and ought to include more information and citations on actual examples of its use. This article could also use a good deal of organization =\. --24.98.124.237 12:34, 9 December 2006 (UTC)Haplo
And who is doing it? Takomat 2nd of March 2007
- This article is poorly organized but it certainly is separate from stream processing. It could benefit from summarizing concepts in stream processing, GPU, etc and referencing appropriately. Potatoswatter 19:35, 7 April 2007 (UTC)
"a recent trend in computer science"
The phrase in the intro "a recent trend in computer science": it's not really anything at all new in computer science at all, is it? Much more computer engineering. Though not just software engineering. (Though "computer science" itself is closer to engineering than science a lot of the time.) The Computer engineering article is about hardware engineering and I suspect wouldn't be the right term to put in the intro. Computer programming isn't the perfect choice either. Ideas? - David Gerard 09:47, 7 September 2007 (UTC)
I agree this would need way more attention... I support your idea since CS usually doesn't even speak about the hardware. I'm not even sure it's the case to call for engineering: this would also be controversial, it's more an application design choice than anything else...
For the time being, I am modifying the page by removing the reference.
MaxDZ8 talk 06:35, 8 September 2007 (UTC)
Suitable decoration?
Is there a suitable image for this article? A photo, some block diagrams? I just thought it could do with some decoration :-) - David Gerard 09:49, 7 September 2007 (UTC)
Based on my awful experience with the shaders page, there's not. Furthermore, looks like editors run away when having to deal with diagrams. Someone shall really do that, Inkscape is your friend.
MaxDZ8 talk 06:35, 8 September 2007 (UTC)
Missing link
This article is definitely remiss for not mentioning or linking to NVIDIA Tesla Raul654 05:44, 6 November 2007 (UTC)
Software portability
A few questions that I was left wondering after reading the article:
- Is code written for CPU processors (eg i386) easily ported to GPUs or is major redesign necessary. (CPU->GPU)
- Is code written for one GPU portable to another? (GPU1->GPU2)
- Are there any GPU programming standards?
Pgr94 11:21, 14 November 2007 (UTC)
Note: I've changed the comment to a numbered list for better tracking.
- Generally redesign is required. Some simple pieces can be ported pretty easily, possibly at sub-optimal performance. In general, re-targeting requires to change not just the implementation but the algorithm itself and the surrounding application. This is a typical weak point of vector-based engines.
- Yes, if you mean for example GLSL, compiled HLSL bytecode or another intermediate language. Differently from CPUs, in which you can copy per-byte the real executable with a high chance of getting it to work on another model, GPU code must generally be recompiled. Compatibility is not guaranteed even in different models of the same family, let alone vendors.
- Yes, you may have heard of shading languages. They're the backbone of all other language but a few ones.
Only interesting for floating-point / arithmetic applications?
The article says it is important for applications to have high arithmetic intensity - does this mean that non-arithmetic applications are not well-suited to GPGPU's? Pgr94 11:25, 14 November 2007 (UTC)
No, it means that the more compute-heavy is the algo, the more it will benefit. Current (and previous) GPUs however also have way higher bandwidth compared to CPUs on typical mainboards so the gain is substantial even if the algorithm is bandwidth-bound.
In both cases however it is important for each algo "step" to be long enough. Some algorithms do not do enough work per-step to benefit because going from step n to n+1 is typically an expensive operation.
MaxDZ8 talk 17:02, 19 November 2007 (UTC)
GL Shader
All this text, and not a single mention of OpenGL Shading Language? Insensitive Clods! -Anonymous Coward —Preceding unsigned comment added by 65.24.75.114 (talk) 04:45, 5 February 2008 (UTC)
Yeah. What is this? An article on DirectX? DirectX gets mentioned over and over, but OpenGL doesn't. And it also turns into a version number fest listing each shader model added in different DirectX revisions... Supertin (talk) 08:47, 3 August 2008 (UTC)
Real-time
Removed a vague mention in the introduction of a (technically questionable) connection with real-time computing. Neither article expands on this connection. If it's legitimate, it should be explained in the body of the article. Bryan Silverthorn (talk) 14:41, 30 March 2008 (UTC)
Proposed deletion of Lib Sh
A proposed deletion template has been added to the article Lib Sh, suggesting that it be deleted according to the proposed deletion process. All contributions are appreciated, but this article may not satisfy Wikipedia's criteria for inclusion, and the deletion notice should explain why (see also "What Wikipedia is not" and Wikipedia's deletion policy). You may prevent the proposed deletion by removing the {{dated prod}} notice, but please explain why you disagree with the proposed deletion in your edit summary or on its talk page.
Please consider improving the article to address the issues raised because even though removing the deletion notice will prevent deletion through the proposed deletion process, the article may still be deleted if it matches any of the speedy deletion criteria or it can be sent to Articles for Deletion, where it may be deleted if consensus to delete is reached. Do you want to opt out of receiving this notice? —Disavian (talk/contribs) 21:15, 10 June 2008 (UTC)
Graphics Specific Applications
It seems to me that Digital image processing, Video Processing, Raytracing, Global illumination and Geometric computing all fall under the normal use of a graphics processing unit and thus do not qualify to be listed on this articles' page as general purpose computing applications. I suggest that they be removed from the list. Bkessler (talk) 02:32, 28 July 2008 (UTC)
Given normal operation, GPU's are used for displaying arbitrary 2d or 3d images onto the user's screen.
In 3D rendering those operations are performed; but they are not the end goal. The result of the computation will be lost save for an image on screen. In general purpose processing; the result of (for example) a ray trace may be used in other ways. Nidomedia (talk) 12:25, 26 March 2009 (UTC)