Talk:Shader/Archive 2

Archive 1

Archive 2

Proposed New Stucture

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))

Hardware Processing and Pipeline Architectures

• Vertex Shaders
• Geometry Shaders
• Pixel Shaders
• Unified Shaders
• Programmable Vertex Shaders

Shading Operation Types

• Light Source Shaders
• Surface Shaders
• Displacement Shaders
• Deformation Shaders
• Volume Shaders
• Imager Shaders

Shading Effects and Algorithms

• Lambert
• Gouraud
• Phong
• Blinn
• Oren-Nayar
• Cook-Torrance
• WardIso

APIs and Software Libraries

• OpenGL
• Direct3D
• ...

Hardware Accellerators

• 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)

Unified shader architecture

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)

Damaged beyond repair?

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)

Hella Confusing, Yo

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)

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)

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

• CG technical terms shall be introduced. Although 'sampler' should be definetly introduced here, many other terms shall be defined in other articles. Future versions will use wikilinks more heavily. The understanding of the terms will still be reader's responsability.
• A non-technical intro is definetly a need (it originally wasn't, but it evolved like that).
• Noted a few user request to keep the technical discussion. Issue: how are all the others to be satisfied? Another page?

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)

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)

That's a great idea. I'm taking a note for future versions.
MaxDZ8 talk 13:26, 16 January 2007 (UTC)

Readability of this article

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.

How it works

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)

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)

Differences between Shader Model versions

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.

• Vertex model 1 is linear execution.
• Vertex model 2 adds static branching (branching based on uniforms).
• Vertex model 3 adds dynamic branching (branching on varyiants/attributes) and vertex texture fetch. Also, vertex formats are more flexible. Instancing isn't really a shader functionality...
• Vertex model 4. I don't know. I guess it adds a instance count like GL, I haven't read the D3D docs yet.
• Geometry model 4: I still have to read the intructions.
• Pixel model 1 isn't really shading but a masked FFP. The numbers may be limited to [-1, 1] (or maybe [-2, 2]?).
• Pixel model 2 adds higher dynamic range (16 bit half and 32 bit single precision) and static branches.
• Pixel model 3 adds dynamic branches.
• Pixel model 4 (not sure) adds indexable pixel registers (previously indexing was allowed only in vertex shaders). Multiple render targets are probably required now.

MaxDZ8 talk 17:43, 30 January 2007 (UTC)

COMPLETE ARTICLE REWRITE

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 made these changes specifically in response to the people on this page who said how awful this article was was and that it needed a rewrite. The objections were mainly that it reads like a technical article at siggraph and tells nothing useful for the normal encyclopedia user after the first few paragraphs.

If there is anything INCORRECT about the new article, by all means change it. And if you want to put the jargon-stuff back in, feel free to do that too, though I would suggest a seperate technical article about the specific topic, as you did with shader languages. and I was wondering myself if the stuff about GPU science processing was excessive.

But for the sake of the readers, I would really advise against reverting the entire general-readership version and replacing it with the confusing mess that was there before. At least until others weigh in here.

Sys Hax 16:30, 26 January 2007 (UTC)

No offense, but your version is too much trimmed down and for me seems to be slightly confusing and "incorrect" (I am sure that I am quite understand CG). Well, how about others? Draconins 00:30, 27 January 2007 (UTC)

if it's incorrect, then for god's sake fix it it! I imagine that inaccuracies would be minor though, as I got most of that stuff from the previous version and nvidia's site. If it's confusing, please make it clearer, that's what we do here. however it couldn't POSSIBLY be more confusing that what came before. I couldn't make heads or tails of the previous article, and I have a CS degree and did operating systems programming in assembler for six years.

The prev version discussed the parameter types fed to various directX shader functions. What do you think the high-school kid who comes here because he's curious about his graphics card would make of that? Nothing! And he'd go away confused and humiliated, thinking he's stupid. THAT image was in my mind when I decided to rewrite this thing.

That kid should be our target audience: an intelligent curious person, not an expert in the field. However WP ought not be limited to that and I would invite any of you graphics hacks to copy from the prev version and paste into a new section of this one, perhaps titled "technical description of vertex shader function"

Just please don't revert the entire thing... *NOT* for my sake, but for the sake of that curious high-school kid who's now just a gamer, but if exposed to the machinery behind his games, will in a few years become one of "us".

Sys Hax 02:12, 27 January 2007 (UTC)

Well, I am still wait for others for now. However, well your tone answering this seems to be angry. Please calm down. I am still waiting how other will respond to it. I am just stating my opinion. Please calm down..... T_T . Cheers. Draconins 09:20, 27 January 2007 (UTC)

??

This is off topic, but I'm not angry. I AM concerned that someone will revert this back to something that won't help the kids who just want to find out what a shader is. The only thing I can figure is that either other people whose edits are challenged DO get angry and so you expect it, or your expertise is in a non-English language, and "angry" isn't the exact word that expresses your concern.

If you ultimately revert the article, I'm not going to get into an edit war; I'll shrug, abandon this one, and and go look at other articles. My only emotion will be sadness for the kids.

Sys Hax 11:34, 27 January 2007 (UTC)

I like Sys Hax' rewrite. Unlike the old version, it actually makes it reasonably clear to the reader (me at least) why you would want to use shaders; a person reading an encyclopedic article on shaders would expect to be introduced to the motivation behind creating shaders and what they do — how they do it needs not be explained in the level of detail of the old version IMHO (though perhaps a little more than that of the new one). The new version could certainly use a lump of tweaks and a few illustrative images, but I think it is a much better starting point than the old one. — Peter L <talk|contribs> 17:29, 27 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.

1. 05:34, 23 January 2007: Rejected. Rationale: calling for extraneous concepts (let triangles pass but edges and curves are simply not there). Removed uniform/variant description. Contains false statements. Further subjective considerations.
2. 06:06, 23 January 2007: Rejected. States again the computer program thing (unnecessary), assumes the computational element does contain graphics data. States again the multi processing unit thing. Removed uniform/varying description.
3. 06:09, 23 January 2007: Accepted. Removed real time shader structure. This didn't fit anyway.
4. 06:11, 23 January 2007: Rejected. Minor edit, not really an improvement.
5. 06:22, 23 January 2007: Partial. Removing list of applications is ok. Moved technical information to the end (not considered optimal but agree, changed name to "details", very generic, but at least doesn't mention hardware which simply doesn't fit). Mostly copyedits. Removed note on non-real time. Also agree on removing the "Lighting and shadowing" section.
6. 06:32, 23 January 2007: Rejected. Moves "pixel shaders" before "vertex shaders" because "more general and common". Besides this being not true on general, this doesn't fit the silicon.
7. 06:40, 23 January 2007: Partial. Removes pixel shader processing unit note (ok but this creates a too short sentence which should be fixed).
8. 06:44, 23 January 2007: Rejected. This is shocked me. Besides what you think about the article or not, the previous article was totally verifiable thuru its references. Now, the article is unreferenced and the old references are deleted. I can see your effort but this one is really weird.
9. 06:59, 23 January 2007: Accepted... Although they're redundant with concepts that can be inferred easily from the references and some are outdated, those are kept anyway.
10. 07:01, 23 January 2007: Accepted. Structure has been changed and this makes now sense.
11. 07:03, 23 January 2007: Accepted. Minor edit (although we all know first gen geometry shaders could be suboptimally implemented).
12. 07:13, 23 January 2007: Uncertain, rejected. This doesn't sound like improving to me but I cannot weight this one. Rejecting because of consistency up to now.
13. 07:32, 23 January 2007: Accepted... although some the wording isn't exactly encyclopedic and I am unsure about it's usefulness.
14. 20:44, 25 January 2007: Rejected. Removes confusing tag. It's easy to remove confusing tags! It just takes to remove everything that sources information!
15. 20:48, 25 January 2007: Rejected. Doesn't sound like a real improvement.
16. 20:59, 25 January 2007: Rejected. Besides it 'condenses' by being more verbose, providing longer list of application isn't of great help (it wouldn't be complete anyway).
17. 21:01, 25 January 2007: Rejected. Just plain out false. It could be true by changing verb to 'could' but this would then be useless.
18. 21:09, 25 January 2007: Accepted. Quoting from marketing departments is BAD. Better to extend this with real links.
19. 00:53, 26 January 2007: Rejected. False statements on geometry shaders. As for "physics shaders", 1) they simply do not exist in GL nor in D3D and 2) this is confusing the goal with the tool.
20. 01:01, 26 January 2007: Rejected. Depends on the previous, which is being removed.
21. 01:22, 26 January 2007: Rejected. Inaccurate wording and very likely to be false (implementation dependant). Too high level to make sense.
22. 10:39, 26 January 2007: Accepted. Some things aren't really ok (for example NV chips always did IEEE right since FX, denormalized FP are not required as I know) but this is rather good. NOTE: the FP accuracy note is possibly false.
23. 10:46, 26 January 2007: Rejected. Does not sound encyclopedic. Somewhat not true.
24. 05:26, 27 January 2007: Rejected. Minor edit depending on previous.
25. 21:57, 27 January 2007: Rejected. Depends on content being deleted.
26. 14:41, 29 January 2007: Rejected. Depends on content being deleted.

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)

Congratulations!

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)

Removed sentance

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)

Misleading regarding floating point

“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)

Split into 2 pages?

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)

Status of article?

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)

Hi AshleysBrain, I looked up the source of the "don't edit" tag, and I've added a note for when it was posted. That was just from yesterday, so don't worry too much. It seems like things are pretty lively here as this is a subject that I think a lot of people are interested in.

MaxDZ8, I appreciate your gung-ho attitude on moving forward with this by working on it yourself, but please don't fall into the same trap as everyone else has: Remember to make it accessible before you make it exhaustive! Contributors: Wikipedia is the first stop in the quest for answers, not the only one. Give an intro, lead them into the subject for a while, then give them references if they want to learn more.

Due to the warning on the front page, I'll list a couple references I like here:

• MSDN Vertex Shader intro (from DX8)
• A very rough description of vertex versus pixel shaders

-- El benito 02:52, 2 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)

Unified shader

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)