Megadrive1988
Veteran
this large number of SALCs remind me of the thread units we talked about over a year ago. basicly, thousands of these things.
Can this SONY patent be the PixelEngine in the PS3's GPU?
- Thread starter j^aws
- Start date
this large number of SALCs remind me of the thread units we talked about over a year ago. basicly, thousands of these things.
Panajev2001a
Veteran
DeanoC said:
Well, I leave the bulk of the computational heavvy workload to the APUs and we could always whish these 256 SALCs to be per PE and having 4 PEs in a VS we would have about 20 fragments per cycle processed.
I do not think that Rasterization will be the bottleneck next-generation.
Edit:
32 serial ALUs = ( 8x3 bits ALU ) * ( 4 channels ).
Right ?
So, this would be a SALP ? We would process each channel by a separate portion of the SALP, right ?
How about a SALP per PE ?
4 SALPs per VS then and we would get 5 fragments ( by your calculation ) per PE per cycle or about 20 in total.
So we are talking about 128x3 bits ALUs connected in 4 serial pipelines.
As I said, once you finish and test a single 3 bits SALC and you go to finish a full SALP then 4 SALPs is not too much of a jump for the engineering team.
Somethign tells me that due to the high redundancy in CELL and in this SALC/SALP structure the engineers dedicated to maximization of yelds should have at least some more breathing room.
Question: Why are we still worried about and practicing borderline numerology instead of worrying about functionality, effeciency and what it does for you. First of all, nobody is limited by sheer rasterization anymore. As Dr. Kirk stated, it utilized <5% of a contemporary IC and I have yet to see a single sign or statement about being raster limited moving forward -- already the NV40 saves logic by assuming that texture ops will be diminishing in importance vis-a-vis shader ops.
And assuming even if you spend 500clocks/fragment and it takes 2 clock cycles to process a fragment per virtual pipeline, it doesn't mean much without knowing the absolute clock. If it clocks at 1 GHz, thats 2GPixel/sec assuming this Fig 6 is indicative of a Pixel Engine in the 'other' Fig 6; which is logical considering the task and the construct outlined.
Isn't the fact that you have the ability to dynamically (re)assign and manipulate the resources and have a such variable output more important than sheer numbers? Especially when comparing it against, say an R300/420, or even the NV40.
And assuming even if you spend 500clocks/fragment and it takes 2 clock cycles to process a fragment per virtual pipeline, it doesn't mean much without knowing the absolute clock. If it clocks at 1 GHz, thats 2GPixel/sec assuming this Fig 6 is indicative of a Pixel Engine in the 'other' Fig 6; which is logical considering the task and the construct outlined.
Isn't the fact that you have the ability to dynamically (re)assign and manipulate the resources and have a such variable output more important than sheer numbers? Especially when comparing it against, say an R300/420, or even the NV40.
I think we'll have much more fragment per cycles processed on a 4 VS Visualizer (or RealizerPanajev2001a said:
).At this time I (you?) need to process 4 vertices at the same time to fully exploit VU1 power, and I have (almost) single cycles access memory with no wait states. (VU1 memory accesses should have higher prority than GIF reads and VIF writes IIRC).
In a 4 Ghz chip that will have for sure longer pipelines than PS2 VUs have, on a shader that requires random accesses to external memory (TMUs? sigh..) what will we do? Or Sony provide us with a novel shading mechanism or we'll have to process a LOT of fragments at the same time in order to hide latencies.
Ok..we already discussed that in another thread some weeks ago. My idea was to convert most of the random accesses to memory to fetch texels in streamlined accesses. That's possible in many cases..but what about things such dependent textures reads or everything that has dynamic mapping coordinates (ie env maps..)
Are we doomed?
Obviously we aren't..but I'd very like to know what STI will do to avoid this kind of problems.
Or maybe they will do nothing about it..just like Sony did with clipping or mipmaps lod selection on the GS..
ciao,
Marco
Vince said:
Because were examing what this is and why? This implies an architecture this scales nicely, low complexity fragment operations and low range data increases fillrate signifcantly. High complexity operations take longer but will likely be submitted less often (a complex pixel shader would take more cycles so less fragments are generated).
Also the fact this hints (just hints mind) at high gfx clocks is interesting. Because tradionally (including PS2 GS) gfx clocks have been low and rely on the natural parellism in graphics to achieve high throughput. The next question you should be asking is why? Why increase clocks over repeating functional blocks on the chip?
Raster bound is easy, shadows being the usual suspect. Simple shaders with fairly complex fragment operations. But if this is programmable then things like NV style depth scissor should be easy to help reclaim those valuable cycles.
Don't be so damn defensive... I'm here to discuss gfx architecture not to insult anybody favorite console maker. I work on consoles every day, I hate them all equally ;-)
Vince said:
So you know that PC don't have similar architecture for there fragment ops.
The actual hardware is NOTHING like the model presented by DirectX.
DeanoC said:
Heh. First of all, I was talking to Panajev since it seems like he always has to justify a number and make it looked bigger. I mean, there's nothing wrong in what you stated that needs a responce to placet the people around here that love to post specs with bigger numbers over understanding why and how it applies.
Hell, I was basically agreeing with you so I'm sorry if I came off as being defensive. I think it's a smart concept all in all, although I see it applied to strictly rasterizatio, not shading tasks as you implied.
PS. Thanks for the heads up on the last part.
archie4oz said:
Actually, you cannot weld NURBS patches... All you can do is ask your 3D app to keep the edges of the patches stitched together, after you've done everything you could to build surfaces with tangency and such. And hope that your app will not fail (which it usually does a few times).
Another problem with NURBS is texturing. You either use the builtin UV parametrization, which will stretch and require a texture per patch; or you have to use projections with all their additional overhead.
Trims, fillets and such are also expensive, and even more problematic. No wonder the CG industry switched to subdivs...
Vince said:
My apolgies then for mis-reading you, Sorry.
Actually I didn't make it clear but I also mean non-shading tasks I think you right that this is logically post-pixel shader (logically becuase the fast z paths make it moveable in practise). I think its covering the tradional fixed function depth/alpha/scissor/stencil ops that go on after the colour value pops out of the shader.
I think lots of people under-estimate how complex this is, due to the hidden way its presented under OGL/DX. This seems to be a nice way to manage it (I specially like that it appears to allow simple ops to be accelerated easily), it would probably give you the double stencil only rates (32x0 of NV40) for shadows but completely programmable (i.e double colour only rate like PS2).
Laa-Yosh said:
Valence is a count how how many 'things' something is attached to. Vertex valence being the number of edges each vertex is attached to.
It has massive importance to subdivision surfaces due to the algorithms requiring special cases when vertex valence is not regular(whats regular depends on the type of subdivision surface). These non-ideal vertex valence are known as extraordinary vertices as they often require special case software to subdivide them, also the mathematical properties that make subdivision surfaces so good to work with, usually break down completely as well.
In practise they are/were what caused a number of artifacts (ripples, pinching etc) in early subdivision surface algorithms.
The higher the valence number, also usually increase the cost to subdivide (extra edge walks, eigen transform and/or memory)
Subdivision surfaces scheme can be implemented just with a bunch of vector-matrix multiply (I'm not referring to the classical representation of a subdivision scheme with a subdivision matrix..) with no knoweldge whatoever about vertices valence, connectivity or subdivision depth. There is no recursion and complexity is linear.
Unfurtunately one needs some huge tables, even if there a lot of ways to minimize tables size...all based on the topological classification of the triangles of the base mesh.
Unfurtunately one needs some huge tables, even if there a lot of ways to minimize tables size...all based on the topological classification of the triangles of the base mesh.
Panajev2001a
Veteran
Borderline numerology ?
Justifying a number and making it look bigger ? Have you ever thought about what I do as part of understanding what number is about ?
If I tell someone about the Earth rotating around the Sun at 30 Km/s and someone tells me that it is nothign because their car can do much more than 30s, guess what I will wonder if that someone understands the difference between doing 30 Km in a second or in an hour ( no, I am not sayign that this was the case between DeanoC and I, this is just a very very loosely related example ). Guess what the context matters. I am just trying to understand the number in its context.
The speed of the SALC based Pixel Engines is important as not being TMUs embedded with APUs is important.
NV40, R42x both have TMUs embedded in their Pixel Shaders and in the case of the NV40 you have TMUs in the Vertex Shaders too.
We are understanding what the SALC/SALP applies to, but the question is now shifting to other subjects.
What will we do to hide latencies in the Pixel Shaders especially when we constantly need texture samples ( which these SALPs would provide ) and the APUs need to permorm multi-cycle context switching to pass from one pixel to the next ( old pixel is stalling and a new one has to start processing ).
You want to understand how it applies, right ? So do I, but thinking a little bit forward you can also think about implementation and about what the prostected performance might mean ?
Thank you for the label, I do not want to understand why and how it applies ? Well, at least I know you do not know something about me.
Darn, what the fuck have you eaten tonight ? I know you have somewhat of an attitude, but geesh calm down... you can say the same things in mnay different ways.
Panajev2001a
Veteran
MfA said:
Scalar ( 1-3 bits ) Multiplication, Addition, Subtraction and Division is provided in the SALC ( FP and FX I think ).
Using 1 bit SALC you would need 16 SALCs to do a 4 bits multiply and you would have 8 outputs to pick up.
Panajev2001a
Veteran
If APUs cannot automatically hide the context switch latency when jumping from pixel to pixel in the case of a stall ( due to a texture fetch... hopefully the time it takes an APU to swithc to another pixel is less than the time it takes for the texture fetch to be completed ) what we can do, like nAo said, is to submit the texture fetches as early as we can and in groups to take advantage of the high clock speed of the SALPs ( which is basically loosely similar to the idea [one of the ideas] why we have double pumped ALUs in the Pentium 4: they allow 0.5 cycles dependent instructions processing to unwind cases in which you filled the ROB with instructions stalling for memory accesses and you want to get them all out in a hurry ).
It is interesting what nAo says about PS2's VU1... even with 16 KB of D-Memory with single cycle access ( basically like accessing registers, 0 cycle load-use penalty for dependent instructions you still need to be processing Vertices in a group of 4 at a time.
I do not see texture fetches in Pixel Shaders becoming less frequent and I see a potential latency issue rearing its ugly head as they say.
What are the APUs going to do ? How fast can they jump from Pixel to Pixel ? How fast in terms of latency could a group of SALC provide a bi-linear filtered texture sample to an APU and how many SALC we would use ?
There are lots of questions to be asked.
I like what this SALC/SALP structure brings and I am all forward to understand how it would be used and how it would impact the Visualizer if used for the Pixel Engines as we are suggesting.
OK so lets say I execute a 10 instruction shader, probably 30% plus of those (probably more) would be texture fetches.
Now Lets say I can afford to spend 100 instructions on a pixel, what percentage of those instructions are likely to be texture fetches?
Now lets say I can afford to spend >1000 instructions on a pixel..... you see what I'm getting at.
Current pixel shaders are a lot like early 80's programming, if you can do it with a table (texture fetch) you do, memory accesses are cheap and you can do a lot of math with one table lookup.
Once you can afford to do a lot of math instructions, or the latency on texture fetches starts to rise (and it will if clockrates go up) you'll solve the problem differently.
This brings me back to How many ops/pixel will we see on nextgen platforms
Panajev2001a
Veteran
ERP said:
OK so lets say I execute a 10 instruction shader, probably 30% plus of those (probably more) would be texture fetches.
Now Lets say I can afford to spend 100 instructions on a pixel, what percentage of those instructions are likely to be texture fetches?
Now lets say I can afford to spend >1000 instructions on a pixel..... you see what I'm getting at.
Current pixel shaders are a lot like early 80's programming, if you can do it with a table (texture fetch) you do, memory accesses are cheap and you can do a lot of math with one table lookup.
Once you can afford to do a lot of math instructions, or the latency on texture fetches starts to rise (and it will if clockrates go up) you'll solve the problem differently.
This brings me back to How many ops/pixel will we see on nextgen platforms
See, I understand what you are saying, but why do we see in off-line CG so much time ( more or less 30% of rendering time ) spent in Texture I/O ?
This is what I am getting at... just because we can afford a lot of math ops per fragment ( a renderfarm able to work several and several hours on a single frame can afford quite long shaders ), it does not eman that our texture fetches will disappear.
Of course I am not telling you anything that you do not either know or have already experienced yourself first hand.
It is true that in off-line CG they have quite a lot of time per frame and latency can be taken care of quite well, but what do we do with the Visualizer ?
I am interested in what you propose... you are talking about a way that won't be see in Xbox 2 ( texture fetches in the Vertex or Pixel Shaders will not be a huge problem as we have TMUs quite closely tied to the Shader ALUs and the Shader ALUs are multi-threaded ) and soemthing that people are not used to in off-line CG.
How much, when we are trying to march towards the quality of off-line CG, can we substitute Textures and the needed Texture fetches with Math ops ?
Latency is a main issue in all computing and in-order, single threaded APUs do not seem so latency happy: of course we can work out things playing around with the APUs, but how much efficiency are we loosing ?
How much faster would we be able to push the APUs if each APU in the VS had a small TMU attached to it with its own Texture cache allowing low latency for Texture fetches ?
Because Texture IO is incredibly slow in offline rendering, best case it's coming out of main memory, more likely off disk. It's the primary reason that renderman uses a tile based system (to maximise texture locality).
In a real time system your working with somewhat different constraints. Yes texture latency is still huge by comparison to ALU ops, but a lot of texture ops in current shaders are there to approximate calculations not as part of the art assets. Really how many textures are we likely to see combined on a pixel.
I've been looking at lighting models that take >25 dot products/pixel and that doesn't include transforming all the inputs into the right space. Once you start doing lighting at a pixel level and you start looking at better lighting models, you can easilly spend 100's of ALU ops per pixel, texture complexity even if it weren't constrained by memory just isn't going to explode like that.
You can increase the speed of your ALU's with clockrate, but doing so increases texture latency, so you need more ALU's if you want to continue to hide it. At some point you just have to say textures will take multiple clocks in the shader.
