后藤大叔的本周评论：
终于进入读秒状态的PS3
http://pc.watch.impress.co.jp/docs/2006/1027/kaigai314.htm

后藤大叔这篇东西，看着挺长的，其实大致的意思也没什么特别
我就不全篇翻译了，大致讲讲主要内容~
主要是说
PS3临近发售了，已经进入起跑线上了，马上要鸣枪
目前PS3看起来，比起之前，要稳定一点了
硬件上，由于延期的原因，其实PS3的部件，都慢慢的变得成熟
像是CELL RSX XDR这些东西，因为延期，现在的工艺和生产能力，都能很好的应付
剩下的硬件问题，主要是BD了~
软件方面，之前后藤大叔TGS时期也提到了，SONY的开发工具在TGS时期还不是1.0版
目前SONY也在为PS3的开发软件支持而努力ing~ 希望能看到进一步的成果~
PS3现在明显的是软件的成熟度落于后硬件~ 还需要时间调整
这也是SONY本身不善于软件开发的体现吧

大体就是这意思了，PS3硬件比较成熟了，但是软件还不行，需要时间熟悉，PS3还有待挖掘

http://psinext.e-mpire.com/index ... icles_articleid=722

Sony's PSSG Project

Part I

What Is PSSG?









Recently, Gavin Cheshire of Codemasters' disclosed in the pages of Develop magazine that their new 'Neon' game engine (Colin McRae) had in fact been developed in part with assistance from SCE themselves.  Though it may not have seemed like it at the time, this statement actually hinted at something much larger in the works over at Sony.

In the tradition of the technology-centric interviews we have pursued of late, it is thus my pleasure to host SCE's Jason Doig - Manager of R&D for SCEI R&D's London office - in what is his first public interview concerning Sony's PSSG project;  a project that has helped to serve as the basis for engines such as Codemasters' 'Neon,' and a project that forms a cornerstone of Sony's SDK offerings.





PSINext: Thanks Jason for taking some time out to discuss the PSSG project with us.  

Something of a stir was created recently with the announcement of Codemasters' Neon game engine and Sony's revealed involvement; yet for the most part people still remain largely in the dark as to the role SCEI has played in providing some of the underlying library.  Can you tell us a little about SCEI R&D's mission, and a little about your own role within that organization?  

Jason Doig: Sure. Put as simply as possible, SCEI R&D is responsible for the PlayStation platform. Not the games - that's a separate part of the company entirely - but the hardware, operating system, developer SDK, etc... Our mission then is simply to make the platform as strong as possible – to build the best hardware, and then help developers (1st and 3rd party alike) get the most out of it by providing software and other development tools. The R&D group has teams in several sites around the world, and I head up the largest of the four software teams based in London. This team has been working on PS3 for a little over three years now, and for most of that time we've been working on PSSG.  

PSINext: Since this is the first time most readers will be hearing about PSSG, are you able to start by telling us what PSSG stands for?  

Jason Doig: Actually, it's hard to give this question a straight answer. As far as I'm concerned, it doesn't really stand for anything at all! A lot of people assume it stands for "PlayStation Scene-Graph," as a scene-graph forms a central part of our graphics engine.  However, we prefer not to think of it that way because there are many more aspects to the project than just a scene-graph library. Really, the name was just chosen to compliment other parts of the SDK, such as PSGL (the OpenGL/ES variant which is one of the main PS3 graphics APIs).  

PSINext: PSSG is a graphics-centric aspect of the SDK tools then?

Jason Doig: PSSG is, at its core, a graphics engine. The whole PSSG package consists of a core set of libraries, some extension libraries to add optional functionality, and assorted samples showing people how to use it. It also contains a lot of documentation and supporting tools for processing art assets as part of a production pipeline. It's not a complete game-engine (unlike Unreal, for example) but it is intended to be a pretty complete package for handling the rendering part of a game. We're not finished yet, but we already have all the things you would expect, like handling of complex scenes, visibility checks, and sophisticated animation playback & blending. We're continually adding new features and responding to requests from developers, so it's also growing.  For example, we're adding integration with physics engines right now - but for the most part, we're still focused on graphics.  

PSINext: Gavin Cheshire of Codemasters conveyed a sense that - perhaps more than usual - SCEI was involved in helping to flesh out their engine.  Is it normal for SCEI to lend advice and help to developers utilizing Sony SDKs in creating something that they can consider to be their own?  

Jason Doig: Certainly I think the biggest help we gave them was PSSG itself - which of course is something that is openly available to all PS3 developers as a downloadable package. However, it's true that we have been working quite closely with Codemasters to help them integrate PSSG with their own technology.  That has included training sessions on PSSG itself, responding to specific feature requests, and discussing how to extend PSSG to fit their needs. Although Codemasters has been making good use of our time, this kind of help is open to any developer, and it's simply the case that Codemasters saw the potential of PSSG relatively early and thus were able to capitalize on that. I think many developers simply were not expecting us to have something like PSSG available, nor that we would allow cross-platform usage.  

PSINext: With animation being one of the focus' of PSSG - and you mentioned soon physics integration as well – are we safe in assuming PSSG is in part geared towards assisting developers draw out the power of the SPEs?  

Jason Doig: Oh absolutely - one of our core aims is to make as much use of the SPEs as we can ourselves, and to enable developers to make use of them as simply as possible when using PSSG.  So within the PSSG framework, we've sought out any area where processing can be done on an SPE and designed PSSG to not only make use of that, but to expose the parallelism through a simple interface. This has been done right from the initial design of the system, despite initial implementations having first been done on a PC platform rather than on Cell... and indeed we still run on non-Cell platforms, as cross-platform support is another important feature for PSSG.

For the animation system we sat down and sketched out how data would flow through the system, starting with "time" entering at the top, and final positions (or other animated values) coming out at the bottom. The process of animating was split down into simple discrete blocks (for example we might have blocks to follow key frames, blend data together or apply IK) from which a complex process could be built, with data flowing cleanly between the blocks. Rather than assuming a traditional random-memory access pattern, we tried to keep all data in contiguous blocks that could be easily passed to and from the SPEs. At runtime the blocks could be running on a single SPE, or could be split between different SPEs. We have a "driver" running on the SPE during the animation processing which handles the task of keeping the data flowing, and that can also fetch whatever other memory the animation processing blocks need. We even do intelligent prefetching of data, working on the basis that an animation will need similar data from frame to frame. In this way, the developer need only write a simple processing script to perform the animation function itself, and we take care of making it run efficiently on the SPEs.

The animation system is one of the best examples of this approach, but we have also applied it to other areas as well... such as the traversal of the scene-graph itself and towards processing streams of geometry (we used to call this "Geometry Shading" but then the term was adopted elsewhere!). The geometry processing is a powerful feature we have; it adds a very flexible pre-vertex-shading stage to the graphics pipeline. Using this we can, for example, create procedural geometry on the fly. Again this is simple for a developer to make use of, and PSSG itself manages the task of pipelining the data and running the code in parallel. It's also modular, so you can connect any number of geometry processes together to create a "network" of processing stages for any given effect or situation. We even have GUI tools so that networks can be viewed or edited by an artist.  

On non-Cell platforms (or if the developer decides not to allow PSSG to use SPEs for some reason?) we can run all these same processes on an "ordinary" core, and even run them multithreaded if appropriate for best performance. However, we certainly run better when SPEs are used!  

PS3 GPU=CELL+RSX？？

[ 本帖最后由 codjc 于 2006-10-29 12:53 编辑 ]

日本版张五常

挖角微软，多招点。

谁 来个全文 翻译 谢谢

英文的？？？

意料之中。。。希望PS3周期可以长一点。。。

:D
随便鸟。
反正2008年再考虑次世代。

微软很有可能会在2008年后半期推出xo的下一个代产品。。。