The author seems to be somewhat biased towards OpenGL. This is fine, OpenGL is a good API, but it's starting to show it's age. Here are some points that I don't really agree with:
- He poses the question as to whether low level access and flexibility is worth it (for D3D). He argues that the more simple OpenGL system is sufficient. That is not the case for most game developers. To get the same performance from OGL as you get from D3D, you really need to use extensions from Nvidia or ATI to get to the same level of flexibility that D3D already offers. Things like Nvidia's vertex array range (with NVFence), or ATI's vertex array objects are very, very useful, and a pain to use since developers need to use both to accomplish the same thing.
- OpenGL on Windows does not support multiple monitors (or, I should say multiple video cards). Some drivers do relatively well here, but the WGL layer binding OpenGL to windows is severly crippled, and some dual monitor machines will blue screen just by trying to initialize OpenGL on a single monitor. D3D (since version 5) has no problems with multiple monitors.
- COM is hard to use: probably true, but DX hides as much COM as you possibly can. The result are C++ interfaces that make using DX without directly linking to it much easier. Writing apps that load the underlying rendering libraries (instead of linking with them) will be much easier with D3D than OpenGL. D3D requires 1 function to be queried for (Direct3DCreate), OpenGL requires dozens.
- D3D requires more code: Possibly true, but not for window initialization, more for texture and vertex buffer initialization. Actual setting up of texture state and render state are nearly identical. In any case, the code size difference is negligible.
- OpenGL is cross platform: But support on the Mac SUCKS!! Apple, in their infinite stupidity, decided that extensions that don't work on the Rage 128 wouldn't be supported. So, people buying those $4000 macs with GeForce4 TI cards can be happy with the fact games that are written to use new fangled features like vertex and pixel shaders will never work on the Mac. This may change when DOOM III is released, but I doubt before then. Even support for anti-aliasing would be nice.
I've written low level application rendering code in DX5, DX7, DX8, and OpenGL. There are areas of each that I like more than the others. In the end, I would probably pick DX8 over the rest, although OpenGL and DX7 are probably neck and neck for second.
So when is Apple going to let developers use features that aren't available on the Rage 128? The latest OpenGL SDK from Apple only lists extensions that run on virtually ALL of their products. Doing this is nice in that developers don't have to worry about compatibility issues when using certain features. However, aside from Carmack and his DOOM demo, no one has been able to use any of the advanced features that the GF3/GF4 support!
Explicitly, Apple's OpenGL doesn't include support for:
GL_NV_vertex_program
GL_NV_texture_shader
GL_NV_vertex_array_range - Yes this is in the glext.h that ships with the SDK, but there is no way to allocate video memory to use with it!
GL_NV_register_combiners2
Any AGL extensions. These would allow the use of offscreen render surfaces, anti-aliasing, allocating memory for vertex array range, etc.
Obviously, Carmack was able to get needed programming info to make these things work, why not the rest of us? Is it that game developers now need to beg Apple to work on cutting edge technology on their machines? In my opinion this is killing any reason to use OpenGL over DX8/DX9 for future game development. Even if OpenGL itself supports advanced features that rival DX, I can't use them to build a cross-platform game. If that's true, what's the point of using OpenGL? (I actually like the DX8 programming model better.)
How many people actually use Borland C++?
on
Borland C++ For Linux
·
· Score: 4, Interesting
I'm sure this will marked as troll, flamebait, lame, whatever, but I'm actually curious.
How many people actually use Borland's C++ products currently? Of those that do, is this just brand loyalty from the Windows 3.1 days? I've been part of product teams (all using C/C++) developing on Windows, Mac, and various unices, and I've never seen Borland being used anywhere. The last Borland product I've seen used was Turbo Pascal for DOS back in high school.
This isn't meant to start a flame war, I've just never actually seen a Borland C++ product being used, and am curious how big their market is. It may be that the Linux version would actually outsell the Windows version due to lack of competition. And it would totally rock if they released the Borland C++ builder IDE that supported not only the Borland compiler, but gcc and icc (intel) as well.
Needless to say, if they do release the IDE, I'll be very interested to see how well it works. I've tried KDevelop, CodeWarrior (older version - 5.0?), Anjuta, a couple other gnome things, etc. And I'm sorry to say none of them allow me to be as productive as I am with VC++ (with the VisualAssist add-in). CodeWarrior was probably the worst (I hope for their sake 6.0 was better), and KDevelop the most mature. However, none of the open source efforts play nice with cross platform projects (damn it, I don't WANT the make files in the same directory as the source!!!), and are terrible when dealing with large projects. If Borland's product can deal with large cross-platform projects, I'll be a happy camper.
Actually, some of the people I work with have been doing research on trying to simulate cartoon physics, it's VERY difficult! It's basically research into getting game characters to stretch or compact realistically when accelerating or colliding with walls/floors. In terms of "real" physics, this is close to soft-body dynamics, which is MUCH harder than the rigid-body dynamics presented in this book...
The 2D hardware on Geforces have been lacking (i.e. blurry at higher resolutions).
This is a result of the OEM's that make the actual boards using cheap components for the analog output. LeadTek's newest Ti offerings use much improved RAMDAC's and filters, and the 2D quality rivals or surpasses Matrox or ATI cards. I've used all of them at 1600x1200x85 and can honestly say that the LeadTek Ti cards are the best looking Nvidia cards I've ever seen and can easily compare with Matrox and ATI.
As stated, the ONLY problem with going with Nvidia is the possibility that experimental kernels will break their drivers. Their OpenGL drivers are the best in the (consumer) business, and are not too bad for "real" (CAD, etc.) work either.
Note: I don't develop on any of these consoles, but I'm a fairly rabid gamer and develop 3D software for the PC...
If you want to develop 3D software for one of these consoles, pray that Sony releases the HD/Linux add-on for the PS2. The official development kits for all of these run several thousand dollars. The hardware required to develop on the consoles typically comes with additional functionality that the retail systems lack (PC connectivity is the obvious one!).
As for ease of porting, the Xbox uses a modified version of DX8, the PS2 gives you an assembly manual (although I hear the Linux they released has an OpenGL implementation), and the Gamecube is unknown to me (although I would guess an OpenGL-like proprietary library). My guess would be that software developed on the PS2 version of linux would NOT run on a regualar PS2. This is similar to the PS1 based Net-Yarozee (sp?).
All three console manufacturers make money by software licensing sales. Making it easy for any developer to write and sell software without paying any to them would definately not be in their best interest!
I asked Nvidia at the last Games Developer's Conference about extensions for vertex/pixel shaders (GL_NV_vertex_program, GL_NV_texture_shader, GL_NV_register_combiners2, etc.) and multiple vendor support. They said that if others were interested, they would have no problem in letting them support the extensions. ATI obviously didn't take that route...
Dan
Re:I don't think he understands memory arbitration
on
nVidia nForce
·
· Score: 3
Err, correct me if I'm wrong,...
OK, I'll correct you;)
The onboard video DOES NOT have integrated frame buffer memory. This is the same for most i810's, i815's etc. In fact, you can lower system performance by running your monitor at a higher refresh rate! To find out how much memory bandwidth your monitor is using on these things, mulitply your screen number of pixels (width * height) by 2 for 16-bit color or 4 for 24/32 bit color. This will give you how many bytes per refresh the RAMDAC is using. Multiply that by your refresh rate (ex. 85) and you have bytes per second. Take this off of your maximum memory bandwidth, and that's what you have left for your CPU. Not a great situation!
For some good commentary from people in the industry, check out VoodooExtreme, and more specifically their Ask Devs articles. Many of them deal with getting a job in games programming.
As for what skills you will probably need:
Math! Learn linear algebra, basic newtonian physics, some more math, taylor series, euler integration, etc.
Learn either D3D or OpenGL. Learn how the 3D rendering path works. While you may not need this directly for a job (i.e. you are working mainly on physics or animation code), it is always beneficial.
Experience... write lots of sample code in your spare time. The only way to get good at it is to do it.
If you do pick up on all the above, just remember: The typical games programmer doesn't make a killing with paychecks (of course, this can vary wildly) and work 80+ hour weeks (many would call this conservative). Be warned!;)
It does run x86 code, but is designed for IA-64 (NOT X86). Curiously, most of the/. crowd is bashing Intel for this because it won't run x86 code as fast as a Pentium 4. The Hammer series from AMD is a 64bit version of x86, with all the problems that traditional x86 chips have. It may work out in the short term, but I would much have a 3rd generation IA-64 bit chip than a 3rd generation Hammer chip.
I just pray that whithin 10 years Intel releases an IA-64 based chip that is NOT backwards compatible. For God's sake, it's time to cut the cord...
I completely agree with the first and last bullets. It is a bit slippery, and using the panning functionality is a bit touchy.
However, seeing as how I mostly play Diablo II (which doesn't need panning support), and I have larger hands (am I the only one who think most mice are WAY too tiny?), I'd have to say THIS THING ROCKS!
Although the shift keys take some getting used to, I've managed to replace EVERY single function in Diablo with the SC. Makes playing the sorceress or the necromancer much easier. It also makes me wonder if you could use two of these things and completely replace a keyboard for typing...
You can program each button to do a COMBINATION of keystrokes. In Diablo II, I use the keys (some with combinations of shift) to: switch to a different spell, right click (cast the spell), and switch back to the "main" spell.
In this case, I think one button press is better then key-mouse_click-key in order. Granted, there are only 6 general purpose buttons, but using the shift keys doesn't take long to get used to. I find it MUCH easier than using the keyboard for most RTS type games.
It's narrower, which is why Rambus works in the first place, but it is not serial. There are still signals (16 data, probably some more control) that travel in parallel. And it's running at 400 MHz instead of SDRAM's 133 MHz.
So yes, I should have added that both of these are parallel technologies, but RDRAM runs faster. RDRAM is proof that as buses get faster, they need to be serial.
First off, the comparison to USB2 and 1394B is WAY off base. The current AGP4X beats both of those quite easily. This is more related to Infiniband, but anyway...
There are really two questions people seemed to be confused over:
Why do we need more bandiwdth?
Why do we need a serial bus?
There is only one reason for more bandwidth: 3D graphics. AGP was originally designed so that graphics cards could use main memory for textures. Alas, it was too slow, and graphics card vendors began to just pile up RAM on the video card. However, most people don't realize that textures aren't the only thing sent down bus. Polygon data needs to be sent down every frame as well. Enter hardware transform and lighting. Suddenly games are starting to be designed with a LOT more polygons. Due to things like animation and dynamic level of detail, this polygon data can't just be stored on the graphics card like textures are, they have to be downloaded every frame. If you extrapolate the curve of supported polygons / second by the history of Nvidia cards, you'll see that AGP4X and AGP8X will be saturated relatively soon. All graphics card vendors (except maybe 3dfx, we'll see what they say after the Rampage ships) are clamoring for more bandwidth.
The reason for going to serial is physics oriented. Parallel wires switching at high speeds can generate electrical fields that cause signals in nearby wires to change. This is known as crosstalk (or noise). This is the reason that Rambus (16-bit 400 MHz) is so hard to manufacture compared to SDRAM. Moving to a serial bus allows the clock speed to be cranked much, much, MUCH higher without worrying as much about data errors.
Cost: 216 more data lines and a few more control lines...
And herein lies the problem. One of the main selling points of rambus is that you only need 16 data lines per channel. Running a few hundered lines on a motherboard at anything close to a good speed will give you all sorts of noise problems (in the electrical sense -- it's not going to blow your ears or anything). This is exactly the problem that is causing the recall -- data corruption from noise! Take away SDRAM and the memory translator hub, and the i820 (at least the latest version) works fine...
Computers would be amazingly fast and easy to design if we could just forget the analog stuff...
example: x86 mov will do register load/stores and mem->mem copies, but it can't do all at once
This still reduces x86 code size. Compare the following memory to memory copy: mov [eax], [ebx] With: mov ecx, [ebx] mov [eax], ecx The RISC-like (second set) code is twice as long as the CISC-like (first example) code. Granted, execution time is about the same (both processors do the same thing internally), but the code to represent that operation is smaller.
I'm not talking about pro's and con's of CISC vs. RISC internal to the processor (RISC wins hands down), I'm just saying that usually, CISC requires less instructions to do the same thing. Although, you're right about variable length instructions helping code size and being a pain in the ass internal to the processor.
First, I agree with post #36, 256KB is usually enough for an x86 CPU. Here is an explanation:
The reason Motorolla (and most RISC cpu's) need more cache is because code size is larger. The whole reason for CISC (x86 type) instructions is that they take up less memory. They do more work per instruction (this is another reason why MHz is a useless comparison between RISC and CISC). Since the code size is smaller, it stands to reason that they don't get as much benefit from a larger cache.
So, why doesn't Intel build larger caches and get just that much extra performance? Two reasons: - it costs more - large caches have more latency It's the never ending battle in cache size to balance low latency with high hit rates. The more you increase one, the more you decrease the other. With full speed caches on x86, 256KB (with some set associativity) seems to be the sweetspot.
So, why use more cache on Xeon's? Applications that have many processes running and access lots of different areas of memory in a short time benefit the most from a high cache hit rate (bigger caches). This is exactly the type of application that servers run. In this case, the higher latency (slower) cache is worth having a higher hit rate.
I think some people need to realize a few things about Microsoft. Regardless of their business tactics, the reason they succeed with a lot of their products is because they are simply the best. That doesn't always mean the most reliable, but the most usable. When they enter a new market, people tend to get mad, and then a while later switch to the MS product because they like using it better. Examples are: IE, Outlook, Excel, Word, Visual Studio, all their hardware (mice, joysticks, etc.), even Win2000 (hasn't crashed on me yet). That doesn't mean I don't support competition (still love Linux), but it's not like MS is trying to release crappy products.
Speaking of the X-Box explicitly, I think it will be the most powerful console for at least 2 years after it is released. That doesn't translate directly to success, but here are some reasons I think it will:
The performance mostly comes from Nvidia. While they may have some Linux issues, their hardware is top notch. It may not live up to marketing claims, but it WILL be much faster than the PS/2
More RAM than any other console (64 MB)
Runs stripped down Win2000 and DX8. Almost all PC developers will jump on the X-Box. The question is the proven console guys...
Unlike the PC, the hardware doesn't change for every user. People will actually use SSE (maybe). But, every feature of the Nvidia chip will be used, because it is guaranteed to be there. As a PC game developer, this is a dream come true.
HDTV support: All 10 people who own HDTV's will love the X-box.
Like it or not, MS is spending a TON of cash on marketing. The ad campaign is rumored to be bigger than the Win95 launch.
Finally, despite what MS is saying now, this eventually will be used as a web/email terminal. $300 for a webTV and a kick ass game console sounds good to me...
The main reason it will succeed: Microsoft has seen Sony nearly double in profit after the debut of the Playstation. They want that money. Sony has proven that game licensing is a VERY lucrative business. MS will do whatever it takes for X-box to be a success. Insert immoral/illegal conspiracy theories here...
*These are my own opinions. I have no "insider" information, just reactions after hearing the specs at GDC and hearing from other developers.
Having worked in both hardware and software shops, I can safely say it applies to both.
Also, while enough people are required to finish a project on schedule, too many right from the beginning can delay things as well. I would like to know why he thinks people were pulled from Willamette to be put on Merced. Intel has a LOT of design engineers. Without knowing the source of his information (and given the nature of his site), I am assuming he pulled this out of his ass.
Let met first say that AMD does done a tremendoes job in providing competition with Intel, and the consumers are the big winners for it.
However, I still have to equate Tom with a marketing type blowhard with just enough of a clue to be dangerous. Conspiracy theories aside, most of his information is rumor, or worse, just plain wrong!
In the meantime, Intel let its next generation 32-bit processor, the "Willamette" (the name could be worse; Intel could have called it the "Sissy"), flounder. Refusing to allocate the necessary resources to the new design, Intel chose to instead add patch upon hack to the geriatric P6 design introduced with the ancient PentiumPro.
I wonder if he's ever read "The Mythical Man Month". More people don't always mean faster...
While I do agree that AMD will probably increase market share in the future, I think writing off Intel is a HUGE mistake. I can't wait to see how the "sissy" Willamette does when Intel actually shows it. I'll wager that it'll be just a little faster than the Athlon...
Sorry to be so off topic, but 1 Mw (should be MW) is a megawatt. I think you mean mW (milliwatt).
Sorry for the rant.
Of course as the number of transisters go up, the leakage current through the devices will begin to overshadow the active, or switching, current. So you're 50 GHz processor may very well need ~1 MW (well maybe 0.0001 MW, that's still a lot).
For those who are unaware, nvidia has a poor history relating to OGL already.
They have a poor history with Linux. They have some of the best consumer OGL drivers on Windows.
Seeing how SGI has been partially helpfull to Brian Paul and Kilgard in the past, I hope that this project will turn out OK.
Kilgard now works for Nvidia. As do many former SGI employees. I wouldn't be surprised to learn that Kilgard is actually heading the team that is writing the Linux driver.
Last year, Nvidia and SGI settled a lawsuit by having the entire SGI midrange 3D design team go to Nvidia, and SGI agree to use future Nvidia products in SGI workstations. I believe that this press release is the first indication of SGI's intent to use Nvidia graphics systems. The reason that the current nvidia driver is slow, is because they are waiting for XFree86 4.0 and DRI. Why spend time and resources optimizing a driver that will be obsolete in a couple months? I am hopeful that this announcement refers to their open-source DRI drivers, but they could also be binary only drivers that come packaged with Nvidia Quadro based products. Regardless, it is in Nvidia's and SGI's best interest to provide excellent 3D support for Linux.
Slashdot Mirror
The author seems to be somewhat biased towards OpenGL. This is fine, OpenGL is a good API, but it's starting to show it's age. Here are some points that I don't really agree with:
- He poses the question as to whether low level access and flexibility is worth it (for D3D). He argues that the more simple OpenGL system is sufficient. That is not the case for most game developers. To get the same performance from OGL as you get from D3D, you really need to use extensions from Nvidia or ATI to get to the same level of flexibility that D3D already offers. Things like Nvidia's vertex array range (with NVFence), or ATI's vertex array objects are very, very useful, and a pain to use since developers need to use both to accomplish the same thing.
- OpenGL on Windows does not support multiple monitors (or, I should say multiple video cards). Some drivers do relatively well here, but the WGL layer binding OpenGL to windows is severly crippled, and some dual monitor machines will blue screen just by trying to initialize OpenGL on a single monitor. D3D (since version 5) has no problems with multiple monitors.
- COM is hard to use: probably true, but DX hides as much COM as you possibly can. The result are C++ interfaces that make using DX without directly linking to it much easier. Writing apps that load the underlying rendering libraries (instead of linking with them) will be much easier with D3D than OpenGL. D3D requires 1 function to be queried for (Direct3DCreate), OpenGL requires dozens.
- D3D requires more code: Possibly true, but not for window initialization, more for texture and vertex buffer initialization. Actual setting up of texture state and render state are nearly identical. In any case, the code size difference is negligible.
- OpenGL is cross platform: But support on the Mac SUCKS!! Apple, in their infinite stupidity, decided that extensions that don't work on the Rage 128 wouldn't be supported. So, people buying those $4000 macs with GeForce4 TI cards can be happy with the fact games that are written to use new fangled features like vertex and pixel shaders will never work on the Mac. This may change when DOOM III is released, but I doubt before then. Even support for anti-aliasing would be nice.
I've written low level application rendering code in DX5, DX7, DX8, and OpenGL. There are areas of each that I like more than the others. In the end, I would probably pick DX8 over the rest, although OpenGL and DX7 are probably neck and neck for second.
Explicitly, Apple's OpenGL doesn't include support for:
Obviously, Carmack was able to get needed programming info to make these things work, why not the rest of us? Is it that game developers now need to beg Apple to work on cutting edge technology on their machines? In my opinion this is killing any reason to use OpenGL over DX8/DX9 for future game development. Even if OpenGL itself supports advanced features that rival DX, I can't use them to build a cross-platform game. If that's true, what's the point of using OpenGL? (I actually like the DX8 programming model better.)
How many people actually use Borland's C++ products currently? Of those that do, is this just brand loyalty from the Windows 3.1 days? I've been part of product teams (all using C/C++) developing on Windows, Mac, and various unices, and I've never seen Borland being used anywhere. The last Borland product I've seen used was Turbo Pascal for DOS back in high school.
This isn't meant to start a flame war, I've just never actually seen a Borland C++ product being used, and am curious how big their market is. It may be that the Linux version would actually outsell the Windows version due to lack of competition. And it would totally rock if they released the Borland C++ builder IDE that supported not only the Borland compiler, but gcc and icc (intel) as well.
Needless to say, if they do release the IDE, I'll be very interested to see how well it works. I've tried KDevelop, CodeWarrior (older version - 5.0?), Anjuta, a couple other gnome things, etc. And I'm sorry to say none of them allow me to be as productive as I am with VC++ (with the VisualAssist add-in). CodeWarrior was probably the worst (I hope for their sake 6.0 was better), and KDevelop the most mature. However, none of the open source efforts play nice with cross platform projects (damn it, I don't WANT the make files in the same directory as the source!!!), and are terrible when dealing with large projects. If Borland's product can deal with large cross-platform projects, I'll be a happy camper.
Actually, some of the people I work with have been doing research on trying to simulate cartoon physics, it's VERY difficult! It's basically research into getting game characters to stretch or compact realistically when accelerating or colliding with walls/floors. In terms of "real" physics, this is close to soft-body dynamics, which is MUCH harder than the rigid-body dynamics presented in this book...
This is a result of the OEM's that make the actual boards using cheap components for the analog output. LeadTek's newest Ti offerings use much improved RAMDAC's and filters, and the 2D quality rivals or surpasses Matrox or ATI cards. I've used all of them at 1600x1200x85 and can honestly say that the LeadTek Ti cards are the best looking Nvidia cards I've ever seen and can easily compare with Matrox and ATI.
As stated, the ONLY problem with going with Nvidia is the possibility that experimental kernels will break their drivers. Their OpenGL drivers are the best in the (consumer) business, and are not too bad for "real" (CAD, etc.) work either.
If you want to develop 3D software for one of these consoles, pray that Sony releases the HD/Linux add-on for the PS2. The official development kits for all of these run several thousand dollars. The hardware required to develop on the consoles typically comes with additional functionality that the retail systems lack (PC connectivity is the obvious one!).
As for ease of porting, the Xbox uses a modified version of DX8, the PS2 gives you an assembly manual (although I hear the Linux they released has an OpenGL implementation), and the Gamecube is unknown to me (although I would guess an OpenGL-like proprietary library). My guess would be that software developed on the PS2 version of linux would NOT run on a regualar PS2. This is similar to the PS1 based Net-Yarozee (sp?).
All three console manufacturers make money by software licensing sales. Making it easy for any developer to write and sell software without paying any to them would definately not be in their best interest!
I asked Nvidia at the last Games Developer's Conference about extensions for vertex/pixel shaders (GL_NV_vertex_program, GL_NV_texture_shader, GL_NV_register_combiners2, etc.) and multiple vendor support. They said that if others were interested, they would have no problem in letting them support the extensions. ATI obviously didn't take that route...
Dan
OK, I'll correct you ;)
The onboard video DOES NOT have integrated frame buffer memory. This is the same for most i810's, i815's etc. In fact, you can lower system performance by running your monitor at a higher refresh rate! To find out how much memory bandwidth your monitor is using on these things, mulitply your screen number of pixels (width * height) by 2 for 16-bit color or 4 for 24/32 bit color. This will give you how many bytes per refresh the RAMDAC is using. Multiply that by your refresh rate (ex. 85) and you have bytes per second. Take this off of your maximum memory bandwidth, and that's what you have left for your CPU. Not a great situation!
So, where exactly is the "Raleigh" theme for GTK 1.2? A search on gtk.themes.org doesn't bring up anything...
As for what skills you will probably need:
If you do pick up on all the above, just remember: The typical games programmer doesn't make a killing with paychecks (of course, this can vary wildly) and work 80+ hour weeks (many would call this conservative). Be warned!
It does run x86 code, but is designed for IA-64 (NOT X86). Curiously, most of the /. crowd is bashing Intel for this because it won't run x86 code as fast as a Pentium 4. The Hammer series from AMD is a 64bit version of x86, with all the problems that traditional x86 chips have. It may work out in the short term, but I would much have a 3rd generation IA-64 bit chip than a 3rd generation Hammer chip.
I just pray that whithin 10 years Intel releases an IA-64 based chip that is NOT backwards compatible. For God's sake, it's time to cut the cord...
However, seeing as how I mostly play Diablo II (which doesn't need panning support), and I have larger hands (am I the only one who think most mice are WAY too tiny?), I'd have to say THIS THING ROCKS!
Although the shift keys take some getting used to, I've managed to replace EVERY single function in Diablo with the SC. Makes playing the sorceress or the necromancer much easier. It also makes me wonder if you could use two of these things and completely replace a keyboard for typing ...
In this case, I think one button press is better then key-mouse_click-key in order. Granted, there are only 6 general purpose buttons, but using the shift keys doesn't take long to get used to. I find it MUCH easier than using the keyboard for most RTS type games.
So yes, I should have added that both of these are parallel technologies, but RDRAM runs faster. RDRAM is proof that as buses get faster, they need to be serial.
There are really two questions people seemed to be confused over:
There is only one reason for more bandwidth: 3D graphics. AGP was originally designed so that graphics cards could use main memory for textures. Alas, it was too slow, and graphics card vendors began to just pile up RAM on the video card. However, most people don't realize that textures aren't the only thing sent down bus. Polygon data needs to be sent down every frame as well. Enter hardware transform and lighting. Suddenly games are starting to be designed with a LOT more polygons. Due to things like animation and dynamic level of detail, this polygon data can't just be stored on the graphics card like textures are, they have to be downloaded every frame. If you extrapolate the curve of supported polygons / second by the history of Nvidia cards, you'll see that AGP4X and AGP8X will be saturated relatively soon. All graphics card vendors (except maybe 3dfx, we'll see what they say after the Rampage ships) are clamoring for more bandwidth.
The reason for going to serial is physics oriented. Parallel wires switching at high speeds can generate electrical fields that cause signals in nearby wires to change. This is known as crosstalk (or noise). This is the reason that Rambus (16-bit 400 MHz) is so hard to manufacture compared to SDRAM. Moving to a serial bus allows the clock speed to be cranked much, much, MUCH higher without worrying as much about data errors.
And herein lies the problem. One of the main selling points of rambus is that you only need 16 data lines per channel. Running a few hundered lines on a motherboard at anything close to a good speed will give you all sorts of noise problems (in the electrical sense -- it's not going to blow your ears or anything). This is exactly the problem that is causing the recall -- data corruption from noise! Take away SDRAM and the memory translator hub, and the i820 (at least the latest version) works fine...
Computers would be amazingly fast and easy to design if we could just forget the analog stuff...
This still reduces x86 code size. Compare the following memory to memory copy:
mov [eax], [ebx]
With:
mov ecx, [ebx]
mov [eax], ecx
The RISC-like (second set) code is twice as long as the CISC-like (first example) code. Granted, execution time is about the same (both processors do the same thing internally), but the code to represent that operation is smaller.
I'm not talking about pro's and con's of CISC vs. RISC internal to the processor (RISC wins hands down), I'm just saying that usually, CISC requires less instructions to do the same thing. Although, you're right about variable length instructions helping code size and being a pain in the ass internal to the processor.
The reason Motorolla (and most RISC cpu's) need more cache is because code size is larger. The whole reason for CISC (x86 type) instructions is that they take up less memory. They do more work per instruction (this is another reason why MHz is a useless comparison between RISC and CISC). Since the code size is smaller, it stands to reason that they don't get as much benefit from a larger cache.
So, why doesn't Intel build larger caches and get just that much extra performance? Two reasons:
- it costs more
- large caches have more latency
It's the never ending battle in cache size to balance low latency with high hit rates. The more you increase one, the more you decrease the other. With full speed caches on x86, 256KB (with some set associativity) seems to be the sweetspot.
So, why use more cache on Xeon's? Applications that have many processes running and access lots of different areas of memory in a short time benefit the most from a high cache hit rate (bigger caches). This is exactly the type of application that servers run. In this case, the higher latency (slower) cache is worth having a higher hit rate.
That's probably accurate if you're talking to a Quake fanatic. Too bad the PC games market is about half the size of the console market...
Speaking of the X-Box explicitly, I think it will be the most powerful console for at least 2 years after it is released. That doesn't translate directly to success, but here are some reasons I think it will:
The main reason it will succeed: Microsoft has seen Sony nearly double in profit after the debut of the Playstation. They want that money. Sony has proven that game licensing is a VERY lucrative business. MS will do whatever it takes for X-box to be a success. Insert immoral/illegal conspiracy theories here...
*These are my own opinions. I have no "insider" information, just reactions after hearing the specs at GDC and hearing from other developers.
Also, while enough people are required to finish a project on schedule, too many right from the beginning can delay things as well. I would like to know why he thinks people were pulled from Willamette to be put on Merced. Intel has a LOT of design engineers. Without knowing the source of his information (and given the nature of his site), I am assuming he pulled this out of his ass.
However, I still have to equate Tom with a marketing type blowhard with just enough of a clue to be dangerous. Conspiracy theories aside, most of his information is rumor, or worse, just plain wrong!
In the meantime, Intel let its next generation 32-bit processor, the "Willamette" (the name could be worse; Intel could have called it the "Sissy"), flounder. Refusing to allocate the necessary resources to the new design, Intel chose to instead add patch upon hack to the geriatric P6 design introduced with the ancient PentiumPro.
I wonder if he's ever read "The Mythical Man Month". More people don't always mean faster...
While I do agree that AMD will probably increase market share in the future, I think writing off Intel is a HUGE mistake. I can't wait to see how the "sissy" Willamette does when Intel actually shows it. I'll wager that it'll be just a little faster than the Athlon...
An objective, intelligent thought was posted above. Slashdot will self destruct in 30 seconds...
Sorry for the rant.
Of course as the number of transisters go up, the leakage current through the devices will begin to overshadow the active, or switching, current. So you're 50 GHz processor may very well need ~1 MW (well maybe 0.0001 MW, that's still a lot).
They have a poor history with Linux. They have some of the best consumer OGL drivers on Windows.
Seeing how SGI has been partially helpfull to Brian Paul and Kilgard in the past, I hope that this project will turn out OK.
Kilgard now works for Nvidia. As do many former SGI employees. I wouldn't be surprised to learn that Kilgard is actually heading the team that is writing the Linux driver.
Last year, Nvidia and SGI settled a lawsuit by having the entire SGI midrange 3D design team go to Nvidia, and SGI agree to use future Nvidia products in SGI workstations. I believe that this press release is the first indication of SGI's intent to use Nvidia graphics systems. The reason that the current nvidia driver is slow, is because they are waiting for XFree86 4.0 and DRI. Why spend time and resources optimizing a driver that will be obsolete in a couple months? I am hopeful that this announcement refers to their open-source DRI drivers, but they could also be binary only drivers that come packaged with Nvidia Quadro based products. Regardless, it is in Nvidia's and SGI's best interest to provide excellent 3D support for Linux.