Have fun complaining about losing those rights you never had, losing rights that you are not actually losing, and how people actually want you to PAY THEM for access to things they created. I'm outta here.
Look on that same page. Read the paragraph under the table. It says that each board can come with either on-board graphics or with an AGP slot, making for 16 total configurations.
I know it will be easier to use an NVidia card with NVidia's mobo. What I'm saying is that it should be just as easy to use an ATI card with NVidia's mobo as it is to use an ATI card with any other mobo. As long as that is the case, no exploitation has occurred, as they have not made it *harder* to use other cards, they have just made it *easier* to use their own.
There is a big difference between having a monopoly (either horizontal or vertical) and exploiting it. I don't see it as a problem if NVidia makes it convenient to use their hardware together. I would see it as a problem, though, if they purposely made it inconvenient to use other hardware. However, as long as it is just as easy to use an ATI card with NVidia's mobo as it is with any other mobo, there's no problem.
BTW, the GF2 on the NVidia motherboard is optional. You can buy the board without it, and choose any card you wish.
Actually, the released quite a bit of specs some time back, just not enough to use 3D effectively. They did release open-source 3D accellerated drivers (based on Mesa) at one point in the past, but they had to leave out some key technologies due to NDA's, and all they got was trash talk from the Linux community for about a year.
But, yeah, obviously their 2D specs are available (XFree includes a 2D NVidia driver), and they did release those 3D specs that they could at one point. Those specs were for the TNT2 and below (GeForce didn't exist then), but due to NVidia's hardware design philosophy they should work with the GeForce line as well. Of course, you won't get the GeForce features, nor the NDA'd stuff. Oh well. Frankly, after the Voodoo 5 driver fiasco, I don't really think the open source community could write a better driver anyway. (BSD support would be nice, but I'm told that BSD hackers are on the verge of getting the Linux binaries to work with BSD anyway.)
If you love writing your own graphics drivers, then, yeah, don't buy NVidia. Personally, I prefer to write higher-level code, and have the stuff below it do what it's supposed to do.
I mean, is there any other possible explanation? NVidia's history started as a small graphics company looking to overthrow the monsterous 3dfx, who at the time seemed to be years ahead of the competition. NVidia came out of nowhere, overtook them, and destoyed them, over but a few short years. Meanwhile, the veterans of the graphics industry tried and failed to beat NVidia's technology.
Now, NVidia is just jumping right on in to the motherboard and sound processing markets. And from the looks of it, their very first product already blows the competition out of the water. How long has this competition been here? We're talking about *Intel* and *Creative*, for crying out loud! You don't just beat these guys overnight! What have they been doing all this time? Why is NVidia able to take them out so easily? Why can't ATI or Matrox touch the GeForce 3? Why is NVidia not afraid to spend Microsoft's money to develop Linux and Mac drivers? What is going on here? At this rate, NVidia will rule the world in five to ten years!
Obviously, NVidia's technology is being provided by aliens. There just is no other explanation. We have to stop this conspiracy before it's too late!
It's not just their unified architecture that makes their drivers special. It's their OpenGL implementation.
I see people making this mistake time and time again. Everyone seems to think that a graphics driver is just like any other driver. They think that the code for the driver is mostly useless for any card other than the one it is written for. With graphics drivers, that is not the case.
In order for your driver to be OpenGL certified, is has to implement *all* of OpenGL. That includes T&L, NURBS, and much much more. NVidia has an *excellent* software implementation of T&L, and I'm sure the people who made the Kyro and Kyro II (neither of which have hardware T&L) would *love* to get ahold of it. You expect NVidia to just give that to you for free? Um, I don't think so.
Motherboards are a different issue, and I don't really think NVidia would do something dumb like keep their motherboard specs closed. I suppose we'll find out, but their record with graphics cards says nothing about it.
Why do so many people think this is funny? NVidia releases new drivers more often than a typical person would ever want to download them. see here. Version 12.40 came out about three weeks ago. 12.60 is already out. And the current Linux release is 12.51.
So which is better, BSD or GPL? The answer: It depends on the author.
Some open source programmers don't mind if their code is used in closed-source products. Some do. I don't think the FSF would like it one bit if some company extended a GNU program without releasing the source, even if it was a significant value-add.
Personally, I prefer to use the LGPL. Most of my work is in libraries, and I want anyone to be able to use them in any project. However, I wouldn't want anyone to pull a Microsoft-style embrace-and-extend on me. The LGPL prevents that. And yes, I have considered switching to a BSD-like license from time to time, but that doesn't mean that I think everyone should.
If you don't like the licensing terms placed on a piece of code, don't use it. Write your own.
------
Re:Final Fantasy blows this away...
on
Linux and Shrek
·
· Score: 2
Ever played any of the Final Fantasy *games*? Final Fantasy 9 was incredible, not just in the graphics, but in its story and characters. OTOH, Final Fantasy 8 sucked in those departments.
SquareSoft is perfectly capable of producing an all-around excellent movie. Whether or not they will... we have yet to find out. As I see it, though, the graphics will at least be entertaining.
------
Re:Don't compare Shrek and Toy Story 2
on
Linux and Shrek
·
· Score: 2
Meanwhile, Final Fantasy, to be released in two months, blows both Shrek and Monsters Inc. out of the water.
Write a wrapper around your OpenGL driver. It's really quite trivial to do. I did it myself once. However, you'll find that having transparent walls and automatic headshots really isn't fun at all. (and no, I didn't distribute my wrapper)
All of those features, except for anisotropic filtering, were implemented on the voodoo 1. Anisotropic filtering is nice, but is usually not noticeable except in extreme situations.
I am guessing that if they had any of the following important features, they would have said so:
Hardware T&L.
Dot3 bump mapping.
Texture compression.
Environment mapping.
Without these, this console is not going to be able to compete as a game console.
Game companies are not going to write games that take advantage of a chip if hardly any of their customers own in. It's a chicken-and-egg problem. Normally, you'd expect innovation to go nowhere in this situation. However, NVidia has consistently taken the risk and implemented technology that they knew wouldn't be fully used until a year or two later, and thus kept the industry moving forward. And all you can do is blast them for it? *sigh*
I was talking about virtual vs. non-virtual. Inline methods are a whole different matter. Yes, inline functions are much much much faster than virtual or even non-virtual (but non-inline) functions.
That's a common myth. If you actually run some tests, you may be surprised to find that a virtual function is hardly slower than a non-virtual function. I did some such tests myself recently, and was stunned by this discovery. And yes, I did make sure that the compiler wasn't optimizing out the virtual call.
Other sources say that a virtual call take about as long as four assignment ops. Almost anything that you might want to call through a virtual function will take at least an order of magnitude more time than that. Thus, the time taken by the virtual call itself is irrelevant.
While I'm at it, I'd like to point out something about efficiency -- poor performance is almost always caused by bad design, not the language of implementation.
For instance, trying to represent a text document in a text editor by using one large string (char* or STL string) is likely to cause problems, since you potentially need to allocate a new block of memory the size of the document and copy the text to the new block every time a change is made.
Another example, in the case of 3D graphics, would be a design where you attempt to store a triangle mesh in a linked list rather than a static array. I've seen people do this! The result is that they have to make at least one OpenGL call *per triangle* rather than per mesh, which increases the time complexity of the algorithm enormously. The author of said software tried to solve his performance problems with little tweaks like using lookup tables for sin and cos. Needless to say, it didn't help much. (Of course, his lookup tables were actually slower since they were not implemented as inline functions, but that's beside the point.)
IMO, evolution-by-design will be much more powerful than evolution-by-selection. It isn't to hard to see why -- in evolution-by-selection, you have to wait for organisms to randomly mutate to fill a new space, which is rather rare. Meanwhile, in evolution-by-design, the designers can design organisms to fill any space directly. Furthermore, a designed organism will use the opportunity much more efficiently than a randomly mutated organism, because it was specifically designed for the task.
Also, I do think that many kinds of designed advancement *are* very dependent on their environmental conditions. In a capitolist economy, people grab the opportunities the same way organisms grab opportunities. Same goes for open source software development, and even scientific advancement in general.
Oh, and a designed organism becomes an evolutionary competitor when it is given the ability to design other organisms more powerful than itself.
In 1988, a man named Ray Kurzweil predicted, based on various mathematical calculations, that a computer would beat the chess grandmaster ten years later. Deeb blue beat Kasperov in 1997.
In 1999, the same man made a few new predictions in a book entitled The Age of Spiritual Machines. Here are the predictions:
In twenty years, the average $1000 home computer will have the processing power of a human brain.
In thirty years, the average $1000 home computer will have the processing power of the entire human race.
Prepare to witness the most significant event since the dawn of life on Earth: The move from evolution by selection to evolution by design. It's going to happen within 20 years whether you like it or not.
Q3 and UT are different from the rest of Loki's games in that the Linux ports were done primarily in-house by the same company that created the game. Loki just supports them.
These two games are examples of how I would like Linux gaming to work, though.
I agree. Even though spend most of my time in Linux, if I am given the choice between a Linux version of a game and a Windows one, I will usually choose the Windows one. The reason is that I mainly play games at LAN parties. I don't want to have to reboot every time we change what game we're playing!
Now, what I would really like to be able to do is buy a hybrid game. I would pay extra for a game which I could run on both platforms.
Unfortunately, Loki is not able to provide this as the original game developer does not want to have to compete with their own game. So, Loki has to provide a Linux-only port, if they provide a separate product. And they have to provide a separate product, because otherwise there is no way to know how many people are playing the Linux version, and thus how much Loki should be paid.
Ideally, the original game developers would do the port. In order for this to be realistic, however, we need to set up an environment where porting a game requires no more than a re-compile. Unfortunately, Microsoft has made this very hard (intentionally or not) with their Win32 and DirectX API's, which can't reasonably be supported on other platforms.
What we need is a complete OS abstraction layer on which people can build platform independent software. There have been many efforts to do this (SDL, etc.), but these have mostly been fairly specialized, which means you usually need several different libraries to wrap all of the OS-specific functionality you use. Chances are that each library will have different supported platforms and other conflicting requirements. Sorting these out can be just as much of a pain as manually porting your code.
It's unfortunate that C and C++ don't have a standard API comparable to Java's. Not that I like Java, but...
The document you refer to was written over a year ago, before NVidia released their XFree4 drivers. It addresses exactly none of my points, and has no relevance to anything which exists today. What is your point?
Slashdot Mirror
Have fun complaining about losing those rights you never had, losing rights that you are not actually losing, and how people actually want you to PAY THEM for access to things they created. I'm outta here.
------
I know it will be easier to use an NVidia card with NVidia's mobo. What I'm saying is that it should be just as easy to use an ATI card with NVidia's mobo as it is to use an ATI card with any other mobo. As long as that is the case, no exploitation has occurred, as they have not made it *harder* to use other cards, they have just made it *easier* to use their own.
------
BTW, the GF2 on the NVidia motherboard is optional. You can buy the board without it, and choose any card you wish.
------
Key words: "seemed to be"
------
But, yeah, obviously their 2D specs are available (XFree includes a 2D NVidia driver), and they did release those 3D specs that they could at one point. Those specs were for the TNT2 and below (GeForce didn't exist then), but due to NVidia's hardware design philosophy they should work with the GeForce line as well. Of course, you won't get the GeForce features, nor the NDA'd stuff. Oh well. Frankly, after the Voodoo 5 driver fiasco, I don't really think the open source community could write a better driver anyway. (BSD support would be nice, but I'm told that BSD hackers are on the verge of getting the Linux binaries to work with BSD anyway.)
If you love writing your own graphics drivers, then, yeah, don't buy NVidia. Personally, I prefer to write higher-level code, and have the stuff below it do what it's supposed to do.
------
Now, NVidia is just jumping right on in to the motherboard and sound processing markets. And from the looks of it, their very first product already blows the competition out of the water. How long has this competition been here? We're talking about *Intel* and *Creative*, for crying out loud! You don't just beat these guys overnight! What have they been doing all this time? Why is NVidia able to take them out so easily? Why can't ATI or Matrox touch the GeForce 3? Why is NVidia not afraid to spend Microsoft's money to develop Linux and Mac drivers? What is going on here? At this rate, NVidia will rule the world in five to ten years!
Obviously, NVidia's technology is being provided by aliens. There just is no other explanation. We have to stop this conspiracy before it's too late!
------
I see people making this mistake time and time again. Everyone seems to think that a graphics driver is just like any other driver. They think that the code for the driver is mostly useless for any card other than the one it is written for. With graphics drivers, that is not the case.
In order for your driver to be OpenGL certified, is has to implement *all* of OpenGL. That includes T&L, NURBS, and much much more. NVidia has an *excellent* software implementation of T&L, and I'm sure the people who made the Kyro and Kyro II (neither of which have hardware T&L) would *love* to get ahold of it. You expect NVidia to just give that to you for free? Um, I don't think so.
Motherboards are a different issue, and I don't really think NVidia would do something dumb like keep their motherboard specs closed. I suppose we'll find out, but their record with graphics cards says nothing about it.
------
Why do so many people think this is funny? NVidia releases new drivers more often than a typical person would ever want to download them. see here. Version 12.40 came out about three weeks ago. 12.60 is already out. And the current Linux release is 12.51.
------
Some open source programmers don't mind if their code is used in closed-source products. Some do. I don't think the FSF would like it one bit if some company extended a GNU program without releasing the source, even if it was a significant value-add.
Personally, I prefer to use the LGPL. Most of my work is in libraries, and I want anyone to be able to use them in any project. However, I wouldn't want anyone to pull a Microsoft-style embrace-and-extend on me. The LGPL prevents that. And yes, I have considered switching to a BSD-like license from time to time, but that doesn't mean that I think everyone should.
If you don't like the licensing terms placed on a piece of code, don't use it. Write your own.
------
SquareSoft is perfectly capable of producing an all-around excellent movie. Whether or not they will... we have yet to find out. As I see it, though, the graphics will at least be entertaining.
------
Meanwhile, Final Fantasy, to be released in two months, blows both Shrek and Monsters Inc. out of the water.
------
Write a wrapper around your OpenGL driver. It's really quite trivial to do. I did it myself once. However, you'll find that having transparent walls and automatic headshots really isn't fun at all. (and no, I didn't distribute my wrapper)
------
Umm... Guess who would end up with *all* of the software patents? I'll give you a hint: Most Slashdotters dislike this company.
------
I am guessing that if they had any of the following important features, they would have said so:
Without these, this console is not going to be able to compete as a game console.
------
Everyone knows that you don't get XP for boss fights!
------
Game companies are not going to write games that take advantage of a chip if hardly any of their customers own in. It's a chicken-and-egg problem. Normally, you'd expect innovation to go nowhere in this situation. However, NVidia has consistently taken the risk and implemented technology that they knew wouldn't be fully used until a year or two later, and thus kept the industry moving forward. And all you can do is blast them for it? *sigh*
------
export __GL_ENABLE_FSAA=1
export __GL_FSAA_QUALITY=2
That should put it in 4xFSAA (aka 2x2) with no LOD bias (pretty).
------
I was talking about virtual vs. non-virtual. Inline methods are a whole different matter. Yes, inline functions are much much much faster than virtual or even non-virtual (but non-inline) functions.
------
That's a common myth. If you actually run some tests, you may be surprised to find that a virtual function is hardly slower than a non-virtual function. I did some such tests myself recently, and was stunned by this discovery. And yes, I did make sure that the compiler wasn't optimizing out the virtual call.
Other sources say that a virtual call take about as long as four assignment ops. Almost anything that you might want to call through a virtual function will take at least an order of magnitude more time than that. Thus, the time taken by the virtual call itself is irrelevant.
While I'm at it, I'd like to point out something about efficiency -- poor performance is almost always caused by bad design, not the language of implementation.
For instance, trying to represent a text document in a text editor by using one large string (char* or STL string) is likely to cause problems, since you potentially need to allocate a new block of memory the size of the document and copy the text to the new block every time a change is made.
Another example, in the case of 3D graphics, would be a design where you attempt to store a triangle mesh in a linked list rather than a static array. I've seen people do this! The result is that they have to make at least one OpenGL call *per triangle* rather than per mesh, which increases the time complexity of the algorithm enormously. The author of said software tried to solve his performance problems with little tweaks like using lookup tables for sin and cos. Needless to say, it didn't help much. (Of course, his lookup tables were actually slower since they were not implemented as inline functions, but that's beside the point.)
------
Also, I do think that many kinds of designed advancement *are* very dependent on their environmental conditions. In a capitolist economy, people grab the opportunities the same way organisms grab opportunities. Same goes for open source software development, and even scientific advancement in general.
Oh, and a designed organism becomes an evolutionary competitor when it is given the ability to design other organisms more powerful than itself.
------
In 1988, a man named Ray Kurzweil predicted, based on various mathematical calculations, that a computer would beat the chess grandmaster ten years later. Deeb blue beat Kasperov in 1997.
In 1999, the same man made a few new predictions in a book entitled The Age of Spiritual Machines. Here are the predictions:
Prepare to witness the most significant event since the dawn of life on Earth: The move from evolution by selection to evolution by design. It's going to happen within 20 years whether you like it or not.
This is not fiction. This is reality.
------
Well... I would have things to say about that, but I have vowed not to attack my competitors in public. :)
------
These two games are examples of how I would like Linux gaming to work, though.
------
Now, what I would really like to be able to do is buy a hybrid game. I would pay extra for a game which I could run on both platforms.
Unfortunately, Loki is not able to provide this as the original game developer does not want to have to compete with their own game. So, Loki has to provide a Linux-only port, if they provide a separate product. And they have to provide a separate product, because otherwise there is no way to know how many people are playing the Linux version, and thus how much Loki should be paid.
Ideally, the original game developers would do the port. In order for this to be realistic, however, we need to set up an environment where porting a game requires no more than a re-compile. Unfortunately, Microsoft has made this very hard (intentionally or not) with their Win32 and DirectX API's, which can't reasonably be supported on other platforms.
What we need is a complete OS abstraction layer on which people can build platform independent software. There have been many efforts to do this (SDL, etc.), but these have mostly been fairly specialized, which means you usually need several different libraries to wrap all of the OS-specific functionality you use. Chances are that each library will have different supported platforms and other conflicting requirements. Sorting these out can be just as much of a pain as manually porting your code.
It's unfortunate that C and C++ don't have a standard API comparable to Java's. Not that I like Java, but...
Uhh... what were we talking about again?
------
The document you refer to was written over a year ago, before NVidia released their XFree4 drivers. It addresses exactly none of my points, and has no relevance to anything which exists today. What is your point?
------