[ps3]PS3的开发工具的一些访谈，'Geometry Shading,' Art Assets

waips3

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

Sony's PSSG Project

Part II

'Geometry Shading,' Art Assets


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 diffi*** to approach relative to the OoOE cores they may otherwise be used to.  Do you have any thoughts on diffi***ies 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 diffi*** 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..

waips3

用CELL的SPE来实现 类似DX10的GS！！！

用于NV的更好的编程。。。。。。。。。。。

该用户已被禁言

向所有为PS3开发游戏的程序员说声：真是难为你们了！！！

psdcgba

翻译一下撒，鸟语看不懂