CELL－SPE有趣的东西！

PSINext: I'm happy that you brought up the 'geometry shading' aspect of PS3, as there has been ample discussion of late with regard to exactly that.  We know that lighting models and particle systems make two readily understood candidates for the SPEs; when you look five years out from now, is your sense that graphics engines created for PS3 will increasingly treat SPEs and RSX as a single transparent graphics subsytem?  

Jason Doig: I'm not sure how transparent it will be in other engines, but certainly with PSSG we've taken steps to put SPEs directly into the graphics pipeline. It's not completely transparent right now - you still after all have different restrictions and requirements for different stages of the pipeline. We do try to make the flow of data very easy to manage, however, even all the way back to the artist who created it, let alone the processes at runtime for rendering it. My suspicion would be that this process will continue to evolve, and we will see greater usage of the SPEs as an extension of the graphics pipeline in the future.

This should give us PS3 developers a lot of flexibility to keep up with any changes in the way CPUs and GPUs work in the PC space, where there seems to be a trend back towards unifying everything. PSSG for example, treats the interface between the geometry pipeline (usually running on SPEs) and a vertex shader in the same way as it treats the interface between the vertex shader and the pixel shader. So it's just a backward extension of the pipeline onto the main CPU, where everything is much more flexible. The two things you mention - lighting and particles - are things that we can already drop fairly seamlessly into the PSSG geometry pipeline and run on SPEs. Particle processing especially has an advantage over current GPU based techniques because of the generality of the SPE (and over a traditional CPU as well due to the speed and parallelism of Cell). Using SPEs as a front end to the GPU opens up a lot of interesting avenues and I'd be very surprised not to see people explore them.  

PSINext: Addressing a more general topic, you brought up PSGL earlier as being Playstation's custom OpenGL/ES variant.  When interviewing Mike Acton recently, he mentioned Cg as a framework that had some cross-SPE/RSX appeal in terms of helping to build a frameset towards approaching the PS3 architecture. Any thoughts on this?

Jason Doig: Using Cg as a language for SPE programming is a potentially good idea, because the same features that make Cg easy to compile into good code for a GPU shader unit would make it easy to compile into good SPE code. In fact, how to potentially unify programming across the shader pipeline is something we've looked at when developing PSSG, as it's a natural next step after trying to bolt SPE processing on the front of vertex shading - but currently we haven't attempted to address it. Really, that's something I'd like to see sorted out between the respective compiler folks, and all we can do is point and say: "Hey, don't these two things look like they go together?"  

PSINext: One of the things we've heard from a lot of devs is that the Cell architecture is difficult to approach relative to the OoOE cores they may otherwise be used to.  Do you have any thoughts on difficulties developers from the x86 world seem to have when approaching an architecture like Cell, and do you feel PSSG is something that can help to take some of the edge off?  

Jason Doig: The OoOE issue isn't peculiar to Cell, and this is truth both now and historically; I think very few developers will not have worked on an in-order architecture. I also don't really think it makes the architecture difficult to approach, it's just that on an in-order CPU, you'll get a little less help squeezing the best performance out of it. But the flip-side is that explicit scheduling can ultimately be faster. So really, I think it's a case of having to go one step further with optimizations and getting down into the scheduling, which is the same problem faced on many common and familiar architectures. Even on modern x86 PCs developers will have to worry about optimizing shaders where the same techniques apply.  Naturally the compilers ought to do as much as possible, but it's still important for the developer to look after some aspects such as program flow and data access.  PSSG could certainly help here, simply by providing a good starting point for developers to use as a framework.  

We've spent a lot of time analyzing the performance of our code, identifying which sections we should optimize or move onto SPEs, and of course we've applied that knowledge to maximize both PPU and SPE performance. This is a continual process, and although I'm happy with the performance now, we're going to keep improving it. Even if a developer didn't want to adopt our code, they can see how we've approached various aspects of the design, and those design decisions should be informative. If developers do choose to use PSSG they get even more help, as we have instrumentation and performance monitoring functions built in for them to monitor both PSSG and their own code.  

If a developer were to really be stuck with performance (and here I'm not just talking about PSSG), we'd be happy to try and investigate to find a solution for them.  

PSINext: One of the major concerns developers have expressed over this generation of game design are cost concerns associated with the creation and management of art assets.  Does PSSG provide any tools to lend assistance in this regard?  

Jason Doig: This is something I've been concerned about myself for a long time, having come from a background in game development. There are two problems I think need to be solved:  

The first is that it is rarely a smooth process from the artist creating some asset to getting it running in a game. In order to render things efficiently there are necessary technical requirements to follow, and  the artwork must have certain characteristics. Generally these will manifest as a bunch of arcane rules the artist must follow, restrictions on packages that can be used, and possibly some combination of plug-ins - or more likely exporters and command-line utilities - before the art is ready to use. This is not only painful for the artist, but can also waste the time of the programmer when things are not followed to the letter (and building and maintaining it all in the first place).  This will generally end up adding to the cost to a project, through the inherent inefficiency.  Plus, the art will almost certainly suffer as a result, because without freedom to create an artists output will be compromised.

The second problem is the one you mention, which is that as we launch into this new generation of games, we are seeing a sharp increase in the amount of art actually required. When we hear talk of team sizes increasing by a factor of five or more, we are not talking about programmers (though we will see bigger teams), but rather the people providing the content. This is only just now becoming a problem in the mainstream, though it's been gradually happening for years.  

When I started programming games, I wrote all the code and drew all the art myself! Worse yet is that this problem is not going to go away; with each generation of console hardware (or the more gradual increase in the PC space) it will continue to grow exponentially. Even the largest companies will eventually struggle to simply increase the number of artists on a project.

So with that in mind, we definitely set out to try to find solutions when designing PSSG. I can't say that we've solved them - I think that would count as a minor miracle - but we're certainly putting a lot of effort into easing the problem. One thing I've had in mind is that PSSG, while useful to a larger developer, is more likely to be adopted by smaller developers who need a solid middleware solution. These developers will be worst hit by the art creation problems, and we'd like to help them. To that end, we're trying a number of approaches.  

Firstly, we've tried to address collecting and processing art assets by coming up with an accessible environment where the programmer can specify technical constraints without burdening the artists. This takes the form of an application capable of viewing and manipulating art assets, and more importantly, doing so in a workspace type of environment using scripts. This is a familiar concept to a programmer - it's just like building a workspace in a programming IDE - except that instead of source code and makefiles, you have art assets and scripts. The programmer prepares this workspace for the project they are working on, and the artists can have a lot more freedom to produce the art. Both sides of the project team are then working together, but in the way that suits them; the programmer writing code, the artist creating art.  

We're also building on the work started elsewhere in SCE R&D by making use of ColladaTM to allow us to utilize assets created in most major packages through PSSG.  In fact right now our team artist is building art in Maya (including applying and adjusting Cg shaders), and with a single click she can send the entire scene across to a PS3 debug unit to view on the PS3 hardware itself. That builds on many components of PSSG, but the result is a very free flowing process for the artist that allows good co-operation with the programmers.

The other thing we're doing is looking at procedural content. I personally feel this is the one of the most potent alternatives to hand-built art, but one that is still in its relative infancy. With Cell we have a lot of power available to create procedural data at runtime, and this slots neatly into PSSG, so we're already dabbling in this area.  In the future I hope we'll see a lot more artist-friendly procedural tools, and combine that with realtime generation to produce increasingly dynamic scenes. With procedural content, as the hardware advances and the amount of content required increases, the processing power that can be devoted to both offline and online production of procedural content also increases... so this is a very scalable solution. The only question is the quality of the result, which is why it needs a lot of research, as well as determining how to bring artists into the process.  

http://psinext.e-mpire.com/index ... 712a227326d6f25b8a2

E文的…………

没翻译什么来着

certainly with PSSG we've taken steps to put SPEs directly into the graphics pipeline

LZ不厚道啊~

LZ转的是PSINext网站对Jason Doig关于PSSG的一篇采访。
Jason Doig是SCEI R&D(research and development) London Office的一个Manager，准确说就是SCE研究发展伦敦分部的一名主管，从访谈内容来看，这个人属于偏向技术方面的主管。

内容主要就是介绍PSSG，什么是PSSG呢？Jason并没有给出非常准确的解释，基本上可以理解为："PlayStation Scene-Graph"。是一种graphics-centric aspect of the SDK tools，翻译过来就是“画面方面的开发工具”。这个工具的目的主要就是让开发人员能够更好的利用PS3的硬件资源来来开发出更好画面的游戏。剩下的内容就是PSSG各个方面的介绍。我还没有仔细看完，不过LZ转过来的意思主要是因为Jason提到了certainly with PSSG we've taken steps to put SPEs directly into the graphics pipeline.和and we will see greater usage of the SPEs as an extension of the graphics pipeline in the future.通俗讲就是SPE加入到图像处理中来，分担GPU的工作Using SPEs as a front end to the GPU把SPE作为GPU的前端来处理。

所以YY SPE无所作为的软饭没可以洗洗睡了。如何灵活运用SPE将会成为PS3游戏开发的关键。

期待性能大爆发。

噢~~~原来如此

期待ff13的白引擎表现，相信ps3的机能，相信se的实力！

以后这种满篇鸟语的新闻就不要转了，要转就请翻译，你这不翻译直接贴出来没几个人会有那么大的耐心看的。这不浪费网络资源么。。

我记得以前有版规说过，外语的新闻，请带翻译，无翻译的，直接删。

大段的E文,没看就晕

这个么，楼主的意思大概是想要提升tgfc的形象问题……再说了，英语好好学也是应该的

好像有版规的，不翻自删吧

太多了，即使是中文