Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length

 
Advanced search

878048 Posts in 32903 Topics- by 24325 Members - Latest Member: hoplite21

May 21, 2013, 04:11:27 AM
TIGSource ForumsPlayerGamesOuya - New Game Console?
Pages: 1 ... 43 44 [45] 46 47 ... 87
Print
Author Topic: Ouya - New Game Console?  (Read 40909 times)
PompiPompi
Level 10
*****



View Profile WWW
« Reply #660 on: August 20, 2012, 01:40:25 AM »

No one ever suggested that GPU's would ever replace CPU's, what we were talking about was the ever expanding functionality of the GPU's when back in the days they would basically just render textured triangles for you and having a GPU that could do the transform-work on the hardware was a big thing.

Only doing non graphics stuff on the GPU is even harder and even more work than doing graphics.
I am sorry, but what was exactly the point? Graphics are evil? Graphics are not important? Graphics take alot of time?



Logged


Kickstarter? no no no... it's Kicksucker...
Graham.
Level 10
*****



View Profile WWW
« Reply #661 on: August 20, 2012, 02:39:28 AM »

It was if you felt extra fidelity wasn't worth the cost. For example, good aesthetic design may be more important than detail. So you take the extra processing power and scale up your AI, simulate a larger part of the world or whatever.

I'm reading http://web.cs.mun.ca/~banzhaf/papers/CEC_2008.pdf. Genetic programming on the GPU in the Xbox.

Logged

J-Snake
Level 10
*****



View Profile WWW Email
« Reply #662 on: August 20, 2012, 06:09:18 AM »

How many of you actually did GPGPU stuff on the GPU?
How many of you actually learned about GPU architecture?
I took a look at OpenCl and designed a parallel algorithm for a certain geometric problem dealing with determing cut out shapes. The performance-boost was astounding. Instead of waiting 10 seconds for the endresult it was practically instant, no noticeable delay.

Since many of my games won't be heavy on the visual part it would be cool to use free ressources for game-logic. However I wish to have a significant performance gain in TrapThem's physics(I haven't tried it yet):
http://www.youtube.com/watch?v=t2wegZx9raI

In that case I could apply them in large metroid-sized maps.
They are really hard to design perfectly parallel but one major part of them is marking the stones to identify isolated shapes. That part can take advantage of parallel processing well. But there is a twist to it. It is only about checking if-statements. I might check OpenCL or something similar out on that when the time is right.
Logged
Graham.
Level 10
*****



View Profile WWW
« Reply #663 on: August 20, 2012, 08:01:20 AM »

Physics libraries should let you off-load work onto the GPU, within constraints that you set, by default.

I was wondering if I could take something like UDK/Nvidia-PhysX and do that, maybe with some hard work. I have no idea. I've never used it before. I'm just planning to.


edit:

@J Nice on the DKC soundtrack.
Logged

Richard Kain
Level 10
*****



View Profile WWW Email
« Reply #664 on: August 20, 2012, 08:46:17 AM »

Fiddling with technical details in order to squeeze a little bit more performance out of hardware isn't the objective of game design. The benefit of technological advancement is not having to worry about details like that.
Logged
Graham.
Level 10
*****



View Profile WWW
« Reply #665 on: August 20, 2012, 08:57:48 AM »

Oh?

The objective of game design is to make a good game. If you can double physics processing then you can have twice as many actors doing things "at standard" levels of computation. You can make the moves twice as nuanced, adding fidelity to the translation between input and execution by a factor of 2.

HD is double resolution of previous tvs. That started a big thing.

You can make a computer that's 3 years old run a game that's new, if it otherwise couldn't. You can push frame-rate up from 40 to 60. You can double the lights.

On and on...

We design games in such a way so that huge sections of memory, opportunities to read from disk, the processor's time, the processor's idle cores, and the GPU aren't used maximally.

If you can double computation you can off-load network usage into prediction, upgrading the reliability and speed of online play, and the number of players.

We're not talking inches here. As some people were saying, some computations on the GPU can be several magnitudes more efficient than on the CPU.

But it's a worthy discussion to have. Needless optimizations are always a big threat too, tempting the unwary. We must wear helmets, with lights.
Logged

Richard Kain
Level 10
*****



View Profile WWW Email
« Reply #666 on: August 20, 2012, 09:49:53 AM »

The objective of game design is to make a good game. If you can double physics processing then you can have twice as many actors doing things "at standard" levels of computation. You can make the moves twice as nuanced, adding fidelity to the translation between input and execution by a factor of 2.

All of what you say is certainly useful from a technical perspective. But is any of that really the job of a game designer? It seems to me that such optimizations fall under the purview of software engineers and game engine developers. If a game designer is spending most of their time optimizing the back-end, they aren't actually designing games. What they are designing is game engines.

Don't get me wrong, designing solid, quality game engines is a very worthy endeavor, and the industry is much better off for having good engine developers. But it is not the same as game design. Engine development helps to empower designers, and has become a very important aspect of game development. But it cannot be equated with game design.
Logged
PompiPompi
Level 10
*****



View Profile WWW
« Reply #667 on: August 20, 2012, 10:48:31 AM »

If you don't intend to do optimizations, then don't do your own GPGPU stuf. Let someone else or some ready library do it for you.
I don't think we are going to see in the near future a technology which lets you just describe anything you want, and the computer will automatically produce a high performance code for the GPU.
Performance intensive games needs optimizations, as I said, things don't get accelerated magically.
Logged


Kickstarter? no no no... it's Kicksucker...
PompiPompi
Level 10
*****



View Profile WWW
« Reply #668 on: August 20, 2012, 10:51:07 AM »

How many of you actually did GPGPU stuff on the GPU?
How many of you actually learned about GPU architecture?
I took a look at OpenCl and designed a parallel algorithm for a certain geometric problem dealing with determing cut out shapes. The performance-boost was astounding. Instead of waiting 10 seconds for the endresult it was practically instant, no noticeable delay.

Since many of my games won't be heavy on the visual part it would be cool to use free ressources for game-logic. However I wish to have a significant performance gain in TrapThem's physics(I haven't tried it yet):
http://www.youtube.com/watch?v=t2wegZx9raI

In that case I could apply them in large metroid-sized maps.
They are really hard to design perfectly parallel but one major part of them is marking the stones to identify isolated shapes. That part can take advantage of parallel processing well. But there is a twist to it. It is only about checking if-statements. I might check OpenCL or something similar out on that when the time is right.
I think a CPU can deal with this task pretty easily.
You just need to implement something similar to an A*, you can also make it parallel.
Unless you are talking maps that are more than 10000x10000 and needs to be updated every frame.

Edit: this is an example of code that might be really bad for the GPU, no matter how much the GPU becomes "OMG MORE GENERAL PROCESSOR THAT CAN DO EVERYTHING!"
Logged


Kickstarter? no no no... it's Kicksucker...
J-Snake
Level 10
*****



View Profile WWW Email
« Reply #669 on: August 20, 2012, 02:52:22 PM »

Yeah, unfortunately gpus suck at if-statements and are not really general.
They are specialized units, just less specialized than pure fixed-funtion-pipelines.
Logged
Graham.
Level 10
*****



View Profile WWW
« Reply #670 on: August 20, 2012, 08:13:07 PM »

The objective of game design is to make a good game. If you can double physics processing then you can have twice as many actors doing things "at standard" levels of computation. You can make the moves twice as nuanced, adding fidelity to the translation between input and execution by a factor of 2.

All of what you say is certainly useful from a technical perspective. But is any of that really the job of a game designer? It seems to me that such optimizations fall under the purview of software engineers and game engine developers. If a game designer is spending most of their time optimizing the back-end, they aren't actually designing games. What they are designing is game engines.

Don't get me wrong, designing solid, quality game engines is a very worthy endeavor, and the industry is much better off for having good engine developers. But it is not the same as game design. Engine development helps to empower designers, and has become a very important aspect of game development. But it cannot be equated with game design.

I don't see what difference it makes. Games are games. If I can do something that takes 40 hours and makes it a lot better then I'll do it. If I can take a different 40 to make it a little better, why would I do that instead, if I can only pick one?

"Optimizations" sell the idea short, as a word. HL2 has loading times. They are terrible, awful intrusions into the experience. They could have been removed. Bad design, bad tech. No engine can fix that problem, only the coders on the game.

I have a lot of tech experience. I know I can leverage it to compete with fidelity of modern games, then outpace them in other areas. My AIs can be richer. I can have online play that's faster, more complex, with more people. ...

Game design is not just creating rules on a page. It's taking whatever resources you have and leveraging them as best as you can to improve the player's experience. If you have artists, you should use them. If you have tech knowledge, you should use that. Any improvement is an improvement.


edit:

I could, for example, spend a lot of time designing a rich combat system. Easy to learn, forever to master; that kind of thing. That's what I'm doing, because that's one of my strong suits.

I could wait for someone to create a system then copy them. Or I could do the work myself and make the game better. Same thing with tech.

Also, good tech design, as with the HL2 example, the kind you get the most mileage out of, is intricately linked with the design itself. Certain operations run on the GPU better. If you understand that, and what sort of code would work well with it, then try to make a game who's calculations heavily fall in that area, you could do some incredible things. You could make a high-end game run on a mid-range computer, increasing your player base.

The designer's job is to provide experiences to the player, through games. However he does that is totally irrelevant. All there is is the player. If you make decisions that create the best experience for him, you've won. Anytime you don't do that you've made a mistake. That which falls into the purview of designers, and that which doesn't, is game- and team-dependent.

I don't understand where the hate for tech comes from. It's one more piece of the puzzle. It's not like caring about tech marginalizes the other areas of design.

Each to his own, and all that.
« Last Edit: August 20, 2012, 08:42:59 PM by toast_trip » Logged

Danmark
Level 7
**



View Profile
« Reply #671 on: August 20, 2012, 11:35:33 PM »

Programmable shaders are useful for graphics, period.
If you are doing non graphics stuff with programmable shaders you don't know what you are doing.
However, if you want to do non graphics stuff with the GPU, you can with things like OpenCL, CUDA, direct compute and etc.

"Fragment shader" is just a synonym for "fragment program". It doesn't denote that you're literally shading pixels or texels. GPGPU predates specialized GPGPU languages, and the meat of programs written in those languages still runs in shaders. Besides, I doubt OpenCL is used for GPGPU in consumer games, since support from both ATI and NVidia is spotty, whereas HLSL version support is broader & more straightforward.


The CPU will always be better than the GPU on certain tasks, and vice versa.
If I am not mistaken the CPU is a lot faster when it comes to accessing memory(because of the cach), branching and out of order execution.
Some algorithms will NEVER be accelerated on GPUs, and you better do them on the CPU.
Things like iterative algorithms and algorithms that require a lot of random access to memeory. And many others.


True. Already said something to this effect. It's also true that the GPU will take over many tasks traditionally given to the CPU, because it has so much more processing power. Even for graphics, all the hoops that must be jumped through to produce an image on the screen are getting more numerous & sophisticated; GPGPU and graphics are converging. Please read this paper on real-time GI. Generating a sparse voxel octree & tracing cones through it isn't the kind of thing we associate with GPUs, yet the technique would be infeasible on the CPU.

AFAIK progress in CPU design has been based on things like (as you say) caching, out-of-order execution, branch prediction, dispatching more instructions per cycle, that kind of thing. Clock rates haven't advanced in ages. Absent a paradigm shift, throughput is becoming far more important than speed, and CPUs will never have as much throughput as GPUs, despite GPUs not sharing in these particular innovations. Where CPUs will always have GPUs beat (excepting trivial graphics stuff) is in convenience: you can write a serial algorithm that works without too much difficulty.

But you can't say anything interesting by speaking on the level of algorithms, since algorithms are used to perform tasks*. If you benefit from performing the same task using different hardware running a different algorithm, you'll do so. The painful jump to multicore CPUs already required a new suite of algorithms.

Heavy processing of AI, physics, sound, and (obviously) graphics- together comprising the things that games burn serious frame time on- is all amenable to the GPU. As more things drift into the GPU's realm in practice, the GPU will slowly adopt more CPU features. To put this another way, GPU development won't stagnate after the point where they're so powerful we can do whatever we damn well please to produce images with the machines. They'll be doing lots of other things as well.


How many of you actually did GPGPU stuff on the GPU?

Can't say I have. I plan to soon, though it seems tremendously awkward at this point (again, we need better tools & a broader grounding in knowledge). What have you done? How did the performance compare to your CPU implementation?


*there are algorithms your shitbox could run faster than the most powerful supercomputer in the world, a point neither interesting nor pertinent
Logged
Superb Joe
Level 10
*****



View Profile
« Reply #672 on: August 21, 2012, 01:09:06 PM »

why arent there any games about proctology
Logged
J-Snake
Level 10
*****



View Profile WWW Email
« Reply #673 on: August 21, 2012, 03:27:13 PM »

Because you dont make them
Logged
richardjames13
Level 0
**



View Profile Email
« Reply #674 on: August 21, 2012, 03:32:56 PM »

why arent there any games about proctology

Because they are a pain in the butt to program.
Logged
Pages: 1 ... 43 44 [45] 46 47 ... 87
Print
Jump to:  

Theme orange-lt created by panic