Barry minor video of cell Demo

[Titanio]

I wonder if any Sony devs or third party devs will try to do what Barry is doing, but in a real game?

I don't know if anyone is doing exactly what is being done here, but Insomniac might be doing something roughly similar with Warhawk. They're doing ray-marching for the cloud rendering, and depending on how they're implementing it, it may use texture-lookups - if those textures couldn't be streamed in or weren't small enough to fit in LS, they might use a cache? Not sure. Perhaps another person could elaborate.

 

[Mintmaster]

I don't know if anyone is doing exactly what is being done here, but Insomniac might be doing something roughly similar with Warhawk. They're doing ray-marching for the cloud rendering, and depending on how they're implementing it, it may use texture-lookups - if those textures couldn't be streamed in or weren't small enough to fit in LS, they might use a cache? Not sure. Perhaps another person could elaborate.

The Barry Minor demo does ray-marching but doesn't use texturing for any of it. The texturing is tacked on at the end. Tens, maybe hundreds of iterations are done to calculate the visibility and normal of each pixel, but no texturing is involved.

What you're describing with Warhawk needs texturing at every step of the ray. Not only that, but for real scattering you need to fire more rays at each step. You have an outer and inner loop per pixel, so that's a lot of texturing.

My guess is they'll use some existing hack to reduce this load. It won't make a whole lot of difference visually.

 

[Titanio]

What you're describing with Warhawk needs texturing at every step of the ray. Not only that, but for real scattering you need to fire more rays at each step. You have an outer and inner loop per pixel, so that's a lot of texturing.

It depends how they're generating their volumes, I think? They may be using 3D textures, or they may be calculating their samples on demand using whatever algo they'd have otherwise used to generate the texture. I guess it depends which is more expensive

 

[onetwo]

Guys, this is absolutely horrible texturing performance.

A 13% hit down to 15fps means the texturing adds 9 milliseconds to the rendering time per frame. The algebraically ray-traced object, which needs 4 lookups per pixel, occupies less than half of the screen, and the background occupies the rest with one lookup per pixel. So we have 1024x1024x(0.5 + 0.5 * 4) = 2.6 million texture lookups. Divide by 9 milliseconds and we get...

300 Mtexels/sec. Slower than the original Geforce.

But with 10x the transistors and 25x the clockspeed

Actually, isn't that 300Mtexels per frame? Your math gives you "# of texture lookups/1 frame measured in seconds." Multiply that by the 15 frames and the number you get is a much more impressive 4400MTexels/Sec.

My thinking may be wrong, though.

 

[Mintmaster]

My thinking may be wrong, though.

It is.

In actuality, the demo is only performing (2.6M * 15) lookups per second, which is 39MTex/s. However, Cell isn't spending all the time on texturing, so from the performance hit of enabling this additional workload we can assume only 13% of the time is spent on texturing. Divide 39MTex/s by 0.13 and you get my answer.

It's more clear if you just look at texture lookups per unit time as I did earlier. Here are some more explicit number in case you doubt the calcs: 15fps means 66.7ms per frame. 17.2 fps means 58 ms per frame. (17.2-15)/17.2 = 13%. Extra time per frame is therefore 8.7ms, during which 2.6M texture lookups are performed.

 

[Mintmaster]

It depends how they're generating their volumes, I think? They may be using 3D textures, or they may be calculating their samples on demand using whatever algo they'd have otherwise used to generate the texture. I guess it depends which is more expensive

You'd be outta your mind to use anything but a 3D texture. Fractals are very hard to control artistically, and take way too much time to evaluate on the fly. A ray-marching algorithm for clouds does not have to do as work much per sample as the cube-map lookups in this demo, though.

 

[onetwo]

It is.

In actuality, the demo is only performing (2.6M * 15) lookups per second, which is 39MTex/s. However, Cell isn't spending all the time on texturing, so from the performance hit of enabling this additional workload we can assume only 13% of the time is spent on texturing. Divide 39MTex/s by 0.13 and you get my answer.

It's more clear if you just look at texture lookups per unit time as I did earlier. Here are some more explicit number in case you doubt the calcs: 15fps means 66.7ms per frame. 17.2 fps means 58 ms per frame. (17.2-15)/17.2 = 13%. Extra time per frame is therefore 8.7ms, during which 2.6M texture lookups are performed.

You're right Sorry -- my mistake!