How was Ps2 thought to work ???
- Thread starter ShinHoshi
- Start date
It does have on-chip ram yeah. It only needs to be very small though as the tiles it works on are only 32x16 pixels. So it would only need about 2kb of on-chip ram for the tile buffer.
Something else to bare in mind is that the PVRDC chip would, on average in, only have to texture about 1 third of the pixels that the GS has too in a normal game.
PS2 certainly has a fillrate advantage over the DC when multi-texturing, but I wouldn't say that its clearly better at multi-texturing, DC has its advantages too being a TBR.
DeadmeatGA
Banned
....
In summary, PSX2 is a MIPS compatible system with a number of programmable devices stuck in, namely two VUs, one IPU, one rasterizer, a sound chip, and an I/O chip. The maximum performance can be achieved if the programmer manages to feed all the devices with data streams without starving any of devices, but this is very difficult to achieve without multithreading support at the OS level(Not sure if the PSX2 OS even has threading support)
A marketing buzz
Another marketing buzz
Neither do we. Kutaragi has no formal education in programming or computer architecture and therefore thinks "unconventionally"... This is not necessarily bad since amatures tend to be more creative than people with a formal training, but the outcome can be disastrous if not reviewed and adjusted by professionals. Unfortunately in Japanese corporate culture, a subordinate does not correct his superior...
The idea was to outperform DC by a substantional margin at all cost, at the great expense of fabrication cost and programmability.
In summary, PSX2 is a MIPS compatible system with a number of programmable devices stuck in, namely two VUs, one IPU, one rasterizer, a sound chip, and an I/O chip. The maximum performance can be achieved if the programmer manages to feed all the devices with data streams without starving any of devices, but this is very difficult to achieve without multithreading support at the OS level(Not sure if the PSX2 OS even has threading support)
Megadrive1988
Veteran
ELAN, yes.
And you know, back in 1997 when PVRSG / PowerVR2 was unvieled, Videologic said there would be 5 versions or varients
1. PC chip intergrated with 2D and audio (PMX/Highlander)
2. PC 3D-only chip ( became Neon250 in 1998)
3. Console chip (CLX2 / Dreamcast PowerVR2DC)
4. Arcade chip
5. Highend Arcade chip with geometry processor (on board and/or seperate)
plans changed somewhat.
I think the lower end arcade chip was just a CLX2 / PowerVR2 DC chip instead, and the Highend Arcade chip never really happened, but the geometry processor did, I guess that is ELAN coupled with a PowerVR2DC.
Well, from what I understood and already know is that the purpose was to use the CPU to do the main calculations while VU1 and VU0 perform all the vector operations (lightning and transform) since they are good at FP operations.
Then you have a main RAM where you leave all the major things such as: game code, textures, models...but every time you want to render you have to stream to the 4MB VRAM. Apparently this could be a handicap but since the bandwith is so huge and you can update this 4MB so fast there is no problem.
But now I have more doubts:
1. Is the GS pixel fillrate (on screen) so fast that can run on par the 4MB updates ???
2. On another thread, Fafalada comented that using a half framebuffer instead of a full one only saves 500 kb (640*240*24*8/1000) vs (640*480*24*8/1000) but didn't the z-buffer and the textures also decrease it's size when halving the resolution ???
Then you have a main RAM where you leave all the major things such as: game code, textures, models...but every time you want to render you have to stream to the 4MB VRAM. Apparently this could be a handicap but since the bandwith is so huge and you can update this 4MB so fast there is no problem.
But now I have more doubts:
1. Is the GS pixel fillrate (on screen) so fast that can run on par the 4MB updates ???
2. On another thread, Fafalada comented that using a half framebuffer instead of a full one only saves 500 kb (640*240*24*8/1000) vs (640*480*24*8/1000) but didn't the z-buffer and the textures also decrease it's size when halving the resolution ???
DeadmeatGA
Banned
...
This is not the problem with other consoles since they have much larger VRAM plus texture compression.
Original Toshiba proposal had only VU0. Some one at SCEI forced the inclusion of VU1 to boost performance.
It is a big problem since the developer has to manage the uploading texture map into GS manually. The GS can access only 4 MB of its own memory and it is upto developers to ensure correct texture is uploaded into GS before the display list is sent. A major design oversight on the part of SCEI. In essence, GS is a very fast Voodoo1 with less features. A very primitive renderer indeed.
This is not the problem with other consoles since they have much larger VRAM plus texture compression.
I don't know how the math works out. I am not a PSX2 programmer.
marconelly!
Veteran
That speculation is something only you came up with, and could never back up with any sort of proof.
We went through this once. In cases when DC can do BM in one pass (with one planar light and flat surface below it), PS2 can do it in two passes, again much otperforming it.
randycat99
Veteran
Shouldn't there be some disclaimer that pops-up whenever DMGA posts? 
If not for safety reasons? Honestly!
If not for safety reasons? Honestly!Teasy said:
Doesn’t it also have some on-die RAM for decompressed textures used in the current tile, or does it have to fetch the whole texture, decompress it to VRAM, and then use it?
DC (like PS2) will still need to have whole maps in its VRAM, or else it would have virtual texturing. So the 800Mb bus between VRAM and PVRDC should play almost the same role as the combined 1.2 Gb EE to GS and the 9.6Gb internal bus on the GS. A bit difficult to compare then.
Being a deferred renderer means that it (DC) relies heavily on the opaqueness of objects for its performance boost and also the compression technique it uses can't do anything else than punch through “alphaâ€.
PS2 on the other hand has free alpha and dual states for fast context switching among other things, that should make it a much superior multitexturer.
Quite possibly yeah, not sure on that one.
Surely PVRDC would only fill the VRam after its performed hidden surface removal and discarded the unseen geometry? In which case why would it load textures into VRam for geometry that its already discarded?
BTW, I hear that GC has virtual texturing, how does that work exactly?
Deferred renderers have lots of advantages, not just the ability to not render pixels behind opaque textures.
For multi-texturing, for instance, PVRDC should be able to do many textures in a single pass, given that a TBR will have all texture info before even starting to render the frame.
Megadrive1988
Veteran
Teasy,
yeah that is basicly what I said.
however the two arcade PowerVR2 solutions I mentioned, number 4 and 5, referred to Videologic/ImgTech's stated plans back in 1997. printed in Next Generation and on the net. As I said, things changed somewhat. by 1998/1999 the lowend arcade chipset was NAOMI, using the console chip (PowerVR2DC) and the highend arcade board (not chip) came out in 2001, NAOMI 2, which was using two PowerVR2DCs and the ELAN T&L unit.
So instead of having three different PowerVR2 chips
(1 for console, 1 for arcade lowend, 1 for arcade highend) they simply used the same PowerVR2 chip that was in DC, the PowerVR2DC, for all three types of hardware. But with the the highend arcade (NAOMI2) they used two PowerVR2DCs plus a seperate (not on-chip) T&L chip, the ELAN.
I was just saying that back in 1997, their annouced plan was to have 5 different PowerVR2 chips
Megadrive1988
Ok, it just sounded to me like you didn't know that there was a highend arcade board based on series 2 when I read your comment.
BTW did they actually say they would have a highend arcade chip?, or did they say they'd use Series 2 for a highend arcade chipset?
Also did they definitely say that each chip in each market would be different? Just curious, as usually a company would just say that they plan to have a chip based on this architecture in each market, not necesarilly a different chip for each market.
Ok, it just sounded to me like you didn't know that there was a highend arcade board based on series 2 when I read your comment.
BTW did they actually say they would have a highend arcade chip?, or did they say they'd use Series 2 for a highend arcade chipset?
Also did they definitely say that each chip in each market would be different? Just curious, as usually a company would just say that they plan to have a chip based on this architecture in each market, not necesarilly a different chip for each market.
Megadrive1988
Veteran
I think I recall them saying that they'd have a highend PowerVR2 chip for arcades, with on-chip T&L.
the lowend PowerVR2 arcade chip was said to be capable of making use of a seperate T&L chip ( if i recall )
the lowend PowerVR2 arcade chip was said to be capable of making use of a seperate T&L chip ( if i recall )
PVR doesn't fill anything - the VRam is the only memory it can address - hence any textures used must be in there before it starts rendering.
The rasterizer can address external memory as texture memory and fetch texture data into internal on chip memory. The term "VT" only loosely applies - this is essentially the same process that happens in NV2a, with the difference that Flipper has a much larger and user configurable texture cache.
And to bitch a little, I'd prefer not to use the term deferred so generally. GC and PS2 for instance are both fully functional deferred renderers - but that doesn't give them access to any of the fillrate saving stuff PVR chips do
Anyway, in regards to multitexture, I was under impression that PVRDC only did one texture per pass?
