Larrabee at Siggraph
- Thread starter nAo
- Start date
I'd certainly argue that deferred shading makes even *more* sense on a tile-based renderer (and I even like it on typical GPUs as well for several reasons)... almost to the point that it's a no-brainer really IMHO, but that's an argument for another thread/day I suppose.
That said, I think the trade-off of having people write their engine/renderer in an explicitly deferred fashion makes sense, rather than trying to infer and reorganize things like pre-z passes automatically internally. Your point about them doing an explicit pre-z pass effectively uselessly doubling the amount of bin data is certainly true, but I don't know how much pipeline "magic" one would really want to do to applications that are already written that way.
Anyways lots of interesting things to come. I think the most exciting thing to keep in mind is that any of these questions can be answered/implemented/changed on a per-application, per-render-target or similar basis to get the most optimal performance. Being able to dynamically reorganize the graphics pipeline is a very powerful tool.
http://www.gamespot.com/hardware/bl...5655/26524729/tim-sweeney-likes-larrabee.html
No surprises there, I guess.
And I see he's not giving up his new overlords that easily.. If I was religious I'd be praying it wouldn't make it into a single console just because of this guy's arrogance.
No surprises there, I guess.
And I see he's not giving up his new overlords that easily.. If I was religious I'd be praying it wouldn't make it into a single console just because of this guy's arrogance.
ArchitectureProfessor
Newcomer
Perhaps you're underestimating the similarities between Conroe (Core 2) and Katmai (Pentium III).
I would say that the Pentium M was derived from the Pentium III, and the Core 2 was derived from the Pentium M. Sure, lots of things changed, but the core renaming style, microcode, and such stayed the same.
In contrast the Pentium IV was certainly not a derivative chip. It looks very different from the other P6-style chips.
If I have a hammer and replace the handle three times and the head two times, is it still the same hammer?
Trust me, they do mean derived! I know you find it ridiculous, but I don't. It makes a lot of sense. They didn't rip out or replace as many things as you think.
ArchitectureProfessor
Newcomer
I think Microsoft has lots of reasons to be interested in Larrabee, even if they don't use it in the XBox. Some of the researchers at Microsoft Research have known about Larrabee for some time, so Larrabee certainly won't be a surprise to Microsoft. The PC is still Microsoft's cash cow, and Larrabee could certainly impact that space.
Perhaps you're underestimating the similarities between Conroe (Core 2) and Katmai (Pentium III).
Silliness. I understand Conroe shares some design philosophy with P6, but it also shares a lot of design philosophy with Netburst. It is a hybrid of the two.
Do you have any evidence to back up your assertion that the microcode remained identical between P6 and Conroe? I find this hard to believe, given Conroe's hybrid nature.
True.
More silliness. CPUs are not hammers (no matter what AMD says). Again, Conroe has as much in common with Netburst as it does P6.
I think that part *was* an analogy
Last edited by a moderator:
I'd suggest that Conroe was more P6 with some Netburst features mixed in (EM64T, Branch Predictors) than a hybrid.
If I remember correctly the front-end in Netburst worked very differently to P6 or Netburst (stored chunks of commonly used instructions pre-decoded to allow it to skip several pipeline stages?) which Core microarchitecture parts definately don't do - doesn't seem too unlikely that the microcode engine wasn't carried over and expanded on from Yonah.
aaronspink
Veteran
Practically nothing, it's mostly a wider Pentium M with nice features like macro-fusion, micro-fusion and loop caching, none of which came from NetBurst. The long pipeline, trace cache, dual-pumped ALUs, basically the entire front end and the execution engine was ditched. The only notable thing that carried over were the ISA extensions that hadn't dripped down to Pentium M/Core Duo yet.
The Core 2 is much much more similar to the P6 than it is to NetBurst.
Faster rendering of legacy software isn't really needed ...
A couple of extra FPS on the popular benchmark games at the time they release Larrabee is certainly worth greasing a few palms though, it's not a big change for the devs.
NetResearchMan
Newcomer
A pre-z pass doesn't double the bin data. The z-pass only needs a single vertex component (position), whereas the other passes will have many channels (at a minimum position, UV, normal, and tangent, sometimes additional UV channels and color channels). Eliminating those extra channels also can result in fewer total vertices because it eliminates seams in the normal and UV channels (on the order of 25% less for models in our game engine).
It's advantageous for a pre-Z pass to sort it front to back (so you get better hierarchical Z rejection), whereas the shaded passes are most efficient in shader or texture order. One advantage of doing a pre-z pass over everything is that you could potentially use the z-pass to do occlusion culling for the later passes (through either predication or a hierarchical occlusion map). That way, you would completely eliminate the later passes, saving the bandwidth of copying and transforming the extra vertex channel data for primitives that will ultimately be completely occluded.
I'm not sure how practical it would be to implement that on Larrabee, since the idea requires separate binning for the pre-Z and shaded passes. An application could add hints as to where the Z pass starts and ends to help out. Whether it would be efficient may depend on the specific scene (how much is occluded, overall triangle count). You would have to store the entire Z-buffer out to memory, and bring it back in for the shaded pass (rather than keeping it in cache), but it could eliminate many primitives from ever being drawn.
One possibility would be to do a pre-Z pass solely for the purpose of generating a hierarchical occlusion map. In such a case, you could store the resulting Z-buffer at a lower resolution than the actual frame buffer (no MSAA, plus half or quarter resolution). It would be good enough for early-rejection, and reduce the bandwidth requirements dramatically. An application hint could indicate how the pre-Z pass is to be used.
I'm just throwing some ideas out there. I think the possibilities of software rendering are awesome! Proper alpha sorting, irregular shadow mapping, high quality anti-aliasing, adaptive tesselation, the list goes on and on. I don't care if it's somewhat slower than a fixed function GPU, it will provide huge render quality advantages that can never be accomplished on current GPUs. At least not unless GPUs move towards the Larrabee approach (which they should, IMO).
I think you're focusing on something other than I was trying to get across, though. I was just conveying that for Intel, the best-case scenario would be getting Larrabee into the XBox as right there it would ensure a certain level of captive industry support... to say nothing of the bevy of development tools Microsoft would start producing around it. And for MS' own purposes, those tools would automatically be supportive of the PC ecosystem as well. So I wouldn't view it as the death of PC gaming at all, simply the 'arrival' of Larrabee in unquestioned terms.
I view the next-gen console efforts (assuming contemporaneous launches) as a matter of mainly die area - whatever the architectures, there will be a fixed area budget of sorts, and whoever makes it count within said budget will have an advantage. It's almost easier to hypothesize around MS and Larrabee if only because it's a (quasi)known quantity; if MS is going the POWER route again - which I'd go with as the default - then it's a real guess as to what sort of chip will emerge. Obviously there are a lot of design directions to draw from/work with.
Unrelated to the above, is there a number/sense as to Larrabee's DP performance capacity?
Well as has been noted earlier in this thread, you don't necessarily need to store anything other than positions in the bins anyways (even for normal rendering). In any case, the gain from just doing an in-core/tile z-pass before shading would be much greater than any cleverness with reducing your pre-z data set before sending it to the API.
Any sort of occlusion queries that alter your draw calls are going to be by necessity at least a frame behind the GPU command buffer consumption. Thus you're not gaining anything/very much by doing a pre-z pass, since you might as well just use the "final" z buffer from the previous frame. Certainly hierarchical occlusion culling stuff is very useful, but it's just as good without a pre-z pass as far as API-level draw calls are concerned.
I'm not entirely sure what you're getting at here, but certainly if z information was known "up front", a binning render could avoid even dumping things into bins that were guaranteed to be entirely occluded. That said, you're only going to get a (likely small) constant factor over doing some simple occlusion culling at the scene graph level yourself. Even if you want to do something fancier, there's nothing preventing you from just rendering a low-resolution image to get conservative visibility data and using that to drive rendering... if you rendered at a resolution approximately equal to the number of tiles on the screen you'd be doing about the same thing.
Indeed I was suggesting something similar above, except that I suspect you can get the majority of the benefit by just doing it in "software" and culling more coarsely (objects vs triangles for instance).
Also note that the Larrabee paper shows that vertex processing is practically free and rasterization isn't really that expensive either. Certainly these trade-offs change from game to game, but part of the reason why pre-z is such a win on current GPUs is because pixel shading costs so much more than entirely re-transforming and re-rasterizing the scene... to that end, just looping over your bin queue - or even better IMHO, just using deferred shading! - is going to be more than enough.
Yeah, all good ideas and I'm looking forward to seeing what people come up with when they get their hands dirty!
PS: I would be remiss if I didn't note that if you're into this sort of stuff, our group at Intel (Advanced Rendering Team) is hiring! Please feel free to fire me a PM if any of you or your smart friends are interested
. Also if anyone is going to SIGGRAPH next week and wants to chat, please also fire me a PM.
Last edited by a moderator:
Similar threads
