Path: chuka.playstation.co.uk!tjs From: tjs@cs.monash.edu.au (Toby Sargeant) Newsgroups: scee.yaroze.freetalk.english Subject: Re: S*ga Dreamc*st Date: 6 Aug 1998 01:34:47 GMT Organization: PlayStation Net Yaroze (SCEE) Lines: 103 Message-ID: References: <3569980E.51FC@saqnet.co.uk> <356A77BD.596@dma-design.com> <356a4d1f.24746116@news.scea.sony.com> <356A8BBD.5DD9@dma-design.com> <35C13E1E.4A99D280@mail.datasys.net> <1dd416x.1cqaclz4vkpc1N@a1-88-110.a1.nl> <6q1g2e$fvf13@chuka.playstation.co.uk> <1dd8b4y.1g33oa41ggvfzhN@[194.151.88.144]> <35C829EA.55EFA3B1@scee.sony.co.uk> NNTP-Posting-Host: indy16.cs.monash.edu.au Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Newsreader: slrn (0.9.5.1 UNIX) On Wed, 05 Aug 1998 10:46:18 +0100, James Russell wrote: >From what I've heard, MS Windows CE is actually very good. You're forgetting that the _main_ reason >why people hate Windows is because it crashes alot. That's because there's millions of lines of >code, dating to way back when, some 16 bit, some 32, lots of horrible legacy code. Windows CE was >created from scratch, and hence its a very stable system. This was my point about the one redeeming feature of Windows CE over Windows 95, and the single reason that I'd be prepared to put up with it. >compete. So DirectX will go out the door very quickly. It will only be useful for PC developers >wanting to port games. I doubt it. The Dreamcast will likely be fast enough that programmers, being the lazy things that they are won't optimize for optimization's sake. People will stop using DirectX either because they don't like it, or because they don't like relying on other people's code. If it doesn't have to support lots of different hardware, the DirectX implementation can be very fast indeed, so it's just a matter of what APIs are supported. >> The problem is not that, it's the fact that on large projects >> like Windows 95, the code base has reached critical mass, and the >> management has fallen apart, allowing bugs to creep in unnoticed. > >No, I think we noticed them alright... :O) Unnoticed by the programmers and testers. Probably mostly unreproducible by the users. They're the nasty bugs. >The cost of such processors is large in comparison with the rest of the console. Remember that they >have to churn out millions of these CPUs _and_ make them cheap enough to put into a home console in >the first place. I would want to see a 1Ghz PPC or a 400 PII in PSX2, but nobody wants to pay £600 >for a console! :O) The N64 manages to provide a decent MIPS processor. I'm not talking about 400 MHz P-IIs, or 1GHz PPCs (which would slaughter 400 MHz P-IIs, but that's another story). I'm more looking at the R[45]000 range processors. Something with an equivalent clock speed but with a better name than Hitachi. >Programming for multi-CPUs _efficiently_ is at least twice as hard as normal coding. And the >complications with the system bus are massive. For instance, there are problems with cache >inconsistency between processors. All of these are solvable, of course, but getting 200% power out >of 2 CPUs is almost impossible and very difficult to design. From what Colin tells me, most Saturn >programmers used the second CPU like a GPU - it just sat there waiting for commands in a queue and >processed them whenever they arrived. That's not efficient, but it's easy to program. Sure. But the point is that price is roughly exponential in terms of power, so by providing 2 CPUs of lesser power, you can get an approximately 1 generation jump for less than the comparable price. It's not all that hard to get good use out of a dual cpu system; you just need to think a little more, and have good OS support. BeOS demonstrates that. >The other thing about multi-CPUs is that they're only good when you want to do many independent >things at once. If you consider that CPU time spent on sound/controller/CD is almost negligible, >then the rest of the time is divided into Pre-Scene Creation (like doing all the physics >calculations in Gran Turismo), Scene Creation (creating the polygons) and Scene Drawing (drawing >them). Since Scene Creation can't be done in parallel with Pre-Scene Creation (with the exception of >some games, and assuming you haven't got enough memory for triple buffering), and Scene Drawing is >done by the GPU anyway, then multi-CPUs aren't going to help in most cases. Lies. All lies. Scene creation occurs as fast as possible into a circual buffer of potential scenes as fast as it can. A separate thread waits for at least one complete scene and then renders the most recent scene into polygons in a second circular buffer. The third thread takes the most recently rendered polygon scene, and then displays it. Thus, scene creation may be a frame or so ahead of scene display, but the user won't feel it. Apart from this, there's obvious parallelism to be exploited by dividing the track up into sections, and parallelising the car physics of cars that are in different sections. I think if you put your mind to it, you'll find that there's parallelism to be had in a _lot_ of 3d games, and even in some 2d ones. [I'm hard pressed to find parallelism in tetris, though...] >Yeah, QNX rocks. However, as I recall, it's only available on Intel CPUs, or at least CPUs with a >proper MMU. For speed and cost reasons, I don't think Next-Next-Gen systems will be either Intel or >have a MMU. QNX was designed for real-time work, like controlling industrial machines. In >comparison, a console OS is really an just an API to the hardware. It only handles interrupts and >system calls to hide the effects possible changes in the ROMs and other hardware from developers. I >don't consider the PSX libraries to be a true OS, which QNX is. http://www.qnx.com/hotnews/pr/jun1_98-mips.html QNX now supports MIPS, PPC. My point stands. By providing a little extra support in the OS (and lets face it, memory is sufficiently cheap these days, that that's viable), you take a lot of load off the programmers. QNX _is_ designed for realtime work. All the better for use in a multi cpu system that has tight constriants on when things must be done. >Why do you need an MMU? You're only running one program. Multi-threading is still possible. Set up >of the MMU registers takes extra time and is potentially buggy (ever written a DPMI stub?). It >marginally slows down the chip. It requires more silicon, which ups the cost of the chip. In any >event, its unlikely that programmers and debuggers would use it much. Again, it's a matter of OS support. An MMU is useful if you've got the support for it already there. There's no reason why a game has to be a single process, and in fact, there's no reason why the OS has to be a single process either. Toby.