New Gamebryo LightSpeed engine for Wii

Status
Not open for further replies.
This engine is really sophisticated since ince it takes adventage of Wii´s arquitecture

http://64.239.241.166/Products/Gamebryo/Platforms/Wii/

Read with close attention these two parts avaible in the last link:

Gamebryo Leverages the Wii's Unique Architecture
"
Gamebryo for the Wii includes optimizations to the exporter pipeline, input mechanisms and rendering pipeline to ensure that you get the most out of this popular console. Gamebryo also supports the Wii Remote™ controller, and other standard Gamebryo features are mapped to the unique capabilities of this platform.
Cross-Platform Game Development With the Wii

Emergent’s Floodgate™ stream processing engine has been made Wii-aware for cross-platform game development projects: execution is now automatically optimized using the locked cache functionality, which reduces risk when porting multiprocessor code. Projects created with Gamebryo for other platforms can now be easily re-targeted to the Wii.

"

I am sure that you may be wondering what is stream processing?

Well, lets see the definition in wikipedia:.
http://en.wikipedia.org/wiki/Stream_processing
"
Stream processing is a computer programming paradigm, related to SIMD, that allows some applications to more easily exploit a limited form of parallel processing. Such applications can use multiple computational units, such as the floating point units on a GPU, without explicitly managing allocation, synchronization, or communication among those units.

The stream processing paradigm simplifies parallel software and hardware by restricting the parallel computation that can be performed. Given a set of data (a stream), a series of operations (kernel functions) are applied to each element in the stream. Uniform streaming, where one kernel function is applied to all elements in the stream, is typical. Kernel functions are usually pipelined, and local on-chip memory is reused to minimize external memory bandwidth. Since the kernel and stream abstractions expose data dependencies, compiler tools can fully automate and optimize on-chip management tasks. Stream processing hardware can use scoreboarding, for example, to launch DMAs at runtime, when dependencies become known. The elimination of manual DMA management reduces software complexity, and the elimination of hardware caches reduces the amount of die area not dedicated to computational units such as ALUs.
"

This engine also has also integrated Nvidia Physx

ATI and PhysX Co-exist on the Nintendo Wii
http://www.tomshardware.com/news/Wii-Nv ... ,7325.html

Read with attention the following

"
PS3
Yesterday Tom's reported that Nvidia signed a deal with Sony Computer Entertainment Inc that gives PlayStation 3 developers access to the PhysX software development kit (SDK). According to the company, the kit is now available as a free download on the SCEI Developer Network and consists of a full-featured API and "robust" physics engine. But because the console's RSX GPU--based on Nvidia's G70 architecture (think GeForce 7800)--doesn't support PhysX in a hardware (or CUDA) sense, the middleware thus relies on the Cell's Synergistic Processing Units (SPUs) to process the physics rather than dumping the entire load on the Cell's Power Processor Unit (PPU).

Wii
what makes the whole announcement rather curious is just how the Nintendo Wii hardware can even handle physics processing. Of the three major consoles on the market today, the Nintendo Wii is the least powerful in a visual sense, relying more on the interaction provided by the Wii Remote.

Let's look at it this way: the Nintendo Wii relies on the PowerPC-based "Broadway" processor clocking in at 729 MHz and developed using 90 nm SOI CMOS processing. On the graphic side, the visuals are rendered by ATI's Hollywood" GPU, clocking in at 243 MHz and developed using a 90 nm CMOS process; there's a 3 MB embedded GPU texture memory and framebuffer thrown in there as well. As for the console's memory, there's 88 MB total: 64 MB "external" GDDR3 SDRAM and 24 MB "internal" 1T-SRAM integrated into the graphics package.

So how will the Nintendo Wii carry the burden? That question has yet to be answered, however after closer inspection of the Gamebryo LightSpeed announcement released last week (link), reporting that Emergent Game Technologies integrated PhysX into its Gamebryo 2.6 development platform for the Wii, today's announcement should not have come as a surprise. According to a Nvidia rep, PhysX has been a part of game development for some time; the company merely made it official with today's announcement. With the new SDK implimentation, Nvidia can now make changes directly to the middleware without the need for developer involvement.

"


If you want to know more about Nvidia Physx then

http://www.nvidia.in/object/physx_faq_in.html
http://www.bit-tech.net/news/hardware/2009/03/27/nvidia-considers-porting-physx-to-opencl/1

http://en.wikipedia.org/wiki/PhysX

What is PhysX
"
PhysX was originally the product of Ageia, a company based in California, which was founded in 2002. PhysX was originally designed to be a hardware physics solution. Specifically, it was sold on a PCI or PCI-E 1x style card, called a Physics Processing Unit, or PPU. It was designed to offload the physics calculations from the main Central Processing Unit, allowing the CPU to focus on other things, resulting in a higher framerate in video games. Also, since the PPU was dedicated to handling physics calculations, physics based effects became more accurate and often had more physics based objects flying about. The Ageia PPU was a large parallel processor, similar to a Graphics Processing Unit, or GPU."
"

The first Gamebryo engine available for Wii was the version 2.3

Q&A: Emergent's Dan Amerson Opens The Floodgates
January 16, 2008
http://www.emergent.net/en/News/News-Ar ... n-Amerson/

Read this with close attention:
"
What is Floodgate used for?

At its core, Floodgate is a stream-processing engine. Developers provide execution kernels that are just code that runs per element of a stream and specify the inputs and outputs to the kernel. Inputs can be fixed across all elements or can be a stream of elements. These items allow developers to build up tasks that Floodgate will execute asynchronously.

On top of that, developers can link tasks together by specifying outputs from one task as inputs to another task. Floodgate uses that information to schedule tasks allowing complex sets of behavior to emerge. Most importantly, all of this work occurs through a single API allowing developers to target a new platform just by recompiling their kernels and application code.
"

Floodgate stream processing engine?

continuing with the interview...

"
Now that Gamebryo is coming to the Wii, what sacrifices has the technology had to make?

I wouldn't say that we've made any sacrifices with our technology in taking it to Wii. We've always strove for maximum compatibility across platforms with Gamebryo, and our commitment to Wii is no exception.

With Gamebryo 2.3 on Wii we have almost all of the core features from Gamebryo 2.3 that the hardware will support. Obviously, there are some things that just aren't portable to Wii from the other platforms. Then again, I can't run a D3DX Effect on PS3, so I don't consider limitations of the platform a sacrifice.

Is Floodgate's technology applicable to the Wii without a multicore processor?

That's a tricky question to address, because it really depends on how you define "applicable." We have Floodgate running on Wii, and you are right that there are not as many opportunities for performance gains with the technology on Wii, since it's running on a single core.

However, we do our best to keep the overhead of using Floodgate minimal, so that companies can leverage code from their titles across all platforms without experiencing an overly high performance impact on platforms that don't have as many cores. Remember that one of the goals with Floodgate was to reduce the workload on programmers. With that fact in mind, I'd say that it's absolutely applicable.

Can you give a percentage of performance and features that the Wii can handle as compared to the 360 and PS3? Given your technical knowledge of the platform, are any games currently on the market pushing the tech as far as it can go? Can it be pushed further?

Coming up with a percentage is a perilous task, and it's one that I won't engage in these days. Any number that I give will be disputed the moment I say it. It's not just an apples-to-oranges comparison; it's like comparing apples to steaks. They're both food, but the comparison really ends there.

It's well understood that Nintendo chose a different strategy than Microsoft and Sony, and that the Wii is not as powerful from a raw numbers or features standpoint as PS3 and Xbox 360, so arguing over whether the GPU in Wii is 30% or 70% as powerful as the RSX or Xenos is a moot point.

As far as your second question goes, I'm pretty comfortable saying that no one is pushing the platform as far as it can go. Necessity is the mother of all invention, and developers will find ways to get more power out of all of these consoles. I think we saw that pretty clearly with the last round of titles in the previous generation. There really was no comparison between them and the launch titles.

"

So how is Gamebryo Floodgate going to run on wii even though it´s cpu is single core?.

http://developer.nvidia.com/object/nvis ... ebryo.html

CUDA and Gamebryo
http://www.nvidia.com/content/nvision20 ... mebryo.pdf

http://www.gamedev.net/columns/events/g ... sp?id=1759


Emergent's Gamebryo Game Engine to Incorporate NVIDIA PhysX Technology
http://www.iminers.com/render.php?eid=1 ... =pressroom


Wii licences Nvidia Physx
http://www.tomshardware.com/news/Wii-Nv ... ,7325.html
 
Wii
what makes the whole announcement rather curious is just how the Nintendo Wii hardware can even handle physics processing.
You do realise even 16 bit games could handle physics? Physics is a very scalable area. Two spheres colliding is physics and requires negligable processing power. That Wii can handle a fair few boxes colliding (you may want to see what the original XBox could handle without a PPU...) isn't in doubt as Boom Blox demonstrates.

And incidentally, you don't need to quote articles and technologies that most on this board already know about. If someone reading this thread doesn't know what Stream Processing is, for example, most have the nounce to Google it themselves, or failing that, ask in the thread. We'd much rather just hear your interpretations and insights then read lots of other people's who aren't members hear and can't argue their positions.
 
Status
Not open for further replies.
Back
Top