Talk:Shader/Archive 2

message: 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)
thread_title:  Proposed New Stucture 

message: *ATI/AMD
*nVidea
*...
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.
*Hardware Processing and Pipeline Architectures: name must be changed. Calling for the metal without a good reason shall be avoided. The docs do speak about "processors" but do not specify if each processor is logical or physical. The idea of providing HW info is basically impossible, no one knows what's inside a pipe.
**Vertex Shaders, Geometry Shaders, Pixel Shaders, Unified Shaders, Programmable Vertex Shaders. In a revision I was editing offline (which I guess will never see the light, I'm too busy) I started from a "generic shader", then specialized for vertex, geometry and fragment. An issue which came out is that the Input Assembly stage (builds vertices for VS processing) may experience additional expansion. It is currently FixedFunction-ish as far as I know but maybe it should be taken in consideration. Programmable vertex shaders: I don't see the difference with Vertex shaders. Unified shaders: this is implementation-specific detail and must be noted on HW pages, as already written, the processors remain logically dinstinct.
*Shading Operation Types: what do you mean by "operations"? In general, it would seem this goes against the idea that shaders are just programs (which, besides all the criticism seems to be The Right Way).
**Light Source Shaders, Surface Shaders, Displacement Shaders, Deformation Shaders, Volume Shaders, Imager Shaders: none of this shaders do exist in realtime. Some applications do have "light source shaders" but it's application specific jargon (are you speaking for offline?). "Surface shaders" is also slang which were being used by a few apps. "Displacement s. and Deformation S." can be mostly done via VS or VS+GS: they surely should not be noted.
*Shading Effects and Algorithms. I also tacked this problem in the offline revision. I would suggest to put this on another page. The list is going to be huge and (most of the time) of little value. Consider this encourages enumerating human creativity ("list of existing colors" or "list of things you can think with your brain").
*APIs and Software Libraries. I don't think APIs should need their own paragraph. What do you mean by "software libraries"?
*Hardware accelerators. I see little value in this.
MaxDZ8 talk 11:38, 23 February 2007 (UTC)
thread_title:  Hardware Accellerators 

message: 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)
thread_title:  Unified shader architecture 

message: 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)
thread_title:  Damaged beyond repair? 

message: 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 shadingBobtheVila 
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)
replies: text:  Only people with a average level of understanding with computers? May be only people with some degree of understanding Computer Graphics. Computer Graphics is notoriously famous for its strange terms... As far as I know from my professor. Anyway, vertex shaders do not calculate physics, but they can be "set" to work according physics. Draconins 14:37, 4 December 2006 (UTC)
replies: text:  I'd suggest against a separate technical page.  Break it into its own section with an appropriate title.  Compare to other articles like General relativity that start out with a reading level appropriate to high-school educated people and then gets increasingly technical for those who are interested. Tarinth 17:13, 28 December 2006 (UTC)
thread_title: Hella Confusing, Yo

message: 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)
replies: text: no offense, but what i came here to find out was how this impacts the games i play and how it will make the game look, enabled and disabled.  maybe thats an idea for some pictures? -divinechancellor
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)
thread_title:  How it works 

message: 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)
thread_title:  Differences between Shader Model versions 

message: 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)
thread_title: Congratulations!

message: 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)
thread_title:  Removed sentance 

message: “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)
thread_title:  Misleading regarding floating point 

message: 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)
thread_title:  Split into 2 pages? 

message: 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)
thread_title:  Unified shader