Recent content by fek

No, AFAIK.

That's partially correct. The pipelines will be vertex fetch limited. The rest of the GPU might be limited by other factors depending on the situation. You spoke of "vertex fetch limited rendering" which is not entirely correct. But we are all being a bit sloppy (it's a forum); pointing your...

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.

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.

Someone has. I agree with the rest you wrote.

You did. Here: Our discussion shows this claim wasnt correct. Are you insulting me? Hope not.

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.

Which is by far the most common scenario and the one to optimize for.

We are discussing about which element is processed (transformed as you say) first. In this context "input vertices" and "transformed vertices" are two completely different concepts, although there's a 1 to 1 mapping between the two concepts. An input vertex has clearly not been processed...

New vertices are fetched (but not processed according to the patent) in advance and stored in the queue. Bubbles or not, in the very rare case there's no fragment to process, vertices must be processed to produce new fragments. This situation is better than processing vertices first; each...

Me and Dave discussed the incongruence in PM. It turns out we had inputs at two different levels from ATI. We can't disclose the specifics about it, but it looks like the high level load balancing algorithm is to "always" give precedence to pixels (which is natural), where my "always" would have...

Which are two quite different concepts. If there's no fragment to process, vertices will be processed to produce new fragments. That's easy.

I agree with you on this. That's exactly the same thing I understood from reading that passage. And that's more or less on the same line of reasoning we heard from ATI.

I can't understand why priorization of fragments is a bad thing in a fragment limited situation. It looks like the opposite to me: in a fragment limited scenario you likely want to process as many fragments you can to not fill up the queue and stall. Can you elaborate this point please?

This kind of stall might happen but it's an infrequent situation. You want to optimise the most frequent situation though. This policy would lead to two problems: - the first is with complex vertices holding fragments to go through, starving the rest of the pipeline (this isnt such a big...