Teknopathetic
Member
Apparently it wasn't FUD so long as it was positive for X360. :lol
-
Hey, guest user. Hope you're enjoying NeoGAF! Have you considered registering for an account? Come join us and add your take to the daily discourse.
Capcom Claims: 360 GPU = Nvidia 8800 series SHOCKER
- Thread starter Dorfdad
- Start date
- Status
-ImaginaryInsider
Member
Nope, they only got to first base...(i.e. the design docs.)f_elz said:
this guy is a Fable 2 Programmer (meaning he actually has an Xbox 360 dev kit
) http://www.beyond3d.com/forum/showpost.php?p=919731&postcount=112
Most likely it just wasn't a development priority - which sucks for people that already paid for licenses, but then again, when you're buying multiplatform middleware you should be well aware what that means (especially when the lead platform is clearly known).Moderation Unlimited said:
If they actually do have difficulties in transition, I'd guess changes required to CPU codebase would be the major culprit. It's PC centric tech, and a known CPU hog, it requires some work to fit into Cell programming model.
You could think of it this way too though - Renderware was off to incredibly poor start on PS2 early on (not JUST performance wise, and ironically the tech was built Around the PS2, quite unlike UE), and that worked out in the end.
IIRC nAo32 already has dynamic range and precision that compares favourably to FP16. That said, there are also techniques that don't require any HDR framebuffer data at all, and can still give results equivalent to "conventional" HDR, so the answer to your question would be yes.
mylilbuddy
Banned
people not working with the hardware in question should not say what it can or cannot do. Especially because they are most likely on a competitors payroll per say.
All I know is games will look awesome on ps3 and 360. This comparing privates is silly and this thread should have been locked/deleted as soon as it started getting out of hand.
All I know is games will look awesome on ps3 and 360. This comparing privates is silly and this thread should have been locked/deleted as soon as it started getting out of hand.
dirtmonkey37
flinging feces ---->
szaromir said:
I'm sorry I had to call you out. That is entirely false......
Putting aside the fact that people are still debating as to whether or not the Xenos is actually one aspect of the 360 that beats out the PS3 (by a slim margin), I'm going to instead focus on the words "far inferior" and how you used them.
.....Hmmm....well, I can tell you that the 360's GPU is not "far inferior" than that of the PS3. If anything, I'd say that in conjunction with the Cell Processor, the PS3 may be able to produce visuals that are noticeably different (better) than those of the 360 by 2009 (a number that I'm pulling out of my...).
But I'm paying for the present. I can't wait 4 years to see a smidget of a difference in graphics...
Part of what some of us do for a living, is also estimating/predicting what can/cannot be done with hw (mostly relative to a given timeframe for development ), before and after we have actual hw numbers.mylilbuddy said:
It's kind of like what analysts do for sales, except with less guessing and more facts.
That said - most of the 'privates' measuring contests are discussing theoretical peaks with complete disregard of development time-frames
pandabear14
Member
Well considering the xenos vs.rsx is similar to the 7900 vs. the 1900 in terms of power, the 8800GTX will crush them. The 8800GTX is roughly 2x the power of the last gen high end PC vid cards.
Moderation Unlimited
Banned
Thanks nAo and Faf for your replies. Much appreciated.
Moderation Unlimited
Banned
dp
Moderation Unlimited
Banned
tp.
MODS...could you please delete these two replicate posts?
Thanks.
MODS...could you please delete these two replicate posts?
Thanks.
BlueTsunami
there is joy in sucking dick
The rere Luke avatar makes the Triple Post highly enjoyable :lol
Shogmaster
Member
one at B3D did a very nice summary of the article (for those interested):
http://www.beyond3d.com/forum/showpost.php?p=919807&postcount=116
90% of the stuff went right over my head but it's facinating read none the less.
http://www.beyond3d.com/forum/showpost.php?p=919807&postcount=116
90% of the stuff went right over my head but it's facinating read none the less.
Panajev2001a
GAF's Pleasant Genius
Nostromo said:
True, I recall you were still in University (I might be wrong, it was a loooong time ago) when I first read your posts online and we exchanged some PM's
.Panajev2001a
GAF's Pleasant Genius
They say that about 160 MB of textures in Lost Planet is in memory at a given time (textures gets streamed in from the disc or the HDD).
Assuming (let's talk about PLAYSTATION 3):
Back-buffer = FP16 720p with 4xMSAA = 1280 * 720 * 8 bytes/pixel * 4 = 28.125 MB
Z-buffer = 32 bits integer 720p with 4xMSAA (we take an equally sized, as the back-buffer, Z-buffer) = 1280 * 720 * 4 bytes/pixel * 4 = 14.0625 MB
Front-buffer = 32 bits integer ready for display 720p = 1280 * 720 * 4 bytes/pixel ~= 3.52 MB
Total GDDR3 VRAM used so far (not counting textures) ~= 47.705 MB
Let's assume that, to allow for smooth XMB interaction, they keep a shadow copy of the whole three buffers (even though, in some cases, keeping just the finished, ready to be tone-mapped and resolved [no more rendering passes affecting/changing it], back-buffer and the Z-buffer should be enough even though it might take a bit more to get back to the game, but only the time needed to generate the front-buffer again and sending it out to the display... still, it would save us about 3.52 MB of VRAM). This would be the OS reserving the additional shadow memory pool.
Total GDDR3 VRAM used so far (not counting textures) ~= 47.705 * 2 = 95.41 MB
Total GDDR3 VRAM used so far (counting 160 MB of textures) ~= 95.41 + 160 = 255.41 MB
Uhm... about 0.59 MB to be shared between off-screen surfaces and DMA transfers from XDR and/or SPU's with vertex data and/or texture data, still that is per-frame. At 30 fps that would mean 17.5 MB/s worth of data... and the FlexIO would probably die of laughter.
I do not think that all 160 MB of textures would need to reside in GDDR3 though as FlexIO is pretty fast (so are the EIB [CELL Broadband Engine CPU's internal ring bus] and the XDR memory pool) and RSX is not exactly unsuited to texture from XDR.
Capcom states that about 60-80 MB of those textures are for background elements and let's say that we decide that we leave those in XDR (meanwhile a guy working on the CELL side of things is yelling... "WHAT?!? TAKING AWAY THAT MUCH XDR SPACE TO STORE TEXTURES?!?"). Let's say we leave then 60 MB worth of textures in XDR memory (hopefully this data is data that needs to be streamed in memory with a lower frequency compared to the textures we store in VRAM (the GPU can wait a few more cycles before needing that pool of textures updated and we can give priority to stream textures to the GDDR3 memory pool).
We could dedicate 4 render-targets at 1/4th resolution (with 4x MSAA on, like they suggest in this article) and that would need 28.15 MB of memory (these 4 render targets are all FP16).
So, we would still have about 32.465 MB of RAM free and we could use portions of it as temporary texture buffers (if we intend to stream textures in GDDR3 memory every frame), vertex buffers (for vertices before T&L and/or after T&L has taken place) and more off-screen surfaces (off-screen surface = memory area that is not part of the area we consider as either the displayed buffer or the back-buffer that represent the screen we are "painting", but we decide to render to and then use it as source element in other rendering operations for example).
Hopefully I kept the count of stupid stuff said low enough for 2:42 P.M., what do you think Faf/nAo ?
(I do not think I have underestimated things too much, I tried to keep FP16 buffers in places you probably would simply use nAo32).
Assuming (let's talk about PLAYSTATION 3):
Back-buffer = FP16 720p with 4xMSAA = 1280 * 720 * 8 bytes/pixel * 4 = 28.125 MB
Z-buffer = 32 bits integer 720p with 4xMSAA (we take an equally sized, as the back-buffer, Z-buffer) = 1280 * 720 * 4 bytes/pixel * 4 = 14.0625 MB
Front-buffer = 32 bits integer ready for display 720p = 1280 * 720 * 4 bytes/pixel ~= 3.52 MB
Total GDDR3 VRAM used so far (not counting textures) ~= 47.705 MB
Let's assume that, to allow for smooth XMB interaction, they keep a shadow copy of the whole three buffers (even though, in some cases, keeping just the finished, ready to be tone-mapped and resolved [no more rendering passes affecting/changing it], back-buffer and the Z-buffer should be enough even though it might take a bit more to get back to the game, but only the time needed to generate the front-buffer again and sending it out to the display... still, it would save us about 3.52 MB of VRAM). This would be the OS reserving the additional shadow memory pool.
Total GDDR3 VRAM used so far (not counting textures) ~= 47.705 * 2 = 95.41 MB
Total GDDR3 VRAM used so far (counting 160 MB of textures) ~= 95.41 + 160 = 255.41 MB
Uhm... about 0.59 MB to be shared between off-screen surfaces and DMA transfers from XDR and/or SPU's with vertex data and/or texture data, still that is per-frame. At 30 fps that would mean 17.5 MB/s worth of data... and the FlexIO would probably die of laughter
.I do not think that all 160 MB of textures would need to reside in GDDR3 though as FlexIO is pretty fast (so are the EIB [CELL Broadband Engine CPU's internal ring bus] and the XDR memory pool) and RSX is not exactly unsuited to texture from XDR
.Capcom states that about 60-80 MB of those textures are for background elements and let's say that we decide that we leave those in XDR (meanwhile a guy working on the CELL side of things is yelling... "WHAT?!? TAKING AWAY THAT MUCH XDR SPACE TO STORE TEXTURES?!?"). Let's say we leave then 60 MB worth of textures in XDR memory (hopefully this data is data that needs to be streamed in memory with a lower frequency compared to the textures we store in VRAM (the GPU can wait a few more cycles before needing that pool of textures updated and we can give priority to stream textures to the GDDR3 memory pool).
We could dedicate 4 render-targets at 1/4th resolution (with 4x MSAA on, like they suggest in this article) and that would need 28.15 MB of memory (these 4 render targets are all FP16).
So, we would still have about 32.465 MB of RAM free and we could use portions of it as temporary texture buffers (if we intend to stream textures in GDDR3 memory every frame), vertex buffers (for vertices before T&L and/or after T&L has taken place) and more off-screen surfaces (off-screen surface = memory area that is not part of the area we consider as either the displayed buffer or the back-buffer that represent the screen we are "painting", but we decide to render to and then use it as source element in other rendering operations for example).
Hopefully I kept the count of stupid stuff said low enough for 2:42 P.M., what do you think Faf/nAo ?
(I do not think I have underestimated things too much, I tried to keep FP16 buffers in places you probably would simply use nAo32
).
mckmas8808
Mckmaster uses MasterCard to buy Slave drives
Nostromo said:
Hey Nostromo can you talk about if Heavenly Sword may have motion blur like that E3 2005 video had?
Could it be possible for you guys to add it in? I mean everything else is there and it looks beautiful.
mckmas8808
Mckmaster uses MasterCard to buy Slave drives
Nostromo said:Do you want me to work at night?!? do you care about my social life?!?
We have some blur effect, but not per pixel mb + velocity buffer as many games have these days.
I think you will have to wait for a sequel for that..:lol
*brings out his whip*
Nah just kidding. Did you guys have that blur effect in the demo that people played at E3 2006 and TGS?
Panajev2001a
GAF's Pleasant Genius
Nostromo said:Do you want me to work at night?!? do you care about my social life?!?
Bad argument, as forum goers will say... NO! GO TO WORK!
.
mckmas8808
Mckmaster uses MasterCard to buy Slave drives
Nostromo said:
Oh great, so the next time we see the game we should notice a little blur effect. That's cool I'll take that.
Is the effect big effect to actually see when playing the game? I'm guessing it is.
Unbelievable.. what's with all the trolling and snide remarks against Nostromo? Guy was answering questions in a perfectly civil manner and he gets ambushed by a few morons for no reason. The reason GAF is so popular, in my opinion, is because industry people contribute. They either get 1) every word worshipped by geeks like a Hollywood celebrity or 2) get stalked by bitter fans of the rival console. Both are equally bad.
Off topic but I know you are viewing this thread Nostromo.Are you embeding any FF or rumble code into HS in the chance that one of the new rumble techs that have been talked about here http://www.neogaf.com/forum/showthread.php?t=140408 lately are implemented by Sony.
please say yes.
Panajev2001a
GAF's Pleasant Genius
Nostromo said:
Hey
, I suspected that it would not be a one-size fits all picture, but I intended only to give a small overview on what I thought developers might find left after all is said and done. With this said, if my calculations have any remote attachment to reality (especially if the OS really reserved the magnitude of VRAM [as shadow memory] I specified in my worst case scenario), I really find myself even more impressed by those developers which manage 1080p HDR rendering with any amount of MSAA applied (even just 2xMSAA).Talking about Shadow Maps rendering, do you think they would not be able to fit into the space I left here ?
Capcom said that they used about 12 MB of space for Shadow Maps rendering, I am sure we could squeeze out the space somewhere as they used FP10 aplenty and I am sure on PLAYSTATION 3 they would try to use NAO32 or variants
as much as possible and that would mean a reduction of occupied space by a factor of 2 (4 bytes per pixel instead of 8 bytes per pixel) in many places so I think we could work things out .Thanks for the reply nAo
.TheIkariWarrior
Member
pandabear14 said:
true, with the exception that Xenos has MASSIVE rendering bandwidth that even 8800GTX does not have. however, 8800GTX has more power overall.
plagiarize
Banned
that Ubisoft were responsible for the RE4 port perhaps.ShowDog said:
Wait what did Capcom say about PC's?
Shogmaster
Member
Panajev2001a said:Hey
Talking about Shadow Maps rendering, do you think they would not be able to fit into the space I left here ?
Capcom said that they used about 12 MB of space for Shadow Maps rendering, I am sure we could squeeze out the space somewhere as they used FP10 aplenty and I am sure on PLAYSTATION 3 they would try to use NAO32 or variants
Thanks for the reply nAo
I'm not sure why you went through all that calculations. To see if LP is possible on PS3 VRAM wise? If they decided to do LP for PS3, wouldn't they have to worry more about other stuff (like how dependent they were on EDRAM and how the "2.5D motion blur" technique leveraged alot on vertex shader performance) and ultimately would have to change not only a chunk of the code but the overall approach on the PS3 version?
160MB for textures in the VRAM may not be even in the top 10 in the potential hurdles.
If any of what I just typed ends up sounding like jibberish nonsense, I literally just woke up about 10 minutes ago.
Moderation Unlimited
Banned
Shogmaster said:I'm not sure why you went through all that calculations. To see if LP is possible on PS3 VRAM wise? If they decided to do LP for PS3, wouldn't they have to worry more about other stuff (like how dependent they were on EDRAM and how the "2.5D motion blur" technique leveraged alot on vertex shader performance) and ultimately would have to change not only a chunk of the code but the overall approach on the PS3 version?
160MB for textures in the VRAM may not be even in the top 10 in the potential hurdles.
If any of what I just typed ends up sounding like jibberish nonsense, I literally just woke up about 10 minutes ago.
The game would obviously not be a straight port. It would have to be reworked to take advantage of what the PS3 is good at. Per-pixel motion blur may have to be toned down a bit (not done on a per pixel basis to avoid a performance hit), but other things might benefit, including physics and collision detection.
Shogmaster
Member
Moderation Unlimited said:
I know. That's why I was puzzled why Pana put so much effort around that 160MB figure.
Mefisutoferesu
Member
???Mmmkay said:
Do we even know what studios let alone games Faf has worked on? As far as I'm aware he's always kept those hush hush...
Panajev2001a
GAF's Pleasant Genius
Altaïr said:
I bet this is ******
.You are talking nonsense.
Panajev2001a
GAF's Pleasant Genius
Shogmaster said:I know. That's why I was puzzled why Pana put so much effort around that 160MB figure.
Maybe because people love to assume that PLAYSTATION 3 just does not have space for textures
or just as a fun exercise. We can worry about the other potential performance bottlenecks a bit later
.Shogmaster
Member
Panajev2001a said:Simply because people love to assume that PLAYSTATION 3 just does not have space for textures
Who cares about people who can't read properly? The only real concerns about space for textures was for multiplatform ports anyways. Thank goodness LP ain't one, eh?
Plus, there is nothing wrong with overestimating potential problems (such as keeping assets structured similarly [still, I did think about moving part of the textures budget over to XDR for RSX texturing from XDR])
Textures would be the least of the concern from what I can tell from reading the article. I think there has to be a whole new way of doing the motion blur for a PS3 version since the method they use for the 360 is quite heavy on the EDRAM and vertex load. And if that's true, how big the texture size will end up in this hypothetical PS3 version is a crap shoot anyways, and using the 160MB figure for any kind of guesstimation is rather moot IMO.
Panajev2001a
GAF's Pleasant Genius
Shogmaster said:Who cares about people who can't read properly? The only real concerns about space for textures was for multiplatform ports anyways. Thank goodness LP ain't one, eh?
Who knows
?Agh, I need to see if I can find those two (AR and LP) on the cheap, cannot afford to throw full price money behind both of them atm
.Then you can add that 160 Mb back in if you like
, but we might still keep it in for fun before we try to guesstimate about the load their motion blur algorithm places on the system.I am glad Capcom made a very successful technical (and judging by the sales of these games also kinda economical) transition to the next-generation. Who knows if MT will ever end-up being the Japanese competitor of UE (Epic was much smaller back when Unreal I kept being delayed). I wonder how well, as far as Japanese developers are concerned, is the documentation translation (and code comments translation) as well as the Japanese oriented support system as far as Epic's UE3 is concerned.
Shogmaster
Member
I personally think UE3 will not be a big force in nextgen development in Japan. Lack of native language support + slow pace of UE3 tailoring for PS3 + advancing of time + growing familiarity with multithreaded coding = alot more in house engines like this one from Capcom over spending $1mil minimum just for the UE3 license.
Panajev2001a
GAF's Pleasant Genius
Shogmaster said:
This is why I think that Capcom should slowly (not to waste too much man-power taking it away from games design), but steadily (just like Epic did) build-up this MT engine improving also its PC port and when the time is right (not 10 years from now
) license it out to other developers. If they prepare properly, they might be ready for next-next-generation consoles and be able to become one of the reference points for Japanese developers looking for a multi-platform engine (PC + consoles) and tools.my frame rate caps out at 35 fps even at 320x240 no aa. There is clearly something wrong with their thinking. 21g/s = my 63 g/s? :lol 48 shader units at .5 GHz is equal to my 96 shader units at 1.4 GHz? Oh, wait, they mean gtx, so those little suckers must be pretty synergistic if they can produce 8x their weight in shaders.
- Status