Physics Processor - AGEIA (Cool Demo)

Calling all grad students. . .waiting for genius can be a bitch.

 

Hehe, since when is DirectX a standard? I think it would be pretty funny if MS decided to start licensing its use one day. But I guess some people think an MS' API is different than a manufacturer's API.

Neat stuff though, I'd definately pick one up if the price was right. This is where real game mechanics innovation is headed imo (physics I mean, not necessarily specialized hardware).

 

I only meant DX is a standard in the sense that it is something IHVs adhere to complying to after giving their input to MS about what it should be.

Something devs can rely upon to be the common denominator across the board with respect to rendering.

I doubt MS would be foolish enough to make anyone directly pay to use it...then again last I heard MS takes 400% profit off it's windows sales so...

No I don't hate MS.

I didn't mean standard in the sense of a level of excellence to be met but rather the level of compliance to the spec.

Also...

I liken this to the recent cross over of graphic techniques into factors in gameplay such as in Splinter Cell, Doom etc.

Physics isn't just fluff now such as in HL2 and most likely many other titles as well.

 

Um, who ever said that the PS3 would be acapable of the level of physics interactions that a PPU could perform? It's not like that's certain, either.

 

Right, a spec controlled by a a player in the marketplace. They have made decisions that benefit one manufacturer over another, and have been partners with them in different context. If MS takes Xbox further and actually starts making graphics parts, or buys somebody that does, is DirectX still a standard? If they start charging for it, is it still a standard? Who's to say AGEIA won't support other company's physics processors down the line.

Basically, I'm just nitpicking.

 

Its not like there aren't any parallel programming languages out there - Linda, Erlang, and Mozart come to mind...

I'm not an expert on any of these languages, but it seems to me that the problem is not lack of innovation in the language field (parallel or otherwise, check out Beta for a really cool OO language), but the fact that there is no widely accepted "parallel" language XXX out there that the vast majority of coders familiar with procedural/OO languages (i.e. myself) can pick up, knowing beforehand that it will be well supported and at least fairly widely adopted in a particular programming field. Adoption of a new language is also daunting because most existing libraries and APIs (DirectX, OpenGL, middleware such as physics SDKs, game engines, in house code) are written in some "old fashioned language", which means you have to do a lot from scratch, or deal with the pain of interfacing between XXX and some other language...

 

Another significant problem from a programming point of view is that many of those languages that are "more advanced" just aren't as efficient as C++. Since performance is the primary reason for going parallel, you'd really have to convince people that the performance is there.

I mean, there are a lot of languages that are really neat from a programming perspective (Smalltalk, for instance), but just don't perform very well due to a number of choices made in the design of such langauges.

That said, though I know many programmers have stated that it is very challenging to write good, parallel code....I'm just wondering why it's really that difficult. I mean, I've done some limited parallel programming. Granted, it's been on trivially-parallelizable code, but I guess I just don't see why developers can't easily avoid some of the problems related in that Anandtech interview, such as two threads each waiting for the other to complete (why not just have one master controller thread that handles all of this?).

 

Here's a couple reasons:
- it's easy to shoot yourself in the foot because (at least in C/C++) safe usage of concurrency primitives is up to the programmer (as opposed to being determined or at least partially checked by the language)
- race conditions and deadlock are problems that can be very hard to track down
- whether/when a problem occurs can depend very much on the OS and the hardware (e.g. can appear/dissappear by changing the underlying number of CPUs)

 

First of all, what are concurrency primitives?

That asked, there are lots of ways to shoot yourself in the foot with C/C++ with just single-threaded programming. This is typically solved by having good programming habits. How is this any different?

How is this a problem if you use a single master controller thread? Besides, there is debugging software available for multithreaded applications.

Makes sense, which would make it harder to detect when there's a problem. But, like with so many things, this would all be made very simple with strict programming practices.

 

Occam with data structures?

 

There are records now (structs) and mobile data types (references, sorta kinda).

 

Thats what they said about 3D graphics before the voodoo turned up innit?

 

Dont forget to remind them to take their handbags back with them when they go

 

http://www.beyond3d.com/forum/viewtopic.php?t=21017&postdays=0&postorder=asc&start=125

 

I did not mean to offend. I was simply making a point.

I wasn't making a decleration of anything I was speaking to what I think would be probable.

Sorry if I came off that way.

 

I'm aware of what you're saying and fair enough. Point taken.

I was only speaking to mass adherence to a spec. If all those other things were true it would suck but in essence DX would be a standard...probably as long as it takes people to switch code to Opengl I doubt MS would be so stupid as to try and create another Creative situation when there are so many players on the field and alternatives to such an initiative.

The government would fix social security, help the poor and elderly, stop world hunger, make peace with all nations and even destroy the factions of democrats and republicans and act as one body to better the world we live in before they would allow MS to enter the HW market. That'll be the day directly.

With respect to Aegia...you're guess is as good as mine. Wider support makes them more appealing to devs but at the same time they would be supporting the competition. Yo no se.

 

Nor WGF 1.0 neither WGF2.0 are next releases of DirectX. WGF is only about graphics, nothing more.
DirextX will be developed henceforward but without DirectDraw and D3D which will be succeeded by WGF.
Physics support can be supported solely by DirectX

 

Chalnoth -

By concurrency primitives I mean things like mutexes ([non]reentrant), read/write mutexes, semaphores, conditions, barriers, monitors - e.g. high level primitives used to control parallel access to resources when doing so would cause program failure.

Race conditions and deadlocks can't be removed just by putting in a control thread - they would occur if worker threads attemp to acquire multiple locks in a different order, or if a situation arises where worker threads exchange lock ownership in way that essentially serializes execution. Again these things can be very sensitive to run-time conditions/data.

I'm not saying these things are insurmountable, but I do think it's fundamentally harder to program multi-threaded code than single threaded code.

 

Okay, you've just replaced some specialized language with a lot more specialized language.

Anyway, here's what I would try to do if I were attempting to write a multi-threaded 3D engine:
1. Process user input serially (afterthought: this might actually just be used as a thread separate from the AI thread, processed in parallel).
2. Process AI: This should be pretty trivial to multithread, actually, as you shouldn't need any AI to know what any other AI will be doing in the upcoming frame: working on the previous frame's data should be just fine. So, simply launching a thread for each AI object shouldn't be a big deal.
3. Process physics: Should probably be done after AI, to then calculate how the AI objects move. Here, since physics objects can interact with one another, I would separate the world into zones, where no object inside one zone interacts with an object in another zone. This shouldn't be too hard to perform, would be a great first-step optimization anyway, and would, in a relatively large game world, result in quite a few independent threads being generated.
4. Send 3D commands: Depending upon how multithreaded OpenGL and/or Direct3D operate, this might actually just be done at the end of each physics thread, with a separate thread making the 3D calls for static world objects. Once all threads sending 3D commands finalize, send the swap buffers and clear buffer commands, then repeat.

Now, under this system, the only shared data will be read-only for the frame, and thus no locks should even be necessary. And as long as the number of threads remains large, as it should, the above should perform quite well in a multiprocessor environment.

 

Chalnoth:

Is there any particular reason you would have seperate threads for each AI entity?

Or do I misunderstand and all of these threads are within the same task or process apart from physic etc.?

Wouldn't that be more efficent and provide enough flexibility?

I'm just trying to understand.

I also wonder if object oriented principles must be given up competely?

Couldn't some struct/class/object/etc with associated functions for interaction be used along with dynamic allocation/de-allocation in place of actual threads for the lower level i.e. physical objects/ai instances. Then on the larger scale use sperate distinct threads for AI, physics, rendering, etc and have all of these threads in the same task or rather engine so to speak. Being in the same task would allow for succificient cross communication when necessary and may help with scheduling things.

I'm assuming you can put seperate threads from the same task on seperate cores which may be out of bounds.

I'm just curious. Don't hurt me