Projecting the future
Author
OBS: Mainly speculation, opinions, and doubts. More a rant asking for feedback and criticism.
Hello,
I would like to call some opinions about some thoughts I had lately. Since I started hobby programming, I have always had an ambition to grow, exceed expectations. Okay, maybe it was just some child thoughts about getting to new ground thoughts, but now that those days are (mostly) over, I have been thinking about what am I going to do. My aim is something in ten years (that's why not all of my ambition has gone ;-) ) so I have been brainstorming for the path to go to follow time (read, keep up when the future is here). Some posts earlier (or some years earlier) I posted a threas asking if ray tracing was the future. After some debate the most obvious answer was probably yes (some said definitly, others said eventully rasterization could fake everything out and as time passes we've seen that the shader revolution has made rasterization more flexible but it is still rasterization...). The most used and believable argument was ray tracing's speed that was less dependant on the number of objects on the scene, different from rasterization. So on the last year I've done some raytracing research and I think it does have some potential.
From there my focus has changed to what is the future to what will take me to the future. I have studied some approaches like realstorm's agressive optimizations and general purpose computing in GPUs and this is where doubts start to appear. I really liked optimizating code in assembly level, but in the end of the day all I saw was the same, OOO execution, highly pipelined, high speed single thread optimized processors. It is definatly not the processor for ray tracing nor graphics applications. In the following years there will be a rise in a multi-core processors. We all know that. AMD and Intel have already released dual-core processors. That is definatly good, but on the other side, IBM, Sony and Toshiba also recently launched Cell BE which is the new FPU-intensive throughput (ray tracing friendly) processor. Also there is some sepculation about Cell "dominating" PCs, which I doubt but it shows there is an alternative future for processors. The throughput computer of the future. Will this be the game machine in the next 10 years? (I'm not talking about PS3, please understand I am referring to games the average Joe with a computer he uses for workstation and also plays games on). So I don't know if I should stay with x86 (or x86-64) and follow the multicore growth or go to the future with DSPs and Cell-like architectures. This is if I would choose the path of optimizations, which would lead to more efficient game engines and with a performance that the processor would easly catch up.
The second path is to go with something that is more safe and that follows the game industry. This is about the average Joe's GPU card and (if it works out) PPU card. My problem with this is that while there already is General Purpose Computing on this side of technology it is still a private, closed industry. I mean, crap, shaders are just abstract code that the GPU translates to some other like assembly like system dependant instructions. And who has access to those instructions? How could I study the architecture of a GPU without nVidia or ATi releasing any serious data-sheets. PLEASE correct me if I'm wrong but there is no datasheets for anyone outside the manufacturer's partners.
The third path is the risky one. I could program for reconfigurable computers which could be the future of co-processors or something like ClearSpeed's 97 FPU coprocessor. Or I could even go to the next step of programming and DESIGN a game engine for an FPGA. Some people speculate eventually reconfigurable computers will be somewhere in the future. I have to imagine that it has some solid arguments. One example is: Why a CPU, a GPU and a PPU on one SINGLE machine when you could hava a chip that reconfigures itself depending on what you are running. That way each game could configure it's own GPU, PPU, AI-PU, etc. Forget optimizations... Go the reconf way :-)
The future seems wild. I seem crazy. This crazy post speculating the future and seeking a path to it is just to open minds about how wierd the information world is and how uncertain the future of programming seems... Or just to entertain as another Sci-Fi "see the future" short story... Anyway, the last path is the safe one. Code everything in Java or C# aiming for coding efficiency, safety, short coding time, fast "results" and clean code hoping in 10 years the Java VM or C# compiler does it's job well and handles the code in realtime.
Well. That's it. Sorry about the long post. I hope I could call some minds and opinions about this. Call me stupid or crazy but I thought it would be fun to join my game of "lets see the future". If you made it this far I can't thank you enough :-). Consider this my .02 cents (sorry if I am using this expression incorrectly) and please post feedback :D,
JVFF
PS. Pleeze xkuse bad English. ;-)
Quote:Original post by jvff
The second path is to go with something that is more safe and that follows the game industry. This is about the average Joe's GPU card and (if it works out) PPU card. My problem with this is that while there already is General Purpose Computing on this side of technology it is still a private, closed industry.
If you have any interest in finding employment in the present, this is probably the path to follow. [wink]
"That way each game could configure it's own GPU, PPU, AI-PU, etc"
We already have that in the form of the generic General Purpose CPU.
Unfortunatley see the difference between graphics speed run on a CPU versus even a lame (specialized) GPU to see the difference. Reconfigurable logic on the scale to build one of todays GPU/CPU/PPU/WPU (a whatever processing unit) is decades away.
Possibly sooner they will have architectures that allow the user to build up a machine to meet their needs by adding specialized processors much like we add SIMMs (hmm, how long before a current high end GPU would fit on a SIMM sized daughter board without requiring liquid nitrogen cooling ??)
Either way programming will have to be done in a multiprocessor orientation. I dont think that hardware will be able to automaticly do all the data protection interlocks so it will still be the job for the programmer.
Author
Neh. Forget employment. At least for the next 10 years. Just hobby. Or as I like to think about it. Just indie planning and thinking :D
Author
Quote:Original post by Anonymous Poster
"That way each game could configure it's own GPU, PPU, AI-PU, etc"
We already have that in the form of the generic General Purpose CPU.
Unfortunatley see the difference between graphics speed run on a CPU versus even a lame (specialized) GPU to see the difference. Reconfigurable logic on the scale to build one of todays GPU/CPU/PPU/WPU (a whatever processing unit) is decades away.
Possibly sooner they will have architectures that allow the user to build up a machine to meet their needs by adding specialized processors much like we add SIMMs (hmm, how long before a current high end GPU would fit on a SIMM sized daughter board without requiring liquid nitrogen cooling ??)
Either way programming will have to be done in a multiprocessor orientation. I dont think that hardware will be able to automaticly do all the data protection interlocks so it will still be the job for the programmer.
Agreed. But remember that this is speculating the future so we have to do some wild guesses and, well, dream a little. I have been hobby researching reconfigurable computers on the past weeks (even designed one to one day put on an fpga) and they really do offer future. Reconfigurable logic isn't a physical chip that has it's own TSMC built in so it can rebuild itself. It is more a virtual processor layer. There are many types of reconf. chips. One of them is a mesh-like architechure of ALUs (can't remember website) so each ALU processes 8bits and routes to a near ALU so you code the path of the data. Another type is multiple mini-cores in a chip. It's just a multi-core processor with the exception you context switch the data and instructions between the mini-cores to reconfigure and route everything. And, the most used type is the FPGA. The downsides are the configuration time (ie. in most FPGAs you have to erase the entire chip and it takes severall ms to reconfigure it) and the area size. The LUTs and CLBs occupy a big array to process a single-bit (fine-grained) and is a waste of space for operation on multi-bit data (mainly because FPGA's aren't designed to be reconfigurable computers but to implement real chips vitually). There are lots of research on the area. Including some comercial examples from Cray, Xilinx (in the form of FPGA's with built-in hardware cores for controlling the FPGA), some other companies and some universities. Anyway, it just might be the future of coprocessors (as it was processed in 1960s) or just prototypes for chips :) . Thank you for your answers,
JVFF
I think the last path is the most promising. Hone your skills at creating a framework that allows rapid prototyping and development of games.
Sure, there's all kinds of neat technologies that come into existence over the years, but look at games. What has really changed over the years? Not much. If you look at all of the games over the different years, there's a handful of genres with the same old gameplay every time. What usually changes over time is that the graphics get flashier, "fancy" gimmicks like ragdoll get thrown in, and so on. But the games are about the same. Sadly, I've felt like a lot of the actual gameplay has declined over the years as more focus is put into the flashy graphics than how the game actually plays.
My prediction is that at some point in the future people will realize that you don't NEED to squeeze out every last drop of performace on a system to make a great game. Think about it. If you have a game that draws 2 million triangles per frame and another game that draws 1.6 million triangles per frame, do you think anyone will actually notice? Probably not. And more importantly, the people who strive the hardest to eek out that extra performance usually end up putting awkward restrictions on their art and design staff.
Sure, you can always use more processing power. You can start to model true 3D volumetric effects, fluids, and all kinds of stuff that aren't easily done today. But at the end of the day, you're making a game. It should be fun. So, I'd focus my efforts on creating a framework that makes it easy to create and iterate through design changes on your game. To me, that is what will make or break games in the future.
-John
Sure, there's all kinds of neat technologies that come into existence over the years, but look at games. What has really changed over the years? Not much. If you look at all of the games over the different years, there's a handful of genres with the same old gameplay every time. What usually changes over time is that the graphics get flashier, "fancy" gimmicks like ragdoll get thrown in, and so on. But the games are about the same. Sadly, I've felt like a lot of the actual gameplay has declined over the years as more focus is put into the flashy graphics than how the game actually plays.
My prediction is that at some point in the future people will realize that you don't NEED to squeeze out every last drop of performace on a system to make a great game. Think about it. If you have a game that draws 2 million triangles per frame and another game that draws 1.6 million triangles per frame, do you think anyone will actually notice? Probably not. And more importantly, the people who strive the hardest to eek out that extra performance usually end up putting awkward restrictions on their art and design staff.
Sure, you can always use more processing power. You can start to model true 3D volumetric effects, fluids, and all kinds of stuff that aren't easily done today. But at the end of the day, you're making a game. It should be fun. So, I'd focus my efforts on creating a framework that makes it easy to create and iterate through design changes on your game. To me, that is what will make or break games in the future.
-John
Ive been looking at programmable logic arrays for 25+ years.
Even with high level functional blocks to help, a complex web of logic interlinks between blocks are still required for something as complex as a GPU pipeline.
Try mapping out what is required even for a single GPU pipeline if your building blocks are only 8 bit ALUs. Suddenly you find the blocks are better if they are 32+ bit for floating point operations and and for this 'configurability' trait you suddenly find that significant sets of your various blocks are unused or too much of the chip is taken up by mostly unused communications buss channels.
Once you start going to these large blocks it becomes more and more like a network of general purpose CPUs (soon you add local memory to the register stores and then you share data channels to increase the utilization/versatility).
Multi core except now there might be hundreds of them. Intel already has plans for 16 cores on one CPU (maybe multiple sub dies to increase yield) in the near future
Quote:Original post by Teknofreek
I think the last path is the most promising. Hone your skills at creating a framework that allows rapid prototyping and development of games.
Sure, there's all kinds of neat technologies that come into existence over the years, but look at games. What has really changed over the years? Not much. If you look at all of the games over the different years, there's a handful of genres with the same old gameplay every time. What usually changes over time is that the graphics get flashier, "fancy" gimmicks like ragdoll get thrown in, and so on. But the games are about the same. Sadly, I've felt like a lot of the actual gameplay has declined over the years as more focus is put into the flashy graphics than how the game actually plays.
My prediction is that at some point in the future people will realize that you don't NEED to squeeze out every last drop of performace on a system to make a great game. Think about it. If you have a game that draws 2 million triangles per frame and another game that draws 1.6 million triangles per frame, do you think anyone will actually notice? Probably not. And more importantly, the people who strive the hardest to eek out that extra performance usually end up putting awkward restrictions on their art and design staff.
Sure, you can always use more processing power. You can start to model true 3D volumetric effects, fluids, and all kinds of stuff that aren't easily done today. But at the end of the day, you're making a game. It should be fun. So, I'd focus my efforts on creating a framework that makes it easy to create and iterate through design changes on your game. To me, that is what will make or break games in the future.
-John
The flashyness may be reaching the point of decreasing returns, but look into whats (hopefully) the next aspect that may bring major game improvements -- AI.
AI can/will use huge amounts of memory and even more CPU resources, which will make whats used for graphics now look like a drop in the bucket. Even general physics for the terrain is a magnitude more CPU than whats currently available.
Most games these days are pretty looking, but are deserts. Very little interaction or 'smart' objects are present. NPCs are lifeless mannekins and monsters might as well run on little tracks.
We will need vast improvements in CPU power for quite a while yet.
Author
Yeah. The last path is not only safe but flexible. If you think about it, architectures have come and gone, assembly language has changed a lot, and x86 gained a lot of extensions, but in the end C rules programming. Since it's origin in Unix until today, C and it's derivatives still prevails in most programs and frameworks. So if your coding Sun's UltraSparc T1, or IBM's Cell BE or just good old x86, you can use the same C code.
About the reconfigurable computers, indeed they are no substitute for ASIC design, but I am impressed but the opportunity it offers to the end user. In some years die shrinks will not sustain the transistor growth necessary for the current path consumer electronics is taking to put everything on one big multifunctional chip. Cell phones soon will be what notebooks are today. So I think it's more worth it to have "virtual chips" that are hot-swappable that allows easier management of the chips resources. I aggree that the 8bit ALU example is true, you just can't make a reliable GPU with it. The point isn't to make reconfigurable machines giant multi-core MIMD machines but something that allows it to be something at one time and another thing at another time. The difference from normal General Purpose Processors is that you can arrange the way instruction flow changes data flow. Some things can run at low speed while it can spawn multiple threads to do the same thing (parallel) others just need a single fast thread (pipelined).
This is getting interesting. Meeting people, gaining knowledge :D. Thanks everyone,
JVFF
About the reconfigurable computers, indeed they are no substitute for ASIC design, but I am impressed but the opportunity it offers to the end user. In some years die shrinks will not sustain the transistor growth necessary for the current path consumer electronics is taking to put everything on one big multifunctional chip. Cell phones soon will be what notebooks are today. So I think it's more worth it to have "virtual chips" that are hot-swappable that allows easier management of the chips resources. I aggree that the 8bit ALU example is true, you just can't make a reliable GPU with it. The point isn't to make reconfigurable machines giant multi-core MIMD machines but something that allows it to be something at one time and another thing at another time. The difference from normal General Purpose Processors is that you can arrange the way instruction flow changes data flow. Some things can run at low speed while it can spawn multiple threads to do the same thing (parallel) others just need a single fast thread (pipelined).
This is getting interesting. Meeting people, gaining knowledge :D. Thanks everyone,
JVFF
Cell's design is the future. I think one important point rarely mentioned is that in real-life algorithms, memory access is almost always the bottleneck. I think many programmers have this mental model of a computer where you can just access any piece of memory, and it's ready in one cycle. This is just wildly false, and becoming more and more false.
Here's an example about how pointless more CPU power is. In most PS2 games, normal game routines run at about 20-25% CPU efficiency, meaning they spend 75-80% of cycles stalling mainly on memory access, either I-cache or D-cache misses. PS2 has a 300Mhz proc and about a 40 cycle cache-miss penalty. PS3 has a 3.2Ghz proc (10x faster) and around a 450 cycle cache-miss penalty (10x worse), so the actual time penalty is the same. Given that the memory penalty hasn't changed, the routine should expect only a 25% increase speed with a 1000% increase in CPU power! And the caches are still 32k each, and the presence of an L2 will give a slight improvement, maybe another 10%, but still not much considering the extra clock speed.
BUT, that just applies to PCs and the PPU. The really beautiful thing about Cell is in the SPUs and the EIB. First memory bandwidth is 25.6 GB/s, which is really unheard of... way, way faster than PCs. So, even though latency is 100's of cycles, there is still enough bus to feed each SPU at about 1 byte per cycle. Second, each SPU has 256kb of super-fast memory. So, in total, there is about 1.8 Megs of L1-speed memory! Additionally, each one has 128 128-bit registers, giving the machine 16 kb total of registers! Incredible.
Bottom line is that Cell actually provides the memory bandwidth needed to approach its theoretical processing limits in real-life problems, so there are all kinds of new possibilities now. The old rule was that you make geometry and textures static so they only need to be uploaded to the GPU once. But now you will see all kinds of dynamic interactions in game elements. Shaders have carried the gfx torch for the past 4 years, but in the end it's all just eye-candy since none of those calculations can be retrieved efficiently and used by game logic. Now there is a huge amount of processing power that CAN be used by game logic, and that is super cool.
Now we just need some really good programmers!
Here's an example about how pointless more CPU power is. In most PS2 games, normal game routines run at about 20-25% CPU efficiency, meaning they spend 75-80% of cycles stalling mainly on memory access, either I-cache or D-cache misses. PS2 has a 300Mhz proc and about a 40 cycle cache-miss penalty. PS3 has a 3.2Ghz proc (10x faster) and around a 450 cycle cache-miss penalty (10x worse), so the actual time penalty is the same. Given that the memory penalty hasn't changed, the routine should expect only a 25% increase speed with a 1000% increase in CPU power! And the caches are still 32k each, and the presence of an L2 will give a slight improvement, maybe another 10%, but still not much considering the extra clock speed.
BUT, that just applies to PCs and the PPU. The really beautiful thing about Cell is in the SPUs and the EIB. First memory bandwidth is 25.6 GB/s, which is really unheard of... way, way faster than PCs. So, even though latency is 100's of cycles, there is still enough bus to feed each SPU at about 1 byte per cycle. Second, each SPU has 256kb of super-fast memory. So, in total, there is about 1.8 Megs of L1-speed memory! Additionally, each one has 128 128-bit registers, giving the machine 16 kb total of registers! Incredible.
Bottom line is that Cell actually provides the memory bandwidth needed to approach its theoretical processing limits in real-life problems, so there are all kinds of new possibilities now. The old rule was that you make geometry and textures static so they only need to be uploaded to the GPU once. But now you will see all kinds of dynamic interactions in game elements. Shaders have carried the gfx torch for the past 4 years, but in the end it's all just eye-candy since none of those calculations can be retrieved efficiently and used by game logic. Now there is a huge amount of processing power that CAN be used by game logic, and that is super cool.
Now we just need some really good programmers!
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
