Sure, but like I said, RSX has to use more BW during that part. When reading the G-buffer for a light, it also has to read the current value to accumulate it and then write the new value to RAM as well. This gets multiplied for multiple lights per pixel (which is likely since you decided on DR instead of FR).
Says who? When you read a Z-buffer from RAM into the EDRAM, the HiZ is updated as well.
http://download.microsoft.com/downl...324bad9b1/Xbox 360 GPU Performance Update.zip
blending is cheap compared to the transfer of 8times the amount data for the g-buffer.
at the same time they say g-buffer+depth+rgba8 is 36MB for them, with 4x32 it should be just about 15MB+depth+rgba8
I said that, and it's still true, you cannot write out the optimizations.
just with an extra pass which is extra cost. in the end you can do everything on any hardware, but the cost rise for every emulation. here half ms for update the hiz, there for downloading rendertargets, here some more passes for tiles.
Because they use 2xAA, I belive, not because they use 64bit rendertargets.
So the rendertarget+zbuffer is like 14MB. that would be even less suitable for X360, but yeah, can be done in two passes.
What math are you using? Your 4x64b example is ridiculous.
Read the KZ2 presentation again, and don't forget about 2xAA.
Read the slides I linked. Not a big deal.
You can't ignore the pros and just look a the cons. 360 will use less BW during the g-buffer creation stage and even more so during the lighting stage. In each pass, geometry processing is substantially faster on 360, and "more passes for tiles" is misleading because you have much less geometry in each pass.
There's no extra cost for more passes here, because there's no geometry except for simple light volumes.
I assumed 36MB of KZ2 is 4*64bit buffers, sorry for not explaining that in detail, I didn't expect anyone could not understand that. (thanks to Thowllly for the hint it's 2AA)
it doesn't save anything more than other architecutres save, it's just overhead.
it's not for free, you're having a huge overhead to process each pass, even if you reject geometry, you're still doing all the other setup, which is suboptimal.
and all I said is the same, tiling is a big overhead for deffered rendering, not giving you much benefit over normal forward rendering on x360.
Yes, that's what i'm talking about all the time. there are quite some cost for reloading the zbuffer at least twice (for deffered and for alpha-forward rendering), the G-Buffer dump, and other reloading of buffers.
that's what I said in the quote, x360 is very good for simple forward rendering. even with multiple passes it does quite a good job. it must have already a lot of load to not handle the rendering in 30ms, but in that case you won't do any better with the deffered overhead.
Yes, a light prepass is nice, it's described in all details there: http://diaryofagraphicsprogrammer.blogspot.com/
If your assumption is wrong then how can anyone be expected to understand it?
What is that supposed to mean? You're basically saying, "It doesn't save anything but it does". It's not just overhead, it's an additional load equal to 40% of the big g-buffer BW load that you're going on about per pixel per light.
You're only duplicating setup work for geometry in objects that overlap both tiles. Everything else is identical to FR.
No, I said that tiling is the only disadvantage. You've been arguing about other disadvantages of DR on 360.
This is a silly way to do things. Alpha geometry can be rendered between tiles after all the lights are accumulated, just like people always do with tiled forward rendering. You already have to sort alpha geometry, so flagging tiles is extremely low cost by comparison.
Comparing DR and FR is not that simple. If you have a lot of local dynamic lights, it doesn't matter if you need more tiling, because DR can still be faster. At the same time, you can have situations where even on RSX, DR will be slower because it needs so much more BW per pixel.
You don't get it. Even with forward rendering you need two tiles for 1280x720 @ 2xAA. Barbarian's suggestion has the same tiling requirement.
sorry, I dunno why other understand it and can tell me that i'm wrong, but you did not understand. I'll try to talk more simple.
maybe you dont get it cause you interpret to much into my words. I just said, it doesnt save more than on other architectures, but to have it you have additional work, additional work that you dont need to do on other systems is called overhead.
additional work, but it's not overhead, sure
.if you use tiled rendering, you dont setup two command buffers, you have one buffer that is executed twice, even if the object dont overlap all tiles, they command-buffer needs to be executed to have the right states all the time. just the draw-calls are skipped, not their setup.
no? i didn't say that tiling and dumping edram to mainmemory is a problem? I dont know what you understand in my first post of this thread, but that was what I tried to say.
I thought you refered to KZ2's way of doing it, so it's impossible to make object motion blur with alphablended stuff already on the shaded geometry. the only way I know is
having local dynamic lights is the best case for DR, worst case would be global lights, handling global lights Deferred is a real bandwidth waste, while local lights would just touch the areas that are affected by them. but again, I still think it would run faster without DR on the x360. assigning x-lights, having a shader with dynamic branching so the mount of loops for lights is dynamic shouldn't be slower, if your geometry is of reasonable size. rendering the whole scene in one drawcall with x lights would be of course maximum overhead..
so why the heck
is he saying
you're right, i dont get it, I thought he was talking about "a slightly non-HD resolution" so 'The EDRAM can fit" it.
just in case you use lower resolution, but again "if you lower the resolution, you can of course save the tiled overhead" you still have other overhead due to the xbox architecture.
But you're wrong because it does save more - 64 bits per light per pixel. That's a lot!
If the draw call is skipped, then all vertex shading and triangle setup is skipped. As for renderstates, if you're worried about that in a deferred renderer then you have severely misplaced priorities. I don't even think you could measure that overhead unless you have a really crappy engine.
You're not reading my post. I am not denying that tiling is a cost, nor am I denying that you mentioned it. What I am saying is that I feel it is the only issue (in particular the IQ sacrifice compared to the same number of tiles with forward rendering), whereas you are putting too much emphasis on other issues like external BW, renderstates, z-buffer issues, etc.
You're not going to notice a big difference in image quality if you motion blur after blending. First of all, KZ2 is using rather rudimentary motion blur in that polygon edges aren't blurred like Lost Planet's advanced technique. Secondly, their alpha buffer compositing already results in artifacts. Finally, there is very little fine detail in their alpha effects, so incidental blur won't be very detrimental.
I actually agree with you here. Dynamic branching is another factor that helps 360 with variable-light forward rendering, and even though I forgot about that in this thread, I've argued the same thing with nAo and others.
The point is that with Uncharted type DR, 1200x720 needs no tiling, and 1200x720@2xAA needs 2 tiles, and both scenarios are the same with FR. Only if you really, really want those 5% more pixels does this form of DR need more tiling than FR. Also, KZ2 uses screen-space normals, so you don't need 4xFP16. 2xFP16 +1x8-bit is enough for normal + specpower, and you don't need to reduce resolution.so why the heck
you're right, i dont get it, I thought he was talking about "a slightly non-HD resolution" so 'The EDRAM can fit" it.
aren't we talking about reloading z and z-optimizations at this point? if not, i'm lost.
I thought we were talking about all the tiles that you get when rendering those 4 1280*720*2AA MRT.
I'm just saying that the cost of those BW, Renderstates... is higher than the benefits due to the good x360 FR ability. that's all.
maybe you should check the guerilla paper that you wanted me to check, motionblur is just a postprocessing effect, and they don't save any objectIDs, so they blur whatever is on screen (but it seems like they have a cutoff, maybe using the depth). I've tried using motionblur after drawing alphaobject (cause my lazyness hoped it will work that easy), but it was completely fucked, especially if the alpha objects have some intensity to cover the objects that will move, then it looked like the alphasurface had some preditors moving infront of them.
like I said, you just interpret too much into my writing
, i'm not saying the x360 is bad, just that it's good suitable for FR, no benefits from DR and there is barely any point doing more work for no benefit.actually, DR is good for simplyfying lightpasses (like we both agree it's anyway not an issue for the x360 shaderunits), but it's very bad for materials as you need either some kind of suboptimal general shader, emulating all kind of materials approximatelly or an uebershader with all possiblie materials and materialIDs in the G-Buffer. additionally you've a very limited set of individual material inputs. no diffuse/specular color, anisotropic, subsurface scattering with e.g. skin layer, or for plants.
yeah, that's a possible workaround for one issue with DR on x360. you're right. (btw. u dont need the 1*8-bit for normals
)yeah, that's a possible workaround for one issue with DR on x360. you're right. (btw. u dont need the 1*8-bit for normals
Nope, I'm talking about what I emphasized at the beginning of these posts:
I am. Command buffer overhead really shouldn't be a problem unless you have a terrible engine. Pixel shader states aren't going to vary much compared to a FR, as every pixel has to output similar basic G-buffer properties.
Now that you put it that way and are considering dynamic branching too, I say that this is very possible. This is quite different from you original posts on the subject, though, where you were talking about why PS3 is better suited to DR.
I know, and that's why I said it's rudimentary.
Well, it depends on a lot of things, like I said. You probably didn't have a quarter resolution alpha buffer composited on top with artifacts and filled with soft alpha particles.
The 1x8-bit was for specular power, as per Barbarian's original post on the technique.yeah, that's a possible workaround for one issue with DR on x360. you're right. (btw. u dont need the 1*8-bit for normals
Well, KZ2 is doing it, so that's why I threw it out there. As for the sign, you can just clamp the normal's view direction component before renormalization. It shouldn't be pointing that way anyway, so image quality won't be negatively affected.
i'm talking about that :/
Mintmaster said:
and I said, it doesn't save more than other architectures do. but it has an overhead reloading the z-buffer/hiz
sadly it is a noticeable overhead, it's not just moving with your get ptr along the commands, you need to push them down the pipe and this takes time, especially shader binaries and constants. the commandbuffer-processor isn't made for high performance, cause usually you're not limited at that point. but seting dozen of states for drawcalls that are not issued will make your gpu idle, waiting for the next drawcall.
I was talking the other way around, why DR is well suited for PS3, why it's not benefit for x360 (all the time), but you seem to interpret a lot more into my text than I actuall write.
particles are just part of the equation, there are other 'solid' alpha objects.
and it doesn't change that it's still overhead, even if it would be just 1-2ms that you waste movie buffer, it's an overhead you don't have on other machines and you might not save with DR over FR rendering.
