xbox360 gpu explained...or so

I think we all agree the situation we want is all blocks "not quite full", the question we are debating is what algorithm to choose to insure this.

 

No.

Which substantially different from your previous claims (vertices always take priority over pixels).

Pixels take priority over vertices to improve blancing most of the times.

This is stating the obvious.

 

Lay off the drugs, Please.

 

Agreed.

Just remember that 1 triangle consumes upto 3 slots in the register block. But when it is rasterised the resulting pixels could easily consume 10s of thousands of slots.

Until some spare slots come up after all of those pixels have started shading, there is no point in starting another triangle.

Believe it or not, but all the pixels don't run out at the same instant. The unified shader will have plenty of time to see that there are no new pixel command threads being generated.

When you load a triangle into the register block you don't have to execute it immediately. You choose your time. As the number of pixels to be shaded dwindles and the latencies due to texture fetching mean that no pixels can be shaded, the vertices get their chance to run through the unified shader.

The developer will probably provide compiler hints in the form of "typical" execution limits for loops, for example "this lighting loop will typically handle a maximum of 6 lights". Armed with that information the scheduler, in evaluating the priorities of command threads, will know the remaining execution cost for each command thread, and can therefore decide how early to start-up the vertex threads, in order to prevent a bubble forming after the last of the pixel command threads have finished.

All the while, the focus of the scheduler is on getting the pixels shaded - because buffered pixels waste valuable die-space in buffers.

You never want to buffer pixels mid-render. You want them to be in the register block or in the backbuffer

Jawed

 

You must me joking. No one has said that ALL the vertices had to be shaded before all the fragments. You have to shade vertices ahead enough in time that you don't run out of fragments creating a bubble in the pipeline. I have yet to read the patent but my guess is that the 'pixel priorization' you say that ATI people told you only means that a large enough group of unshaded vertices must be stored before the shader unit can switch from fragment to vertex. May be because that switch is expensive. But creating bubbles out of nowhere just because you want to empty your fragment pipeline so that you can wait even more cycles doing 100% nothing in the fragment pipeline until the vertices are shaded and new fragments generated is silly.

And you actually want the preshading fragment queues to be and remain filled as fast as possible because early Z and hierarchical Z have the task of remove large amounts of fragments even before they have to expend cycles being shaded and consuming texture bandwidth for absolutely no useful work. For filling those queues you require the vertices shaded as soon as possible.

 

yes

I never claimed that, try to read this:

If vertices always take over pixel there's no autobalancing at all.

Vertices are the First Cause, pixels are the conseguence

I know, you asked me to explain the obvious to you

 

I'm trying to digest al this info...can someone verify for me if I've got the basics right here?

 

In fact the shader unit is vertex limited as there shouldn't be anything to be done for fragment shading. However the GPU pipeline as a whole isn't likely to be (vertex) shader limited but fillrate (z and stencil) limited .

 

Stencil shadows rendering is vertex fetch limited? are you serious!? You must be kidding..

 

That's too specific for me ... may be if you removed the details ...

 

You did. Here:

Our discussion shows this claim wasnt correct.

Are you insulting me? Hope not.

 

Good one joe.

 

Well, you'll just have to come up to speed.

Fyi Dave...you have my permission to use that diagram in any article you produce.

 

Stop talkin' all technical, damnit!

 

Someone has.

I agree with the rest you wrote.

 

The R500 should be a monster at this. 64Z per clock and all 48 ALUs allocated to vertices. (is it possible?)

If no shader program is assigned, and color writes are disabled, will the arbiter never try to assign ALUs to pixels, or are they still neccessary for Z/Stencil data to flow to the eDRAM/ROP chip?

The more I hear about the Xenos, the more I have to congratulate ATI on a job well done, and a gutsy, risky, high payoff design.

 

Correct. Color write disabled and alpha test disabled mean no fragment shader work to be done. From the unified shader perspecitive, this is a heavily vertex biased situation, all pipelines can be (and are) allocated to vertex work.

 

He said "vertex fetch limited rendering" which is nonsense as you pointed out already. Even more so if you start doing soft stencil shadows.

 

I was referring to when the hw switch to work from vertices to pixels, since the patent is saying exactly the same thing you're also saying the patent itself it's not correct.

You asked me to explain in other words what I previously wrote, since you couldn't understand it and suddenly you tell us it's so obvious. Well, you asked me to explain it to you
Maybe you haven't heard the term 'pixels walking' before today, it's a pretty common term in literature.

 

Don't lecture me. You are being childish.
This sentence is not exactly decent english and deserved to be explained better for the sake of clarity:

Go back to the topic now.