Ps3 To Go Easy On Developers

[Ironlungz]

Check it....

PlayStation 3 chip goes easy on developers
By David Becker
http://news.com.com/PlayStation+3+chip+goes+easy+on+developers/2100-1043_3-5476933.html

Story last modified Fri Dec 03 15:26:00 PST 2004
SAN FRANCISCO--The "Cell" processor that will power the next version of the PlayStation game console will also be adaptable for advanced scientific research, but you won't have to be a rocket scientist to program it.
That is the pledge of one of the chief architects of the Cell, jointly developed by IBM, Sony and Toshiba, who on Friday sought to allay fears that the chip would create huge programming challenges for game developers just starting to learn their way around the complex circuitry that powers the current PlayStation 2.
"We're very much aware of the need to balance between innovation in architecture and the ability to leverage that innovation," H. Peter Hofstee, a researcher in IBM's Systems and Technology division, said during a break at an IBM press event here. "The learning curve for this platform should be significantly better than previous ones."
The three companies announced their Cell plans three years ago, describing an advanced processor tailored for demanding multimedia tasks. The companies said earlier this week that they plan to begin test production of Cell chips early next year, with the first Cell-based products--workstation PCs for computer graphics production--set to arrive late in the year.
Sony and Toshiba both plan to start selling high-definition TV sets powered by the chip in 2006, which is also when Sony is expected to introduce the Cell-powered PlayStation 3.
Hofstee said the Cell will benefit game developers not only by giving them a stable and easily approachable foundation for games to run on, but by powering the workstations they use to produce games. The upshot is that developers should be spending a lot less time waiting for their equipment to render the animation they create.
"We think it's going to be a much more seamless and speedy process for developers using these workstations," he said.

Besides workstations, game machines and TV sets, Cell is also likely to power certain types of scientific supercomputers, streaming media servers and image analysis systems, all of which have continually expanding needs for processing power. Hofstee said Cell taps into an emerging "convergence between what we think of as supercomputing and what we use in the entertainment space."
Beyond that, the sky's the limit, according to Hofstee, who said the Cell development team set out to create a flexible design that would dramatically increase processing power while skirting growing chipmaker concerns about power consumption.
"We've created something that is very flexible," he said. "Having a more generic architecture will allow people to do new things."

[PeanutButterMunky]

This is very, very, very, very, very, very, very, very, good news =) i guess they decided to stay away from the crappy and hard to program for PS2 curse =)

[axia777]

This news, combined with the graphics that EA has released makes me drool like a baby! A YAH MAN! Bring on PS3, cause it is gonna kick some major ass! :D

[JoshD]

Sony announced a while ago that they would make all future gaming consoles easier to program for. Not surprising after the crap they got from the PS2 programming situation.

[Domination]

Check it....

PlayStation 3 chip goes easy on developers
By David Becker
http://news.com.com/PlayStation+3+chip+goes+easy+on+developers/2100-1043_3-5476933.html

Story last modified Fri Dec 03 15:26:00 PST 2004
SAN FRANCISCO--The "Cell" processor that will power the next version of the PlayStation game console will also be adaptable for advanced scientific research, but you won't have to be a rocket scientist to program it.
That is the pledge of one of the chief architects of the Cell, jointly developed by IBM, Sony and Toshiba, who on Friday sought to allay fears that the chip would create huge programming challenges for game developers just starting to learn their way around the complex circuitry that powers the current PlayStation 2.
"We're very much aware of the need to balance between innovation in architecture and the ability to leverage that innovation," H. Peter Hofstee, a researcher in IBM's Systems and Technology division, said during a break at an IBM press event here. "The learning curve for this platform should be significantly better than previous ones."
The three companies announced their Cell plans three years ago, describing an advanced processor tailored for demanding multimedia tasks. The companies said earlier this week that they plan to begin test production of Cell chips early next year, with the first Cell-based products--workstation PCs for computer graphics production--set to arrive late in the year.
Sony and Toshiba both plan to start selling high-definition TV sets powered by the chip in 2006, which is also when Sony is expected to introduce the Cell-powered PlayStation 3.
Hofstee said the Cell will benefit game developers not only by giving them a stable and easily approachable foundation for games to run on, but by powering the workstations they use to produce games. The upshot is that developers should be spending a lot less time waiting for their equipment to render the animation they create.
"We think it's going to be a much more seamless and speedy process for developers using these workstations," he said.

Besides workstations, game machines and TV sets, Cell is also likely to power certain types of scientific supercomputers, streaming media servers and image analysis systems, all of which have continually expanding needs for processing power. Hofstee said Cell taps into an emerging "convergence between what we think of as supercomputing and what we use in the entertainment space."
Beyond that, the sky's the limit, according to Hofstee, who said the Cell development team set out to create a flexible design that would dramatically increase processing power while skirting growing chipmaker concerns about power consumption.
"We've created something that is very flexible," he said. "Having a more generic architecture will allow people to do new things."

Before I go on, I would just like to say four words: I TOLD YOU SO!

Close to a year ago, I stated that Sony were taking a different approach to making the Cell/PS3 a lot easier to program for far beyond that of the PS2. There was also a small quote on this concerning the GScube not too recent as well inwhich you can find HERE (http://www.wired.com/wired/archive/9.05/gs3_pr.html). Some obviously didn't pay it any attention or take it as serious. But, anyway, this is great news!

[Domination]

Sony announced a while ago that they would make all future gaming consoles easier to program for. Not surprising after the crap they got from the PS2 programming situation.

I most definitely agree. NOW, where the hell are all of those nay sayers? :o

[julps31]

This news, combined with the graphics that EA has released makes me drool like a baby! A YAH MAN! Bring on PS3, cause it is gonna kick some major ass! :D
I'm drooling right along side you man. :lol: I never really doubted that Sony was making sure that the PS3 was much easier to take advantage of than the PS3. This just solidifys it.

[___Deadmeat]

This is quite a misleading statement.

CELL is an improvement over Emotion Engine, which was considered to have the worst programming model in computer architecture's history, in terms of use of high-level language for APU programming, and a homogenous APU architecture(EE's VUs were different from each other).

However, CELL programming model is not easier than the XNA programming model, which has gone through a dozen refinement and is concrete as rock(Developers understand how to code for Xbox Next before they receive their first kit). Furthermore, CELL's filter/shader/whatever_you_call distributed programming model works well for a data set with no minimal interdependency; it works well with geometry/rendering but fails at physics and world database modification with heavy interdependency, which Xbox Next's CPU should accel at.

Lastly, a platform's programming complexity is determined by the available amount of library; Xbox Next carries a decade's worth of accumulated library; CELL is starting from scratch.

So if I had the choice, I would work with the Xbox Next; because this is something every developer already fully understands, unlike CELL which is entirely a different kind of beast.

[___Deadmeat]

Furthermore, performance optimization is much more difficult on CELL than DX9; DX9 presents a unified view of shaders so a programmer does not have to worry about load-balancing of his vertex data; this part is handled by the GPU itself.

CELL, on the other hand, exposes each individual APU to the end programmer, so the responsibility of load-balancing falls upon the end developer, not the hardware. To extract the maximum performance possible from CELL, the developer must ensure that he is feeding all the APUs with data at all times, and monitoring the runtime status of 8 APUs can be tricky. CELL's 8 APUs are more flexible than R520's 8 Vertex Shaders, but more freedom comes at the cost of a greater responsibility.

[Grandia]

Sony announced a while ago that they would make all future gaming consoles easier to program for. Not surprising after the crap they got from the PS2 programming situation.

I most definitely agree. NOW, where the hell are all of those nay sayers? :o
I think all the Sony bashers are speechless. Especially Xbots. I just find it funny how they are going on about how Sony isn't concerned about the devs, and how difficult the PS3 will be to develop for. EAT YOUR WORDS NOW!

(Eh, I'm excited)

Deadmeat, why do you even come here? You've been proven wrong so many times, it's going out of style.

[Rallyracr420]

Deadmeat may know a few things about microchips, but he just proved he doesn't know anything about programming. A properly written API will distribute the proper threads to the corresponding cores by itself, with no intervention of the programmer. In otherwords, if Sony chooses to continue with Colada, the programmers don't need to write to the Colada API and the Cell at a low level. It would be writing the same code twice. Maybe deadmeat likes to write his code twice but no developer does. Wait, what am I saying....if deadmeat ever coded even once in his life he would already know this.

And MS doesn't have 10 years worth of libraries to utilize. If they did, they wouldn't have a reason to start over with XNA...it would be DirectX11.

And a platform's programming complexity isn't determined by the available amount of library. But once again, if you had ever programmed you would already know this. Programming complexity has to do with two things: the quality of the API and the programming language used. For example, PS2's API sucked, which is why devs had to write so much low level code.

[Domination]

This is quite a misleading statement.

Figures. :roll:

I don't think anything could get any simpler for you.

BTW, your screen name seems to be getting a little too long.

[Z]

Furthermore, performance optimization is much more difficult on CELL than DX9; DX9 presents a unified view of shaders so a programmer does not have to worry about load-balancing of his vertex data; this part is handled by the GPU itself.....etc

We do agree that PS3 is easier to develop for. We may also agree that Xenon is potentially easier to develop for than PS3, due to the fact that Xenon is ‘more PC’, which is a relatively better understood environment.
But what about this; if development becomes too easy, doesen’t that mean less creativity? Because more and more tasks will be done automatically by the machine, but if one had to do those things by himself, he may have new ideas and change a few things. Of course this becomes a problem of it is intense. So like everything in life “balance” is a must.
finally, I am not concerned about PS3 Development difficulties. Why? Because look at the crazy support for the PS2. so if the PS3 is easier, then that only means more support. Almost every game developer and publisher wants to make PS2 titles. (yes, not because it is fun, but much more profitable).
Another thing; isn’t OpenGL better than DX, due to the fact that it is ‘open’, thus more preferred?
November has seen: MGS3, Jack3, R&C3, Killzone, ATV3, and many others. Nov.’s line up alone is considered a much better offering than ALL the games in ALL the months of the other consoles.

What do you think?

[___D_eadmeat]

A properly written API will distribute the proper threads to the corresponding cores by itself
You ask for something SCEI never provides...

Beside, CELL really isn't a multithreaded architecture; multithreading means a shared process space but each apulet is a separate process. Multi-processing, yes. Multi-threading, hell no.

with no intervention of the programmer
I understand what you are thinking but that's not what SCEI is planning. From the APU API I have seen from the patent applications, it is upto the programmer to direct the data stream to each APU individually, not API. Clearly, SCEI emphasize more on flexibility and a hand-on performance-tuning than any developer convenience. If you are a wimp, go code for Xbox Next; this is SCEI's mentality.

And MS doesn't have 10 years worth of libraries to utilize. If they did, they wouldn't have a reason to start over with XNA...it would be DirectX11.
XNA is just a new brand name for DirectX. Same stuff in a new bottle. All MS is doing is consolidating DX variants on Xbox, LongHorn, and CE so that you can build three executables from single source(in theory at least). This has a powerful implication since it truely is possible to have a game disc that will run on both Xbox Next and a LongHorn PC.

And a platform's programming complexity isn't determined by the available amount of library.
Surely it is. More library available, the less you code.

For example, PS2's API sucked, which is why devs had to write so much low level code.
SCEI rushed things so PSX2 came with no library, something that CELL looks to repeat. The second problem was the lack of a high-level language for VU; all VU stuff was to be coded in assembly. CELL solves this problem(APU themslves are PowerPCs) but also introduces the load balancing problem; a developer must ensure that all 8 APUs are constantly fed to maximize the resource utilization.

So CELL programming model really isn't much of an improvement over PSX2.

if development becomes too easy, doesen’t that mean less creativity?
MS argues it's the other way since you can save time and money coding the engine and focus on game design..

[Domination]

The four-year project, code-named Cell and set for completion in spring 2005, aims to create a powerful processor for home electronics with ultra-fast Internet connections that could, for example, transmit high-resolution moving pictures.

"It's possible PlayStation 3 would come out in 2005, since that's when Sony's Cell project will yield something,'' said Kazuharu Miura, an analyst at Daiwa Institute of Research.

At this rate, commercial production of Cell could come as soon as the end of 2004.




Let me see, the project started early 2001 not counting what they managed to accomplish with the GScube way before this time. The 65nm architecture is expected to be done around March or April of next year, especially since the latest version (90nm) is in close progress to be shipped later this year in the workstation. Yup, they really rushed the hell out of this thing, didn't they? :roll:

[Rallyracr420]

You ask for something SCEI never provides...

What opportunity have they been given...the PS3 isn't even out yet. There's also no reason Sony can't make the PS3 API into a multithreaded one. Different threads can be handled by different cores, thereby alleviating the programmer's need to interviene.

From the APU API I have seen from the patent applications

Where?

Quote:
And a platform's programming complexity isn't determined by the available amount of library.

Surely it is. More library available, the less you code.

You can have a hundred libraries to draw from and you'll find that many of those libraries duplicate functions of each other. More libraries, especially ones written by Microsoft's award winning coders (yeah right), is only more confusion for programmers. Once again, if you ever wrote any code you'd know this.

A good example of Microsoft's crappy code is a quote from John Carmack, the creator of Doom and Quake. He wrote a small article with sample code on why OpenGL is so much easier and more efficient to write for than DirectX.

Here's a quote from an article covering Carmack's paper:
n June, id's John Carmack and John Romero (creators of DOOM, DOOM II, Quake, and other hit games) were among the leading games developers that signed an open letter to Microsoft begging them to develop OpenGL as a standard Windows 95/NT API for 3D games development. The developers explained that Direct3D, the 3D component of DirectX, was a miserable hack and was very much inferior to OpenGL. Alex St. John agreed with the developers that DirectX was too complex and wanted to create a simpler, OpenGL-like API. He said as much in debates about the topic within Microsoft, but the Redmond, Washington company had other ideas and decided to stick with the current line of DirectX APIs. St. John was fired for his vocal opposition to the decision.

Source: http://www.win2000mag.com/Article/ArticleID/17148/17148.html


Granted, its an old article, but if you've ever programmed in DirectX you'll see it hasn't changed at all the way Microsoft requires the declaration of entire classes to create the same thing OpenGL can do with a few function calls.

SCEI rushed things so PSX2 came with no library, something that CELL looks to repeat. The second problem was the lack of a high-level language for VU; all VU stuff was to be coded in assembly. CELL solves this problem(APU themslves are PowerPCs) but also introduces the load balancing problem; a developer must ensure that all 8 APUs are constantly fed to maximize the resource utilization.

So we now have an API for the PS3 that handles all the shortcomings that Sony fell through on with the PS2. However I still don't see any load balancing problem you mention. By your theory when Sony creates 200 core workstations they'd have to feed each one independently. We can do this already with current technology...why even bother creating the Cell if we haven't made any progress on handling multiprocessor systems? The Cell was designed to talk to other Cells without the devs having to reach in with low level code and do it manually.

[Domination]

I noticed this generation carrying A LOT of sequels. I guessing it is due to developers not wanting to take a chance on something new on the fear of it possibly failing to meet consumers expectations, therefore causing them to lose a ton a money. Maybe and hopfully this will change next-gen.

[Rallyracr420]

EDIT: Delete this post so Omega stops whining about my double posting.

[Rallyracr420]

Here's Carmack's actual article on OpenGL vs DirectX:
source: http://www.azillionmonkeys.com/windoze/OpenGLvsDirect3D.html

I am going to use this installment of my .plan file to get up on a soapbox about an important issue to me: 3D API. I get asked for my opinions about this often enough that it is time I just made a public statement. So here it is, my current position as of december '96...

While the rest of Id works on Quake 2, most of my effort is now focused on developing the next generation of game technology. This new generation of technology will be used by Id and other companies all the way through the year 2000, so there are some very important long term decisions to be made.

There are two viable contenders for low level 3D programming on win32: Direct-3D Immediate Mode, the new, designed for games API, and OpenGL, the workstation graphics API originally developed by SGI. They are both supported by microsoft, but D3D has been evangelized as the one true solution for games.

I have been using OpenGL for about six months now, and I have been very impressed by the design of the API, and especially it's ease of use. A month ago, I ported quake to OpenGL. It was an extremely pleasant experience. It didn't take long, the code was clean and simple, and it gave me a great testbed to rapidly try out new research ideas.

I started porting glquake to Direct-3D IM with the intent of learning the api and doing a fair comparison.

Well, I have learned enough about it. I'm not going to finish the port. I have better things to do with my time.

I am hoping that the vendors shipping second generation cards in the coming year can be convinced to support OpenGL. If this doesn't happen early on and there are capable cards that glquake does not run on, then I apologize, but I am taking a little stand in my little corner of the world with the hope of having some small influence on things that are going to effect us for many years to come.

Direct-3D IM is a horribly broken API. It inflicts great pain and suffering on the programmers using it, without returning any significant advantages. I don't think there is ANY market segment that D3D is apropriate for, OpenGL seems to work just fine for everything from quake to softimage. There is no good technical reason for the existance of D3D.

I'm sure D3D will suck less with each forthcoming version, but this is an oportunity to just bypass dragging the entire development community through the messy evolution of an ill-birthed API.

Best case: Microsoft integrates OpenGL with direct-x (probably calling it Direct-GL or something), ports D3D retained mode on top of GL, and tells everyone to forget they every heard of D3D immediate mode. Programmers have one good api, vendors have one driver to write, and the world is a better place.

To elaborate a bit:

"OpenGL" is either OpenGL 1.1 or OpenGL 1.0 with the common extensions. Raw OpenGL 1.0 has several holes in functionality.

"D3D" is Direct-3D Immediate Mode. D3D retained mode is a seperate issue. Retained mode has very valid reasons for existance. It is a good thing to have an api that lets you just load in model files and fly around without sweating the polygon details. Retained mode is going to be used by at least ten times as many programmers as immediate mode. On the other hand, the world class applications that really step to new levels are going to be done in an immediate mode graphics API. D3D-RM doesn't even really have to be tied to D3D-IM. It could be implemented to emit OpenGL code instead.

I don't particularly care about the software only implementations of either D3D or OpenGL. I haven't done serious research here, but I think D3D has a real edge, because it was originally designed for software rendering and much optimization effort has been focused there. COSMO GL is attempting to compete there, but I feel the effort is misguided. Software rasterizers will still exist to support the lowest common denominator, but soon all game development will be targeted at hardware rasterization, so that's where effort should be focused.

The primary importance of a 3D API to game developers is as an interface to the wide variety of 3D hardware that is emerging. If there was one compatable line of hardware that did what we wanted and covered 90+ percent of the target market, I wouldn't even want a 3D API for production use, I would be writing straight to the metal, just like I allways have with pure software schemes. I would still want a 3D API for research and tool development, but it wouldn't matter if it wasn't a mainstream solution.

Because I am expecting the 3D accelerator market to be fairly fragmented for the forseeable future, I need an API to write to, with individual drivers for each brand of hardware. OpenGL has been maturing in the workstation market for many years now, allways with a hardware focus. We have exisiting proof that it scales just great from a $300 permedia card all the way to a $250,000 loaded infinite reality system.

All of the game oriented PC 3D hardware basically came into existance in the last year. Because of the frantic nature of the PC world, we may be getting stuck with a first guess API and driver model which isn't all that good.

The things that matter with an API are: functionality, performance, driver coverage, and ease of use.

Both APIs cover the important functionality. There shouldn't be any real argument about that. GL supports some additional esoteric features that I am unlikely to use (or are unlikely to be supported by hardware -- same effect). D3D actually has a couple nice features that I would like to see moved to GL (specular blend at each vertex, color key transparancy, and no clipping hints), which brings up the extensions issue. GL can be extended by the driver, but because D3D imposes a layer between the driver and the API, microsoft is the only one that can extend D3D.

My conclusion about performance is that there is not going to be any significant performance difference (< 10%) between properly written OpenGL and D3D drivers for several years at least. There are some arguments that gl will scale better to very high end hardware because it doesn't need to build any intermediate structures, but you could use tiny sub cache sized execute buffers in d3d and acheive reasonably similar results (or build complex hardware just to suit D3D -- ack!). There are also arguments from the other side that the vertex pools in d3d will save work on geometry bound applications, but you can do the same thing with vertex arrays in GL.

Currently, there are more drivers avaialble for D3D than OpenGL on the consumer level boards. I hope we can change this. A serious problem is that there are no D3D conformance tests, and the documentation is very poor, so the existing drivers aren't exactly uniform in their functionality. OpenGL has an established set of conformance tests, so there is no argument about exactly how things are supposed to work. OpenGL offers two levels of drivers that can be written: mini client drivers and installable client drivers. A MCD is a simple, robust exporting of hardware rasterization capabilities. An ICD is basically a full replacement for the API that lets hardware accelerate or extend any piece of GL without any overhead.

The overriding reason why GL is so much better than D3D has to do with ease of use. GL is easy to use and fun to experiment with. D3D is not (ahem). You can make sample GL programs with a single page of code. I think D3D has managed to make the worst possible interface choice at every oportunity. COM. Expandable structs passed to functions. Execute buffers. Some of these choices were made so that the API would be able to gracefully expand in the future, but who cares about having an API that can grow if you have forced it to be painful to use now and forever after? Many things that are a single line of GL code require half a page of D3D code to allocate a structure, set a size, fill something in, call a COM routine, then extract the result.

Ease of use is damn important. If you can program something in half the time, you can ship earlier or explore more aproaches. A clean, readable coding interface also makes it easier to find / prevent bugs.

GL's interface is procedural: You perform operations by calling gl functions to pass vertex data and specify primitives.

glBegin (GL_TRIANGLES);
glVertex (0,0,0);
glVertex (1,1,0);
glVertex (2,0,0);
glEnd ();

D3D's interface is by execute buffers: You build a structure containing vertex data and commands, and pass the entire thing with a single call. On the surface, this apears to be an efficiency improvement for D3D, because it gets rid of a lot of procedure call overhead. In reality, it is a gigantic pain-in-the-ass.

(psuedo code, and incomplete)
v = &buffer.vertexes[0];
v->x = 0; v->y = 0; v->z = 0;
v++;
v->x = 1; v->y = 1; v->z = 0;
v++;
v->x = 2; v->y = 0; v->z = 0;
c = &buffer.commands;
c->operation = DRAW_TRIANGLE;
c->vertexes[0] = 0;
c->vertexes[1] = 1;
c->vertexes[2] = 2;
IssueExecuteBuffer (buffer);

If I included the complete code to actually lock, build, and issue an execute buffer here, you would think I was choosing some pathologically slanted case to make D3D look bad.

You wouldn't actually make an execute buffer with a single triangle in it, or your performance would be dreadfull. The idea is to build up a large batch of commands so that you pass lots of work to D3D with a single procedure call.

A problem with that is that the optimal definition of "large" and "lots" varies depending on what hardware you are using, but instead of leaving that up to the driver, the application programmer has to know what is best for every hardware situation.

You can cover some of the messy work with macros, but that brings its own set of problems. The only way I can see to make D3D generally usable is to create your own procedural interface that buffers commands up into one or more execute buffers and flushes when needed. But why bother, when there is this other nifty procedural API already there...

With OpenGL, you can get something working with simple, straightforward code, then if it is warranted, you can convert to display lists or vertex arrays for max performance (although the difference usually isn't that large). This is the right way of doing things -- like converting your crucial functions to assembly language after doing all your development in C.

With D3D, you have to do everything the painful way from the beginning. Like writing a complete program in assembly language, taking many times longer, missing chances for algorithmic improvements, etc. And then finding out it doesn't even go faster.

I am going to be programming with a 3D API every day for many years to come. I want something that helps me, rather than gets in my way.

John Carmack Id Software

[Omega Blue]

you really do NEED to stop with the double and triple posting, no matter who agrees with you, it will get you banned. Matt has a hard enough time dealing with stinky man ass lovers like Dickmeat, and when people clog of the forum it doesn't make it much easier for Matt.

[Rallyracr420]

relax man...go back and count the number of times i've double posted. its a whopping 2 times (today included).

[cpiasminc]

From the APU API I have seen from the patent applications
Where?

Probably referring to these --
http://makeashorterlink.com/?M1D162038
http://makeashorterlink.com/?V1C121038
http://makeashorterlink.com/?J1B164038
http://makeashorterlink.com/?H2A161038
http://makeashorterlink.com/?T49125038
http://makeashorterlink.com/?Z16122038
http://makeashorterlink.com/?Z44116038

He's a little confused. Yes, you do have to write the code that issues code and data to the individual APUs. However, the programmer does not have to explicitly choose which APU and manage loads and properly distribute according to which ones are in use and which are available. The API itself takes care of that. You simply make requests to the API to "get an APU" and then send your apulets and data to the APU you got. And there's a very good reason why Sony would implement it that way. If you're trying to go through your debugger and step through code, if the API were handling all the scheduling, sync, distribution on its own, you wouldn't inherently be able to track which APU has which code and which data at a given moment. By putting the sync portion in the developer's hands (and in the codebase) and the load balancing portion in the OS, you end up with explicit reference points regarding when code+data is sent to the APUs.

Granted, its an old article, but if you've ever programmed in DirectX you'll see it hasn't changed at all the way Microsoft requires the declaration of entire classes to create the same thing OpenGL can do with a few function calls.
Well, with DX9, they have managed to make it a little more OpenGL-like, but the real annoyance is that the GL-like bindings are exclusive to C# with the intention of never making it available to any non-.NET-exclusive language like C++. A little way to try and sell

There are a few things for which DX is preferable -- in particular, handling of vertex buffers is a much cleaner and straightforward thing in DX8/9 than in GL. But that's primarily because for the longest time, vertex buffers/arrays in GL were available only as an extension, and when they finally got folded in as a native feature, the interface was kept similar rather than trying to rework the interface into a native GL style component. Similarly, there are still a lot of things that are originally extensions, which aren't that clean now in GL, but with DirectX, every feature you have is a native API component. That also makes DirectX inherently hardware-agnostic. For a console, that's not really important, but for a PC, it's kind of a valuable guarantee.

There used to be a lot of argument that DX was faster than OpenGL, but lately, it's been the other way around. OpenGL's API call overhead is much less than DirectX. More importantly, the setup workload for any given task is always going to be less. If I'm going to try and prototype some concept, DirectX is pretty much unacceptable. If I'm going to write some sort of simple user tool, DirectX is still a poor choice. The only exception would be some sort of WYSIWYG preview tool that depends on your existing, already DX-based renderpipe.

Either way, Xbox will have both DX and OpenGL bindings, simply because Microsoft would rouse the ire of many developers without it, and because part of the point with XNA is to make tools widely available, and DX slows down tools development.

[__D_eadmeat]

http://pc.watch.impress.co.jp/docs/2004/1202/kaigai137.htm

Some confirmations of what I claimed.

1. 4.8 Ghz SRAM : The ISSCC presentation in question is titled "26.7 A 4.8GHz Fully Pipelined Embedded SRAM in the Streaming Processor of a CELL Processor". Once again, 4.8 Ghz refers to the SRAM clockspeed and not the core, which runs at 1/4th the rate.

2. APU instruction set : Hiroshige once again confirmed that each APU is a PowerPC processor based on his PSX3 developer sources(Hence it is impossible for APU to run at 4.8 Ghz, but 1.2 Ghz is realistic). He is not sure if APU attains 100% instruction set compatibility yet(His guess is it does), but the IBM source he talked spoke of the possibility that their work on APU will flow back to all POWER architecture.

[__D_eadmeat]

As for John Carmack's comment, you must realize that John is a PSX3 hater who publicly criticized PSX3 architecture as going in the wrong direction. On the other hand, John does work with DX now, so you can guess which platform he would prefer...

[axia777]

This is quite a misleading statement.

CELL is an improvement over Emotion Engine, which was considered to have the worst programming model in computer architecture's history, in terms of use of high-level language for APU programming, and a homogenous APU architecture(EE's VUs were different from each other).

However, CELL programming model is not easier than the XNA programming model, which has gone through a dozen refinement and is concrete as rock(Developers understand how to code for Xbox Next before they receive their first kit). Furthermore, CELL's filter/shader/whatever_you_call distributed programming model works well for a data set with no minimal interdependency; it works well with geometry/rendering but fails at physics and world database modification with heavy interdependency, which Xbox Next's CPU should accel at.

Lastly, a platform's programming complexity is determined by the available amount of library; Xbox Next carries a decade's worth of accumulated library; CELL is starting from scratch.

So if I had the choice, I would work with the Xbox Next; because this is something every developer already fully understands, unlike CELL which is entirely a different kind of beast.

Have you programmed for Cell? Do you know how easy or difficult it is? Has anyone here programmed for Cell? NO, no one has here. How do you know how easy XNA is to programm for? Have you programmed for XNA? So how do you know how easier it is gonna be? You don't "know". All you have is your opinions. Opinions are just that, opinions. All of our posts are opinions, no matter how much experience we may or may not have with programming, the fact remains the same, none of us have used the systems mentioned. So, until you program for both XNA and Collade, stop acting like your opinions are facts, because they are not. You act like you have a corner on the truth, when in fact you do not. None of use here know, otherwise we most likely would not be posting on this board. If you did work for say, Sony or Microsoft and released info in a public forum, you would most likely get sued for breaking non-disclouser agreements.

As for John Carmack's comment, you must realize that John is a PSX3 hater who publicly criticized PSX3 architecture as going in the wrong direction. On the other hand, John does work with DX now, so you can guess which platform he would prefer...

Really, got a link to back up that statement?

[__D_eadmeat]

Really, got a link to back up that statement?

http://www.beyond3d.com/forum/viewtopic.php?t=11095

[axia777]

Really, got a link to back up that statement?

http://www.beyond3d.com/forum/viewtopic.php?t=11095

Seems like he dislikes the idea of multiprocessor consoles, including X-Box:Next, not just PS3. Looks like you cherry picked the info to prove your point, yet again.

[__D_eadmeat]

John Carmack's comment doesn't really cover Xbox Next since

1. Xbox Next has only two cores.
2. Doom3's engine is multithreaded.
3. Doom3 runs on Xbox.
4. You will probably see a Quake remake on Xbox Next.

Having a second processor with thorough multithreading support is not a big deal; but being asked to code for 8 APU is another matter.

[axia777]

John Carmack's comment doesn't really cover Xbox Next since

1. Xbox Next has only two cores.
2. Doom3's engine is multithreaded.
3. Doom3 runs on Xbox.
4. You will probably see a Quake remake on Xbox Next.

Having a second processor with thorough multithreading support is not a big deal; but being asked to code for 8 APU is another matter.

From your own source:

"In a Q&A after the keynote, Carmack stated that he wondered why future game consoles like the PS2 and the Xbox 2 will likely use multi-processors, saying such technology has not worked well for consoles in the past and wondered why this way of working was back in vogue again from console makers. "

Uh, yes it does, unless I am crazy and am imageing that statement above.

BTW, how do you KNOW that X-Box:Next is going to use two processor cores? Uh, you dont know, because Microsoft has not relased the official tech specs for X-Box:Next. It is again your opinion, not fact.

This article seems tho think that it will have three processor cores, but again, it is rumor and hearsay, not facts.

http://www.mercurynews.com/mld/mercurynews/business/7849191.htm?1c

[__D_eadmeat]

BTW, how do you KNOW that X-Box:Next is going to use two processor cores?
The Xenon DK shipped to developers is a dual-processor PowerMac with the latest videocard.

[axia777]

BTW, how do you KNOW that X-Box:Next is going to use two processor cores?
The Xenon DK shipped to developers is a dual-processor PowerMac with the latest videocard.

Again, got a link? :D Preferrably official, not another posting board, please.

[__D_eadmeat]

Again, got a link?
You are behind everyone on this news. You go look it up on google yourself. Might catch a pic of a delivery of a truckload of PowerMacs to Redmond posted somewhere. Also the Xenon OS screen pic if you are lucky.

[__D_eadmeat]

This article seems tho think that it will have three processor cores, but again, it is rumor and hearsay, not facts.
That rumor is based on somebody's joke diagram which I instantly shot down as a fraud. I could find at least 6 flaws in that diagram to conclude it was drawn up some fanboy hoaxter.

[axia777]

I did goggle it. I found NO official info, just a bunch of hearsay and rumor. Which, by the way, those are not facts. Which again proves my original point. That you spout opinions and rumors as they were fact. Which they are not. So until there is an offical release from both Microsoft on X-Box:Next and Sony on PS3, well, opinions and hearsay are all we have to work on. Not facts. Conjectures, you know? Speculations. You get the idea.

This article seems tho think that it will have three processor cores, but again, it is rumor and hearsay, not facts.
That rumor is based on somebody's joke diagram which I instantly shot down as a fraud. I could find at least 6 flaws in that diagram to conclude it was drawn up some fanboy hoaxter.

This again proves my point, hearsay and rumors. Not facts. Not offical. See my point? Even people on this board like cpiasminc, though knowledgeable in the subject of prgramming, do not know the facts. None of use do. Not yet at least. Wait for the GDC and E3 to see the facts.

[Matt]

Continue here please:

http://www.psinext.com/forums/viewtopic.php?t=4486