3d Real Performance

[bustaballs]

Wait. The Pandora won't have any dedicated VRAM? It all going to be shared from system memory? That changes my mind a little on the potential possibilities of the system.

While I'm a decent computer tech, I'm not nearly as knowledgeable as some of the people here. It feels like I just took a foreign language course and went to a native speaking country. I know quite a bit but some of the stuff goes right over my head.

 

[WizardStan]

VRAM does not necessarily equal memory swapping. VRAM still maps into real memory as well, it just allows you to exceed physical memory by swapping to disk if physical memory gets full. I assume you meant memory swapping though.
I still don't think the SD cards would be fast enough for swap, even accounting for the seek time. Not only does the average write rate account for random access, but you wouldn't normally write one block at a time anyway; more likely a few megs at a time in one contiguous chunk.
It'd be an interesting comparison at the least, I think.
Anywho, I'm hoping it's all a moot discussion anyway: I'm currently running dosbox, kdevelop, pidgen, totem (playing MP3s), and a professional decompiler called The Interactive Disassembler through Wine in about 150 megs. A few tweaks should easily bring memory usage down. Speaking of Firefox will only hurt my case, unfortunately...
I remember running Netscape and word, and some other apps all at the same time on win3.1 with a whole 4 meg of ram, and up to 8 megs of swap space. WOW! And now we're worried that 128 megs won't be enough?

 

[Squidge]

Wait. The Pandora won't have any dedicated VRAM? It all going to be shared from system memory? That

As already stated, no dedicated VRAM, but the processor does have dedicated cache

 

[icurafu]

WizardStan, I think he was talking about video ram, not virtual ram... which as a little random based on what was discussed.

 

[Exophase]

Wait. The Pandora won't have any dedicated VRAM? It all going to be shared from system memory? That changes my mind a little on the potential possibilities of the system.

I wouldn't too easily write off a unified memory architecture, N64 and XBox were UMA and they were the graphical leaders of their respective generations. In the case of the SGX in the Pandora, it isn't going to be clocked high enough to significantly outstrip the bandwidth main memory can provide, and the latency can probably be hidden (graphics has good locality of reference). Naturally the SGX will have its own cache as well, although how much is anyone's guess.

UMA is just more flexible in general, as are unified caches, unified shaders, etc.

 

[WizardStan]

WizardStan, I think he was talking about video ram, not virtual ram... which as a little random based on what was discussed.

Right you are. Sorry, my confusion. I'll just shut up now.

 

[vision]

Swapping is unpleasant at any speed and should be avoided at the design stage if at all possible .

Tell it to GTA developers, and players

Swapping is a WONDERFUL resource when you take good care using it

 

[christo930]

I do think that this is a real and potentially rather serious problem, however it is somewhat mitigated by:

a] CPU's L2 cache (most other embedded devices are lacking this) which minimizes main memory stress somewhat.
b] Caches on the SGX's side... although we don't know how large they are.
c] Deferred tile rendering which minimizes texture accesses and framebuffer writes compared to other archs.
d] Texture compression.

I think the Wiz is going to be doing much worse because it doesn't have any of a or c and I don't know if it even has d (and texture caches are probably much smaller), AND it has half the memory bandwidth (16bit bus)

Also I think that the frequency will be fine so long as the SGX clock doesn't exceed it (such that it can't provide one 32bit transfer per cycle, which it should be able to do hopefully, if latency is hidden), and it won't.

Does texture compression compromise the graphics quality? If so, how much? Can it be eliminated with lossless compression or limited with less aggressive compression (like is there different levels of compression)?

Chris

 

[Svartalf]

Huh?? Why the hell would the system let you swap in the first place? Why would there be any swapping? It doesn't make sense that anyone should let any app swap to the SD (utter nonsense) so if you try to use more than you can your allocations should just fail. I don't see why it should be any different.

Because with OS, loader, and game, coupled with the framebuffer, textures, FBOs, etc. you can, in theory, exceed 128 MB of system memory by a factor of at least 50%. The Pandora is quite a bit more than a 2X on steroids- and some titles may exceed the capacity of the unit without swapping some non-actively used applications to a small swapfile on flash, much like the N800 does or a desktop machine. It's not the thing you think it is. The inactive launcher, pieces of the OS not actively used, would be what would be swapped out to give the game maximal memory- but only if the request from the game exceeds what is available. I have to ask, considering that other handheld devices DO swap and to the SD, why you call it "utter nonsense"? Keep in mind, I've been doing embedded systems for some 10 years now, mostly with Linux, so you're going to have to back that up with solid facts- but I'm interested in hearing what you have to say. If you can sell me on what you just claimed, I'll back it up and we'll make sure it's NOT an option that's readily available to people on the firmware image.

 

[warmi]

I do think that this is a real and potentially rather serious problem, however it is somewhat mitigated by:

a] CPU's L2 cache (most other embedded devices are lacking this) which minimizes main memory stress somewhat.
b] Caches on the SGX's side... although we don't know how large they are.
c] Deferred tile rendering which minimizes texture accesses and framebuffer writes compared to other archs.
d] Texture compression.

I think the Wiz is going to be doing much worse because it doesn't have any of a or c and I don't know if it even has d (and texture caches are probably much smaller), AND it has half the memory bandwidth (16bit bus)

Also I think that the frequency will be fine so long as the SGX clock doesn't exceed it (such that it can't provide one 32bit transfer per cycle, which it should be able to do hopefully, if latency is hidden), and it won't.

Does texture compression compromise the graphics quality? If so, how much? Can it be eliminated with lossless compression or limited with less aggressive compression (like is there different levels of compression)?

Chris


It depends.

Here is an example:
On the left an uncompressed version of a 512x512 texture , on the right the same but compressed using PVRTC1/4BPP.

TGA - 786 KB
PVRTC1/4BPP - 171 KB

http://www.warmi.net/tmp/Comparison.png

Here is another one .. same story, the only difference being the one on the right compressed using PVRTC1/2BPP.
http://www.warmi.net/tmp/Comparison2.png

TGA - 786 KB
PVRTC1/2BPP -86 KB

Obviously, there is some difference but I think it is quite acceptable.

In any case, a lot will depend on what kind of image are you trying to compress.

 

[Svartalf]

On the left an uncompressed version of a 512x512 texture , on the right the same but compressed using PVRTC1/4BPP.

TGA - 786 KB
PVRTC1/4BPP - 171 KB

Here is another one .. same story, the only difference being the one on the right compressed using PVRTC1/2BPP.

TGA - 786 KB
PVRTC1/2BPP -86 KB

Obviously, there is some difference but I think it is quite acceptable.

Heh... I think the sizes are telling, especially the 2bpp compression. While there IS loss, I think everyone is going to find that the memory goes REAL fast if you don't use compressed textures for many things.

QUOTE

In any case, a lot will depend on what kind of image are you trying to compress.



Indeed.

I still don't think the SD cards would be fast enough for swap, even accounting for the seek time. Not only does the average write rate account for random access, but you wouldn't normally write one block at a time anyway; more likely a few megs at a time in one contiguous chunk.

It's actually more usable than one would think. I do it right now on my N800- and it only occasionally pauses for a slight time when something HUGE gets swapped in or out.

QUOTE

Anywho, I'm hoping it's all a moot discussion anyway: I'm currently running dosbox, kdevelop, pidgen, totem (playing MP3s), and a professional decompiler called The Interactive Disassembler through Wine in about 150 megs. A few tweaks should easily bring memory usage down. Speaking of Firefox will only hurt my case, unfortunately...



Heh... You're forgetting modern games, 3D stuff, etc. All this stuff eats RAM like candy. Especially when you're sharing the framebuffer, 3D accel, OS, and app at the same time. 128Mb goes fast when you look at the textures you're having to deal with.

QUOTE

I remember running Netscape and word, and some other apps all at the same time on win3.1 with a whole 4 meg of ram, and up to 8 megs of swap space. WOW! And now we're worried that 128 megs won't be enough?



And they will be for using a lighter browser, and something like AbiWord. It's just that Q3, for example, would do "okay" with a 64Mb machine of the day- and that machine HAD video RAM for the framebuffer, vertex buffers, textures, etc. Plus the machine had swap to offload extra things like the bulk of X11, etc. off to swap to PLAY the game. We're looking at a similar thing here with what we're doing.

We're going to be "okay" with many of the things we are going to do with the Pandora- it's just that some of them are going to be a bit more aggressive with the resouce usage and you're going to need to leave the option open (don't require it out of the box...) to provide swap so that you can use the top-end games or to do several things simultaneously.

And for those clamoring that a console doesn't need swap, etc. What do you think each "Loading..." piece is on a PS2, etc. They're clearing out and loading up level stuff into memory. Much like what the swap does automatically.

 

[ldesnogu]

I do think that this is a real and potentially rather serious problem, however it is somewhat mitigated by:

a] CPU's L2 cache (most other embedded devices are lacking this) which minimizes main memory stress somewhat.
b] Caches on the SGX's side... although we don't know how large they are.
c] Deferred tile rendering which minimizes texture accesses and framebuffer writes compared to other archs.
d] Texture compression.

IIRC someone on BeagleBoard IRC told that turning on the FB was reducing bandwidth by about 10% (as measured by lmbench). I will try to reproduce these results (though I won't be doing that with the 3d drivers).

 

[Exophase]

I do think that this is a real and potentially rather serious problem, however it is somewhat mitigated by:

a] CPU's L2 cache (most other embedded devices are lacking this) which minimizes main memory stress somewhat.
b] Caches on the SGX's side... although we don't know how large they are.
c] Deferred tile rendering which minimizes texture accesses and framebuffer writes compared to other archs.
d] Texture compression.

IIRC someone on BeagleBoard IRC told that turning on the FB was reducing bandwidth by about 10% (as measured by lmbench). I will try to reproduce these results (though I won't be doing that with the 3d drivers).


What resolution framebuffer?