Taking your career advice from the usually-hysterical-about-something-or-other slashdot group think is your first mistake, seriously.
Do what you love, work hard at it, try to have some fun along the way. Take a risk or two; the worst case scenario is almost certainly not that bad in the end and you only live once (those expecting reincarnation notwithstanding). That seems what you'd been doing up until the loony bunch here got you worried.
(And disregard anyone who follows up to this saying "I did what I love and it didn't work out so that's a lousy idea". Even that's a better outcome than confused and indecisive working at the grocery store.)
What makes you think that spending lots of time playing video games has anything to do with being a good game developer? Studying more math, for example, would probably be time better spent to that end.
to point out the blindingly obvious, if a single CPU is hampered by memory bandwidth limitations, then all of those CPUs and SPEs operating in parallel just makes the memory bandwidth crunch worse.
Yep. That is exactly the world we live in.
The good news is that if the particular algorithms you're interested in have a favorable ratio of computation to memory access (aka good data reuse), then you are loving the new parallel world and your code is getting faster at the rate that computational capability is increasing (which is greater than Moore's law.)
If your algorithms have a poor ratio of compute to memory (e.g. you process each item of data once and are done with it), then your algorithm will only get faster as memory access gets faster (much much less than Moore's law.)
So the new Cell/GPU/etc world helps the first class of algorithms. The second remains where it is. Fortunately for Sony and Cell/PS3, quite a bit of computer graphics has a nice compute/memory ratio.
Newell was equally harsh, if not more so, on Sony for its design of the PS3 architecture and programming environment. "There are incredibly few programmers who can safely write code in the PlayStation 3 environment. And I totally see why Sony wants people to write code that runs on seven SPEs and a central processing unit, because that code is never going to run well anywhere else," he said.
What he seems to not understand/want to pretend isn't the case is the fact that the architecture of the Cell is a reflection of longstanding trends in computer architecture, not an exotic thing that Sony dreamed up to be troublesome.
In particular, there has been a longstanding disconnect between the growth in the amount of memory bandwidth available to chips versus the amount of computation that can be done on them. Computational capacity is growing much more quickly than memory access. Over enough years, this disconnect makes a big difference! Nowadways, processor architects will tell you that computation is basically free while communication is what is expensive.
Architectures ranging from GPUs to multicore CPUs to Cell take advantage of these trends in various ways, deliving much more computational capacity than standard CPUs. All of these architectures are deeply inherently parallel. There just isn't any other viable way to take advantage of all of this computation.
If Newell (or whoever) doesn't want to program the SPEs on the Cell, he's free to just use the PPC CPU on it. And his game will be much slower than someone who uses it well. But there aren't going to be very many performance gains in the future to be had from single-threaded code running on CPUs. So while Cell is not trivial to program, none of the other choices are any easier. (Note that there are C/C++ compilers for the SPE instruction set, etc, so they're not *that* hard to program.)
(I'd like to hope that Newell actually knows all this and is just posturing in he middle of his Steam pimping and that this doesn't reflect reality in Valve's world!)
Welcome to slashdot, kids, where a post that expresses a perfectly reasonable opinion and is in no way a troll is modded "troll" since it doesn't match with the prevailing groupthink. Oh well.
They have been producing highly sophisticated cores that left a P4 bite the dust in a lot of cases.
I may be wrong, but I'm guessing they don't cost a few hundred dollars each, though, like GPUs do. (The economies of scale that GPU manufacturers see thanks to the fact that they make millions of these things are really quite nice for keeping prices down.)
GPUs like those from nVidia or ATI are still a lot less sophisticated than those DSPs, or hybrid DSP/uCs.
I think I disagree. How familiar are you with the architecture of modern GPUs? For example, you do know that modern GPUs have upwards of 300M transistors (which is roughly 2x as many as modern CPUs), that most of them are devoted to computational units, etc.?
Still, in a few years FPGAs or CPLDs will surely be a so called "bigger threat" to (your favorite CPU company's) domination....;)
I think the FPGA crowd has been predicting that their day will come "real soon now" for quite a long time now.:-)
I'm not sure I buy that it was the problems with the technologies.
As I think about it more, let me make a slightly modified statement versus the one I made above:
VR failed since the practitioners focused on technology, not story.
Things like MMORPGs, MUDs (as noted by another poster), and even first person shooters (the good ones, at least), have a narrative and a plot of sorts behind them. Even better, that narrative is effectively generated by the other people playing the game at the same time, so it's new, different, surprising, etc.
It is that that gets the user's brain engaged and it's that that gets the user to forget about the outside world and become engrossed in the virtual environment.
Stuff like fancy 3D shutter goggles and haptic feedback and yadda dadda doesn't deliver anything to engage the brain. Without that, the user never forgets that they've got some wacky gizmo attached to their head.
With a narrative and an engaged brain, it's easy to not notice so-so graphics, the fact that one is viewing a LCD display of limited resolution, that there's no stereo, etc, etc...
Though the point is flying over the mods heads, the OP has a good point.
Back in 1995-1996, VR was all the big thing, SGI and others were promoting VRML and virtual reality (on teh web!) was supposed to be just around the corner.
At about that some, some game called Quake was getting a lot of attention in the real world. When you compared the experience of playing quake to the experience of "VR", quake was infinitely more engrossing. All the VR stuff then ran at about 5 frames per second, with less detailed scenes than quake was spitting out at 30+ fps. Quake was a successful virtual reality in that it pulled you in and you could forget it was a game (in a sense). None of the VR stuff had anywhere near the same success at making the user forget what was going on.
The gap between the best of what people did with VR and the best of what people did with games was big enough that it became apparent that VR was not relatively successful. VR researchers were too focused on fancy hardware--data gloves, 3D headsets, stuff like that--and not enough focused on the graphics part. (IMHO).
Look at games like Half Life 2 today. Or the MMORPGs that many people are addicted to. The reason people spend so much time with them is that they are successful examples of VR. The academic approach to it just didn't pan out.
Christophe Hery of ILM won an award this year for his work on rendering realistic skin. ILM has won a number of other awards from the Academy for their technical work over the years; see the Oscars web site.
To Christophe Hery, Ken McGaugh and Joe Letteri for their groundbreaking implementations of practical methods for rendering skin and other translucent materials using subsurface scattering techniques.
These groundbreaking techniques were used to create realistic-looking skin on digitally created characters.
Other folks honored for related work are:
To Henrik Wann Jensen, Stephen R. Marschner and Pat Hanrahan for their pioneering research in simulating subsurface scattering of light in translucent materials as presented in their paper "A Practical Model for Subsurface Light Transport."
This mathematical model contributed substantially to the development and implementation of practical techniques for simulating subsurface scattering of light in translucent materials for computer-generated images in motion pictures.
I've looked at a number of Wikis for doing exactly this.
I ended up settling on moin, for the following reasons:
1. It's easy to set up
2. Stores everything in plain text files: no fancy SQL database backend that I don't need for this small/scale stuff, and I trust text files.
3. It supports uploading of files as attachments to pages in the wiki. So if you come to a PDF document you want to save, you can easily dump it into the wiki.
So far, it's been a pretty nice way to organize stuff like this.
/* zlib.h -- interface of the 'zlib' general purpose compression library
version 1.2.1, November 17th, 2003
Copyright (C) 1995-2003 Jean-loup Gailly and Mark Adler
This software is provided 'as-is', without any express or implied
warranty. In no event will the authors be held liable for any damages
arising from the use of this software.
Permission is granted to anyone to use this software for any purpose,
including commercial applications, and to alter it and redistribute it
freely, subject to the following restrictions:
1. The origin of this software must not be misrepresented; you must not
claim that you wrote the original software. If you use this software
in a product, an acknowledgment in the product documentation would be
appreciated but is not required.
2. Altered source versions must be plainly marked as such, and must not be
misrepresented as being the original software.
3. This notice may not be removed or altered from any source distribution.
Jean-loup Gailly jloup@gzip.org
Mark Adler madler@alumni.caltech.edu
Alias has offered this personal learning edition version of Maya for years now; they're just announcing that the latest release of Maya, 5.0, is also available in the PLE form.
Don't get me wrong--it's great that they do this. There's just no real news here.
The PLE version has a few limitations compared to the version you pay for, but they're really amazingly small in the grand scheme of things.
Sure, there are classes completely about the architecture of graphics hardware here and there. The slides for each of these two classes on graphics hardware are excellent.
Re:Why do we need general purpose cpus at all?
on
Future of 3d Graphics
·
· Score: 1
The Geforce FX GPUs absolutely do have 32-bit IEEE floats as first-class citizens in the fragrment units. (The vertex units as well.) They support a 16-bit float variant as well, but they have first-class 32-bit floats if you need them.
Re:The head of Nvidia agrees with the poster
on
Future of 3d Graphics
·
· Score: 5, Informative
OpenGL and Direct3D are the two interfaces that graphics card vendors provide to get at the hardware; there is no lower-level way to get at it. However, these APIs now include ways of describing programs that run on the GPUs directly; you can write programs that run at the per-vertex or per-pixel level with either of those APIs.
These programs can be given to the GPU via specialized low-level assembly language that has been developed to expose the programmability of GPUs. (They are pretty clean, RISC-like instruction sets).
Alternatively, you can use a higher level programming language, like NVIDIA's Cg, or Microsoft's HLSL, to write programs to run on the GPU. These are somewhat C-like languages that then compile down to those GPU assembly instruction sets.
I have the exact same situation--dead hard drive on old 133Mhz machine that I'm using for a firewall. I ended up using the Dachstein distribution--see the home page for the linux firewall project.
It's quite a slick setup--they've built a nice system! It boots off of the CD, loads configuration data from a floppy (basically stored as diffs from the configuration files on the CD), seems to be pretty secure, runs a 2.4 kernel, etc, etc. After it has booted, everything is loaded into RAM and it doesn't access the CD any more.
If that is the case, then there is prior art in the shading language of the RenderMan standard, which was first published in 1988. (RenderMan is a general 3d graphics api that pixar was pushing as a standard many years ago; now their renderer is also known as RenderMan.)
Anyway, in the shading language, surface shaders set an output color and opacity, both as RGB. To generate the final image, these are then blended the obvious way, from the Porter and Duff paper that other people have referenced.
Here is a link to PDF of the spec, and here is a direct link to information about surface shaders.
Now, the amusing thing about all this is that the prior art here is from Pixar, which of course shares the same CEO as Apple...
If you're willing to write a little opengl application that draws your wireframes, etc, there are two nice options that producting high quality postscript output by intercepting the opengl calls and then turning them into appropriate postscript calls.
It would be cool, but it will never happen, for two reasons.
First, there's the issue of studios protecting their intellectual property: have to be sure that those 3D Jar Jar models don't make their way onto the internet, or that images from the films don't leak out early.
More importantly, the amount of data required to describe a frame in these kinds of movies is immense. We're talking gigabytes for a single image. So you're talking about gigabytes of communication and then a few hours of processing. It just doesn't make sense.
There are actually pretty strict rules about what companys can publicly announce in the time period shortly before their IPOs. So this is very much likely not something fishy like that.
But I forgot, Transmeta is evil and anything they do is motivated by that. Just like Rambus. And NVIDIA. Righto.
For the purposes of texture compression, the basic idea behind VQ is that the texture is broken into (e.g.) 4x4 blocks and each of the blocks is analyzed. The algorithm finds n blocks of 4x4 pixels that "best" represent the overall texture. These are stored in a codebook. Then, each 4x4 block of pixels in the original texture is encoded by finding the one of the n codebook blocks that is closest to it in appearence; all those pixels can thus be represented by a single block number.
This is obviously a lossy compression method, since the total number of blocks in the codebook is much less than the number of blocks in the original texture.
There is some interesting trickiness in figuring out what are the best n blocks to store as well as given a region of the image, which codebook block to represent it with.
VQ tends to take a long time to encode--it's a CPU-intensive pre-process. However, decoding is *really* fast (just a table-lookup) and it can have very high compression ratios. For both of these reasons it fits well with graphics hardware.
See "Rendering from Compressed Textures", a paper from SIGGRAPH '96 that talks about VQ for texture compression and introduces some clever things that can be done with mip-mapped VQ textures.
Slashdot Mirror
Taking your career advice from the usually-hysterical-about-something-or-other slashdot group think is your first mistake, seriously.
Do what you love, work hard at it, try to have some fun along the way. Take a risk or two; the worst case scenario is almost certainly not that bad in the end and you only live once (those expecting reincarnation notwithstanding). That seems what you'd been doing up until the loony bunch here got you worried.
(And disregard anyone who follows up to this saying "I did what I love and it didn't work out so that's a lousy idea". Even that's a better outcome than confused and indecisive working at the grocery store.)
-matt
What makes you think that spending lots of time playing video games has anything to do with being a good game developer? Studying more math, for example, would probably be time better spent to that end.
-matt
to point out the blindingly obvious, if a single CPU is hampered by memory bandwidth limitations, then all of those CPUs and SPEs operating in parallel just makes the memory bandwidth crunch worse.
Yep. That is exactly the world we live in.
The good news is that if the particular algorithms you're interested in have a favorable ratio of computation to memory access (aka good data reuse), then you are loving the new parallel world and your code is getting faster at the rate that computational capability is increasing (which is greater than Moore's law.)
If your algorithms have a poor ratio of compute to memory (e.g. you process each item of data once and are done with it), then your algorithm will only get faster as memory access gets faster (much much less than Moore's law.)
So the new Cell/GPU/etc world helps the first class of algorithms. The second remains where it is. Fortunately for Sony and Cell/PS3, quite a bit of computer graphics has a nice compute/memory ratio.
-matt
From TFA:
Newell was equally harsh, if not more so, on Sony for its design of the PS3 architecture and programming environment. "There are incredibly few programmers who can safely write code in the PlayStation 3 environment. And I totally see why Sony wants people to write code that runs on seven SPEs and a central processing unit, because that code is never going to run well anywhere else," he said.
What he seems to not understand/want to pretend isn't the case is the fact that the architecture of the Cell is a reflection of longstanding trends in computer architecture, not an exotic thing that Sony dreamed up to be troublesome.
In particular, there has been a longstanding disconnect between the growth in the amount of memory bandwidth available to chips versus the amount of computation that can be done on them. Computational capacity is growing much more quickly than memory access. Over enough years, this disconnect makes a big difference! Nowadways, processor architects will tell you that computation is basically free while communication is what is expensive.
Architectures ranging from GPUs to multicore CPUs to Cell take advantage of these trends in various ways, deliving much more computational capacity than standard CPUs. All of these architectures are deeply inherently parallel. There just isn't any other viable way to take advantage of all of this computation.
John Owens has a nice chapter in GPU Gems 2 on this topic.
If Newell (or whoever) doesn't want to program the SPEs on the Cell, he's free to just use the PPC CPU on it. And his game will be much slower than someone who uses it well. But there aren't going to be very many performance gains in the future to be had from single-threaded code running on CPUs. So while Cell is not trivial to program, none of the other choices are any easier. (Note that there are C/C++ compilers for the SPE instruction set, etc, so they're not *that* hard to program.)
(I'd like to hope that Newell actually knows all this and is just posturing in he middle of his Steam pimping and that this doesn't reflect reality in Valve's world!)
-matt
Welcome to slashdot, kids, where a post that expresses a perfectly reasonable opinion and is in no way a troll is modded "troll" since it doesn't match with the prevailing groupthink. Oh well.
And that chip can do 50+ GFLOPS of computation and has 256MB of local memory with 20-30GB/s of bandwidth to that local memory??
-matt
They have been producing highly sophisticated cores that left a P4 bite the dust in a lot of cases.
;)
:-)
I may be wrong, but I'm guessing they don't cost a few hundred dollars each, though, like GPUs do. (The economies of scale that GPU manufacturers see thanks to the fact that they make millions of these things are really quite nice for keeping prices down.)
GPUs like those from nVidia or ATI are still a lot less sophisticated than those DSPs, or hybrid DSP/uCs.
I think I disagree. How familiar are you with the architecture of modern GPUs? For example, you do know that modern GPUs have upwards of 300M transistors (which is roughly 2x as many as modern CPUs), that most of them are devoted to computational units, etc.?
Still, in a few years FPGAs or CPLDs will surely be a so called "bigger threat" to (your favorite CPU company's) domination....
I think the FPGA crowd has been predicting that their day will come "real soon now" for quite a long time now.
-matt
NVIDIA's GPUs are only one or two bits short of perfect 32 bit IEEE floats. (ATI's are still at 24 bit floats.)
See Karl Hillesland and Anselmo Lastra's cool work on measuring this error on current GPUs, GPU Floating-Point Paranoia for much more information.
-matt
I'm not sure I buy that it was the problems with the technologies.
As I think about it more, let me make a slightly modified statement versus the one I made above:
VR failed since the practitioners focused on technology, not story.
Things like MMORPGs, MUDs (as noted by another poster), and even first person shooters (the good ones, at least), have a narrative and a plot of sorts behind them. Even better, that narrative is effectively generated by the other people playing the game at the same time, so it's new, different, surprising, etc.
It is that that gets the user's brain engaged and it's that that gets the user to forget about the outside world and become engrossed in the virtual environment.
Stuff like fancy 3D shutter goggles and haptic feedback and yadda dadda doesn't deliver anything to engage the brain. Without that, the user never forgets that they've got some wacky gizmo attached to their head.
With a narrative and an engaged brain, it's easy to not notice so-so graphics, the fact that one is viewing a LCD display of limited resolution, that there's no stereo, etc, etc...
-matt
Though the point is flying over the mods heads, the OP has a good point.
Back in 1995-1996, VR was all the big thing, SGI and others were promoting VRML and virtual reality (on teh web!) was supposed to be just around the corner.
At about that some, some game called Quake was getting a lot of attention in the real world. When you compared the experience of playing quake to the experience of "VR", quake was infinitely more engrossing. All the VR stuff then ran at about 5 frames per second, with less detailed scenes than quake was spitting out at 30+ fps. Quake was a successful virtual reality in that it pulled you in and you could forget it was a game (in a sense). None of the VR stuff had anywhere near the same success at making the user forget what was going on.
The gap between the best of what people did with VR and the best of what people did with games was big enough that it became apparent that VR was not relatively successful. VR researchers were too focused on fancy hardware--data gloves, 3D headsets, stuff like that--and not enough focused on the graphics part. (IMHO).
Look at games like Half Life 2 today. Or the MMORPGs that many people are addicted to. The reason people spend so much time with them is that they are successful examples of VR. The academic approach to it just didn't pan out.
-matt
The rules of cricket are actually quite simple
Riiiiiiiiiight. Now please give me a concise but accurate one sentence explanation of when "leg before wicket" is called.
Christophe Hery of ILM won an award this year for his work on rendering realistic skin. ILM has won a number of other awards from the Academy for their technical work over the years; see the Oscars web site.
Oscars web site, 2003 sci-tech winners
To Christophe Hery, Ken McGaugh and Joe Letteri for their groundbreaking implementations of practical methods for rendering skin and other translucent materials using subsurface scattering techniques.
These groundbreaking techniques were used to create realistic-looking skin on digitally created characters.
Other folks honored for related work are:
To Henrik Wann Jensen, Stephen R. Marschner and Pat Hanrahan for their pioneering research in simulating subsurface scattering of light in translucent materials as presented in their paper "A Practical Model for Subsurface Light Transport."
This mathematical model contributed substantially to the development and implementation of practical techniques for simulating subsurface scattering of light in translucent materials for computer-generated images in motion pictures.
I've looked at a number of Wikis for doing exactly this.
I ended up settling on moin, for the following reasons:
1. It's easy to set up
2. Stores everything in plain text files: no fancy SQL database backend that I don't need for this small/scale stuff, and I trust text files.
3. It supports uploading of files as attachments to pages in the wiki. So if you come to a PDF document you want to save, you can easily dump it into the wiki.
So far, it's been a pretty nice way to organize stuff like this.
You remember incorrectly. That looks like zlib (which gzip is based on). zlib's license is very flexible:
/* zlib.h -- interface of the 'zlib' general purpose compression library
http://www.gzip.org/zlib/zlib_license.html
version 1.2.1, November 17th, 2003
Copyright (C) 1995-2003 Jean-loup Gailly and Mark Adler
This software is provided 'as-is', without any express or implied
warranty. In no event will the authors be held liable for any damages
arising from the use of this software.
Permission is granted to anyone to use this software for any purpose,
including commercial applications, and to alter it and redistribute it
freely, subject to the following restrictions:
1. The origin of this software must not be misrepresented; you must not
claim that you wrote the original software. If you use this software
in a product, an acknowledgment in the product documentation would be
appreciated but is not required.
2. Altered source versions must be plainly marked as such, and must not be
misrepresented as being the original software.
3. This notice may not be removed or altered from any source distribution.
Jean-loup Gailly jloup@gzip.org
Mark Adler madler@alumni.caltech.edu
*/
Alias has offered this personal learning edition version of Maya for years now; they're just announcing that the latest release of Maya, 5.0, is also available in the PLE form.
Don't get me wrong--it's great that they do this. There's just no real news here.
The PLE version has a few limitations compared to the version you pay for, but they're really amazingly small in the grand scheme of things.
Owens @ UC Davis
Akeley and Hanrahan @ Stanford
The Geforce FX GPUs absolutely do have 32-bit IEEE floats as first-class citizens in the fragrment units. (The vertex units as well.) They support a 16-bit float variant as well, but they have first-class 32-bit floats if you need them.
OpenGL and Direct3D are the two interfaces that graphics card vendors provide to get at the hardware; there is no lower-level way to get at it. However, these APIs now include ways of describing programs that run on the GPUs directly; you can write programs that run at the per-vertex or per-pixel level with either of those APIs.
These programs can be given to the GPU via specialized low-level assembly language that has been developed to expose the programmability of GPUs. (They are pretty clean, RISC-like instruction sets).
Alternatively, you can use a higher level programming language, like NVIDIA's Cg, or Microsoft's HLSL, to write programs to run on the GPU. These are somewhat C-like languages that then compile down to those GPU assembly instruction sets.
It's quite a slick setup--they've built a nice system! It boots off of the CD, loads configuration data from a floppy (basically stored as diffs from the configuration files on the CD), seems to be pretty secure, runs a 2.4 kernel, etc, etc. After it has booted, everything is loaded into RAM and it doesn't access the CD any more.
-matt
Anyway, in the shading language, surface shaders set an output color and opacity, both as RGB. To generate the final image, these are then blended the obvious way, from the Porter and Duff paper that other people have referenced. Here is a link to PDF of the spec, and here is a direct link to information about surface shaders.
Now, the amusing thing about all this is that the prior art here is from Pixar, which of course shares the same CEO as Apple...
-matt
Congratulations. You (and by the looks of it, michael) have been trolled. Read the text of the item a few more times...
http://reality.sgi.com/opengl/tips/Feedback.html
http://www.easysw.com/~mike/opengl/
First, there's the issue of studios protecting their intellectual property: have to be sure that those 3D Jar Jar models don't make their way onto the internet, or that images from the films don't leak out early.
More importantly, the amount of data required to describe a frame in these kinds of movies is immense. We're talking gigabytes for a single image. So you're talking about gigabytes of communication and then a few hours of processing. It just doesn't make sense.
There are actually pretty strict rules about what companys can publicly announce in the time period shortly before their IPOs. So this is very much likely not something fishy like that. But I forgot, Transmeta is evil and anything they do is motivated by that. Just like Rambus. And NVIDIA. Righto.
This is obviously a lossy compression method, since the total number of blocks in the codebook is much less than the number of blocks in the original texture.
There is some interesting trickiness in figuring out what are the best n blocks to store as well as given a region of the image, which codebook block to represent it with.
VQ tends to take a long time to encode--it's a CPU-intensive pre-process. However, decoding is *really* fast (just a table-lookup) and it can have very high compression ratios. For both of these reasons it fits well with graphics hardware.
See "Rendering from Compressed Textures", a paper from SIGGRAPH '96 that talks about VQ for texture compression and introduces some clever things that can be done with mip-mapped VQ textures.