Why should that make a difference? Unless you program it directly (and you don't, you use directx) this shouldn't matter at all. Remember, there are also PCs which use the same memory for the cpu and the video - obviously, nforce comes to mind - and these of course just run the same programs as do PCs which don't have shared memory.
Additionally look at the GeForce4 and the Radeon 8500. On paper the Radeon 8500 was superior, and yet the GF4 beat it in benchmarks consistently. Why? The drivers. They were more mature, better written, and streamlined
Now this is simply not true. First, the Radeon 8500 is not superior to the GF4 on paper, on paper it is almost the same. And the reason it is slower in practice is almost certainly not the drivers, rather design flaws of the chip. It's true initial drivers were slower, but the same is true for the GF4. Compare the R9000 to the R8500 (which use the same driver set, though of course it's not exactly the same binary) and the R9000 has not the slightest chance on paper - but in practice their performance is quite comparable. This strongly indicates the R8500 has some other problems beyond drivers.
What you said about trade secrets could be true however, even ATI doesn't want all their features exposed in an open-source driver (which is why the opernsource dri driver for the Radeon 8500 lacks hyper-z, support for pixel/vertex shaders).
mczak
The binary driver for the R8500 is indeed missing texture compression. However, ATI has a driver which does support s3tc since quite some time already, but it is not released yet - but don't ask me why. ATI also already demonstrated a 3d xfree/linux driver for the R9700 (they did a demo on it), but no release so far (and I haven't heard anything of a release plan neither).
The DRI people have some problems with supporting s3tc with the Radeon 7200/8500, but these are not technical problems, and they don't have anything to do with ATI - s3tc is covered by patents.
mczak
I'd agree, one hd per week or so could be a bit too expensive.
But how exactly is the tape going to help with virii? The virus will just be backed up by the tape as well as by another hd (this isn't true in case of a boot sector virus, but they are mostly a thing of the past).
mczak
ATI already has a linux/Xfree driver for the radeon 8500 / firegl 8700/8800 which supports compressed textures, however it's not yet released (check http://www.tommti-systems.de unfortunately links only work with session management on that site, so go to archive, and click the link for july - relevant message is on 23.07.2002.
The Weather Channel funded driver is also nice and can be downloaded from http://dri.sourceforge.net - but no texture compression because of patent issues:-(.
Surely "How much does this sound like the original?" is a better test than "Which sounds best?"
I agree. But the test indeed did work like the former. You were given the original.wav file and 7.wav files which were encoded (and decoded so you don't judge them by filename of course) with the different codecs. There was some "cheat" however, only 6 of those 7 files were actually run through an encoder/decoder, the 7th was identical to the original.
I can't remember what the instructions for the rating exactly were, but at least I did my ratings based on differences to the original. However, I was a bit disappointed by the choice of the 5-second samples. The first (Kylie Minogue) had so much flanger and things like that I could hardly hear anything - worst of all, it contained "mp3-artifacts" in the orginal! (Not "real" mp3 artifacts of course, but it exatly sounded like what you would expect from a too-low bitrate mp3 encoded file.). The second sample was some jazz stuff, not really my taste. The final sample was a classical piece (Verdi IIRC) which was IMHO not very well mastered (a bit unnatural) - but it was a good example to test if the codecs have sufficient channel separation (and Vorbis failed this test somewhat for me, it was easily distinguishable from the original, even though it did not "sound worse").
No, both results are perfectly correct - the difference is hardocp used DDR333 ram together with DDR333 FSB, and tomshardware used DDR333 ram together with DDR266 FSB. This just shows that to get the most out of fast ram, you need a fast FSB which has around the same bandwidth. The tomshardware link I used was just to show that the ram bandwidth throughput is indeed limited by the FSB bandwidth (you can't expect more than 2GB ram bandwidth throughput even if you'd use dual-channel DDR 400 memory system with a maximum bandwidth of 6.4GB/s).
The theoretical throughput rates of ddr (and also sdr) ram are far from only being theoretical. Every modern chipset is able to get around 95% of that value in practice easily (the famous SiSoft Sandra memory scores...). That 95% is only possible if you have consecutive memory accesses however, if you read random 8 Bytes blocks out of your 1GB, throughput will completely go down the toilet. So, maybe faster ram really does help somewhat, at least if the accesses are not consecutive. But it's easy to see faster ram won't help for peak throughput since it indeed will saturate the bus (almost) completely: http://www17.tomshardware.com/mainboa rd/02q1/02022 0/kt333-14.html (the ddr266 scores are on a different chipset unfortunately, but the KT266A is close enough to the KT333 to draw that conclusion).
nope, the original poster was (somewhat) correct. It's true the ram doesn't need to run at the same frequency than the FSB, but it doesn't help if it runs faster (DDR 333 ram has a bandwidth of 2.7GB, but the FSB at DDR 266 only 2.1GB). So, the FSB is not the bottleneck if you have DDR 266 ram, but it definitely is with DDR 333 ram. (There is an exception to the rule that higher-bandwidth-than-fsb ram won't do much for performance, this is if agp texturing is used, but this really only matters if you have an integrated graphics chipset.) That said, tests with the higher (333) FSB show decent, but not really large performance increases - the Athlon XP doesn't seem to be that much memory bandwidth limited today. I also disagree with the original poster about just using DDR 400. Not only a JEDEC specification for DDR 400 ram doesn't exist (and DDR 400 ram is needed to get really a performance improvement out of a DDR 400 FSB), but first boards which support such rams have some stability problems obviously at that speeds (the new asus kt400 board only allows one (!) dimm at DDR400 speed, and 2 at DDR333 speed). So, this would most likely be a nightmare for board manufacturers.
There is no way a driver update will help the GeForce 4 Ti to be able to compete with the R9700. First, there were already some driver releases since the GeForce 4Ti is out (usually you get only really a performance improvement from a driver upgrade if the card is really new, later on it's mostly bug fixing in drivers which don't help much performance, if at all).
Second, and more importantly, the difference is really too great - drivers might improve things by 10% in general, maybe 20%, but we're speaking about a 200% difference in a lot of situations between a Ti 4600 and a R9700.
That said, the next revision of Nvidia drivers (release 40!) is supposed to offer better anisotropic filtering performance, don't know if it's just a rumor, but even if it isn't it still won't catch up to the R9700.
he shift from GIF to JPEG was accelerated when CI$ wanted royalties for GIFs.
JPEG is no replacement for GIF. GIF is a lossless compressed image format (at least, if you don't count the color reduction you'd probably have to do), where JPEG uses lossy compression. GIF is very good in compressing diagrams and similar pictures, but won't compress "real" images very well. JPEG OTOH compresses things like photos very well (however, depending on the quality (compression) factor, with noticeable artifacts), but simple diagrams are not very well suited to that algorithm. There exists a replacement for GIF, this is PNG (and for animated GIFs, MNG). However, even now, IE6 still doesn't support PNG very well (no transparency, at least not in the way it is specified) and doesn't have a clue about MNG. So, you can't say that shift was fast - it still isn't completed.
The "shift" from GIF to JPEG was mainly because people wanted to use high-res photographs and such, which aren't really suited to the GIF compression algorithm - it has not much to do with legal issues.
It's a something between a Coppermine PIII and a Celeron. Coppermine PIII has 8-way 256KB cache, Coppermine Celeron 4-way 128KB cache. The X-Box CPU is a 733Mhz (133Mhz FSB) Coppermine CPU with 128KB 8-way cache. So, it's neither a PIII nor a Celeron (Desktop Celerons also don't come in 133Mhz FSB versions, but mobile Celerons do. Still, mobile Coppermine Celerons also have 128KB 4-way cache).
mczak
For that matter, no current processor has the fill rate necessary to comply with the Pixel Shader 2.0 specs
Are you sure of that? AFAIK there are no requirements at all about fill rate which must be satisfied to comply with ps 2.0 specs. You are probably refering to the 16 textures per pass which a chip must be able to do to be dx9 compliant, but this has nothing to do with fill rate. You can easily build a 100Mhz, single pipe, single TMU (must be able to do 16 loopbacks) GPU which is DX9 compliant with a paltry fillrate of 100MPixels/s (and also 100MTexels/s). mczak
I wouldn't call the sun jre "subpar". At that time, the ms "java" did have some improvements over the sun jre (mainly it had a JIT so it was faster), but it added some incompatible extensions plus it lacked some required (by the jvm definition) functionality (JNI, rmi). This was clearly not in sun's interest, so they sued ms and won - which didn't do any good either, since windows users just won't get a jre installed per default (or only a very outdated and incompatible one, compared to current sun's jre for the most part the ms jvm is just utter crap). But AFAIK nobody would prevent ms to supply the "real" jre to its customers - but, since this is a potential competitor of c# and their.NET strategy, they don't. IMHO, MS should be FORCED to supply the sun jre to its customers - even though this might not be in ms interests, I'm actually wondering why this wasn't considered as a penalty in the ms anti-trust cases? mczak
How do you know you're AGP-bandwidth limited? I doubt you can really exceed the bandwidth of agp 4x with current systems. After all, the triangles need to be processesd in the graphic card - graphic card manufacturers claim high poly throughput numbers, but in reality they are much lower. Plus, you need to take that triangle data from somewhere. If you take it from ram, you could in fact get more data than 2.1GB/s - but the scene would obviously be static. And can you really calculate 1M polygons (in a way that makes sense) on current cpus?
mczak
This is probably the wrong place to post it, but IE is my browser of choice. I don't like Opera's inability to render PRE tags to the right size and iffy javascript handling and I unfortunately don't have 20 hours to sit around to download Mozilla at 2k/sec on my modem.
Just a little math: if you really only get 2k/sec (even my old 28800bps modem does more than that!), the download is nowhere near 20 hours. A download of, say, IE6, is a lot larger (then again, you get half the OS with it, too). Mozilla 1.0rc3 talkback enabled full installer = 9.8MB. That's not even one and a half hour with the 2k/sec. And don't you download things like jre 1.4, which is about the same size?
I have to disagree. IE6 is certainly not the most W3C standards compliant browser. It does support CSS1 almost 100%, but CSS2 is a different story - Konqueror, Opera, IE5 Mac (!) and of course Mozilla do a lot better job of supporting CSS2 (but none of them is 100% CSS2 compliant - yet). IE6 for instance doesn't understand "position:fixed" (which you could use to implement navigation menues on web sites without having to use frames), CSS2 selectors are very limited, absolutely positioned elements can't have a relative height and so on. Of course, IE6 renders all pages out there just fine, but this is because the web pages are built so they work in IE, if you make a web site just with the w3c html and w3c css2 specifications in mind, chances are it won't display properly in IE6 (done that - and it didn't work in IE6, there were some issues in Opera6 and Konqueror3 too, but IE6 had the most problems).
> The only real advantage of ATA133 is to support drives >120GB.
Why does everybody believe this, even on/.? Someone (VIA, Maxtor ?) must have done a very good job of spreading misinformation. So, again:
ATA133 (aka "Fast Drive") has nothing at all to do with LBA-48bit addressing (aka "Big Drive").
Nobody will stop you from implementing a bios with lba-48bit support for an old udma33 controller.
Of course, you won't see any support for such old hardware, but today you are already able to use harddisks >128GB on a lot of boards with udma100 controllers. If you don't believe me, believe asus:
how big hds are supported on asus boards (sorry the link is in german, but the table almost only contains numbers).
I guess that should be "Statistisches" Bundesamt. Being a governmental organization, they might not be very dynamic, but to call them "static" is a bit unfair...
"gcc 3.0, the current so-called "stable" release (released quite some time after Red Hat released gcc 2.96-RH), fixes some problems, but introduces many others - for example, gcc 3.0.1 can't compile KDE 2.2 correctly due to bugs in gcc 3.0.x's implementation in multiple inheritance in C++. Until another set of 3.0.x updates is released, I still claim 2.96 is the best hot grits compiler yet."
I don't agree here with you. While gcc 2.96 may still have some advantages over 3.0.x, todays gcc 3.1 is better in every way: generates faster code (at least if you believe the people running speccpu all day long), even more c++ compliant (and yes, it has those bugs fixed which prevents the correct compilation of artsd from kde). Of course you can say that 3.1 isn't a release version - but neither is 2.96, so that's not a valid objection. gcc "2.96" might be (though I still have my doubts) the best compiler shipped in a distribution, since no distribution (that I'm aware of) uses gcc-3.0.x or a developer version of 3.1.
Slashdot Mirror
Why should that make a difference? Unless you program it directly (and you don't, you use directx) this shouldn't matter at all. Remember, there are also PCs which use the same memory for the cpu and the video - obviously, nforce comes to mind - and these of course just run the same programs as do PCs which don't have shared memory.
What you said about trade secrets could be true however, even ATI doesn't want all their features exposed in an open-source driver (which is why the opernsource dri driver for the Radeon 8500 lacks hyper-z, support for pixel/vertex shaders).
mczak
The binary driver for the R8500 is indeed missing texture compression. However, ATI has a driver which does support s3tc since quite some time already, but it is not released yet - but don't ask me why. ATI also already demonstrated a 3d xfree/linux driver for the R9700 (they did a demo on it), but no release so far (and I haven't heard anything of a release plan neither).
The DRI people have some problems with supporting s3tc with the Radeon 7200/8500, but these are not technical problems, and they don't have anything to do with ATI - s3tc is covered by patents. mczak
I'd agree, one hd per week or so could be a bit too expensive.
But how exactly is the tape going to help with virii? The virus will just be backed up by the tape as well as by another hd (this isn't true in case of a boot sector virus, but they are mostly a thing of the past).
mczak
ATI already has a linux/Xfree driver for the radeon 8500 / firegl 8700/8800 which supports compressed textures, however it's not yet released (check http://www.tommti-systems.de unfortunately links only work with session management on that site, so go to archive, and click the link for july - relevant message is on 23.07.2002.
:-(.
The Weather Channel funded driver is also nice and can be downloaded from http://dri.sourceforge.net - but no texture compression because of patent issues
mczak
I can't remember what the instructions for the rating exactly were, but at least I did my ratings based on differences to the original. However, I was a bit disappointed by the choice of the 5-second samples. The first (Kylie Minogue) had so much flanger and things like that I could hardly hear anything - worst of all, it contained "mp3-artifacts" in the orginal! (Not "real" mp3 artifacts of course, but it exatly sounded like what you would expect from a too-low bitrate mp3 encoded file.). The second sample was some jazz stuff, not really my taste. The final sample was a classical piece (Verdi IIRC) which was IMHO not very well mastered (a bit unnatural) - but it was a good example to test if the codecs have sufficient channel separation (and Vorbis failed this test somewhat for me, it was easily distinguishable from the original, even though it did not "sound worse").
mczak
No, both results are perfectly correct - the difference is hardocp used DDR333 ram together with DDR333 FSB, and tomshardware used DDR333 ram together with DDR266 FSB. This just shows that to get the most out of fast ram, you need a fast FSB which has around the same bandwidth. The tomshardware link I used was just to show that the ram bandwidth throughput is indeed limited by the FSB bandwidth (you can't expect more than 2GB ram bandwidth throughput even if you'd use dual-channel DDR 400 memory system with a maximum bandwidth of 6.4GB/s).
mczak
The theoretical throughput rates of ddr (and also sdr) ram are far from only being theoretical. Every modern chipset is able to get around 95% of that value in practice easily (the famous SiSoft Sandra memory scores...). That 95% is only possible if you have consecutive memory accesses however, if you read random 8 Bytes blocks out of your 1GB, throughput will completely go down the toilet. So, maybe faster ram really does help somewhat, at least if the accesses are not consecutive. But it's easy to see faster ram won't help for peak throughput since it indeed will saturate the bus (almost) completely:a rd/02q1/02022 0/kt333-14.html (the ddr266 scores are on a different chipset unfortunately, but the KT266A is close enough to the KT333 to draw that conclusion).
http://www17.tomshardware.com/mainbo
mczak
nope, the original poster was (somewhat) correct.
It's true the ram doesn't need to run at the same frequency than the FSB, but it doesn't help if it runs faster (DDR 333 ram has a bandwidth of 2.7GB, but the FSB at DDR 266 only 2.1GB). So, the FSB is not the bottleneck if you have DDR 266 ram, but it definitely is with DDR 333 ram. (There is an exception to the rule that higher-bandwidth-than-fsb ram won't do much for performance, this is if agp texturing is used, but this really only matters if you have an integrated graphics chipset.)
That said, tests with the higher (333) FSB show decent, but not really large performance increases - the Athlon XP doesn't seem to be that much memory bandwidth limited today.
I also disagree with the original poster about just using DDR 400. Not only a JEDEC specification for DDR 400 ram doesn't exist (and DDR 400 ram is needed to get really a performance improvement out of a DDR 400 FSB), but first boards which support such rams have some stability problems obviously at that speeds (the new asus kt400 board only allows one (!) dimm at DDR400 speed, and 2 at DDR333 speed). So, this would most likely be a nightmare for board manufacturers.
mczak
There is no way a driver update will help the GeForce 4 Ti to be able to compete with the R9700.
First, there were already some driver releases since the GeForce 4Ti is out (usually you get only really a performance improvement from a driver upgrade if the card is really new, later on it's mostly bug fixing in drivers which don't help much performance, if at all).
Second, and more importantly, the difference is really too great - drivers might improve things by 10% in general, maybe 20%, but we're speaking about a 200% difference in a lot of situations between a Ti 4600 and a R9700.
That said, the next revision of Nvidia drivers (release 40!) is supposed to offer better anisotropic filtering performance, don't know if it's just a rumor, but even if it isn't it still won't catch up to the R9700.
mczak
JPEG is no replacement for GIF. GIF is a lossless compressed image format (at least, if you don't count the color reduction you'd probably have to do), where JPEG uses lossy compression. GIF is very good in compressing diagrams and similar pictures, but won't compress "real" images very well. JPEG OTOH compresses things like photos very well (however, depending on the quality (compression) factor, with noticeable artifacts), but simple diagrams are not very well suited to that algorithm. There exists a replacement for GIF, this is PNG (and for animated GIFs, MNG). However, even now, IE6 still doesn't support PNG very well (no transparency, at least not in the way it is specified) and doesn't have a clue about MNG. So, you can't say that shift was fast - it still isn't completed.
The "shift" from GIF to JPEG was mainly because people wanted to use high-res photographs and such, which aren't really suited to the GIF compression algorithm - it has not much to do with legal issues.
mczak
It's a something between a Coppermine PIII and a Celeron. Coppermine PIII has 8-way 256KB cache, Coppermine Celeron 4-way 128KB cache. The X-Box CPU is a 733Mhz (133Mhz FSB) Coppermine CPU with 128KB 8-way cache. So, it's neither a PIII nor a Celeron (Desktop Celerons also don't come in 133Mhz FSB versions, but mobile Celerons do. Still, mobile Coppermine Celerons also have 128KB 4-way cache).
mczak
mczak
I wouldn't call the sun jre "subpar". At that time, the ms "java" did have some improvements over the sun jre (mainly it had a JIT so it was faster), but it added some incompatible extensions plus it lacked some required (by the jvm definition) functionality (JNI, rmi). This was clearly not in sun's interest, so they sued ms and won - which didn't do any good either, since windows users just won't get a jre installed per default (or only a very outdated and incompatible one, compared to current sun's jre for the most part the ms jvm is just utter crap). .NET strategy, they don't. IMHO, MS should be FORCED to supply the sun jre to its customers - even though this might not be in ms interests, I'm actually wondering why this wasn't considered as a penalty in the ms anti-trust cases?
But AFAIK nobody would prevent ms to supply the "real" jre to its customers - but, since this is a potential competitor of c# and their
mczak
How do you know you're AGP-bandwidth limited? I doubt you can really exceed the bandwidth of agp 4x with current systems. After all, the triangles need to be processesd in the graphic card - graphic card manufacturers claim high poly throughput numbers, but in reality they are much lower. Plus, you need to take that triangle data from somewhere. If you take it from ram, you could in fact get more data than 2.1GB/s - but the scene would obviously be static. And can you really calculate 1M polygons (in a way that makes sense) on current cpus? mczak
I have to disagree. IE6 is certainly not the most W3C standards compliant browser. It does support CSS1 almost 100%, but CSS2 is a different story - Konqueror, Opera, IE5 Mac (!) and of course Mozilla do a lot better job of supporting CSS2 (but none of them is 100% CSS2 compliant - yet). IE6 for instance doesn't understand "position:fixed" (which you could use to implement navigation menues on web sites without having to use frames), CSS2 selectors are very limited, absolutely positioned elements can't have a relative height and so on. Of course, IE6 renders all pages out there just fine, but this is because the web pages are built so they work in IE, if you make a web site just with the w3c html and w3c css2 specifications in mind, chances are it won't display properly in IE6 (done that - and it didn't work in IE6, there were some issues in Opera6 and Konqueror3 too, but IE6 had the most problems).
> The only real advantage of ATA133 is to support drives >120GB. /.? Someone (VIA, Maxtor ?) must have done a very good job of spreading misinformation. So, again:
ATA133 (aka "Fast Drive") has nothing at all to do with LBA-48bit addressing (aka "Big Drive").
Nobody will stop you from implementing a bios with lba-48bit support for an old udma33 controller.
Of course, you won't see any support for such old hardware, but today you are already able to use harddisks >128GB on a lot of boards with udma100 controllers. If you don't believe me, believe asus:
how big hds are supported on asus boards (sorry the link is in german, but the table almost only contains numbers).
Why does everybody believe this, even on
I guess that should be "Statistisches" Bundesamt. Being a governmental organization, they might not be very dynamic, but to call them "static" is a bit unfair...
I don't agree here with you. While gcc 2.96 may still have some advantages over 3.0.x, todays gcc 3.1 is better in every way: generates faster code (at least if you believe the people running speccpu all day long), even more c++ compliant (and yes, it has those bugs fixed which prevents the correct compilation of artsd from kde). Of course you can say that 3.1 isn't a release version - but neither is 2.96, so that's not a valid objection. gcc "2.96" might be (though I still have my doubts) the best compiler shipped in a distribution, since no distribution (that I'm aware of) uses gcc-3.0.x or a developer version of 3.1.