Larrabee delayed to 2011 ?

Nice slides, thanks Tom mentions scattering from the vector is undefined if multiple dests are the same, but it's well defined in reality. Does it just walk the vector lanes 0-15, last one wins?

 

likely its something like that, low to high or high to low but its also the kind of thing you likely don't want to rely on as a programmer unless you are writing actual machine code because even an asm can do some code morphing that can change ordering.

 

"Challenges of an all-software pipeline
a lot of code to write
It all takes time to write, test & tune"

Like I said, Larrabee's biggest challenge is the software and a likely cause for the delay.

"You always have standard x86
All your code will run, even if you don’t SIMD it
Great for the 90% of code that just has to work
Profile it once it’s running, find out which bits need love"

Like I said, it's an enormous advantage to be able to port your code in an instance and optimize it incrementally. This is the primary reason Larrabee is x86.

 

True just wasted some of my precious minutes looking at them

 

I hadn't seen that presentation in full, so they were nice to me.

@aaronspink, cheers

 

The point of ee380 isn't the slides, its the talks and Q&A. You generally find out more about something in the 1-2 hour talk than you would reading a billion slides. Its not exactly uncommon for a company or speak to go back and view the video and then ask for it to be removed because it revealed too much!

 

you did watch the video, right Rys? The talk is WAY better than the slides.

 

That and it might be an implicit "we reserve the right to change this internally whenever we feel like it". It might be a bad idea to bet on program correctness if it relies on implementation-specific behavior.

 

I didn't spot there was a video That's on my list for tonight I think.

 

I'm probably mistaken, but didn't he (Tom Forsyth, in the talk) mention that setup (or at least the part of it that relates to tri/clk--say hi to my ignorance, it's shy) wasn't an issue? I remember him saying something like 500M+ tri/s being more than enough. Whether that was for Larrabee or GPUs in general, and whether that takes into account tessellation, I don't remember.

Feel free to disappear this post before I do if I'm wrong.

 

He talked about 1.2million triangles per frame. I think that's a normal amount for a non-tessellated game. However, once games become heavily tessellated it can be a problem.

 

Yes definitely! I didn't even realize there were slides linked when I posted the link to the site... the point was for people to watch the video

Not necessarily... I maintain that the most important use of tesselation is to *remove* triangles that would otherwise be there without it. If you're rendering too many more than a couple million or so triangles you're not doing your LOD/occlusion culling well enough (at least for today's screen resolutions) The goal is for triangles that are 4-8ish pixels.

 

Yep, as soon as you start getting into or certainly deep into the triangles per pixel range, you probably want to seriously look at what rendering algorithm you should be using.

 

Ideally, though, your engine should be taking into account distance from camera WRT the objects being tessellated. Right now, tessellating down to sub-pixel geometry is horribly inefficient, so we obviously don't want them too small, but then we don't want them too large either. The closer to the camera they get the smaller they need to become, but there needs to be a fall-off point in both directions.

 

Are you saying that an overall increase in maximum model complexity coupled with an effective LOD scaling scheme would result in a net reduction in triangle counts compared to today's games? I somehow doubt that very much given the sorry state of affairs we are in now.

 

It possibly will... particularly if games are already pushing 1.5+ million polygons (I don't know the current numbers specifically) per frame. You really don't need more than that even at 1920x1200... that's already nearly one polygon/pixel.

As with pixels for the last few years, we need *better* triangles now, not more. Tesselation helps somewhat with that.

 

Well, it's not that easy to cull all hidden triangles away... so triangles do overlap. Tesselation may make that problem better or worse, depends on the situation.

 

One of the issues with triangle count is shadow buffering. That instantly "doubles" the effective triangle count with just a single light source. Done right, tessellation of just the silhouettes of objects, as seen by the light source, will save triangles.

Jawed

 

Sure, but it's not terribly hard to get within a factor of 2 in my experience, and that's not even applying any cleverness. With occlusion queries and predicated rendering it's even easier to get the last few orders of magnitude. Using the 4 pixel triangles guide (which is on the small side) that still gives you a factor of 3 on a 1920x1200 screen before you're >1.5mil.

Definitely shadows add another render of the complexity of the scene (per light!) for global lights. Still, as has been noted, if you're going to be rendering lots of tiny triangles you'd better start looking at why you're using the current rendering pipeline at all, and if you're rendering lots of occluded triangles you'd be well-served by spending a bit more time on culling - even if entirely on the GPU.