Yeah, these e-mails are pretty old (2000!) So I figured what the hell, I'd share them with fellow tech geeks. I'm the one asking the questions... Fafalada and TK Mai are answering. But lots of stuff, especially the way PS2 does texturing is explained in detail. Enjoy. NDA's usually only last a year, so I should be able to post this. I see that SCEE is posting here now, so if I shouldn't be posting this, let a mod know! I'll edit it out, or if I'm not around, just have someone delete the contents of this post and lock it.
Not all of those were the same e-mail, I just kind of pasted the important stuff together. Interesting, eh? I can't believe I cared so much about something as stupid as a console's architecture. Never again!
From: "TK Mai" <tkmai@*******.***> Add to Address Book
To: "sdaf sadf" <diablos**@*******.com>
Subject: Re: Questions?
Date: Mon, 8 May 2000 14:12:33 -0700
The following information is for the eyes of DiablosX only:
Typical textures per frame along with polygon throughput really cannot
be determined because they share the same GIF-to-GS bus. One affects the
other. Even with 2.5MB scratchpad space on the GS, you do not necessarily have
to use exclusively 8-bit palletized textures. The space only seems small
if you're looking it from the perspective of a PC/DC architecture where
you pretty much preload the entire level's worth of textures in one go.
With PS2 you load entire textures for the object you're rendering at the time
and even then, only the required MIP-maps. That alone is a substantial
savings in memory and bandwidth over PC/DC. So 2.5MB on PS2 is not equivalent
to 2.5MB on PowerVR or Voodoo3.
Hmm...Factor5 claims 7.5 million polys/sec? That's far from the
maximum, they must be having trouble with the hardware or using LOTs of
textures. Are they pushing 15MB textures/frame or something? Using 16 or 32-bit
textures exclusively would take more room and leave less bandwidth for geometry.
I would prefer a mix of 16, 8, and 4-bit textures. 8-bit palletized
textures don't really look so bad and you'd be surprised at how many games use
even 4-bit. The major drawback is when you're doing a lot of texture
blending passes and accumulate errors which leads to banding. If you're running
10-20MB of textures per frame, it could be any combination of texture
bit depths. Depends on the type of texture and the resolution you want. PS2
supports 1024x1024 textures but obviously you're not going to need them
on a 640x480 display. And it'll be a rare case where you need a 512x512
MIP-map. At texture resolutions below that, there's quite a bit of room in eDRAM
for higher bit depths.
IMO, the biggest limitation is the external 64-bit 150Mhz from GIF to
GS. But for an external bus, that's very large. Making it 128-bit would
have made the console too expensive so I understand why SCE did what they
had to.
The fact that vertex and texture information goes through the same pipe
means the programmer has to do a lot of load balancing. This is one of
the hardest parts of developing on the console, along with VLIW coding on
the VUs. I do not believe that it is as hard as the Saturn, at least not in
the same sense. On the Saturn you had redundant processors all doing the
same task, the two SH-2's and SCU DSP all did geometry tranforms. Balancing
all three was a headache and the SH-2's shared the same bus to system RAM.
With PS2, it's also hard to tap the full potential of the console but unlike
SS the results are worth it. Each component has a set task, MIPS r5900 for
AI/program control, VU0 for physics calculations, VU1 for geometry, GS
for rendering. There are enormous performance yields from smart coding. I
do not think that developer support will be a problem.
And yes, Sony definitely IS working on better libraries for the
development kits. Otherwise, I wouldn't have a job! Hehe. I'm working on some of
the libraries myself. The number of libraries will increase greatly with
time and existing ones revised. PSX has over 1600 libraries available right
now, PS2 has quite a ways to go but it will get there eventually. FSAA isn't
free on PS2 or any other architecture.
-Kenji
Sony Team Nishi
DVD and MPEG-2 Applications
From: "Rok Erjavec" <rok@******.***> Add to Address Book
To: "sdaf sadf" <diablos**@*******.com>
Subject: Re: PS2 tech sheets
Date: Mon, 7 Feb 2000 08:12:39 +0900
> How did Duane get them if they are confidental? Could
> I/we (Duane) get in trouble if he sent it to me?
You misunderstood me, the pdf's Duane has are not confidential material
from what I could understand. They were actually publicly presented at some
conferences where PS2 was presented. Of course they do not deal with
purely technical detail, but I think they should serve to explain things a bit
better to you well enough.
> Hmm, looks like your information about the PS2 with
> textures, etc. on the forum seem to be more correct
> than the Nintendo fanboys and people who love making
> the PS2 look bad ^_^
Well I am not really concerned with personal motives of why some info
of PS2 is discussed, I am fully aware of this machine's limitations and the
fact that it is not perfect. But I don't like people being misled when there
is false or misinterpreted info presented that's all.
> -What is the actual compression ratio for textures? Is
> 15:1 or 7:1 possible? Or is it really 2:1 or 4:1?
It can easily go well beyond 20:1 as well. What you need to understand is
that this will not increase the number or size of textures displayed in a
single frame of animation. That limit stays. However you can vary the textures from frame to frame with no problems, and that's where the compression really comes handy.
Dolphin and DC texture compression on the other hand increase the amount of
textures possible to display in a single frame, because they are built
into their graphic chips.
> What is the estimated poly rate? Is it 12-15 as
> stated by gaming sites, or lower, or higher?
I can't really say much about that at the moment. I would estimate the
first generation games to be somewhere between 8-15mio depending on
developper and game. But I have no official confirmation on this, and for all I know I could be very wrong. (I didn't include the projected numbers for my own project here for
obvious reasons).
> -Will the Dolphin REALLY be all that much better?
> Besides memory... I doubt we'll see the Dolphin doing
> 25-30 polys/sec, and an overall presentation that will
> make the PS2 look bad.
Think of it this way. PS2 with all its power doesn't really make DC
look bad. Games such as DOA2, ShenMue, SoulCaliber...etc. look very good,
and they won't be concidered crap just because PS2 games will look better.
I am pretty certain Dolphin will be better, and look better, but I
doubt the difference will be all that big either. Marketing and software support rather then processing power, are what is more likely to be deciding the upcoming console war in my opinion.
> Wow. A 20:1 compression ratio? Will this be a normal
> ratio for most games, or is that the maximum, when
> developers can really tweak into the system?
The compression ratio is basically dependant on how you compress the
textures you will use. Eg., 20:1 will exhibit minor quality loss, but still, 15:1 will be a
bit better. So its up to the developer to decide. Also depending on the type of
game, how much textures you will need to hold in main mem.
But in a nutshell, it's just a choice of how much compression you set
your compression utility to do.
> That info really surprised me. So this means the PS2
> can/will actually have something like 80MB (4x20) for
> textures, exceeding the Dolphin's? What I don't get is
> when you say
> What is the "limit?" Does this mean the texture
> compression WON'T act as if it can have up to 80MB, or
> 20MB per frame?
See this is where it isn't so simple, since PS2 deviates from
traditional architecture at this point. The limit of textures you can use per frame
is limited by the GS bus bandwith. At 150mhz*64bit the maximum texture load is 1.2GB/sec. Divide that by 60 (for 60frames per sec), and you end up with a maximum of roughly 20-24mb textures per frame. (but remember you have to share that bus with
vertex data as well). All of these textures can be swapped every frame however.
So taking a pseudo real life scheme, - 20mb of storage in main memory for compressed textures 15:1 = 300mb of textures.- 10mb of textures per frame
Each frame a different 10mb of textures out of possible 300mb can be
displayed. On Dolphin on the other hand, with 8mb of VRam, 6:1 compression, every frame you can display nearly 50mb of textures all at once. (not on Dreamcast however because the graphic chip on DC couldn't handle rendering all that). While that may seem like a big deal, let me remind you that in screen resolution 640x480 using up 50mb of textures in one single frame is next to impossible. (you can calculate why, very easily).
> Also, about your comment towards the DC and Dolphin's
> texture compression -- are you basically saying that
> the PS2's is best?
JPeg will always have clearly superior compression ratio, but PS2
architecture should have been designed different to really take
advantage of it. As things stand, it has some advantages, but also plenty of weaknesses.
Also IPU decompression chip is not infinitely fast, but I don't have any
real numbers on that yet.
> If you are wrong about the 8-15 million pp/s, does
> this mean it could be higher or lower? Also, even
I just said it was a guess, I estimated from what I have seen of upcoming
games. I wouldn't want to accuse Namco of running 8mio polys where I
have no solid data to confirm that. They could be pushing a lot more then
that... Some games may only use 6mio pps too, not all games will even need
polycounts higher then that, especially if you concider what
developpers are pulling off with DC's 3.
> You are certainly right about DC screens. They look
> very close to what the PS2 can do.
So far they do But wait a bit to see what comes out... Namco for instance hasn't
really shown their stuff in full yet trust me. So probably haven't many others.
> --Would you rather have me not post this info in
> forums and things of the like? I won't if you don't
> want me to.
I just suggest you don't try doing any comparison with Dolphin until
some hard specs are released. Comparing specs of one machine to rumours of
another is rather pointless you know Also I hope you aren't asking these questions just so you can argue on www forums with what you learned.
> Sorry to bother you again, but if the PS2 claims it
> can have a normal poly per second rate of 20-25
> (according to
> but two developers claim they can only get 10pp/s, I
> am confused.
Noone said getting in the range of 20mio pps will be easy. I don't
expect any first generation games to reach that either. But with each project
we learn, and improve the performance.
> I was looking at an older thread and both you and
> Panajev claimed you could only push 10pp/s. So the
> only way to get 20-25 is if you build the polys almost
> perfect? Is this another weakness of the console?
10mio is a solid range for first generation games. I suppose some may
even exceed it, some may fall short. Building a graphical engine that can
take full potential of this thing is by no means easy when you deal with it
the first time. Similary lots of first DC games fell short of even 1mio polys/sec.
No new hardware is trivially easy to optimize for I'm afraid.
Cut developpers some slack here... they'll get more out of it given some
time And building as perfect triangle strips as possible has been something
developpers had to do for a long time before PS2 was ever even
mentioned. A little tid bit you might not know, but even the original Quake1
engine uses triangle strips for increased performance, inspite of the fact
that hardware and API libraries at the time didn't really support them.
(they had to use them internally for geometry calculations only, yet it
was still worth it)
> But its pathetic, you'd think people are anticipating
> the consoles release to play the games rather than
> insult them. Games like DoA2 supposidely won't have as
> much detail, transparency, or cleaner textures on the
> PS2 version, I have no idea why, but you know people
> are going to use it as a lame excuse to put down the
> PS2's power.
Oh most of that crap is nonsense. The thing about transparencies was
particulary amusing as DC's graphic chip is the one that really has
problems with transparencies. Not only its alpha blending engine is outdated and
rather primitive compared to what is in GS, but also transparencies are
the thing that causes biggest problems for tiling architecture since you
HAve to overdraw polygons with transparencies. No fillrate savings there...
But then people argued over two pics captured with different settings,
and "established" that DC version is less blurry and has sharper colors
*L*. I mean no matter how you look at it it's ridicolous.
I guess it's a thing that obviously happens to all new hardware.
Sometimes just more. Sony is the industry leader. People like to route against
them. Most people don't particulary like ATI in the graphic card market,
similarly because they are the industry leader, inspite of the fact their
products are not top of the line (performance wise). Same thing could be said about Micro$, although reasons for hatred of them are deeper then general, "they are on top" reasons.
> So in other words, for example 4 or 8-bit textures
> support "X" amount of colors, and you can specify how
> many can be used? This does make sense, being that if
> you wanted a grass texture with maybe only 8 different
> shades or blends of green. Much better than using a 16
> or 32 bit texture (for something that doesn't require
> much 16384+ colors.) Can 4, 8, 16 (maybe 32) bit
> textures be used all at once in the game?
Yes to the first question, and yes to the second one. We are using 4 8
16 and even some 32 bit textures in our own game all at the same time.
Rarely textures utilize more then 256 colors anyway. And with dithering
methods, it can be preferred to use even less colors to increase
resolution and clarity of the texture.
Not all of those were the same e-mail, I just kind of pasted the important stuff together. Interesting, eh? I can't believe I cared so much about something as stupid as a console's architecture. Never again!