Hang on a sec. I think calling this a "marketing ploy" is going a little over the line. Two points about the triangle setup engine: it's not necessary to have the WARP triangle setup specs in order to get good 3d acceleration. You still get the rendering engine, after all, and it ain't half bad. But regardless, the WARP gives you about a 25% performance boost (J. Carmack's estimate, not mine), and Matrox has committed to helping the open-source driver developers use it. Considering their track record on promises to open-source folks, I'd say they're serious. On this one, let's wait a month or two and see what happens with the WARP -- my feeling (and the attitude on the GLX development list) is that Matrox will probably do what they say.
Sure, Nvidia released "already-written GPLed drivers", but a) they aren't fully finished, b) they didn't send the specs along with the drivers, and c) the Nvidia drivers were based on... the same GLX source base as the G200 drivers. Surprise.
As to your note on Matrox needing to have a faster card *and* releasing full specs... well, I don't want to get into a pissing contest here. But the result of having the card specs is that the *G200* is faster than any TNT(2)(Ultra) card under Linux right now -- the drivers are just better. So, if your only metric is Linux 3d (OpenGL) speed, then I would guess Matrox is a-okay: they've opened the specs on everything we could have asked for (as a public company, they would likely be liable and be sued for releasing specs on something as proprietary as the WARP... I'm amazed they were able to release the G2/400 specs, personally), and have committed to help us (which, notably, is the same response we have from Nvidia -- code and a committment to continue helping) on the small remaining parts. Furthermore, their G200 (not to mention the forthcoming G400) is arguably the fastest Linux 2d/3d combo accelerator at present. (The Voodoo2's still beat up on it in pure 3d performance.) I'm not running off to buy Matrox stock or anything, but in regards to their open-source community standings, I would say they're doing all the right things.
Seeing this message and your other anti-Matrox message, it looks like you've made the full transition from Matrox fan/Nvidia hater to Matrox hater/Nvidia fan. Might I suggest reserving religious commentary for something other than graphics cards?:) There are better things to get worked up about -- both of these companies have helped out 3D under Linux *tremendously*. Bashing Matrox here doesn't do anyone any good.
For those who weren't looking, Matrox released the G200 *specs* (minus the WARP setup engine, but more on that in a sec) a while back. After a few months of hacking by notables including John Carmack himself:), the G200 is pretty well supported in 3d under Linux.
1) I'm happy you bought an Nvidia card, and the release of a TNT(2)/Riva128 driver is a good thing. However, without the specs to the card, it's difficult to do major optimization and rework of the driver. The consequence of this is that right now the G200 (and that's 200, not 400 or 400MAX) is faster in 3d under Linux than *any* Nvidia card, including the TNT2 Ultra. It's a consequence of not being able to really re-work the drivers, plus the fact that the drivers haven't been out as long. I have no doubt that this will change in the near future:), but for the moment the lack of specs seems to hinder the Riva driver development. (My theory on why there are no specs is that... there simply are no easily-grok'd designed-for-a-third-party-to-write-a-driver specs, *anywhere* (including internally at Nvidia). Likely that Nvidia wrote a sample driver and gives that out with the chips for clients to customize... I'm doubting they send the chips out with a programming manual. Just like any good programmer, Nvidia has left comprehensive chip programming documentation as the last thing to do. =)
2) The G200/G400/G400MAX isn't even limited by the lack of the triangle setup engine. Having the WARP specs would give us a 25% increase in performance, assuming we could even saturate the card now. (But we can't, we only got asynchronous DMA in the last few days.) Soon -- as in, when we get a direct rendering interface in place -- the lack of the WARP will be a problem. But for now, it's not. And Matrox has committed to helping the open-source GLX drivers utilize the WARP, without releasing the specs on the device -- and this is fine. It would be a bit like Adaptec putting a developer on the task of helping the kernel SCSI guys develop a driver, without releasing all the details of chip operations -- the company does some legwork, and tells us how to integrate that proprietary microcode into our open-source driver. And thus, almost everyone is happy.
3) Chill. Stop bashing Matrox. They are so far the most progressive 3d hardware company out there, at least in terms of releasing programming information. Nvidia is right behind them, and that's a great thing -- neither chip is encumbered with something like Glide, and both give good performance. This is a choice between two *good* options, not a win/lose proposition.
Another option is to get an (admittedly dated) G200 board. The specs are open, the driver under Linux is rapidly maturing, and hey... you even get John Carmack hacking on the card drivers.:) I found one refurbished for $30 (no joke), and it works like a charm. It has all the 3d power I need right now, so... me, I'm happy.
I guess everyone missed the opening of the G200 3d specs a while back -- in any case, there are GLX drivers for the G200 under Linux. Now. Go to http://www.on.openprojects.net/glx and grab a binary. Watch the gears screensaver go *real* fast, or heck -- leave it running in the background on your desktop.:) In any case, you can certainly try out Q3test with your G200. (In fact, under Linux a G200 is faster than a TNT(2) right now because of driver maturity. Go figure.)
In a word: it won't suffer much. The optimizations for the two processors, in the sense of FPU pipelining issues, are almost identical.
The main thing "Intel optimizations" do is put FADDs (add) between FMULs (multiply), because you have to have an FADD after an FMUL (maybe two FADDs? I forget) to get reasonable FPU throughput on the P6-series of CPUs (Ppro, P2, P3, Celeron). This is because the two pipelines of the P6s can do an FADD and and FMUL in parallel... but can't do two FADDs simultaneously (for instance). The K7 structure is very similar, except for a few things: 1) fewer restrictions on what can execute simultaneously. 2) lower latency on complex (FDIV and FSQRT) instructions, and 3) FMUL (and FADD of course, in the other pipeline) can execute partially in parallel with an FDIV. All these mean that anything "Intel optimized" (for the P6) will run great on a K7. In fact, anything optimized for the P6 is already 75% optimized for a K7... the difference is that the ordering of FDIV relative to FMULs and FADDs is important in the K7, allowing for some further tuning if that's important to you.:)
Re:Some real-world benchmarks
on
K7 Benchmarking
·
· Score: 1
You know, I don't think we're going to get those kind of benchmarks until the K7 actually ships. (Hey AMD! Free publicity if you send me a K7!:) ANYway, barring that event, here's a way to estimate those performance metrics: base them on the P3 500, which someone around here just might have floating around. Conservatively, here's what I would guess, based on K7 being 6% faster integer and 35% faster than a *Xeon* at equivalent clocks:
Jpeg is mostly floating point, with some integer thrown in for good measure. I would say that a K7 500 can do... what, about 20% faster than a P3 500 on this? (Considering the K7 500 is almost 50% faster than a P3 500 in specfp95.)
MPEG encoding and seti@home are similar, except that SETI@home is a double-precision floating-point beast. As I understand it, the K7 is pipelined on double-precision, whereas the P3 is only partially pipelined. So, I would guess the K7 will wax the P3 at SETI@home, but I can't even guess by how much. MPEG encoding should (somewhat like JPEG) be about 20% faster, as a conservative estimate.
bzip2 is primarily an integer program, so it might be 10% faster in the processor... but as pointed out by someone else, compressing a 200M file is more of an I/O test than a processor test.:) [NB: the 128K L1 cache might make a big difference here. bzip2 definitely won't just fit into L1 on a K7, but if it has good cache locality then that could really help it here.]
You know the drill... your mileage may vary. I'm basically talking off the top of my head, but these should be educated guesses. One thing's for certain, we won't know any real numbers until someone gets their paws on a K7 system loaded with Linux and actually times these tests.
Consider the CPUs, though, too. I mean, a K6-3/450 is roughly equivalent in Mhz and L2 to a P2 Xeon 450. That doesn't make it suitable for the same tasks... same goes for K7 & P3. If the K7 at equivalent clock speeds is really 6% faster integer and 35% faster fp than a *Xeon*, then I'd be willing to pay about the same for a K7 500 as I would for a P3 (non-Xeon, now) 550 or 600 -- although I think AMD will price them somewhat lower than that, given their history. But that assumes that spec95 benchmarks really represent real life, and we all know that there's no perfect benchmark. (Spec95 ain't bad, but...)
It's what makes Debian... well, Debian. As a group that only makes a distribution (and doesn't care about income from CDs), they have more of an incentive for smooth online upgrades. And what a wonderful thing apt is (most of the time). Thank you, Jason Gunthorpe and Co.
anybody installed it on rh 5.2?
on
Java 2 on Linux
·
· Score: 1
I don't know the names of the RPMs, but Debian's "egcc" is egcs, and libstdc++ (as far as I know) is part of the egcs package, at least as it comes from Cygnus. As someone else has reported, this seems to already be in the Blackdown bug tracking system.
I am no Debian developer officially, but I think that's actually the recommended procedure. Part of the Debian packaging policy is to touch nothing in/usr/local, so... anything you do there is free and clear of dpkg/apt/dselect/Debian's control. I put local stuff there, and generally don't worry about it -- if I need a development package, I just install the -dev version of the Debian library. (Have -yet- to find a library that hasn't been packaged.:) The local stuff occasionally breaks on upgrades -- but again, that's not the package manager's fault... I did compile and install it, after all. Even using this strategy of just locally compiling applications, things break -very- infrequently. And, you'll never find a Debian-packaged app that depends on a library not packaged by Debian, so breakage the other way is an impossibility... provided you haven't mucked around with your dynamic linker setup... in which case, you know what you're doing, right?:)
This was actually a very well-informed article. Go NY Times. They even pointed out something about "free speech not free beer". Amazing what decent journalism can do.:)
I think it's more a commentary on the people who seem to use/advocate it most. I know that if I had to concisely describe Debian, I would describe it as a technically-focused distribution -- i.e. the goal is to do things right, not necessarily to do them in the flashiest or most bleeding-edge-trendy way. I think the sheer number of packages and the (relative) lack of advertising and marketing budget add to this effect. I would guess the other reason is the usual corporate fear -- "there's no company behind Debian" -- and this isn't a bad thing, because (with 0.9 probability:) there will be one eventually, at least in a support role. Support for Debian is great and is largely unnecessary -- but as can be seen from the Gartner report, that's not going to sway many PHBs.
Slashdot Mirror
Hang on a sec. I think calling this a "marketing ploy" is going a little over the line. Two points about the triangle setup engine: it's not necessary to have the WARP triangle setup specs in order to get good 3d acceleration. You still get the rendering engine, after all, and it ain't half bad. But regardless, the WARP gives you about a 25% performance boost (J. Carmack's estimate, not mine), and Matrox has committed to helping the open-source driver developers use it. Considering their track record on promises to open-source folks, I'd say they're serious. On this one, let's wait a month or two and see what happens with the WARP -- my feeling (and the attitude on the GLX development list) is that Matrox will probably do what they say.
... the same GLX source base as the G200 drivers. Surprise.
... well, I don't want to get into a pissing contest here. But the result of having the card specs is that the *G200* is faster than any TNT(2)(Ultra) card under Linux right now -- the drivers are just better. So, if your only metric is Linux 3d (OpenGL) speed, then I would guess Matrox is a-okay: they've opened the specs on everything we could have asked for (as a public company, they would likely be liable and be sued for releasing specs on something as proprietary as the WARP ... I'm amazed they were able to release the G2/400 specs, personally), and have committed to help us (which, notably, is the same response we have from Nvidia -- code and a committment to continue helping) on the small remaining parts. Furthermore, their G200 (not to mention the forthcoming G400) is arguably the fastest Linux 2d/3d combo accelerator at present. (The Voodoo2's still beat up on it in pure 3d performance.) I'm not running off to buy Matrox stock or anything, but in regards to their open-source community standings, I would say they're doing all the right things.
:) There are better things to get worked up about -- both of these companies have helped out 3D under Linux *tremendously*. Bashing Matrox here doesn't do anyone any good.
Sure, Nvidia released "already-written GPLed drivers", but a) they aren't fully finished, b) they didn't send the specs along with the drivers, and c) the Nvidia drivers were based on
As to your note on Matrox needing to have a faster card *and* releasing full specs
Seeing this message and your other anti-Matrox message, it looks like you've made the full transition from Matrox fan/Nvidia hater to Matrox hater/Nvidia fan. Might I suggest reserving religious commentary for something other than graphics cards?
For those who weren't looking, Matrox released the G200 *specs* (minus the WARP setup engine, but more on that in a sec) a while back. After a few months of hacking by notables including John Carmack himself :), the G200 is pretty well supported in 3d under Linux.
:), but for the moment the lack of specs seems to hinder the Riva driver development. (My theory on why there are no specs is that ... there simply are no easily-grok'd designed-for-a-third-party-to-write-a-driver specs, *anywhere* (including internally at Nvidia). Likely that Nvidia wrote a sample driver and gives that out with the chips for clients to customize ... I'm doubting they send the chips out with a programming manual. Just like any good programmer, Nvidia has left comprehensive chip programming documentation as the last thing to do. =)
1) I'm happy you bought an Nvidia card, and the release of a TNT(2)/Riva128 driver is a good thing. However, without the specs to the card, it's difficult to do major optimization and rework of the driver. The consequence of this is that right now the G200 (and that's 200, not 400 or 400MAX) is faster in 3d under Linux than *any* Nvidia card, including the TNT2 Ultra. It's a consequence of not being able to really re-work the drivers, plus the fact that the drivers haven't been out as long. I have no doubt that this will change in the near future
2) The G200/G400/G400MAX isn't even limited by the lack of the triangle setup engine. Having the WARP specs would give us a 25% increase in performance, assuming we could even saturate the card now. (But we can't, we only got asynchronous DMA in the last few days.) Soon -- as in, when we get a direct rendering interface in place -- the lack of the WARP will be a problem. But for now, it's not. And Matrox has committed to helping the open-source GLX drivers utilize the WARP, without releasing the specs on the device -- and this is fine. It would be a bit like Adaptec putting a developer on the task of helping the kernel SCSI guys develop a driver, without releasing all the details of chip operations -- the company does some legwork, and tells us how to integrate that proprietary microcode into our open-source driver. And thus, almost everyone is happy.
3) Chill. Stop bashing Matrox. They are so far the most progressive 3d hardware company out there, at least in terms of releasing programming information. Nvidia is right behind them, and that's a great thing -- neither chip is encumbered with something like Glide, and both give good performance. This is a choice between two *good* options, not a win/lose proposition.
Another option is to get an (admittedly dated) G200 board. The specs are open, the driver under Linux is rapidly maturing, and hey ... you even get John Carmack hacking on the card drivers. :) I found one refurbished for $30 (no joke), and it works like a charm. It has all the 3d power I need right now, so ... me, I'm happy.
I guess everyone missed the opening of the G200 3d specs a while back -- in any case, there are GLX drivers for the G200 under Linux. Now. Go to http://www.on.openprojects.net/glx and grab a binary. Watch the gears screensaver go *real* fast, or heck -- leave it running in the background on your desktop. :) In any case, you can certainly try out Q3test with your G200. (In fact, under Linux a G200 is faster than a TNT(2) right now because of driver maturity. Go figure.)
I stand corrected. I was going on "Jpeg in general involves lots of DCTs", and I think of those as floating-point. :)
In a word: it won't suffer much. The optimizations for the two processors, in the sense of FPU pipelining issues, are almost identical.
... but can't do two FADDs simultaneously (for instance). The K7 structure is very similar, except for a few things: 1) fewer restrictions on what can execute simultaneously. 2) lower latency on complex (FDIV and FSQRT) instructions, and 3) FMUL (and FADD of course, in the other pipeline) can execute partially in parallel with an FDIV. All these mean that anything "Intel optimized" (for the P6) will run great on a K7. In fact, anything optimized for the P6 is already 75% optimized for a K7 ... the difference is that the ordering of FDIV relative to FMULs and FADDs is important in the K7, allowing for some further tuning if that's important to you. :)
The main thing "Intel optimizations" do is put FADDs (add) between FMULs (multiply), because you have to have an FADD after an FMUL (maybe two FADDs? I forget) to get reasonable FPU throughput on the P6-series of CPUs (Ppro, P2, P3, Celeron). This is because the two pipelines of the P6s can do an FADD and and FMUL in parallel
You know the drill
Consider the CPUs, though, too. I mean, a K6-3/450 is roughly equivalent in Mhz and L2 to a P2 Xeon 450. That doesn't make it suitable for the same tasks ... same goes for K7 & P3. If the K7 at equivalent clock speeds is really 6% faster integer and 35% faster fp than a *Xeon*, then I'd be willing to pay about the same for a K7 500 as I would for a P3 (non-Xeon, now) 550 or 600 -- although I think AMD will price them somewhat lower than that, given their history. But that assumes that spec95 benchmarks really represent real life, and we all know that there's no perfect benchmark. (Spec95 ain't bad, but ...)
It's what makes Debian ... well, Debian. As a group that only makes a distribution (and doesn't care about income from CDs), they have more of an incentive for smooth online upgrades. And what a wonderful thing apt is (most of the time). Thank you, Jason Gunthorpe and Co.
I don't know the names of the RPMs, but Debian's "egcc" is egcs, and libstdc++ (as far as I know) is part of the egcs package, at least as it comes from Cygnus. As someone else has reported, this seems to already be in the Blackdown bug tracking system.
I am no Debian developer officially, but I think that's actually the recommended procedure. Part of the Debian packaging policy is to touch nothing in /usr/local, so ... anything you do there is free and clear of dpkg/apt/dselect/Debian's control. I put local stuff there, and generally don't worry about it -- if I need a development package, I just install the -dev version of the Debian library. (Have -yet- to find a library that hasn't been packaged. :) The local stuff occasionally breaks on upgrades -- but again, that's not the package manager's fault ... I did compile and install it, after all. Even using this strategy of just locally compiling applications, things break -very- infrequently. And, you'll never find a Debian-packaged app that depends on a library not packaged by Debian, so breakage the other way is an impossibility ... provided you haven't mucked around with your dynamic linker setup ... in which case, you know what you're doing, right? :)
There's a review on Anandtech, and there was another over on SharkyExtreme. They were both pretty positive.
This was actually a very well-informed article. Go NY Times. They even pointed out something about "free speech not free beer". Amazing what decent journalism can do. :)
I think it's more a commentary on the people who seem to use/advocate it most. I know that if I had to concisely describe Debian, I would describe it as a technically-focused distribution -- i.e. the goal is to do things right, not necessarily to do them in the flashiest or most bleeding-edge-trendy way. I think the sheer number of packages and the (relative) lack of advertising and marketing budget add to this effect. I would guess the other reason is the usual corporate fear -- "there's no company behind Debian" -- and this isn't a bad thing, because (with 0.9 probability :) there will be one eventually, at least in a support role. Support for Debian is great and is largely unnecessary -- but as can be seen from the Gartner report, that's not going to sway many PHBs.