Vertex shading on CPUs & accomodating vertex-biased work
- Thread starter Titanio
- Start date
Jawed
Legend
Jaws said:
Sadly, this breaks down extremely quickly. One thing I learnt from the efficiency thread is that NV40/G70 has "combinations" of instructions that it can execute in one cycle.
There might be 50 or 100 of these different combinations (just a guess). Some combinations will amount to only 2 instructions per clock. Others might amount to 6 or 8 or more instructions.
It's hideously complicated.
Simple texture operations appear not to block ALU1 - I don't know what defines this. But I don't think it's possible to say that a texture operation on ALU1 always blocks that ALU from other instructions.
Jawed
Inane_Dork said:
I actually figured, just purely looking at Gflops which may be simplistic, that it would take nearly all your SPEs.
But while cycle-to-cycle you may see a 100:0 ratio of vertex to pixel work on Xenos, frame-to-frame you won't. The tasks being talked about where 100:0 is useful apparently would be ultra-fast. If that were the case, I'm sure you could for one or two tasks per frame do the same with your SPEs and VS, before letting the work balance out more (on the CPU) between vertex work and other CPU stuff i.e. do a really fast z-pass with all SPEs once before returning to a more balanced physics etc/vertex mix for the rest of the frame.
Frame-to-frame, rather than cycle-to-cycle, what might the ratio look like when we move away from a heavy pixel bias? How far would it go in favour of vertices? That would be a better indicator of how many SPEs would have to generally be invested in vertices. If over the frame the proportions of work are more like 50:50, which in itself would be a significant shift away from a (typical) heavy pixel bias, looking purely at Gflops you might need maybe 2-3 SPEs for most of the time to match the same amount of vertex work in absolute terms, as is being done by Xenos. That'd be pretty comfortable to accomodate, I'd think. 60:40 would be more extreme and you'd need about 3 SPEs. 70:30, would require 4.
Also, I'm perhaps missing something, but why would your pixel shaders have to be more simple?
Re. load balancing, how much overhead would a software solution introduce? Although NVidia may "provide" here, if we're lucky. The problem could be approached from a number of angles, methinks, if done in software.
Jawed said:
Something tells me that we won't get to the bottom of this but anyway, I opened another thread to discuss specifically the G70 fragment pipeline,
http://www.beyond3d.com/forum/viewtopic.php?t=24933
But from what you've mentioned, the 5 instructions/cycle for each G70 fragment pipeline may also exclude 'norm'... :?
Jawed
Legend
Xenos is designed to switch thread every clock. It doesn't care if there's a change from pixel fragments to vertices because the shader instructions and data formats are essentially common to both types of objects.
The loss in efficiency would appear to derive from units that are operating (because of the 16-wide array) but have nothing to do. A good example is where a triangle edge leaves one or more pixels in a batch of 16 "off the edge" of the triangle.
Jawed
The loss in efficiency would appear to derive from units that are operating (because of the 16-wide array) but have nothing to do. A good example is where a triangle edge leaves one or more pixels in a batch of 16 "off the edge" of the triangle.
Jawed
Their respective names are self-explainatory: the first one is a cache and saves more recently transformed vertices, the second one is a buffer and its purpose it's to reduce pipeline bubble/stalls between VS and the setup engine.Jawed said:
As example we could afford a post transformed cache of few vertices while there could be much larger fifo (filled with transformed vertices incoming from the post transformed vertices cache) that sits between VS and setup engine to damp workload unbalance.
Yep.Jaws said:
That's the source of the difference. I thought one of the 2 ALUs was used as a texture coordinate setup unit when a texture op was made. Thus either you get 4 math ops + 1 free op or you get 2 math ops + 1 texture op + 1 free op, peak. That was my thinking, anyway.
Certainly possible, I would think. You might find yourself limited by fillrate, bandwidth or one of the fixed function parts of the pipe, but it would be interesting to see where you could throw the bottleneck.Titanio said:
It depends on how you're thinking of adding polygons. If you want to draw the same objects just with better tessellation, then pixel shader complexity need not change. If you want to draw far more objects with roughly similar tessellation, you will be drawing more pixels.
Inane_Dork said:
Thanks again for your reply.
I'm not sure I really follow on this part, though. How are you painting more pixels? Does this not remain constant, fixed to resolution? Or are you talking about work per pixel? Or..?
If this were the case, would this - high vertex bias - not then be quite unattractive (depending on developer goals), on Xenos? It may be a more sustainable situation on PS3, where for example with a 50/50 vertex
ixel ratio, on paper RSX would be left with roughly 2x the pixel power to keep pixel shader complexity higher.I guess if you stuck with a Z prepass, it wouldn't be too different. Though, it depends on what you're adding. If you add more guys, no big deal. If you add more birds, small deal as you replace skybox filling with more expensive ops. If you add more trees, the alpha testing may add work. And the main culprit is if you added more particles which all have to be pixel shaded presuming they're not occluded by an opaque object.Titanio said:
Well, if you're comparing a few SPEs + RSX to Xenos, yeah, the first option has more power.If this were the case, would this - high vertex bias - not then be quite unattractive (depending on developer goals), on Xenos? It may be a more sustainable situation on PS3, where for example with a 50/50 vertex
But vertex work can go on XeCPU pretty well, and that would increase the pixel work you could do.IIRC, ERP commented that with X1 level pixel work, you might get around the Xenos' polygon limit. With aid from the XeCPU, you could push a bit more complexity than that. Anyway, at that point you really have to re-examine what has to take place in the pixel shader. Is normal mapping worth it anymore? I don't know.
Inane_Dork said:
Ah, I see what you're getting at now. I can see now how the average may raise depending on what you're doing.
Inane_Dork said:Well, if you're comparing a few SPEs + RSX to Xenos, yeah, the first option has more power.
True. In our 50:50 instance, thinking again in quite simple "gflop" terms the usage of two Xenon cores for vertex processing could allow Xenos could then split 15:85 in favour of pixels (maintaining the same amount of vertex performance before). But to be then fair to PS3, also keeping just one PPE for non-graphics work would still allow it, roughly speaking again, nearly 2x the power for vertices and 1.15x the power for pixels vs X360.
As the bias toward vertices goes up, the gap in terms of vertices goes down and the gap in terms of pixels go up. The only scenario that I can figure out where X360 would "win" is where the 2 Xenon cores and a really high proportion of Xenos were busy with vertex work - say 90%. This is a crazy, academic extreme of course, but in that scenario, X360 would have 1.2x the power for vertices, but the gain would be on only one front (on the pixel side, PS3 would then have a whopping 12x gap).
There are ways to try reduce the pixel load with some vertex tricks as mentioned before, but the same options are open to both systems on that front.
I think you're more likely to gain useful insight in thinking of reasonable scenarios and what usage is like in them. For instance, I wouldn't expect more than one thread on the XeCPU to be generating or shading vertices simply due to graphics state synchronization. Sure, you could work it otherwise, but I would expect no more in the general case.Titanio said:
True, but you always gain performance on Xenos from that, whereas you only gain a speedup on RSX when you're pixel shader bound. It's the mixed blessing/curse of dedicated hardware.
EDIT: You don't *always* get a speed up on Xenos, but you're much more likely to get more work done in its case.