This would a be an example of where the most generic solution, a 1-D memory space, does penalize a usage case where the more natural mapping would be 2-D.
Hardware MSAA
- Thread starter trinibwoy
- Start date
I think you hit 1 nail in the head, a very specific nail in a broad wooden construction. But such a big one, that has been the topic of countless research efforts. All of them (the serious ones) with excellent results. My take is, and it is very likely with graphics converging with compute, is that hardware (physical memory mapping) solutions will be adapted to 2D mappings in the future.
http://forum.beyond3d.com/showthread.php?p=1533681#post1533681 There's no hard data but LRB1 likely always required multiple cycles to complete a gather operation, while it is suggested that LRB3 can do it in one cycle in the best case.
Current many-port caches use multi-banking, which becomes slow when you have bank conflicts and requires a lot of duplicate addressing logic. Making use of wider cache lines and gathering multiple elements in parallel can drastically reduce the number of ports you need.
And just because such gather/scatter hardware is not available to the public yet doesn't make it an argument against it. Innovation would be at a standstill if we only looked at existing solutions.
Texel lookups are typically very localized (with lots of reuse between adjacent pixels). But it can't be implemented with wide loads and shuffle.
Gather/scatter is no less generic than any other vector operation. Yes there are worst case scenario's where you need a cycle per scalar, but that's also true for arithmetic operations. But just like arithmetic vector operations are very valuable because in the typical case it provides a major parallel speedup, so does gather/scatter help a great deal, with a low hardware cost. So there's no need to point out the corner cases.
Generic load/store caches as implemented in Fermi and Cayman both only offer half the bandwidth compared to ALU throughput. And because they're multi-banked they're not without area compromises either. And considering that they're shared by hundreds of threads, they're really tiny and must have a poor hit ratio.
And yes, while the gather/scatter-specific logic remains idle with regular wide loads, note that current GPUs have lots of different specialized cache which are frequently either a bottleneck or idle. As the workloads diversify, unifying them into one generic cache starts to make sense. By combining several techniques it can offer high performance for a wide range of uses, while not necessarily taking lots of area. Plus you get a higher total amount of storage for the data you care most about, it simplifies the hardware and software design, and enables further unification (texture units, ROP units, etc).
Tell me the settings you want me to test (just one combination please).
What makes you think that? Mipmapped texture accesses have a very high spacial locality because on average only one extra texel is accessed per pixel. The sampling footprints of adjacent pixels largely overlap.
Tiling improves locality and saves bandwidth. Take for example a 4x4 pixel tile. Without texture tiling, you need to access 5-7 cache lines. With 4x4 texel tiles, the pixel tile typically hits 4 texel tiles. Also with texture tiling the next pixel tile will typically reuse half of the texture tiles, while without tiling it depends on the orientation whether or not any of the cached tiles will get reused before being evicted.
Combining true multi-porting and gather/scatter seems close to ideal to me to achieve high performance at a reasonable hardware cost.
VTune can count cache misses, but because there are many dynamically generated functions it's not really feasible to isolate the ones related to texturing. It might be possible to use serializing instructions and count the actual number of clock cycles per access but then we'd still have to isolate the effect of out-of-order execution, prefetching and SMT. Frankly that's a lot of work and I seriously doubt it will change the overall conclusion.
I'm confident that even the simplest out-of-order execution implementation would allow GPUs to reduce the number of threads needed to achieve good utilization. It also reduces the required register set size, which in turn further reduces latency. Of course the average memory access latency also has to be brought down, but with less threads the thrashing decreases and the smaller register set frees up space for a larger cache, and simple prefetching can work miracles.
Mark my words, in the long run there is no other option. The number of ALUs keeps increasing exponentially, but soon noone can develop a practical consumer application which can keep them all busy if the latencies remain this high. NVIDIA has already resorted to parallel kernel execution and superscalar execution, but that won't suffice for long. Eventually it will have to evolve into true SMT and out-of-order execution.
Tiling merely requires swapping some of the address bits around. You could just have regular and tiled load/store instructions. No need to change the actual cache.
Could you point me to a few of those? Thanks.
The next generation unreal engine trailer http://kotaku.com/#!5789088/world-exclusive-first-look-under-the-hood-of-the-next-unreal-engine shows DX11 deferred rendering with MSAA support at 1:00.
If you can compile your code under Linux, you could try "kcachegrind" which might give you some useful (albeit approximate/simulated) figures.
Good luck selling >4 cores to 90% of the consumer population. The data center market, for some reason wants LOTS of tiny x86/arm cores per die. I wonder if utilization is the reason ...
No predication, no scatter/gather. IOW, useful only for tiny niches.
You can already dual issue mul and add. FMA doesn't increase compute density by itself. You'll need to ~double the area of the simd unit for that.
Where are these cpu's with gather/scatter?
There are many problems with gpu's today but excessive ff hw is not one of them. What they need is a more flexible memory hierarchy, ability to submit jobs and integration with cpu's mmu. Ditching ff hw even when it makes sense for some ideological goal is pointless.
There is no hard data for that claim, true.
My understanding from earlier Larrabee presentations was that it could sustain generally 1 L1 cache access per cycle when gathering.
It does slow down in conflict cases. I am not clear on the latter claim. Both banking (pseudo-dual porting if an AMD CPU) and multiporting involve performing addressing on more than one access per cycle. What is the lots of additional logic?
There must be reasons why it is not available. Innovation is usually made as people work around problems and constraints. It is difficult to predict innovations by ignoring those constraints.
There is locality in the problem space and locality with respect to the linear address space. If there is locality within the address space, why can't a few wide loads and shuffling the values around suffice?
That is consistent with what I said. I went on to say that vector operations are not as generic as scalar ones.
We're on a utilization kick here, why are we now pulling peak performance (at the expense of utilization) into the argument?
This has been asserted, not substantiated.
My statement was a shot at implementing a specialized load on a generic architecture, not a specialized design.
We can get much better utilization of generic hardware with a stream of scalar loads.
When exactly is idle hardware good or bad?
I was curious about what settings you used to arrive at your numbers.
I think a run at whatever is closest to 1080p in the benchmark at High settings could be a good test, that should have a decent level of AF and whatever AA is used. Extreme may have the full featureset, but I haven't kept up on what it enables.
I haven't kept up with the discussion on hacking the ini to activate the various modes to see what else can be done.
I'd prefer actual gameplay, but that throws comparability out the window.
True multi-porting is more expensive than banking, since it increases the size of the storage cells and adds word lines.
In the absence of consideration for power, area, and overall performance within those constraints, probably true.
How would this be implemented? It sounds like it would need some kind of stateful load-store unit to know the proper mapping over varying formats and tiling schemes.
Fermi is already there.
That is partly because on a cpu you do a lot more alu operations than you would with some ff hw (filtering, texture address generation and the like), so it's easier to keep an even otherwise alu-poor (relatively speaking, of course) architecture fed.
True, but for that a more flexible memory hierarchy is much more important as memory latency is 30x more than alu latency and rising.
Will a smaller alu latency vanquish the need for hiding mem latency?
The fermi arch analysis on b3d explained how fermi does it.
As long as you can rasterize faster than you can shade them, it doesn't matter what was the size of the original triangle.
Where are these "more programmable chips of the competition...."?
A full custom rasterizer which can do large and small triangles with high throughput will take much more closer to 4 mm2 area than ~20mm2 area of fermi's cores. Besides, large triangles are becoming less and less common, so you can probably cut corners there without having to worry too much.
Meh, a 32 or 64 deep fifo should be enough. I doubt if it will take even 0.1 mm2 of area.
So I sincerely doubt that it would take only 4 mm² to make GPUs capable of efficiently processing micropolygons.
No, overall perf/W factors in whatever utilization actually took place. Besides, if the ff hw is cleanly isolated, it is easier to power down than a bit of hw deeply embedded inside the data path.
Let it be, hardly something to bother about when the rest of the 250mm2 worth of silicon is right next door.
How many shader units does 4mm2 buy these days?
In 10 years, sure, why not?
IIRC, lrb1 could do scatter/gather to one cache line from L1 in 4 clocks.
Which, if every one of those tiles is a cacheline, means about 75% of redundant data read.
Also small triangles are the future, so you'd need to defer the texturing a bit to actually get 4x4 tiles.
Last edited by a moderator:
Mintmaster
Veteran
What you and a lot of people don't understand is that the majority of space taken up by shader units is data flow. NVidia has also talked about using lots of distributed cache to reduce power consumption, because data flow is the big problem there, too.
Programmable shader units need a lot of flexibility in moving data around, but certain fixed function tasks do not. This is why you will never see fixed function texture filtering go away in a GPU. The cost of just getting all the data from the texture cache to the shader units at the rate needed to maintain speed is more than that of the logic eliminated. It just makes sense to decompress and filter eight RGBA vales and send one to the shader.
Again it's about data. Look at steps 1 and 3 on page 12. How do you parallelize step 1 in shaders? It's easy to pack bounding boxes into your wavefront one per clock, but not beyond that unless you want to make your wavefront an incoherent mess. What about early z-reject? You need access to the HiZ cache and then have to do Z decompression. Step 3 is not trivial in shaders either. You either have to keep those parts fixed function or immensely complicate your shader units.
Bump mapping is not a good example, as pixel shaders evolved from DOT3 and EMBM (i.e. PS is just bump mapping extended). Same thing for T&L; in fact, ATI's first T&L capable chip - R100 - had a vertex shader just short of DX8 specs to implement all the fixed-function DX7 vertex stuff. There's nothing ridiculous about alpha testing, as it's still fixed function. You just think that it's "general" because they gave it an instruction name.
First of all, any algorithm that puts the burden of motion and defocus blur on the rasterizer is very slow compared to other techniques with nearly as good results. Secondly, nobody is planning to implement those features, and rpg.314 wasn't suggesting it either.
The data routing and pixel ordering challenges in a real GPU are even harder to address with ALU rasterization, so you're not helping your case.
Not really. What matters is idle consumption. If you can stop your FF unit from using power when not in use (and AMD/NVidia are pretty good at that today), then FF will always clobber general purpose.
There's no need to state the obvious. What you're glossing over is that once you put reasonable estimates of figures into the argument, we're not even close to seeing a win from eliminating rasterizers.
There has been a lot of research in linear algebra algorithms with regards to special orders for matrix-matrix or matrix-vector operations. The idea is to map the 2D structures of matrices to the linear structure found in caches.
Make a search on google about "peano order" or "morton order", or in general "space filling curves".
If you look at the area associated with a rasteriser you couldn't put sufficient ALUs down in that area to give equivalent performance, so you end up with ALUs that are bigger comsumers of power active for longer, net result is higher power consumption.
I've actually been round this loop recently with fixed function interpolation, and although the overall area and even utilisation of a prgrammable solution looks better the extra power consumption wasn't even close to being an acceptable compromise.
I disagree on the degree of "detours" that are really needed. Further, just about all modern programmable GPU architectures do not handle arbitrary code well, this is a byproduct of making them small enough to put large numbers of units down in order to give you the huge amount of horse power that you are seeing today. To do what you appear to want will require a significant increase in complexity which means higher power and less performance. We onyl have to look to intel for exampls of this.
That depends on how you design your pipeline, for example the SGX unified shader handles narrower data types at a higher rate within the same data path, this means there is no power hit for processing pixel data down the same path as vertex data. The streaming of vertex data into or out of the shader pipeline is not unified and is handled by a seperate (tiny) peice of hardware, as I beleive it is in all other GPU designs, same is true for texture units i.e. they are not part of the unified design, for good reason.
The power consumption increase had nothing to do with unification, it was the move from vector to scalar processing units and the move from Dx9 to Dx10 precision & functionality resulting in less effiency in terms of flops/mm^2 and more power for similar performance.
The important benifit NVidia (and AMD before them) acheived when they moved to unidied shaders was an increase in both pixels and vertices processed per flop, this is the key benifit of unification. Applicability to more generalised work loads is secondary, irrespective of what NVidia marketing says!
For performance scaling to continue it requires continued scaling of power consumption, even desktops are now approaching a practical power cap (at least in terms of true mass market) which will restict that scaling. In mobile space that power cap is around three orders of magnitude lower (1-2W TDP vs ~1KW TDP), there is simply never going to be the power budget to make everything programmable in mobile space.
Rasterisation isn't evolving, but alternative rendering techniques are continually being developed. I think there is space for a paradigm shift but I don't think you need hardware that caters for everything as many techniques have little or no practical value outside of research. From my perspective the next step is the ability to efficiently cast rays within a scene, to do this well in terms of both power efficeincy and managable memory BW is going to require no small amount of fixed function HW. However going forward I beleive that HW needs to be accessible without the restrictions of the current GPU pipeline, I think rasterisation can be refactored in the same way.
Every application doesn't have to do things in completely different ways, in fact everyone going off and constantly re-inventing the wheel is of little benefit to anyone.
Ultimately practicalities dictate what you get not what is interresting.
10 years is a long time but I would be prepared to bet you a few quid that fixed function will still be around for things like video encode/decode and that graphic hardware will have evolved but still include significant fixed function units.
Applications such a crysis 2 still make extensive use of fixed function hardware, texturing units beign the most obvious, I'm pretty sure rasterisation is heavily utilised as well...
I'd agree that programmability will increase, however I'm certan that doesn't mean the end of fixed function hardware, I think it just means a refactoring of how it's expressed within the pipeline.
John.
That's exactly the sort of time frame I'm talking about.
Similar threads
