![]() | This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 1 | Archive 2 |
The word shader is used quite liberally in graphics and might need separation into distinct articles. This page could become either a disambiguation or a summary page. I am thinking of making them into table format to ensure that they stay short (to avoid overlapped, duplicated and conflicting explanations). Please feel free to make suggestions to this.
(William Leizerowicz Wleizero 13:59, 20 February 2007 (UTC))
Thank you proposal. It's greatly appreciated. Unluckly, there are always a few issues to consider unless we find "The Right Way". The idea of doing a disambiguation is good. It would also help people who want to write on offline renderers. I am confident this shall be done. This would also help in grouping the various "advancements" on the issue, a thing which has been asked many, many times.
MaxDZ8 talk 11:38, 23 February 2007 (UTC)
Does some expert on the subject want to add information on "unified shader architectures"? As far as I can see, they involve using the same pipeline and processing units to work on both shaders and vertices, but I'm sure there are more nuances that the article needs to address.
GeorgeBills 03:31, 9 November 2006 (UTC)
The GLSL specification lets implementors choose between multi-processor and single do-it-all processors, as soon as the other requirements are met. The same applies to D3D10.
This is implementation-dependant and should be noted on other pages (such as your favourite vid card).
Note that the whole "unified" thing is somewhat out of place since a fragment cannot be cut (geometry shader only operation on primitives), just as a vertex cannot be discarded once has been created by the GS (fragment only operation).
Obviously, you can call the "kill-vertex" operation discard, just as the "kill-fragment" operation but this is just a superficial difference.
I'm reading the G80 specifications right now, but I hardly believe there will be the need for a lot of changes. Logically speaking, the processors are distinct. If they end up in the same silicon, it's not an issue for the programmer.
I'm rather busy recently so don't hold your breath.
MaxDZ8
talk 12:02, 9 November 2006 (UTC)
So, after a quick glance, here's what it does take to write something useful on the new G8x functionalities.
Up to yesterday, the GL spec was a few hundred pages. NVidia's extensions up to NV4x/G7x was about ~1500 pages. The new G8x specs alone count roughtly 500 pages (blowing the total page count to 2075) so it does take a while before they can be digested. There's everything you were expecting: geometry shaders, stream out, new buffer formats, gamma correction, uniform buffers and such.
Rectifying my previous statement, I expect it'll take a lot of time before a major update could be done. There's now enough material for a split.
MaxDZ8
talk 14:01, 9 November 2006 (UTC)
My feeling is that unified shader should not be described at all. At this moment it's a hardware implementation detail (i.e. some hardware might run everything on the same pieces of silicon), but in no way a new "unified" shader type. There are still separate vertex, geometry, pixel shaders; and their capabilities are almost identical (but not quite... can't discard a vertex for example; or amplify input data in vertex/pixel shaders). NeARAZ 18:05, 10 March 2007 (UTC)
Folks, this article is largely a write-off at this stage. :( Strongly suggest re-write it offline then delete the whole thing and replace the text.
I'm also convinced it's the best thing to do. It probably has more sense now to have a whole chapter on this, as well as a shading pipeline page.
MaxDZ8
talk 09:50, 11 November 2006 (UTC)
It starts off good but then starts rambling. It begins to fall apart right about at "By design, hardware shaders are ideal candidates for parallel execution..." Way to much high level speculative stuff beyond this point. Why is the bulk of this article about Real-time shader structure? Somebody got carried away on this and I agree that a re-write wouldn't be a bad idea. I have a background in 3D graphics (artistically) so perhaps I can help. But really the first bit is OK and the rest of it is just too much info. Lomacar 09:56, 4 December 2006 (UTC)
This article is a mess from start to finish. Author is all over the map. This article should simply discuss the differences between pixel and vertex shading. It should definitely be dumped.
Here is a better place to start: http://computing-dictionary.thefreedictionary.com/vertex+shader
I agree Joelholdsworth 10:04, 20 February 2007 (UTC)
Ok people, i could tell just by skimming it that it would be too hard to understand. wtf? u ppl are supposed to help us understand what shaders are, not confuse us even more.
do vertex shaders calculate physics? KittenKiller
No they are are a polygon transformer as in lighting or shading BobtheVila
One thing you should do is look up terms you do not know. Basically, only people with a average level of understanding with computers will understand this. Tockwork 03:39, 22 November 2006 (UTC)
I looked at the article and didn't find it confusing. However I think it could be improved a bunch, and some of the technical terms should be elaborated on before they are introduced to the reader (since some people may read it with little familiarity with 3D technology). I think the first paragraph should be rewritten or modified to define what a shader is in less technical terms. However, shaders in general are a technical (but notable) subject, and like many subjects on Wikipedia that deal with physics or mathematics, it isn't unreasonable that some readers would have trouble with the subject. Tarinth 18:19, 22 December 2006 (UTC)
DO NOT DELETE, IT SHOWS THE TRUTH THAT ALL IT IS(pixel shading) IS MERE PROGRAMMING! BobtheVila
I am taking note that
I am considering writing a bunch of interlinked articles (note: this isn't going to happen any time soon).
MaxDZ8
talk 09:51, 23 December 2006 (UTC)
That's a great idea. I'm taking a note for future versions.
MaxDZ8
talk 13:26, 16 January 2007 (UTC)
The article as such appears quite readable to me. I speak out here in a capacity of a layman, so I hope my opinion will help to restrain professionals who contribute to the contents of the article from making it a "reading written by professionals for professionals". I mean that none should expect any kind of language specifications here, just a general discussion that is capable of letting curious people know what they pay their money for when they buy a new video adapter "with the support of such and such". I believe there's no sense to make up a voluminous treatise out of any article here at Wikipedia. Of course I realize it is hard sometimes to distinguish what is pertinent to the main line of discussion and what is not but I strongly encourage the author and the prospective contributors to try their best. It is a nice style to split the article when the discussion of some important but hardly indispensable notion is needed. I believe the issue with the pipeline to be just the case: one may easily grasp the notion of a shader without knowing exactly some side things. This is important because it makes an article much easier to read and understand.
It's simple. Objects are made of a bunch of points in 3D space, and you draw lines between certain points to make a shape, like you'd only make lines along the skin and the stem of an apple. These points are vertexes (or vertices). So, vertex shaders alter only the positions of the vertexes (which you could use to make everything look 'warped', i.e. in a fish-eye style as mentioned in the article), whereas you'd use pixel shaders to do anything to any pixel, anywhere, such as making everything more red, or making fog effects, or whatever you may want to do.
MGlosenger 12:24, 16 December 2006 (UTC)
That's it, although it's a bit oversimplified.
MaxDZ8
talk 10:08, 17 December 2006 (UTC)
Unluckly, no, because this is application dependant. For example, a 'true' DX10 game will just not run. A DX8.1 game will likely look the same with and without shaders. It's like asking how a game changes with
SSE. A few games will look similar but maybe because they just do different things. You can see more on that in the archive.
You are encouraged at pointing out an effect you would like to get more information about.
MaxDZ8
talk 13:37, 16 January 2007 (UTC)
Can somebody create or give me a list defining the differences between the various versions of Shader Model (SM 1, 1.1, 2, 3, 4, etc.)? —The preceding unsigned comment was added by Einhanderkiller ( talk • contribs) 11:09, 14 January 2007 (UTC).
I once wanted to do this but it's way too tedious. Take this with a bit of salt... I may be forgetting something. Consider this as "major" improvements only.
MaxDZ8 talk 17:43, 30 January 2007 (UTC)
It took all day and a lot of research, but now I know all about shaders and appreciate my GeForce 7800 SO much more. What fun wikipedia is!! I think I'd rather be a technical writer than a programmer.
Sys Hax 23:30, 25 January 2007 (UTC)
Consider this as a note. I'm considering reverting most (if not all) your recent contributions in the last few days. Most things are not an improvement... even on the long run.
Also, since this is a collaborative environment, please consider using the talk page before beginning rewriting everything.
As soon as I'll have time to figure out what you're doing, I'll probably take action. In the meanwhile, have fun.
MaxDZ8
talk 16:06, 26 January 2007 (UTC)
I have walked thuru all edits up to now. Here's a summing up. Note to readers: if you want to reply, please do this at the end of the message quoting the edit number (or date) you're referring to.
As suggested by
Tarinth an
introduction to shader link have been created just like in
general relativity. Casual users shall go there. I want to recall that in a hypermedia document, article X must assume (for clarity) all the needed concepts are understood. If this is not true, it is reader's responsability to follow the links.
Who candidates to write the intro?
MaxDZ8
talk 17:33, 30 January 2007 (UTC)
You converted the entire article into unintelligible jargon. You replaced a description of what a vertex shader does ("modifies the shape of an object") with "defines a method to compute vector space transformations and other linearizable computations". You and I and Dilbert understand vector spaces because we read topology textbooks for fun. The problem is that intelligent-but-normal people who come here are lost in the second paragraph.
Here's the point (actually, two points):
1) Almost everyone who understands that shaders "compute vector space transformations and other linearizable computations" already knows what a shader does, and
2) Almost no one who comes here to find out what a shader does understands "vector space transformations and other linearizable computations".
It's okay though! You added a link to a nonexistent page that, were it not make-believe, does what this article is supposed to do: explain what a shader does. This is okay, since "the theory of relativity does it too". The problem there is that people who look up relativity know what they're getting into: something complex and mysterious. Nobody goes to the relativity article because a video card is advertised as having "ass-kick Riemann tensors". They DO come HERE because their video card has "ass-kick vertex shaders", and they are curious as to what that means.
But congratulations, YOU'VE just chased them away! It was more important to show off your college education that it was to help the lesser, non-Jedi understand their increasingly-complex world.
...then you wonder why they call us "geeks".
I am TOTALLY disgusted.
Sys Hax 01:58, 31 January 2007 (UTC)
This sentance has just been removed from the introduction: "Breaking up the traditional graphics pipeline gives programmers direct control over how the rendered picture will look."
I agree with removing it, but could it go elsewhere? Joelholdsworth 09:14, 13 February 2007 (UTC)
“Current GPUs are limited in this respect because they use proprietary representations of floating point numbers (as opposed to the IEEE standard) and thus give slightly different results than on a CPU.” This gives the impression that IEEE representation guarantees identical results on different CPUs, which is not the case – IEEE floating point allows significant margins of errors which result in different results on different architectures, or with different instruction sequences (and thus, with different compilers/compiler settings) on the same architectures. - Ahruman 13:43, 27 February 2007 (UTC)
Removed. Since it seems like there's nothing to do besides removing info piece by piece, I also added a rewrite tag.
MaxDZ8
talk 08:59, 28 February 2007 (UTC)
I see the article has been rewritten yet again, and while it now has fewer confusing sentences, it seems light on actual usable information. I know what a shader is in relation to visual effects in film, but I don't see it talked about in this page, and I don't accurately know what a hardware shader is, but I still don't after reading the article, either.
I think one of the reasons the article has resisted all efforts to make it comprehensible is that we're trying to describe two slightly different definitions of the word. What do people think of splitting this article into at least 2 pages, like "Shader (computer graphics pipeline)" and "Shader (hardware)"? In my opinion (possibly because I've been in the film industry for a decade), "shading (pipeline)" is a step in the computer graphics pipeline and should be simply described as such (shaders define colors, textures, and light reflection properties like diffuse and specular, etc.) and the page should link to very simple shading models and shaders (phong shading model, etc.), and "shaders (software)" are programs written in shading language that do "shading (pipeline)". Whereas "shaders (hardware)" are programs that implement something that's similar but not quite the same as the "Shader (computer graphics pipeline)". I have no knowledge of this kind of shader, other than it seems to make my Splinter Cell game look pretty sweet.
As a point to keep in mind when trying to clarify "shaders", I believe we should look at the target audience of this page (i.e. "who is trying to look up Shaders on the wikipedia?").
1. Somebody interested in playing videogames
2. Somebody interested in writing videogames (or other PC/comsole application taking advantage of the GPU on the card)
3. Somebody interested in watching film/TV special effects/CGI
4. Somebody interested in creating CGI (e.g. writing prman shaders or understanding what Maya or other renderer is doing under the hood)
5. Somebody interested in writing a computer graphics pipeline (e.g. writing a renderer)
In my opinion, none of these people will find the information they are interested in by reading this article. If we split the article in two, I think the "shader (hardware)" page could be more easily targetted towards either of the first two kinds of readers (people interested in using or writing applications like games using the GPU on videocards on PCs), and the "shader (computer graphics pipeline) page could be targetted towards people who are interested in how shading and software shaders work in a traditional final-frame renderer (e.g. for film, TV, etc.; the last 3 kinds of readers.) Kjl 23:32, 28 February 2007 (UTC)
It's my intention to use disambiguation in the future to solve a few of those problems.
MaxDZ8
talk 14:52, 2 March 2007 (UTC)
I am interested in helping sort out this article, but the source says it's being "rewritten offline"... if so what is the progress on this? It seems that message has been around for a week or so. I'd like to help, but not if someone is about to come along and paste their own work over everything. -- AshleysBrain 22:12, 1 March 2007 (UTC)
I understand. I'll think about it. Anyway, the offline revision is growing very, very slow - the point this time is in providing more, more, more references. I guess people will stop complaining "I don't like it" when they bash
WP:ATT. Although the disambiguation thing is going to help, there's a lot of problems with the Wiki policies, mainly regarding various sources with different levels of authorithy (and popularity) contradicting each other...
Since a few days ago, when I put on {{rewrite}} I am no more looking at the article. In fact, it already started spreading information I have many, many doubts about.
MaxDZ8
talk 15:02, 2 March 2007 (UTC)
I see the unifier shader architecture catalyzing much attention.
Could you please provide an example of an unified shader (not of an unified shader architecture - there's no doubt those things do exist) because after cheching the whole GL specs, the GL extensions, the whole D3D9 and D3D10 docs I found no way to use "unified shaders". (take this as an hint)
MaxDZ8
talk 07:13, 30 April 2007 (UTC)
![]() | This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 1 | Archive 2 |
The word shader is used quite liberally in graphics and might need separation into distinct articles. This page could become either a disambiguation or a summary page. I am thinking of making them into table format to ensure that they stay short (to avoid overlapped, duplicated and conflicting explanations). Please feel free to make suggestions to this.
(William Leizerowicz Wleizero 13:59, 20 February 2007 (UTC))
Thank you proposal. It's greatly appreciated. Unluckly, there are always a few issues to consider unless we find "The Right Way". The idea of doing a disambiguation is good. It would also help people who want to write on offline renderers. I am confident this shall be done. This would also help in grouping the various "advancements" on the issue, a thing which has been asked many, many times.
MaxDZ8 talk 11:38, 23 February 2007 (UTC)
Does some expert on the subject want to add information on "unified shader architectures"? As far as I can see, they involve using the same pipeline and processing units to work on both shaders and vertices, but I'm sure there are more nuances that the article needs to address.
GeorgeBills 03:31, 9 November 2006 (UTC)
The GLSL specification lets implementors choose between multi-processor and single do-it-all processors, as soon as the other requirements are met. The same applies to D3D10.
This is implementation-dependant and should be noted on other pages (such as your favourite vid card).
Note that the whole "unified" thing is somewhat out of place since a fragment cannot be cut (geometry shader only operation on primitives), just as a vertex cannot be discarded once has been created by the GS (fragment only operation).
Obviously, you can call the "kill-vertex" operation discard, just as the "kill-fragment" operation but this is just a superficial difference.
I'm reading the G80 specifications right now, but I hardly believe there will be the need for a lot of changes. Logically speaking, the processors are distinct. If they end up in the same silicon, it's not an issue for the programmer.
I'm rather busy recently so don't hold your breath.
MaxDZ8
talk 12:02, 9 November 2006 (UTC)
So, after a quick glance, here's what it does take to write something useful on the new G8x functionalities.
Up to yesterday, the GL spec was a few hundred pages. NVidia's extensions up to NV4x/G7x was about ~1500 pages. The new G8x specs alone count roughtly 500 pages (blowing the total page count to 2075) so it does take a while before they can be digested. There's everything you were expecting: geometry shaders, stream out, new buffer formats, gamma correction, uniform buffers and such.
Rectifying my previous statement, I expect it'll take a lot of time before a major update could be done. There's now enough material for a split.
MaxDZ8
talk 14:01, 9 November 2006 (UTC)
My feeling is that unified shader should not be described at all. At this moment it's a hardware implementation detail (i.e. some hardware might run everything on the same pieces of silicon), but in no way a new "unified" shader type. There are still separate vertex, geometry, pixel shaders; and their capabilities are almost identical (but not quite... can't discard a vertex for example; or amplify input data in vertex/pixel shaders). NeARAZ 18:05, 10 March 2007 (UTC)
Folks, this article is largely a write-off at this stage. :( Strongly suggest re-write it offline then delete the whole thing and replace the text.
I'm also convinced it's the best thing to do. It probably has more sense now to have a whole chapter on this, as well as a shading pipeline page.
MaxDZ8
talk 09:50, 11 November 2006 (UTC)
It starts off good but then starts rambling. It begins to fall apart right about at "By design, hardware shaders are ideal candidates for parallel execution..." Way to much high level speculative stuff beyond this point. Why is the bulk of this article about Real-time shader structure? Somebody got carried away on this and I agree that a re-write wouldn't be a bad idea. I have a background in 3D graphics (artistically) so perhaps I can help. But really the first bit is OK and the rest of it is just too much info. Lomacar 09:56, 4 December 2006 (UTC)
This article is a mess from start to finish. Author is all over the map. This article should simply discuss the differences between pixel and vertex shading. It should definitely be dumped.
Here is a better place to start: http://computing-dictionary.thefreedictionary.com/vertex+shader
I agree Joelholdsworth 10:04, 20 February 2007 (UTC)
Ok people, i could tell just by skimming it that it would be too hard to understand. wtf? u ppl are supposed to help us understand what shaders are, not confuse us even more.
do vertex shaders calculate physics? KittenKiller
No they are are a polygon transformer as in lighting or shading BobtheVila
One thing you should do is look up terms you do not know. Basically, only people with a average level of understanding with computers will understand this. Tockwork 03:39, 22 November 2006 (UTC)
I looked at the article and didn't find it confusing. However I think it could be improved a bunch, and some of the technical terms should be elaborated on before they are introduced to the reader (since some people may read it with little familiarity with 3D technology). I think the first paragraph should be rewritten or modified to define what a shader is in less technical terms. However, shaders in general are a technical (but notable) subject, and like many subjects on Wikipedia that deal with physics or mathematics, it isn't unreasonable that some readers would have trouble with the subject. Tarinth 18:19, 22 December 2006 (UTC)
DO NOT DELETE, IT SHOWS THE TRUTH THAT ALL IT IS(pixel shading) IS MERE PROGRAMMING! BobtheVila
I am taking note that
I am considering writing a bunch of interlinked articles (note: this isn't going to happen any time soon).
MaxDZ8
talk 09:51, 23 December 2006 (UTC)
That's a great idea. I'm taking a note for future versions.
MaxDZ8
talk 13:26, 16 January 2007 (UTC)
The article as such appears quite readable to me. I speak out here in a capacity of a layman, so I hope my opinion will help to restrain professionals who contribute to the contents of the article from making it a "reading written by professionals for professionals". I mean that none should expect any kind of language specifications here, just a general discussion that is capable of letting curious people know what they pay their money for when they buy a new video adapter "with the support of such and such". I believe there's no sense to make up a voluminous treatise out of any article here at Wikipedia. Of course I realize it is hard sometimes to distinguish what is pertinent to the main line of discussion and what is not but I strongly encourage the author and the prospective contributors to try their best. It is a nice style to split the article when the discussion of some important but hardly indispensable notion is needed. I believe the issue with the pipeline to be just the case: one may easily grasp the notion of a shader without knowing exactly some side things. This is important because it makes an article much easier to read and understand.
It's simple. Objects are made of a bunch of points in 3D space, and you draw lines between certain points to make a shape, like you'd only make lines along the skin and the stem of an apple. These points are vertexes (or vertices). So, vertex shaders alter only the positions of the vertexes (which you could use to make everything look 'warped', i.e. in a fish-eye style as mentioned in the article), whereas you'd use pixel shaders to do anything to any pixel, anywhere, such as making everything more red, or making fog effects, or whatever you may want to do.
MGlosenger 12:24, 16 December 2006 (UTC)
That's it, although it's a bit oversimplified.
MaxDZ8
talk 10:08, 17 December 2006 (UTC)
Unluckly, no, because this is application dependant. For example, a 'true' DX10 game will just not run. A DX8.1 game will likely look the same with and without shaders. It's like asking how a game changes with
SSE. A few games will look similar but maybe because they just do different things. You can see more on that in the archive.
You are encouraged at pointing out an effect you would like to get more information about.
MaxDZ8
talk 13:37, 16 January 2007 (UTC)
Can somebody create or give me a list defining the differences between the various versions of Shader Model (SM 1, 1.1, 2, 3, 4, etc.)? —The preceding unsigned comment was added by Einhanderkiller ( talk • contribs) 11:09, 14 January 2007 (UTC).
I once wanted to do this but it's way too tedious. Take this with a bit of salt... I may be forgetting something. Consider this as "major" improvements only.
MaxDZ8 talk 17:43, 30 January 2007 (UTC)
It took all day and a lot of research, but now I know all about shaders and appreciate my GeForce 7800 SO much more. What fun wikipedia is!! I think I'd rather be a technical writer than a programmer.
Sys Hax 23:30, 25 January 2007 (UTC)
Consider this as a note. I'm considering reverting most (if not all) your recent contributions in the last few days. Most things are not an improvement... even on the long run.
Also, since this is a collaborative environment, please consider using the talk page before beginning rewriting everything.
As soon as I'll have time to figure out what you're doing, I'll probably take action. In the meanwhile, have fun.
MaxDZ8
talk 16:06, 26 January 2007 (UTC)
I have walked thuru all edits up to now. Here's a summing up. Note to readers: if you want to reply, please do this at the end of the message quoting the edit number (or date) you're referring to.
As suggested by
Tarinth an
introduction to shader link have been created just like in
general relativity. Casual users shall go there. I want to recall that in a hypermedia document, article X must assume (for clarity) all the needed concepts are understood. If this is not true, it is reader's responsability to follow the links.
Who candidates to write the intro?
MaxDZ8
talk 17:33, 30 January 2007 (UTC)
You converted the entire article into unintelligible jargon. You replaced a description of what a vertex shader does ("modifies the shape of an object") with "defines a method to compute vector space transformations and other linearizable computations". You and I and Dilbert understand vector spaces because we read topology textbooks for fun. The problem is that intelligent-but-normal people who come here are lost in the second paragraph.
Here's the point (actually, two points):
1) Almost everyone who understands that shaders "compute vector space transformations and other linearizable computations" already knows what a shader does, and
2) Almost no one who comes here to find out what a shader does understands "vector space transformations and other linearizable computations".
It's okay though! You added a link to a nonexistent page that, were it not make-believe, does what this article is supposed to do: explain what a shader does. This is okay, since "the theory of relativity does it too". The problem there is that people who look up relativity know what they're getting into: something complex and mysterious. Nobody goes to the relativity article because a video card is advertised as having "ass-kick Riemann tensors". They DO come HERE because their video card has "ass-kick vertex shaders", and they are curious as to what that means.
But congratulations, YOU'VE just chased them away! It was more important to show off your college education that it was to help the lesser, non-Jedi understand their increasingly-complex world.
...then you wonder why they call us "geeks".
I am TOTALLY disgusted.
Sys Hax 01:58, 31 January 2007 (UTC)
This sentance has just been removed from the introduction: "Breaking up the traditional graphics pipeline gives programmers direct control over how the rendered picture will look."
I agree with removing it, but could it go elsewhere? Joelholdsworth 09:14, 13 February 2007 (UTC)
“Current GPUs are limited in this respect because they use proprietary representations of floating point numbers (as opposed to the IEEE standard) and thus give slightly different results than on a CPU.” This gives the impression that IEEE representation guarantees identical results on different CPUs, which is not the case – IEEE floating point allows significant margins of errors which result in different results on different architectures, or with different instruction sequences (and thus, with different compilers/compiler settings) on the same architectures. - Ahruman 13:43, 27 February 2007 (UTC)
Removed. Since it seems like there's nothing to do besides removing info piece by piece, I also added a rewrite tag.
MaxDZ8
talk 08:59, 28 February 2007 (UTC)
I see the article has been rewritten yet again, and while it now has fewer confusing sentences, it seems light on actual usable information. I know what a shader is in relation to visual effects in film, but I don't see it talked about in this page, and I don't accurately know what a hardware shader is, but I still don't after reading the article, either.
I think one of the reasons the article has resisted all efforts to make it comprehensible is that we're trying to describe two slightly different definitions of the word. What do people think of splitting this article into at least 2 pages, like "Shader (computer graphics pipeline)" and "Shader (hardware)"? In my opinion (possibly because I've been in the film industry for a decade), "shading (pipeline)" is a step in the computer graphics pipeline and should be simply described as such (shaders define colors, textures, and light reflection properties like diffuse and specular, etc.) and the page should link to very simple shading models and shaders (phong shading model, etc.), and "shaders (software)" are programs written in shading language that do "shading (pipeline)". Whereas "shaders (hardware)" are programs that implement something that's similar but not quite the same as the "Shader (computer graphics pipeline)". I have no knowledge of this kind of shader, other than it seems to make my Splinter Cell game look pretty sweet.
As a point to keep in mind when trying to clarify "shaders", I believe we should look at the target audience of this page (i.e. "who is trying to look up Shaders on the wikipedia?").
1. Somebody interested in playing videogames
2. Somebody interested in writing videogames (or other PC/comsole application taking advantage of the GPU on the card)
3. Somebody interested in watching film/TV special effects/CGI
4. Somebody interested in creating CGI (e.g. writing prman shaders or understanding what Maya or other renderer is doing under the hood)
5. Somebody interested in writing a computer graphics pipeline (e.g. writing a renderer)
In my opinion, none of these people will find the information they are interested in by reading this article. If we split the article in two, I think the "shader (hardware)" page could be more easily targetted towards either of the first two kinds of readers (people interested in using or writing applications like games using the GPU on videocards on PCs), and the "shader (computer graphics pipeline) page could be targetted towards people who are interested in how shading and software shaders work in a traditional final-frame renderer (e.g. for film, TV, etc.; the last 3 kinds of readers.) Kjl 23:32, 28 February 2007 (UTC)
It's my intention to use disambiguation in the future to solve a few of those problems.
MaxDZ8
talk 14:52, 2 March 2007 (UTC)
I am interested in helping sort out this article, but the source says it's being "rewritten offline"... if so what is the progress on this? It seems that message has been around for a week or so. I'd like to help, but not if someone is about to come along and paste their own work over everything. -- AshleysBrain 22:12, 1 March 2007 (UTC)
I understand. I'll think about it. Anyway, the offline revision is growing very, very slow - the point this time is in providing more, more, more references. I guess people will stop complaining "I don't like it" when they bash
WP:ATT. Although the disambiguation thing is going to help, there's a lot of problems with the Wiki policies, mainly regarding various sources with different levels of authorithy (and popularity) contradicting each other...
Since a few days ago, when I put on {{rewrite}} I am no more looking at the article. In fact, it already started spreading information I have many, many doubts about.
MaxDZ8
talk 15:02, 2 March 2007 (UTC)
I see the unifier shader architecture catalyzing much attention.
Could you please provide an example of an unified shader (not of an unified shader architecture - there's no doubt those things do exist) because after cheching the whole GL specs, the GL extensions, the whole D3D9 and D3D10 docs I found no way to use "unified shaders". (take this as an hint)
MaxDZ8
talk 07:13, 30 April 2007 (UTC)