Dreamcast would be awesome

[Prometheus]

I'm just curious, but were they common in 1998?


EDIT: I just realised that I ought to explain my curiousity so I don't end up coming off like I'm being a smartass, which isn't my intent at all. What I mean is, whilst they were common in 1999, the Dreamcast launched almost a full year before that, in 1998, so I'm wondering if that makes a difference to that part of the discussion.

 

[Asiyura]

Have you tried Eve Online, Dungeons and Dragons Online, Horizons: Empires of Istaria, Dark Age of Camelot, Neocron 2?


[…]

I've played EVE online for a while, never played the others, but I admit I over generalized.


Still, I think most of the current MMO games are complete rip-off of each others.


Example :


Take Lineage 2, slightly change the models, improve the 3D engine, you have Rappelz.


Take Lineage 2, use colorful Comics-like textures and change the background story with the one from a big RTS license, I think you've got it…


But I'll stop derailing this topic

 

[Khan_81]

IIRC drkRaziel got stuck with OGL coding in NullDCe for Pandora so he grew frustrated and kept the project on hold (until he receives his Pandora, I guess).


Anyway, Adventus was granted access to the last SVN so, on the bright side, he might continue the project while sharing dev-talk with drkRaziel in case any shortcoming arises.


Who knows, maybe we will be able to run some of the non-so-taxing DC titles on Pandora at playable speeds (Power Stone showed a peak of 8-9 fps in-game on an unoptimized

https://www.youtube.com/embed/skUS7UI5OGU?feature=oembed build, right?)

PD: We better wait for Pandora to show its true colors perfomance-wise (DSP, NEON, OpenGL-ES...) before prematurely killing it discussing about its succesor (It sounds sooooo wrong >_<)

 

[Exophase]

Almost all modern emulators have idle loop detection, I assume that's what drk||Raziel is doing. I doubt he's modelling the internal stalls and cache misses.

I really doubt that it's at all common for games to be expecting 200MIPS before they hit idle loops, unless they're performing well under expected spec. What's more likely is that there's hardware halts somewhere that (some?) games are using, but I wouldn't know exactly. Maybe he can tell us.


I challenge your claim that almost all modern emulators have idle loops detection. drk has said before that he's underclocked the SH4s to gain performance, on several occasions... there'd be no point in doing this if there was at all effective idle loop detection, and it wouldn't have resulted in the speedups he's shown.

If the Dreamcast RAM is really 64-bit and 100MHz as often claimed, the cache misses probably aren't that severe. 60ns DRAMs were pretty common in 1999, and if it can really transfer 64 bits per cycle, it could probably service a cache miss within 15 cycles.

That's quite optimistic, I mean, to think that the cache miss duration would be defined entirely by the RAM latency and not some cycles of overhead on the cache controller and bus. That's just rather contrary to my experiences. The SH4 manual in particular indicates 2 CPU cycles and 3 bus cycles of penalty for a dcache miss (page 162 of SH7750 manual ADE-602-156A)

 

[ari64]

I really doubt that it's at all common for games to be expecting 200MIPS before they hit idle loops, unless they're performing well under expected spec. What's more likely is that there's hardware halts somewhere that (some?) games are using, but I wouldn't know exactly. Maybe he can tell us.


I challenge your claim that almost all modern emulators have idle loops detection. drk has said before that he's underclocked the SH4s to gain performance, on several occasions... there'd be no point in doing this if there was at all effective idle loop detection, and it wouldn't have resulted in the speedups he's shown.

The SH4 has a SLEEP (idle) instruction. No idea how many games use it.

That's quite optimistic, I mean, to think that the cache miss duration would be defined entirely by the RAM latency and not some cycles of overhead on the cache controller and bus. That's just rather contrary to my experiences. The SH4 manual in particular indicates 2 CPU cycles and 3 bus cycles of penalty for a dcache miss (page 162 of SH7750 manual ADE-602-156A)

So 3 bus cycles, plus 5 or 6 bus cycles (for 50ns or 60ns RAM) plus 3 bus cycles for the rest of the data transfer (cache line size is 32 bytes).


The CPU can continue once the cache line is partially filled, so the effective latency is around 9 bus cycles or 18 CPU cycles. If there are 40 million reads per second, and 10% miss the cache, that would be 72 million cycles waiting on the memory, or 36% of the CPU time. I don't know if that's a reasonable estimate or not, but it falls roughly within the range of what drk||Raziel is claiming. Unlike the N64, the Dreamcast doesn't have to share the bus with the framebuffer. (N64 spends ~60% of its time waiting on the RAM, I doubt DC is that bad.)


There are some other stalls on the SH4, such as a 1-cycle shift stall and a load-use stall, but the big stalls are the FPU instructions and read-modify write instructions, which he indicates are relatively uncommon.


I'm surprised that floating point was less than 5% of the instructions. N64 games typically have a similar percentage of FPU instructions, but I would have guessed that the FPU would be more heavily used on the Dreamcast. Guess not.

 

[kuru]

This incredibly interesting although I understand not half of it. A little reading up revealed that this SH4 is popular in the automotive industry. According to wikipedia an SH4 clocked at 600MHz is being used in the latest Mercedes E-Class. Heh. Maybe we should just get a Benz to have Dreamcast on the go.

 

[Exophase]

The SH4 has a SLEEP (idle) instruction. No idea how many games use it.

Hopefully a lot! It's silly for things to not use these instructions and do other simple things to save power. Sadly, even today on platforms like Nintendo DS they're not used all the time.

So 3 bus cycles, plus 5 or 6 bus cycles (for 50ns or 60ns RAM) plus 3 bus cycles for the rest of the data transfer (cache line size is 32 bytes).

Okay, so 3 + 5 + 3 = 11 bus cycles = 22 + 3 = 25 CPU cycles. 19 to get the first word. A bunch of other stuff goes down if the cache is write back. Store queues help.

The CPU can continue once the cache line is partially filled, so the effective latency is around 9 bus cycles or 18 CPU cycles. If there are 40 million reads per second, and 10% miss the cache, that would be 72 million cycles waiting on the memory, or 36% of the CPU time. I don't know if that's a reasonable estimate or not, but it falls roughly within the range of what drk||Raziel is claiming. Unlike the N64, the Dreamcast doesn't have to share the bus with the framebuffer. (N64 spends ~60% of its time waiting on the RAM, I doubt DC is that bad.)

90% hit rate seems optimistic to me for direct mapped 16KB cache. The Dreamcast probably spends a lot of time preparing big chunks of data for the PowerVR chip, which would typically burn straight through cache. Unlike the N64 the Dreamcast CPU is performing T&L itself.

There are some other stalls on the SH4, such as a 1-cycle shift stall and a load-use stall, but the big stalls are the FPU instructions and read-modify write instructions, which he indicates are relatively uncommon.

Taken branches usually stall too, although they also probably pair well. Indirect branches are a little worse.


In his case, who knows what his timing model is. Load-use and branch stalls alone might be enough to bring a game from 200 MIPS to 120 if no superscalar execution is detection (and no cache stalls, of course)

I'm surprised that floating point was less than 5% of the instructions. N64 games typically have a similar percentage of FPU instructions, but I would have guessed that the FPU would be more heavily used on the Dreamcast. Guess not.

I'm surprised too, but the instructions are probably much more likely the heavy duty matrix * vector operations.

 

[DaMummy]

exophase, i know you dont like it when people tell you not to talk and start coding, but may i just say that every time i see you and ari exchanging ideas, my ears get wet

 

[Exophase]

Ew.

 

[Poem58]

I'm afraid I have no idea what DaMummy meant by that. I'm also too afraid to ask.


+1 on Ew.

 

[Targus]

I've played EVE online for a while, never played the others, but I admit I over generalized.


Still, I think most of the current MMO games are complete rip-off of each others.


Example :


Take Lineage 2, slightly change the models, improve the 3D engine, you have Rappelz.


Take Lineage 2, use colorful Comics-like textures and change the background story with the one from a big RTS license, I think you've got it…


But I'll stop derailing this topic

Just felt like randomly saying lineage 2 stole 3 years of my life and another 3 to 4 years on private servers . Now playing Ragnarok 2: gate to the world, is uses the same engine as lineage 2


In fact the game almost looks the same but different looking characters. Cool thing about it is Ragnarok 2: Gate to the World. Will NEVER be released so playing it is kind of fun knowing its a


leak of a MMORPG that never was lol.


Oh a side note I also have no clue about the coding side of this conversation but I do know Exophase is a big wig in the psp coding scene so I feel honored having him post in a thread i made


Getting wet ears though.. uhh you should see a doctor about that. I don't think it's normal.

 

[ari64]

Hopefully a lot! It's silly for things to not use these instructions and do other simple things to save power. Sadly, even today on platforms like Nintendo DS they're not used all the time.

I'd expect that most would. Traditionally console games render at a fixed frame rate, halting the CPU and waiting for the next vblank interrupt. Games on modern hardware are less likely to be designed this way, but it was still fairly common in the late 90s.


Not sure about the DS, but a lot of game engines nowadays are multi-threaded and output frames as fast as the GPU will do so. Goldeneye is one N64 game that was notable for doing this, but most games of that era used a fixed frame rate.

Okay, so 3 + 5 + 3 = 11 bus cycles = 22 + 3 = 25 CPU cycles. 19 to get the first word. A bunch of other stuff goes down if the cache is write back. Store queues help.

Er... 8 bus cycles to get the first word, and 1 bus cycle for each of the subsequent words.


The SH-4 manual states, "Data reading is performed, using the wraparound method, in order from the longword data corresponding to the effective address, and when the corresponding data arrives in the cache, the read data is returned to the CPU." (SH-4 Software Manual, REJ09B0318-0600)


The SH-4 apparently has store queues, although I'm not sure I understand the description in the manual.


The store queue getting full is a problem on the OMAP3530. I found that rearranging the instructions to put loads after stores often improved performance (apparently it can load from the L1 cache while a write back is in progress).

90% hit rate seems optimistic to me for direct mapped 16KB cache. The Dreamcast probably spends a lot of time preparing big chunks of data for the PowerVR chip, which would typically burn straight through cache. Unlike the N64 the Dreamcast CPU is performing T&L itself.

For sequential reads, the hit rate would be 87.5% (every eighth word would be a new cache line). If it's doing a lot of constant loads, it could be >90%. Random reads would of course have a low hit rate. I don't have any idea what the i-cache miss rate would be.


drk||Raziel refers to "static" and "inline" memory accesses. I'm not completely sure I understand what he is referring to, but since he refers only to reads, and not writes, being "static", I assume that these are PC-relative constant pool loads. As for "inline", the way I handle memory accesses normally is that there is a test of the address and a conditional branch, which either goes to a memory access or to a more complex handler. If the address can be pre-determined via constant propagation, then there is no branch, so these are inline.


If I'm understanding this correctly, 53.75% inline reads is absolutely huge. I just profiled some N64 games and found 15.6% in Mario 64 and 6.7% in Zelda OoT. Something very strange is going on with DC games if this is true.

 

[Exophase]

I'd expect that most would. Traditionally console games render at a fixed frame rate, halting the CPU and waiting for the next vblank interrupt. Games on modern hardware are less likely to be designed this way, but it was still fairly common in the late 90s.

Not sure about the DS, but a lot of game engines nowadays are multi-threaded and output frames as fast as the GPU will do so. Goldeneye is one N64 game that was notable for doing this, but most games of that era used a fixed frame rate.

Despite the fixed frame rate for virtually everything, several games on GBA and DS don't use hardware wait for interrupt. DS has a fixed framerate of 60 for the graphics so you can't render faster than that (and the transform capabilities are unlikely be outstripped at 60Hz), so most games are 60Hz. SNES also had the capability to wait for interrupts and I think I've heard of only one game using it. For whatever reason games often poll despite not having to, even in a situation where it costs them battery life.

Er... 8 bus cycles to get the first word, and 1 bus cycle for each of the subsequent words. The SH-4 manual states, "Data reading is performed, using the wraparound method, in order from the longword data corresponding to the effective address, and when the corresponding data arrives in the cache, the read data is returned to the CPU." (SH-4 Software Manual, REJ09B0318-0600)

We're saying the same thing, read what I said again.. I just accidentally added 3 internal CPU cycles instead of 2 (why I said 19 where you said 18)

For sequential reads, the hit rate would be 87.5% (every eighth word would be a new cache line). If it's doing a lot of constant loads, it could be >90%. Random reads would of course have a low hit rate. I don't have any idea what the i-cache miss rate would be.

It's a direct mapped cache at 16KB, it will have a lot of collisions due to aliasing in the upper bits, in particularly unfortunate cases it may even end up fighting over the same cache line simultaneously. I expect the constant loads to cause a lot of conflicts too.

drk||Raziel refers to "static" and "inline" memory accesses. I'm not completely sure I understand what he is referring to, but since he refers only to reads, and not writes, being "static", I assume that these are PC-relative constant pool loads. As for "inline", the way I handle memory accesses normally is that there is a test of the address and a conditional branch, which either goes to a memory access or to a more complex handler. If the address can be pre-determined via constant propagation, then there is no branch, so these are inline.

If I'm understanding this correctly, 53.75% inline reads is absolutely huge. I just profiled some N64 games and found 15.6% in Mario 64 and 6.7% in Zelda OoT. Something very strange is going on with DC games if this is true.

No, it's just the nature of SH4. Instruction width is only 16-bit and it isn't really optimized for large constants at that. A lot of branches and subroutine calls can't be made except indirectly, and immediate operands fall around 8-bit. It's very different from MIPS.

 

[Targus]

I figured it out i figured out how we can get DC to run on the Pandora. Just super glue one to the back of the pandora! genius....

 

[ari64]

Despite the fixed frame rate for virtually everything, several games on GBA and DS don't use hardware wait for interrupt. DS has a fixed framerate of 60 for the graphics so you can't render faster than that (and the transform capabilities are unlikely be outstripped at 60Hz), so most games are 60Hz. SNES also had the capability to wait for interrupts and I think I've heard of only one game using it. For whatever reason games often poll despite not having to, even in a situation where it costs them battery life.

I don't know of any SNES emulators that do idle loop detection anyway. Snes9x treats WAI/STP as a busy wait loop.

No, it's just the nature of SH4. Instruction width is only 16-bit and it isn't really optimized for large constants at that. A lot of branches and subroutine calls can't be made except indirectly, and immediate operands fall around 8-bit. It's very different from MIPS.

Yeah but even given that, his numbers don't make a lot of sense. He adds inline+static to come up with 27M instructions (81%). That doesn't seem right.

 

[Exophase]

I don't know of any SNES emulators that do idle loop detection anyway. Snes9x treats WAI/STP as a busy wait loop.

I don't know if any of them actually do it, I would guess not.. but PocketSNES does have the ability to patch them manually. I guess it only starts really mattering when you have a 2D engine to render SNES graphics for you and very little CPU and suddenly emulating the 65c816 is the main burden.


Back on the topic of idle loop detection for more modern platforms, and why I challenge you - I can't say for sure which of the closed source emulators do or don't do it, but I know among the open source ones there isn't a GBA, DS, PS1, or PS2 emulator that does it. PCSX2 does have a hack option around certain hardware register loads, but that's not the same thing. I don't think dcemu does it (haven't verified yet), because it talks about setting safe instruction execution ratios.

Yeah but even given that, his numbers don't make a lot of sense. He adds inline+static to come up with 27M instructions (81%). That doesn't seem right.

Yeah, I dunno. To be honest, trying to read the lists gives me a headache. Needs some formatting and clarification, badly >_> We don't actually know what "inline" means. It could just mean memory that's loaded from recompiled code as opposed to a function called from recompiled code.

 

[ari64]

Back on the topic of idle loop detection for more modern platforms, and why I challenge you - I can't say for sure which of the closed source emulators do or don't do it, but I know among the open source ones there isn't a GBA, DS, PS1, or PS2 emulator that does it. PCSX2 does have a hack option around certain hardware register loads, but that's not the same thing. I don't think dcemu does it (haven't verified yet), because it talks about setting safe instruction execution ratios.

Looking at the source code of nulldc, it does appear to do something reasonable with the SLEEP instruction.

Yeah, I dunno. To be honest, trying to read the lists gives me a headache. Needs some formatting and clarification, badly >_> We don't actually know what "inline" means. It could just mean memory that's loaded from recompiled code as opposed to a function called from recompiled code.

I would've asked, but his blog is closed to comments.

 

[notaz]

Despite the fixed frame rate for virtually everything, several games on GBA and DS don't use hardware wait for interrupt. DS has a fixed framerate of 60 for the graphics so you can't render faster than that (and the transform capabilities are unlikely be outstripped at 60Hz), so most games are 60Hz. SNES also had the capability to wait for interrupts and I think I've heard of only one game using it. For whatever reason games often poll despite not having to, even in a situation where it costs them battery life.

Genesis/MegaDrive situation is similar, I only remember one game using 68k's STOP instruction. It wasn't emulated at all by Cyclone for some time.


Don't know if 32x uses SLEEP much, but I know various wait loops are common, some of which are really nasty, involving procedure calls and jump tables.. I guess I'll have to use external database for these cases.

 

[ari64]

Genesis/MegaDrive situation is similar, I only remember one game using 68k's STOP instruction. It wasn't emulated at all by Cyclone for some time.


Don't know if 32x uses SLEEP much, but I know various wait loops are common, some of which are really nasty, involving procedure calls and jump tables.. I guess I'll have to use external database for these cases.

Yabause has a fairly complex method of detecting wait loops, although it won't handle procedure calls and jump tables.


http://yabause.svn.sourceforge.net/viewvc/yabause/trunk/yabause/src/sh2idle.c?revision=2375&view=markup

 

[Jourdy288]

Ow, my brain, I tried reading this conversation and I felt screaming inside my head...