Talk:Pixel pipeline

Someone needs to explain what a pixel pipeline was

Someone needs to explain what a pixel pipeline was and what it is now. I can't tell from this article. 23:02, 20 March 2007 (UTC)

Someone needs to clean this up

Someone needs to clean this up, the grammar is pretty bad and it lacks any section distinction. Ixtli 18:27, 12 January 2007 (UTC)

What is better?

What is better? More Pipelines and 128mb of Video RAM? or Less Pipelines but 256mb of Video RAM. -Bandit

Depends on the game and texture quality setting. Higher textures will run better with more VRAM. But the game still makes a big difference in how much it utilizes the pixel pipelines.. Last Avenue 01:22, 25 January 2006 (UTC)

This page doesnt explain

This page doesnt explain the exact impact of pixel pipelines on rendering rate. My guess that is if you have twice as many pixel pipelines you will be able to process twice as many pixels, effectively doubling (or close to doubling) the preformance. Also maybe there should be somthing on texture pipelines? ~dart

The definition of a pixel pipeline is far more ambiguous today than it used to be. The different parts of the chip are being separated and their numbers are no longer in 1:1 proportion. So, it's tough to tell. More pixel pipes = faster, but there's also a limit imposed by available memory bandwidth. And honestly the definition is just not what it was. In fact, it may be hard to even say there are "pixel pipelines" in the near future. --Swaaye 20:10, 3 July 2006 (UTC)

would is be better to have a faster clock speed or more pipelines? Say you had two cards that that had the exact same specs (same ammount of memory, same memory bandwidth, etc) execpt for clock and pipeline. Say one had a 550Mhz clock and 16 pipelines, and and the other had a 440 MHz clock and 20 pipelines. Which would be better, or would they both be the same? ~dart

also, does the pixel pipeline have anything to do with pixel processors? Take the 7800GT, its got 20 pixel pipelines. But i've see other places refer to the same number (20) as pixel processors?

Someone should add

Someone should add the GeForce 8 series.

Merge with Pixel Pipelines

Support - Both articles are on the same topic and the name is only slightly different. Bakkster Man 16:02, 2 May 2007 (UTC)

DirectX

This article discusses only DirectX implementations of pixel pipelines, so I have altered the title accordingly.

This has been a terrible idea IMHO. I would have reverted it right away if you wouldn't had occupied the previous name with a new page. While we're at this, please elaborate on your concept of "DirectX pixel pipelines" and "OpenGL pixel pipelines".
MaxDZ8 talk 17:46, 6 August 2010 (UTC)

Requested move

The following discussion is an archived discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. No further edits should be made to this section.

The result of the move request was: Per WP:BRD I have reverted the move to allow the merits to be discussed. — Martin (MSGJ · talk) 12:25, 3 September 2010 (UTC)

---

okpkpkkpkp

Pixel pipeline (DirectX) → Pixel pipeline — Proposal to revert move/replication. 1-The splitting is based on non-trivial concepts which would need discussion. 2- There's not enough content to justify a page separation.
MaxDZ8 talk 06:53, 9 August 2010 (UTC)

• Question - There's a request at the top of this article to merge it into graphics pipeline. How does this move request stand with respect to that merge request? -GTBacchus^(talk) 23:22, 1 September 2010 (UTC)

• Move In hope of this "discussion" eventually ending, I merged and redirected Pixel pipeline back to this article. So now there's only one article and it can be moved back to where it belongs. Propaniac (talk) 15:37, 2 September 2010 (UTC)

The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page. No further edits should be made to this section.

Req move VS mergeTo

This is meant to be a response to GTBacchus in the "Requested move" thread. GTBacchus asked: "How does this move request stand with respect to that merge request?". There's surely some subjectivity to this, but when it comes to me, I have to say that the requested move is not an improvement, in the sense that it doesn't work to the goal of merging.
The requested move merely rolls back part of the wiki regarding shader technology back to previous state, which has been far from optimal for quite a long time. As far as I know, there's no active merging effort around.
I have personally invested quite some effort back in the past but I failed in getting skilled editors to that set of articles. Unfortunately, as more and more editors given up maintaining, more and more users want to have a try at this, resulting in a set of stubs and little more than that.
What recently happened is quite indicative of how "improvements" are carried over this set of articles.
MaxDZ8 talk 17:01, 6 September 2010 (UTC)

So, what kind of work would you say most needs to be done, regarding these articles? Are there many pages that need to be merged, or just the two I initially asked about? -GTBacchus^(talk) 22:46, 6 September 2010 (UTC)

First of all, what articles are we talking about? An incomplete list includes Pixel pipeline, Graphics pipeline, shader, vertex shader, pixel shader, geometry shader, 4th generation shading pipeline, fixed function pipeline and surely others I cannot even think about. Those articles cover a complex subject of computer science which partially shares some terminology with other application fields. To further complicate the issue, the degree of historical evolution is massive, with publicly available documentation stemming mostly from older generation technology.
It is clear the articles needs to be merged however, a few users in the past wanted to leave room for disambiguation.
The main problem here is that based on my experience, bold changes are seldom appreciated. Trying to enforce an unified structure was something out of reach. Given the small amount of skilled/qualified editors available on this field of expertise, the produced pages resulted in plenty of redlinks to be populated. As such, some other editors, likely not understanding the implications behind the approach opposed the changes.
While this was being carried over, other editors just went bold and added articles over articles. Right now, most are basically stubs but I'm having consistent difficulties in precisely mapping a set of articles to cite here.

So, what should be done? Those pages hove shown consistent correlations over the years so it really makes sense to have a coordinated effort on them. I cannot see how to make this happen in a reasonable time frame, so when it comes to me, I just do what I'm doing since a few years: I leave them here and I pray someone will eventually try to put serious effort into that.
MaxDZ8 talk 13:37, 7 September 2010 (UTC)

Thanks for the thorough answer. A pool of editors with knowledge and time is obviously a resource we can't do without, and when they're in short supply, it's hard to build the encyclopedia. There are things we could do, though, to make these articles more visible to the right editors.

I've just added a banner to the talk pages of all the articles you linked in your reply. They'll all now appear on lists as part of WikiProject Computing, and that's where you'll find more experts hanging out and working on computer science articles. From skimming their page, it looks like they might be open to highlighting these articles for special collaborative attention. That could perhaps overcome the effects of inertia and erosion that you describe. You might just post a note at the project talk page, and see if there's any interest.

If I can be of any assistance, just let me know. Take care. :) -GTBacchus^(talk) 23:02, 8 September 2010 (UTC)