I've done a couple of these before and was told that's where the requirements come from. I never asked if it was required or implementing recommended policy.
The securities and exchange commission (SEC) is protecting you from yourself and fraudulent investment brokers. IPOs are considered extremely risky investments. You have to demonstrate (via the form) that you are qualified to invest in such things. That typically means a certain amount of trading experience, that you're not investing too large a percentage of your net worth, etc.
Red Hat and E*Trade don't have anything to do with it really. They invited you to participate, but if the SEC won't let you do so, there's nothing else they can do about it.
A lot of what we're doing in direct rendering is based on the work SGI has done in the past. Their hardware and software supports the equivalent of our direct rendering.
sgi provided GLX to the open source community, and we integrated it into XFree. They are also funding some of our work.
I don't know if they are using our framework for the visual workstation, but regardless, I'm sure it'll perform well.
I too attended the kickoff of the revolution tour. I think Arne completely missed the point on the CodeWarrior product and Erik Troan's response to the question.
Erik categorically denied having made an exclusive relationship with MetroWerks. In fact, he said that Red Hat would not do such a thing. So MetroWerks is making CodeWarrior for Red Hat Linux. What's Red Hat supposed to do? Should they not help MetroWerks port their product to Linux? Should they somehow force MetroWerks to support other distributions? The only thing Red Hat has done in this is be successful. So any fault you have should be pointed at MetroWerks and not Red Hat.
If we look at the picture from the view of MetroWerks, it does cost money to support different distributions. It is not nearly as trivial as Arne believes with his "Yes you can--./configure; make; make install," response. You have to make installers for each distribution, you have to have multiple machines and/or reboot to rebuild for each distribution, you have to go through test and quality assurance each time the distribution changes, you have to train your support staff in the differences between distributions, you have to print different user documentation, just to name a few. Compiling the code is the least of the issues. All these issues cost money.
It all comes down to time and money. If other distributions have a large enough market share that MetroWerks can take advantage of, then MetroWerks should do the work and make the extra profit. If not, then they shouldn't. You can't reasonably expect MetroWerks to support Daryll's Sunday Night distribution (DSND) which has three users if you include my cat. The line needs to be drawn somewhere.
Let's look at the alternative. MetroWerks does support every distribution they can find. They put all the time and resources into doing it even though the cost of supporting little distributions like DSND is really high. Then they take the total cost and divide it by the total users. Everyone ends up paying a lot of money to support the three users of DSND. The cost of CodeWarrior doubles because of it. They lose sales or have a lot of unhappy users when the Linux version costs twice as much as the Windows version. Not a very good solution.
Luckily the Linux is similar enough, and the LSB will improve those similarities further, so that even DSND will probably run MetroWerks even though it isn't supported. It allows you to have the flexibility to run all these products even though your system is unique for one reason or another. For the vendor the LSB will make it even cheaper to test their product against many distributions. That's another example of the power of Linux.
So don't villify Red Hat or MetroWerks for their descision. If your distribution has the market share to support CodeWarrior then demonstrate that to MetroWerks and they would be foolish not to support it. In fact, another poster posted mail from the President of MetroWerks saying they were already in the process of testing against SUSE and Caldera and working on other distributions. So the process is working exactly as it should!
I wanted to make it as easy for users as possible. Having support for each distribution in its own native packaging fomat would be the best answer. Unfortunetly, I can't do that. I don't have the time to make separate packages and install scripts and maintain all the different distributions on my system. So I had to compromise. For MOST people the easiest solution is an RPM. (Red Hat, SUSE, and Caldera)
I didn't want to leave other users out in the cold. My website has two different solutions for converting out of the RPM, either alien or rpm2cpio. So if RPM doesn't work for you, you've got an alternative. I've also had other distributions do the work of repackaging, which was fine with me.
The problem with a tar.gz is that you need to know how to install it, where to install it, and to do any of the extra steps required for correct execution. A single RPM bundles all that up. As long as you have a way to convert out of RPM it seems like the best answer.
I can tell you from my experience that even RPMs aren't easy enough for a lot of users. I spend a lot of time trying to answer people's questions. As we move towards things like games that HAS to get easier as the users aren't going to have the skills to handle it otherwise.
The only solution I see to this problem is a standard packaging format that works accross distributions. So support LSB and their efforts to standardize packaging!
XF4.0 will include our (Precision Insight) direct rendering infrastructure. One of the important issues for good 3D performance is getting a fast path to the hardware. Direct rendering provides that structure.
When the FAQ says that the performance isn't great, it is because they have to use GLX and go through the X server to do their 3D rendering. There's some significant work to connect up a new driver to the DRI, but the nVidia drivers appear to be well suited to the PI DRI.
Once that's done the performance will improve. Beyond that there's undoubtedly other optimizations that will be needed, but it'll be a great start.
People seem to be worried about in a window rendering versus full screen. That's really a non issue. It is true that GLX implies rendering is in a window, but if the window is the same size as the screen, then there isn't really a difference. It should be possible for the driver to detect this case and do page flipping instead of copying and get the performance improvement.
I signed up with FLashCom in Southern California. The rate was good. GTE was providing the actual DSL service. I'm running a Linux box so I have almost no reliance on the FlashCom services except for netnews.
When I signed up (Dec 1998) they had a different contract than they do now. They appear to have broken down the service into two offers. One is for home use and has the "no static IP, no servers, and no NAT" clause. The other (more expensive) is less restrictive.
I ended up getting SDSL 384k for $90/month with a less restrictive contract. Southwestern Bell/Pacific Bell has some very good deals for ADSL in this area as well, but I'm in GTE country.
Installation went smoothly. GTE showed up, installed the in house end of the phone line in 10 minutes. They brought the DSL modem plugged it in, waited for the lights to turn green and said "I'm done." Luckily I knew to call FlashCom and request an IP address and gateway. Time from order to on the net was about two weeks and installation was $99 with the modem thrown in for free.
Another key point to be aware of with DSL is the CIR, the certified information rate. The phone company will tell you the maximum data rate your line can carry. Ask them what the CIR is. This is the minimum rate that they guarantee. You'll find it to be much lower. From what I've seen the CLECs give you a better CIR at a higher cost than the RBOC.
Your DSL line connects to an ISP and the ISP connects you to the net. So, how your ISP connects to the net is very important (like any ISP). Are they multihomed? Where are their exchange points? Do they get network service from the major players?
Overall I've been very happy with it. It would have been tough if my wife and I weren't extremely knowledgable on the topic. Hopefully this is useful as a comparison for other people looking at DSL.
- |Daryll
Working on Linux for a living
on
VA on Upside
·
· Score: 4
I left Digital Domain because I had the opportunity to do good work for Linux on something I cared about (3D support). That was my motivation.
I did my job hunting at Linux World. I picked a few key people and companies that I wanted to talk to and mentioned that I was thinking of moving on. The response I got was extremely positive.
I knew I could have my pick, so I took my time and decided what was important to me. I wasn't concerned about the money. I knew all the companies would offer me "enough." I was looking for where I could do the most good, and have the most fun doing it.
For what I wanted to do Precision Insight had the right mix. I get to work from home. They are leading the charge in 3D. It's a great group of people that would have been difficult to assemble in one place.
So, I'm very pleased with how it all worked out. I get what I want and Linux moves forward in the process.
I bought a two processor mainboard and I've got one PII-400 in it. The PII-400 is now cheap enough that I COULD get a second one, but for the same money I could get two Celerons and have a PII-400 left over. I can't decide what to do to get top performance and not waste money.
3Dfx is serious about wanting to work with Linux. This isn't marketting fluff. They've appreciated the work I've done, and they understand the value.
Glide is a hardware abstraction layer. They use it for their in-house applications. You don't have to write to it if you don't want to. Mesa talks through Glide and that's a fine way to access the hardware. There is essentiantially no performance hit for doing so.
Linux users complaining about Glide only games don't know what they are talking about. Most of the "Glide only" games you see are OpenGL games, that need Glide only to talk to the hardware. They won't be Glide only when more hardware has OpenGL support under Linux. Hopefully that'll be soon.
No, Glide will not be Open Source anytime soon. That might be less than optimal, but I take the position that having it be well supported by the vendor is almost as good. (As an example, do you have the source to the BIOS on your PC? Why don't you complain about that?) Having their own team in house to work on Linux is the way to get it well supported
I asked them a while back to start looking to hire people in house. They really wanted to hire me. I seriously considered their offer, but decided to work for Precision Insight instead. I figured being vendor neutral was better. I hope to continue working with 3dfx and whoever they hire in house.
If anyone from here is interested in the job with 3dfx, please feel free to contact me. They are a great group of people. They want to do some really cool work. I believe it'll be good for Linux in general.
Let me speak a little to the state of all this, since it is somewhat confusing and I'm seeing some incorrect information.
I don't know the details of the TNT2 release. My best guess is that they have SGI OpenGL as a base. That means they'll be releasing binary only.
That's not particularly bad. There is room to have more than one OpenGL implementation. In fact, there are already three (Mesa, XiG, MetroLink).
The biggest problem is that OpenGL provides and API and not an ABI. That means programs can be recompiled against different OpenGL libraries and work, but compiling against one library doesn't insure compatability with another. No one wants that to be a problem, because we don't want different versions of applications to be required. I've been talking with vendors and suggesting that Mesa be made a reference platform. The advantage of that is that everyone gets it for free and we all agree on interface difference. Mostly this hasn't been a major issue in my testing so far, but it has come up. It also helps that we have some common benchmarking programs that we can all use to test.
That takes care of the commercial side of the discussion, now lets look at the free software side of the problem.
Mesa is the OpenGL layer. It currently has a hardware layer known as DD for lack of a better term. The current 3dfx support for Mesa goes through that interface. SUSE has worked on extending that to something they call ACL. See http://www.suse.de/~sim for more information. People are also adding multithread support and optimizations to the core of Mesa
GLX provides and interface layer between an X server and OpenGL. It also allows remote OpenGL applications to communicate with a local server. SGI made GLX open source.
Precision Insight took GLX and Mesa and rolled that into the XFree 4.0 tree. So, minimally all XFree 4.0 servers will have the capability of doing software OpenGL. This will become a new "assumption" about a Linux workstation which is great.
There is parallel work going on between SUSE and PI at the moment. Simon from SUSE, is working on a hardware interface layer (generic PCI) and an integration layer (MLX).
Finally Precision Insight is working on the DRI, direct rendering infrastructure. This allows applications outside the X server to talk straight to the hardware. Here's Q&A you can read.
My work on Glide for Rush (and now Banshee/V3) needs something like the DRI. My first solution was a bit of hack (called the Rush extension) and was an X server extension. Switching to the DRI should standardize things further.
I hope this clears things up. I'm extremely pleased to see all the progress. Having nVidia release an OpenGL is fine as long as it interacts well with applications compiled against Mesa. I'm fairly sure it will since they want Q3 to work!
I'm pleased to hear they're close to releasing. I don't know any details, but I know they've been working on it for a while and they wanted to release full OpenGL for it.
I guess this and Q3 mean I need to get my butt in gear and get the Banshee/V3 stuff out!:-) Actually my time between jobs has helped progress it greatly.
There is nothing "interesting" from the 3dfx interface in/dev/3dfx. It just does some programmed I/O and memory mapping. So releasing it open source wasn't a problem.
I didn't break that ground, but it will happen soon I suspect.
The fellow was an engineer in their compiler group. I wouldn't say high up, but it jives with the story I've been getting from the more senior people
The CPML libraries are nice because they ADD precision compared to gnu libm and they are faster. In fact, our application is bound mostly by simpler operations anyway.
Glide? I hope to. It's been a matter of time and it hasn't percolated up my stack. With 3Dfx picking up more of the support themselves and the Banshee 2D being open source my workload should get better. I hope!
I was speaking to one of the guys from the Compaq compiler group at Linux World. Compaq realizes that good compilers just make their hardware look better, so they do want to see that happen. The problem is that they can't (for whatever reason) release all the technology open source. They can provide information and some technology to help gcc based compilers get better, but they are afraid that it is a major overhaul and will require a couple years to become functional. The big problem is that the instruction scheduling has to change dramatically particularly for floating point. So, they are taking a two pronged approach. One is to get their compiler out in the short term for a low cost. The second is to add functionality to gcc. Eventually they could get out of selling their compiler. It's a good plan and the right thing happens over time. Alpha's rock running Linux, but our 400 Mhz DEC Unix systems out perfrom 466Mhz Linux systems. I suspect that's mainly because of the compiler and the good math libraries which they have also released for free (proprietary). - |Daryll
I'll be doing a presentation at Linux World Conference on the state of 3D for Linux. The presentation and benchmark results will be available on my website (http://www.linux3d.org) soon after the show.
Here's the short answer: Xi Graphics and Metro Link have servers out to Beta testers. I have them and will be benchmarking them before the show. Precision Insight is adding Mesa and GLX support to XFree as well as creating a direct rendering infrastructure for drivers to be built on. 3Dfx Voodoo cards work now. Banshee and V3 will be reasonable (low end) cards for in a window 3D. No extra software costs. Permedia2 is in alpha and is open source.
I personally expect all this to really be solid by Linux Expo and I expect SIGGRAPH to be pretty exciting.
For Titanic we used the boxes strictly for rendering, no interactive work. Without 3D hardware support doing interactive work doesn't make any sense. We did run our compositing software remotely using Mesa and X and it worked surprisingly well! That was just for testing not for real work.
Can you get a reasonable setup for $1k? It depends on what you mean by reasonable. For film work, the answer would be no. The modelling packages we use range from $2,500 to $15,000. A good OpenGL card can set you back another $2,500. A good rendering package is another $2,500 to $5,000.
As a home user you could buy a V3 or Permedia for $150, no extra OpenGL cost, and a low end modelling package (say Animation Master were it available) for another $200. You'd be in good shape.
It's actually more complicated than that. There are four things to getting the Banshee/V3 running:
1) An X server. Since people want to do 2D on these things. (Actually the X server provides some other support functions as well). I'm working on this now.
2) Glide. This talks to the hardware. This is just routine code messaging to make it run under Linux. A little assembly that needs to move between MASM and GAS.
3) X Server/Glide Integration. They have to cooperate in talking to the hardware. This is the XFree86-Rush extension slightly modified for the Banshee. Shouldn't take much work.
4)/dev/3dfx. No changes needed excepting updating to the 2.2 kernel which has already been done by some other folks. I just need to grab thier fixes.
The reason the Xi Graphics and Metro Link solutions help is that it gets a lot more boards supported. To do 3D well you really do need a 3D board. Xi supports several.
I'm doing a presentation at Linux World Conference and Expo on the state of 3D for Linux. At that presentation I'll be talking about the state of the free and comercial software. I'll also be presenting some benchmark results on a variety of boards and servers.
After the show is over I plan on putting my results up on my website.
Slashdot Mirror
I've done a couple of these before and was told that's where the requirements come from. I never asked if it was required or implementing recommended policy.
In any case, it is standard procedure.
- |Daryll
Red Hat and E*Trade don't have anything to do with it really. They invited you to participate, but if the SEC won't let you do so, there's nothing else they can do about it.
- |Daryll
sgi provided GLX to the open source community, and we integrated it into XFree. They are also funding some of our work.
I don't know if they are using our framework for the visual workstation, but regardless, I'm sure it'll perform well.
- |Daryll
visual workstation products
- |Daryll
If you're interested in telephony, check out
- |Daryll
Erik categorically denied having made an exclusive relationship with MetroWerks. In fact, he said that Red Hat would not do such a thing. So MetroWerks is making CodeWarrior for Red Hat Linux. What's Red Hat supposed to do? Should they not help MetroWerks port their product to Linux? Should they somehow force MetroWerks to support other distributions? The only thing Red Hat has done in this is be successful. So any fault you have should be pointed at MetroWerks and not Red Hat.
If we look at the picture from the view of MetroWerks, it does cost money to support different distributions. It is not nearly as trivial as Arne believes with his "Yes you can--./configure; make; make install," response. You have to make installers for each distribution, you have to have multiple machines and/or reboot to rebuild for each distribution, you have to go through test and quality assurance each time the distribution changes, you have to train your support staff in the differences between distributions, you have to print different user documentation, just to name a few. Compiling the code is the least of the issues. All these issues cost money.
It all comes down to time and money. If other distributions have a large enough market share that MetroWerks can take advantage of, then MetroWerks should do the work and make the extra profit. If not, then they shouldn't. You can't reasonably expect MetroWerks to support Daryll's Sunday Night distribution (DSND) which has three users if you include my cat. The line needs to be drawn somewhere.
Let's look at the alternative. MetroWerks does support every distribution they can find. They put all the time and resources into doing it even though the cost of supporting little distributions like DSND is really high. Then they take the total cost and divide it by the total users. Everyone ends up paying a lot of money to support the three users of DSND. The cost of CodeWarrior doubles because of it. They lose sales or have a lot of unhappy users when the Linux version costs twice as much as the Windows version. Not a very good solution.
Luckily the Linux is similar enough, and the LSB will improve those similarities further, so that even DSND will probably run MetroWerks even though it isn't supported. It allows you to have the flexibility to run all these products even though your system is unique for one reason or another. For the vendor the LSB will make it even cheaper to test their product against many distributions. That's another example of the power of Linux.
So don't villify Red Hat or MetroWerks for their descision. If your distribution has the market share to support CodeWarrior then demonstrate that to MetroWerks and they would be foolish not to support it. In fact, another poster posted mail from the President of MetroWerks saying they were already in the process of testing against SUSE and Caldera and working on other distributions. So the process is working exactly as it should!
- |Daryll
I didn't want to leave other users out in the cold. My website has two different solutions for converting out of the RPM, either alien or rpm2cpio. So if RPM doesn't work for you, you've got an alternative. I've also had other distributions do the work of repackaging, which was fine with me.
The problem with a tar.gz is that you need to know how to install it, where to install it, and to do any of the extra steps required for correct execution. A single RPM bundles all that up. As long as you have a way to convert out of RPM it seems like the best answer.
I can tell you from my experience that even RPMs aren't easy enough for a lot of users. I spend a lot of time trying to answer people's questions. As we move towards things like games that HAS to get easier as the users aren't going to have the skills to handle it otherwise.
The only solution I see to this problem is a standard packaging format that works accross distributions. So support LSB and their efforts to standardize packaging!
- |Daryll
When the FAQ says that the performance isn't great, it is because they have to use GLX and go through the X server to do their 3D rendering. There's some significant work to connect up a new driver to the DRI, but the nVidia drivers appear to be well suited to the PI DRI.
Once that's done the performance will improve. Beyond that there's undoubtedly other optimizations that will be needed, but it'll be a great start.
People seem to be worried about in a window rendering versus full screen. That's really a non issue. It is true that GLX implies rendering is in a window, but if the window is the same size as the screen, then there isn't really a difference. It should be possible for the driver to detect this case and do page flipping instead of copying and get the performance improvement.
- |Daryll
Hopefully this will be a good example for other hardware vendors.
We're moving rapidly towards making Linux into a good 3D workstation!
- |Daryll
When I signed up (Dec 1998) they had a different contract than they do now. They appear to have broken down the service into two offers. One is for home use and has the "no static IP, no servers, and no NAT" clause. The other (more expensive) is less restrictive.
I ended up getting SDSL 384k for $90/month with a less restrictive contract. Southwestern Bell/Pacific Bell has some very good deals for ADSL in this area as well, but I'm in GTE country.
Installation went smoothly. GTE showed up, installed the in house end of the phone line in 10 minutes. They brought the DSL modem plugged it in, waited for the lights to turn green and said "I'm done." Luckily I knew to call FlashCom and request an IP address and gateway. Time from order to on the net was about two weeks and installation was $99 with the modem thrown in for free.
Another key point to be aware of with DSL is the CIR, the certified information rate. The phone company will tell you the maximum data rate your line can carry. Ask them what the CIR is. This is the minimum rate that they guarantee. You'll find it to be much lower. From what I've seen the CLECs give you a better CIR at a higher cost than the RBOC.
Your DSL line connects to an ISP and the ISP connects you to the net. So, how your ISP connects to the net is very important (like any ISP). Are they multihomed? Where are their exchange points? Do they get network service from the major players?
Overall I've been very happy with it. It would have been tough if my wife and I weren't extremely knowledgable on the topic. Hopefully this is useful as a comparison for other people looking at DSL.
- |Daryll
I left Digital Domain because I had the opportunity to do good work for Linux on something I cared about (3D support). That was my motivation.
I did my job hunting at Linux World. I picked a few key people and companies that I wanted to talk to and mentioned that I was thinking of moving on. The response I got was extremely positive.
I knew I could have my pick, so I took my time and decided what was important to me. I wasn't concerned about the money. I knew all the companies would offer me "enough." I was looking for where I could do the most good, and have the most fun doing it.
For what I wanted to do Precision Insight had the right mix. I get to work from home. They are leading the charge in 3D. It's a great group of people that would have been difficult to assemble in one place.
So, I'm very pleased with how it all worked out. I get what I want and Linux moves forward in the process.
- |Daryll
- |Daryll
- |Daryll
3Dfx is serious about wanting to work with Linux. This isn't marketting fluff. They've appreciated the work I've done, and they understand the value.
Glide is a hardware abstraction layer. They use it for their in-house applications. You don't have to write to it if you don't want to. Mesa talks through Glide and that's a fine way to access the hardware. There is essentiantially no performance hit for doing so.
Linux users complaining about Glide only games don't know what they are talking about. Most of the "Glide only" games you see are OpenGL games, that need Glide only to talk to the hardware. They won't be Glide only when more hardware has OpenGL support under Linux. Hopefully that'll be soon.
No, Glide will not be Open Source anytime soon. That might be less than optimal, but I take the position that having it be well supported by the vendor is almost as good. (As an example, do you have the source to the BIOS on your PC? Why don't you complain about that?) Having their own team in house to work on Linux is the way to get it well supported
I asked them a while back to start looking to hire people in house. They really wanted to hire me. I seriously considered their offer, but decided to work for Precision Insight instead. I figured being vendor neutral was better. I hope to continue working with 3dfx and whoever they hire in house.
If anyone from here is interested in the job with 3dfx, please feel free to contact me. They are a great group of people. They want to do some really cool work. I believe it'll be good for Linux in general.
- |Daryll
They also include an application CD for other commercial products
There's no reason they couldn't put nVidia's and 3Dfx's stuff on the application disk. I wish I had thought of that earlier!
- |Daryll
The $299 was the support program as I recall.
- |Daryll
I don't know the details of the TNT2 release. My best guess is that they have SGI OpenGL as a base. That means they'll be releasing binary only.
That's not particularly bad. There is room to have more than one OpenGL implementation. In fact, there are already three (Mesa, XiG, MetroLink).
The biggest problem is that OpenGL provides and API and not an ABI. That means programs can be recompiled against different OpenGL libraries and work, but compiling against one library doesn't insure compatability with another. No one wants that to be a problem, because we don't want different versions of applications to be required. I've been talking with vendors and suggesting that Mesa be made a reference platform. The advantage of that is that everyone gets it for free and we all agree on interface difference. Mostly this hasn't been a major issue in my testing so far, but it has come up. It also helps that we have some common benchmarking programs that we can all use to test.
That takes care of the commercial side of the discussion, now lets look at the free software side of the problem.
Mesa is the OpenGL layer. It currently has a hardware layer known as DD for lack of a better term. The current 3dfx support for Mesa goes through that interface. SUSE has worked on extending that to something they call ACL. See http://www.suse.de/~sim for more information. People are also adding multithread support and optimizations to the core of Mesa
GLX provides and interface layer between an X server and OpenGL. It also allows remote OpenGL applications to communicate with a local server. SGI made GLX open source.
Precision Insight took GLX and Mesa and rolled that into the XFree 4.0 tree. So, minimally all XFree 4.0 servers will have the capability of doing software OpenGL. This will become a new "assumption" about a Linux workstation which is great.
There is parallel work going on between SUSE and PI at the moment. Simon from SUSE, is working on a hardware interface layer (generic PCI) and an integration layer (MLX).
Finally Precision Insight is working on the DRI, direct rendering infrastructure. This allows applications outside the X server to talk straight to the hardware. Here's Q&A you can read.
My work on Glide for Rush (and now Banshee/V3) needs something like the DRI. My first solution was a bit of hack (called the Rush extension) and was an X server extension. Switching to the DRI should standardize things further.
I hope this clears things up. I'm extremely pleased to see all the progress. Having nVidia release an OpenGL is fine as long as it interacts well with applications compiled against Mesa. I'm fairly sure it will since they want Q3 to work!
- |Daryll
I guess this and Q3 mean I need to get my butt in gear and get the Banshee/V3 stuff out! :-) Actually my time between jobs has helped progress it greatly.
- |Daryll
Incorrect. /dev/3dfx is open source.
There is nothing "interesting" from the 3dfx interface in /dev/3dfx. It just does some programmed I/O and memory mapping. So releasing it open source wasn't a problem.
I didn't break that ground, but it will happen soon I suspect.
- |Daryll
The CPML libraries are nice because they ADD precision compared to gnu libm and they are faster. In fact, our application is bound mostly by simpler operations anyway.
Glide? I hope to. It's been a matter of time and it hasn't percolated up my stack. With 3Dfx picking up more of the support themselves and the Banshee 2D being open source my workload should get better. I hope!
- |Daryll
I was speaking to one of the guys from the Compaq compiler group at Linux World. Compaq realizes that good compilers just make their hardware look better, so they do want to see that happen. The problem is that they can't (for whatever reason) release all the technology open source. They can provide information and some technology to help gcc based compilers get better, but they are afraid that it is a major overhaul and will require a couple years to become functional. The big problem is that the instruction scheduling has to change dramatically particularly for floating point. So, they are taking a two pronged approach. One is to get their compiler out in the short term for a low cost. The second is to add functionality to gcc. Eventually they could get out of selling their compiler. It's a good plan and the right thing happens over time. Alpha's rock running Linux, but our 400 Mhz DEC Unix systems out perfrom 466Mhz Linux systems. I suspect that's mainly because of the compiler and the good math libraries which they have also released for free (proprietary). - |Daryll
I'll be doing a presentation at Linux World Conference on the state of 3D for Linux. The presentation and benchmark results will be available on my website (http://www.linux3d.org) soon after the show.
Here's the short answer:
Xi Graphics and Metro Link have servers out to Beta testers. I have them and will be benchmarking them before the show.
Precision Insight is adding Mesa and GLX support to XFree as well as creating a direct rendering infrastructure for drivers to be built on.
3Dfx Voodoo cards work now. Banshee and V3 will be reasonable (low end) cards for in a window 3D. No extra software costs.
Permedia2 is in alpha and is open source.
I personally expect all this to really be solid by Linux Expo and I expect SIGGRAPH to be pretty exciting.
For Titanic we used the boxes strictly for rendering, no interactive work. Without 3D hardware support doing interactive work doesn't make any sense. We did run our compositing software remotely using Mesa and X and it worked surprisingly well! That was just for testing not for real work.
Can you get a reasonable setup for $1k? It depends on what you mean by reasonable. For film work, the answer would be no. The modelling packages we use range from $2,500 to $15,000. A good OpenGL card can set you back another $2,500. A good rendering package is another $2,500 to $5,000.
As a home user you could buy a V3 or Permedia for $150, no extra OpenGL cost, and a low end modelling package (say Animation Master were it available) for another $200. You'd be in good shape.
- |Daryll
I agree. It is a good product that's been around for a long time and supported Linux early on.
It's already listed on my software page of my website. (http://www.linux3d.org) I expect I'll plug them in the SciVis area in my talk.
It's actually more complicated than that. There are four things to getting the Banshee/V3 running:
1) An X server. Since people want to do 2D on these things. (Actually the X server provides some other support functions as well). I'm working on this now.
2) Glide. This talks to the hardware. This is just routine code messaging to make it run under Linux. A little assembly that needs to move between MASM and GAS.
3) X Server/Glide Integration. They have to cooperate in talking to the hardware. This is the XFree86-Rush extension slightly modified for the Banshee. Shouldn't take much work.
4)
The reason the Xi Graphics and Metro Link solutions help is that it gets a lot more boards supported. To do 3D well you really do need a 3D board. Xi supports several.
I'm doing a presentation at Linux World Conference and Expo on the state of 3D for Linux. At that presentation I'll be talking about the state of the free and comercial software. I'll also be presenting some benchmark results on a variety of boards and servers.
After the show is over I plan on putting my results up on my website.