Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[MadocComadrin]

It also depends on the buses connecting these various logical units. The last thing you need is to have bottlenecks countering the advantage you get from division of labor.

[alway]

A GPU can be effectively used as a specialized physics hardware unit; the architecture is very amiable to such a purpose. Most high end physics stuff is just a bunch of highly parallel, simple tasks like matrix multiplication.
When it comes to specialized hardware, I can't see a legitimate use for much more than a CPU and GPU setup for anything other than extreme cases. The CPU has its fast sequential operations, the GPU has its OMGWTFBBQ high level overall processing power.

The other thing about dedicated hardware is it requires dedicated hardware, which means larger overall circuitry This tautology reduces the speed at which the computer can run. The speed of light is about 300 million m/s. A 1 megahertz computer goes through 1 million cycles per second, allowing light to travel a maximum distance of 300 meters. A 1 gigahertz computer goes through 1 billion cycles per second, allowing information to travel a maximum distance of 30 centimeters through circuitry. In a typical 3 gigahertz CPU, light can travel through approximately 10 centimeters of wire. As a result of this limitation, dedicated hardware like the GPU must run differently (after all, it takes around 3 CPU cycles just for light travelling in a straight line to move from 1 end of my 12 inch long GPU to the other; actual clock speeds are typically around 500megahertz) and, unless the data being computed is truly massive, a large chunk of time will be spent as overhead.

For example, the notes from this particular CUDA lecture I attended: http://www.cs.rit.edu/~ark/lectures/cuda01/

CPU vs. GPU computation time and total time comparison (msec) -- minimum of three runs
       ----CPU----  ----GPU----
    N  Comp  Total  Comp  Total
 1024    25     32     0    156
 2048    74     88     0    284
 4096   209    224     1    224
 8192   711    748     5    564
16384  2549   2656    22   1752

This was the result of computing the outer product of 2 vectors of length N. Note that while the CPU spends nearly all its time doing computations, the GPU is spending something on the order of 99% of its time merely transferring the data. That is one of the real limitation of dedicated hardware external to the CPU: telling it to do something takes an incredibly long time. If it were doing something much more complex computationally, the time spent computing would make up for the lost time, as demonstrated by the 100:1 computing advantage that particular GPU had over the CPU; but unless such massive computations need to be made, spending the time to transfer data elsewhere is a bit of a waste.

... That said, next quarter myself and some others will be doing an independent study about good practices for programming on the GPU, and good uses we find to put it to, which I will of course report here.

[malloc]

Depends on the demand really.
Remember physics procession units? They where proposed some years back as the new big thing for gamers, but never really became anything big, as there is no real demand for dedicated collision solving hardware.

Also, I think you should be thinking a bit more broad when it comes to dedicated hardware. The reason why GPU's can be used for more than just graphics today, is actually because they are essentially powerful parallel processors, which can be used for a very broad spectrum of different tasks. Since the processing power was already there, they made the architecture capable of supporting more general processing.

[Virex]

Well, now that people have finally been able to produce Majorana fermions, I wouldn't be surprised if quantum coprosessors become common place on some systems (though not necessarily consumer hardware). Other then that, pretty much everything I can think of has already been done.

[Gatleos]

*sigh*
Man, I give up. There is no such thing as a simple 2d physics library. Either I work with a library designed to bounce 400 spinning 12-sided shapes around the inside of a hexagonal bounding box, or I make my own. Looks like I have to go with the latter.

[Max White]

I'm telling you, programmers just hate to make anything simple. They don't want to make it, they don't want to show it, they just don't want anything to do with very simple 2d physics.

I think they take it as a rite of passage thing. They banged their heads on their desks figuring out every step up to the top, there for you should too!

[MorleyDev]

When you've written simple physics in an efficient and reusable manner, you may as well keep going.

It's not "simple 2D physics" but Box2D is pretty much the go to library for 2D physics and is used in countless games especially on the iOS. Newton Game Dynamics is a pretty good looking 3D physics library, and was what Penumbra and Amnesia used (for example).

[Gatleos]

Yeah, Box2D looked like what I was looking for for a long time. But as weird as it sounds, it wasn't precise enough. I'm looking for pixel units, which Box2D explicitly isn't; it's made to model mass, velocity, torque, angular impulse, etc. in a virtual space, and often produces gaps when you try to map it to pixel units (even at a sane ratio).

A simple platformer engine is what I'm making, so not only do I not need rotating and bouncing shapes, they would actually get in the way of the engine. The only thing I need is a system to prevent dynamic AABBs from intersecting each other, and from intersecting terrain made of static AABBs and static triangles (also axis-aligned).

It's in the sweet spot where it's a bitch to program without a reference, but far below the scope of any library out there.

[Levi]

Blarg!  I just wasted an hour and half trying to figure out why my code wasn't working.

Levi's punishment lines:

Spoiler (click to show/hide)

I shall not leave out the () when calling python methods like I can with ruby methods.
I shall not leave out the () when calling python methods like I can with ruby methods.
I shall not leave out the () when calling python methods like I can with ruby methods.
I shall not leave out the () when calling python methods like I can with ruby methods.
I shall not leave out the () when calling python methods like I can with ruby methods.
I shall not leave out the () when calling python methods like I can with ruby methods.
I shall not leave out the () when calling python methods like I can with ruby methods.

[alway]

Yeah, Box2D looked like what I was looking for for a long time. But as weird as it sounds, it wasn't precise enough. I'm looking for pixel units, which Box2D explicitly isn't; it's made to model mass, velocity, torque, angular impulse, etc. in a virtual space, and often produces gaps when you try to map it to pixel units (even at a sane ratio).

A simple platformer engine is what I'm making, so not only do I not need rotating and bouncing shapes, they would actually get in the way of the engine. The only thing I need is a system to prevent dynamic AABBs from intersecting each other, and from intersecting terrain made of static AABBs and static triangles (also axis-aligned).

It's in the sweet spot where it's a bitch to program without a reference, but far below the scope of any library out there.

I just got done 2 days ago with a quarter long project which made heavy use of Box2D. We noticed those gaps, and we highly suspect they are the result of floating point errors and/or a small push back force when objects get too close together. However, you may still be able to use it for some parts of your intentions. It has built in spatial partitioning, meaning fast collision checking, and allows you to perform your own AABB collision checks without requiring you to use their collision response system. But yeah, if you don't need the efficiency of their spatial partitioning, a simple system you whip up yourself would be better if you are going to avoid their collision response system.

[Valid_Dark]

Does anyone here have experience with SDL and OpenGL?
What is the benefit of using OpenGL for 2d graphics instead of SDL?
SDL looks easier for 2d graphics, and I know OpenGL can do 3d, but I'm seeing a lot of projects that are using SDL and OpenGL but using openGL for all the graphics.  And I was just wondering why this is.

[RulerOfNothing]

The main one is that SDL cannot use hardware acceleration for 2D graphics (at least in the latest stable version; I have heard that the version in development can do this).

[Valid_Dark]

And is that really the only difference ?
Because i'm having a hard time finding anything on this topic.

[RulerOfNothing]

Not the only difference, but it is fairly significant, especially if you want to do more than blitting images to the screen. OpenGL also allows you to easily do things like rotating images and drawing geometric primitives (which is possible with plain SDL, but considerably harder and slower).

[Gatleos]

OpenGL has a far greater learning curve than the blitting functions in SDL, and as far as I know it doesn't directly support loading images from files (I rigged up an image loading function for this, if you want it). But once you actually get everything set up (and there's a lot, trust me) you'll never go back to SDL rendering.