xbox360 gpu explained...or so

[DemoCoder]

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.

 

[fek]

If hw would work as Jawed described this case will be quite common, not rare!

No.

No one is saying the hw has to transform ALL the vertices before start to work in pixels, what I say is in order to avoid pipeline bubbles you'd want to allocate some ALUs slots to vertices way before all the previous fragments batch is completely shaded.

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.

Once vertices are transformed new primitives are assembled.
Rasterizer takes new primitives and extract (walk..) fragments to shade.

This is stating the obvious.

 

[Fafalada]

Clearly a great example of vertex fetch limited rendering is a stencil shadow rendering pass

Lay off the drugs, Please.

 

[Jawed]

No one is saying the hw has to transform ALL the vertices before start to work in pixels, what I say is in order to avoid pipeline bubbles you'd want to allocate some ALUs slots to vertices way before all the previous fragments batch is completely shaded.

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

 

[RoOoBo]

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

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.

 

[nAo]

No.

yes

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

I never claimed that, try to read this:

A stupid arbiter would just transform vertices until a internal buffer that stores transformed vertices is full, then arbiter switches ALUs to process pixels and so on, autobalancing pixels and vertexs troughput.

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

Vertices are the First Cause, pixels are the conseguence

This is stating the obvious.

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

 

[Joe DeFuria]

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

 

[RoOoBo]

Clearly a great example of vertex fetch limited rendering is a stencil shadow rendering pass

Lay off the drugs, Please.

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 .

 

[nAo]

Clearly a great example of vertex fetch limited rendering is a stencil shadow rendering pass. Xenos should be very good at those...

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

 

[RoOoBo]

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

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

 

[fek]

I never claimed that, try to read this:

You did. Here:

Pixels have priority over vertices only when there's no more space for incoming vertices. You're very good at twisting arguments, nice

Our discussion shows this claim wasnt correct.

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

Are you insulting me? Hope not.

 

[DemoCoder]

Good one joe.

 

[Joe DeFuria]

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

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.

 

[John Reynolds]

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

Stop talkin' all technical, damnit!

 

[fek]

You must me joking. No one has said that ALL the vertices had to be shaded before all the fragments.

Someone has.

I agree with the rest you wrote.

 

[DemoCoder]

Clearly a great example of vertex fetch limited rendering is a stencil shadow rendering pass. Xenos should be very good at those...

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

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.

 

[fek]

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?

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.

 

[Fafalada]

In fact the shader unit is vertex limited as there shouldn't be anything to be done for fragment shading.

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

 

[nAo]

Pixels have priority over vertices only when there's no more space for incoming vertices. You're very good at twisting arguments, nice

Our discussion shows this claim wasnt correct.

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.

Are you insulting me? Hope not.

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.

 

[fek]

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:

new pixels to shade that the rasterizer have still to walk upon (tranform vertice and assemble primitives in advance!)

Go back to the topic now.