Yes this is definitely true. A few years ago I was an (almost) tournament-level Quake 2 player, and I definitely performed MUCH better with a 60fps system than a 30fps system.
One wrinkle that creeps in at high frame rates is synchronization with the monitor refresh. Typical monitors run 75-100Hz, and when the video card starts breaking into that range of frame rates, you can get bad stuttering effects where a few consective refreshes show different frames and then one refresh repeats a frame because the video card couldn't quite catch up. (or you can turn off "vsync" and get tearing instead of stuttering).
There is definitely a benefit to an "overpowered" graphics system that can deliver 200fps, because it gives extra headroom for when the action gets intense and the frame rate drops a bit. You might not notice a drop from 200-150fps but you will REALLY notice 60fps-30fps...
(John Carmack talks about this in a.plan from a few years ago, check the plan archives if you are interested)
The aic78xx driver is kind of a special case - ego conflicts and lapses in communication between Justin Gibbs (the driver author) and the rest of the Linux kernel crew have caused repeated problems with that driver. If nothing works try getting the latest aic78xx driver from Justin's site.
Of course, I understand the silliness of all this - why should Linus or Redhat let internal conflicts cause the quality of released drivers to suffer? Well, such is life in the free software world.
I think PRMan has two characteristics that reduce its memory usage below other renderers: first, the texture tile cache means that only a small, fixed amount of memory (well under 100MB) needs to be devoted to textures. Second, unless you are using raytracing PRMan does not need to keep all the finely-tesselated geometry in memory at once. (although AFAIK geometry is the limiting factor on memory in Pixar's scenes - due to PRMan's bucketing algorithm it does need to keep at least bounding boxes for the whole scene in memory).
Last SIGGRAPH a developer from Pixar hinted that they are working on a new architecture that "streams" all geometry through the pipeline without retaining any of it (sort of like modern OpenGL cards, or setting PRMan's bucket size so that the entire image is in one bucket). This kind of renderer would require only a constant (albeit large) amount of memory for the frame/Z buffer, regardless of scene complexity. It makes sense because future scenes will get more and more complex, but frame resolution seems to be holding steady (there are very few situations where you'd really need more than 4K or even 2K pixels, at least for the next few years...)
Well I know a bunch of people who have left California because of its strict gun laws, and I personally won't consider moving there unless both the gun laws and state/local taxes were moderated. Those are the same reasons why I'm leaving New York State in the near future...
Many video editing programs on Windows have trouble with >4GB (or >2GB) AVI files. There is an extension to the AVI file format that allows 64-bit file lengths, but not all Windows software supports it.
In fact, Apple's own Quicktime framework cannot handle >4GB AVI files on Windows!
I learned this the hard way when trying to compress a 6GB AVI file to Quicktime. The encoder did the worst thing possible - not only did it chop off the video as it went past the 4GB mark, it didn't give any kind of warning or error message either!
You might brag to them that the Linux DV system is much less likely to drop frames during FireWire capture or plaback (as long as you're using my dv1394 driver)... dv1394 is designed so that even if it drops a frame, which is unlikely with a properly-written player, the application can notify you immediately - so you can be sure your tapes come out looking good without having to check them over manually...
I'd say there is a fair chance this is just a typo... My guess is they were updating each browser-customized version of the main page, made a typo in the Opera version, and neglected to test it. (I doubt anyone at MS has Opera, anyway...).
As far as "deliberate attempt to destroy another's product", how about giving away IE for free:). Or that time they used a reserved field in the Kerberos protocol which broke compatibility with non-MS Kerberos software...
NT gurus correct me if I'm wrong, but I'm pretty sure "C$" is the default share for the C drive, just like any other SMB share. i.e. it's not doing anything magical with the filesystem, it's just a plain shared drive that happens to be called "C$"... (ever notice when you go to share a drive for the first time, it's always shared as C$ already? That's the default share)...
Don't quote me on this but I'm pretty sure modern Pentiums and Athlons already keep a cache of branches taken and use it to predict future branches...
The IA-64 instruction set embeds branch likelihood in the opcodes. You (or the compiler) can explicitly tell the CPU whether you think the branch is likely to be taken.
SSE gives the PIII and later a full set of eight explicitly-addressable floating-point registers (xmm0-xmm7). Although SSE is targeted towards SIMD code, you can certainly compile regular floating-point code for it. I'm pretty sure recent versions of GCC can do this already.
Right but the ownership of these industries still lies in US hands. The US is the world's leading supplier of entrepreneurship - which is not just an abstract concept, it has a concrete meaning - i.e. people willing to risk investing time and money with the expectation of future returns. Many of these overseas operations would not exist without US capital investment.
glibc 2.3 breaks static binaries. You read that right: some (not all) programs that were compiled statically with glibc 2.2 or earlier WILL NOT RUN on a system with glibc 2.3. Now THAT is breakage of the first class kind.
IMHO the correct solution is to freeze all APIs that enter common use. Once an API (say, "glibc 2.x" or "libstdc++ 2") escapes from development into the world at large, it should NEVER be changed in a way that is backwards-incompatible.
It is perfectly fine to start over again with a new API, just as long as it's named differently. If backwards-compatibility gets ugly, then you need to start a completely separate line of development (e.g. "glibc 3", "libstdc++ 3"). No monkeying around with sub-version numbers.
On most Linux systems if you 'ls/lib/libc*' you will see only one libc.so, which may (or may not!) be compatible with whatever other software you have. It's Russian roulette whether anything works at all, especially after you've upgraded different parts of the system. (e.g. on many distros you have to upgrade glibc and locales together, otherwise "bad things" happen...). What I would prefer to see in/lib is something like this:/lib/libc1.so.42/lib/libc2.so.19/lib/libc3.so.3
i.e. one distinct library for each API, which can be upgraded to fix bugs or add backwards-compatible features without ANY worry that existing software will break.
The root problem with glibc is that it includes too much stuff at different stages of development - e.g. malloc(), printf(), and friends are pretty much set in stone for the rest of time. But the pthread and DNS functions still change quite often. IMHO glibc needs to be split into several libraries, e.g. one for core stuff that will never change, like malloc and stdio, and one or more libraries for the unstable stuff like pthreads.
Don't even get me started on the very subtle and confusing interactions betwen pthreads, glibc, and gcc. The interfaces between these three systems have never been stabilized, so again it's Russian roulette when upgrading one of them - sometimes it works and sometimes BANG! all threaded software now crashes. Or all C++ software crashes. (both things have happened on my systems, I'm speaking from experience here...)
Distributing Linux software that uses C++ or pthreads without statically linking everything is asking for trouble. When was the last time you couldn't run a Windows program because it was missing the right C++ runtime library??
BTW, I give very high marks to the Debian maintainers for understanding all of this. Debian is the only Linux distro I consider safe enough that I can install or upgrade things without worry. Redhat is a complete farce, it's far worse than Windows in this regard.
I actually think OSS has the opposite problem - library developers are too willing to change the API. I am ok with cleaning up APIs, but only if you rename the library so old software continues to work. Some packages are smart enough to do this (and Debian enforces it even if the developers get it wrong), however LOTS of free software APIs break without warning. And the worst offenders are the core things like glibc and libstdc++! You can hardly upgrade one of those packages without upgrading practically everything else on your system. (the kernel does a really good job - you can pretty much drop in any kernel and everything will continue to work - the only incompatible change I can remember was modutils, I think)
Yes, sometimes proprietary APIs get pretty clunky for backwards-compatibility reasons (consider all the Win32 structs where you have to put the size of the struct in a member, to differentiate between different versions). But I'm a lot happier with Windows because I know I can upgrade most DLLs without worrying about the system breaking.
Thanks for the link... But do you know if it actually works? I am concerned about the odd resolutions of the Cinema displays (1920x1200 or 1680x1050). Since it's an LCD you need a video mode that exactly matches the pixel resolution and refresh rate the display wants... Windows display drivers tend not to be flexible in this regard (NVIDIA's recent drivers might work with some registry hacking though). With XFree I guess it might be made to work with the correct modeline.
The DVIator website doesn't actually state the details of how one might get it to work on a PC (understandable, since Apple might sue them...). So, I ask, has anyone actually done it?
Does anybody know if it is possible to drive one of these displays from a standard PC graphics card with a DVI output? Is there such a thing as a DVI-to-ADC adaptor?
I found a very interesting document on this problem (I REALLY wish I had the URL handy, sorry)... There ARE things you can do on your side that will avoid extreme latency when someone is downloading from your server.
The problem is that cable modem/DSL "capping" is implemented by the modem itself - internally it keeps a large buffer of outgoing packets, and only lets packets trickle out to the ISP at a predefined rate. You see horrible latency during uploads because your web browsing/game packets (which tend to be small) are stuck in the queue behind your upload packets (which tend to be large). i.e. the cable modem, through its buffering mechanism, introduces a delay of up to several seconds for outgoing packets.
The document I found described a way to solve this problem using a traffic shaper. If you can find out exactly what your bandwidth cap is, you can set up an IP traffic shaper (e.g. with the Linux packet filter/shaper code) to not release packets to the modem at a rate that will cause the internal queue to build up. By doing the capping "yourself," you give the network stack the feedback it needs to avoid extreme latency (e.g. by forcing the file server to block rather than continue transmitting packets that will only end up plugging the modem's queue). You can also set the packet shaper to prioritize UDP and "interactive" TCP traffic (i.e. games and ssh) higher than bulk TCP traffic (big downloads).
JWZ didn't realize that the majority of video codecs are not available under a free license (all common ones except for MPEG-1/2 I think). There are ways to use some of these codecs on Linux, but they involve either downloading non-redistributable binaries, or using reverse-engineered/patent infringing code (whose legality is questionable in the U.S.). This is why a default Redhat install doesn't easily let you play anything other than MPEG-1 or 2...
Also, the crappiness of RPM-based distros isn't Linux's fault, it's the fault of careless distributors. Move to Debian and you'll see a huge improvement.
I'm pretty sure PRMan, RDC, and 3Delight texture files *are* TIFFs. If you run 'tiffinfo' on them it spits out what looks like a list of mip-map tiles. (this works with the 'tiffinfo' from the standard libtiff distribution, not just the one included with PRMan). I have not actually tried to read pixels from one of these, but I bet it would work...
Running txmake doesn't bother me except sometimes it takes a loooong time...
Tiled TIFFs are used by PRMan and other RenderMan-type renderers to store texture maps. But there are very good reasons for this - mip-mapping and cache locality - and nobody edits the tiled files directly, they just work on a master non-tiled file and convert it to the tiled format before rendering.
Hi Mike, it's Dan Maas:). Totally agree - I am NOT excited about the current state of LCDs. What bothers me most is the refresh rates and phosphor persistence (or whatever the LCD term is) - I really prefer 100Hz over 85Hz, which is the fastest LCD I've seen. (yes I can tell the difference between an 85Hz display and a 100Hz display). Ghosting is just yucky, compared to the virtually instant response of a good CRT.
I am also a big fan of Sony's high-end CRTs. Unfortunately the one I'm using developed some kind of problem where it goes fuzzy from time to time, and it's never as sharp as when I first got it. It's out of warranty now so I suppose I'll have to get a new one at some point. (there's one good thing about LCDs - they drive down the prices of "old-fashioned" CRTs:)
It's been my opinion that if you really need tiles, you can always do it as an additional layer on top of the image file format. Rather than hacking tiles into the format (and all the complexity that involves), just store each image as a directory containing one tile per file.
I don't know about Shake but I know Nuke is completely scanline-oriented. Processing in scanlines makes sense because each line fits in the CPU cache, whereas an entire image does not. Performing repeated ops on a single scanline without leaving the cache is a huge performance win. I don't see as clear a benefit for tiling horizontally also, except in specialized cases where you are working on HUGE images (like that 40Kx20K Earth mosaic) or using lots of sub-regions of larger images.
I've been reading over the code - anyone who wants to study good C++ style should definitely check this out, even if you aren't interested in graphics! The ILM libraries make good use of templates, exceptions, operator overloading, and iostreams - in ways that are clear and easy to understand (as opposed to many other C++ libraries I've seen...). You'll have to look hard to find a more appropriate application of C++ features.
Slashdot Mirror
Aqsis is under active development. It works pretty well for standard things but is rather slow. Not sure about the other open-source efforts.
Yes this is definitely true. A few years ago I was an (almost) tournament-level Quake 2 player, and I definitely performed MUCH better with a 60fps system than a 30fps system.
.plan from a few years ago, check the plan archives if you are interested)
One wrinkle that creeps in at high frame rates is synchronization with the monitor refresh. Typical monitors run 75-100Hz, and when the video card starts breaking into that range of frame rates, you can get bad stuttering effects where a few consective refreshes show different frames and then one refresh repeats a frame because the video card couldn't quite catch up. (or you can turn off "vsync" and get tearing instead of stuttering).
There is definitely a benefit to an "overpowered" graphics system that can deliver 200fps, because it gives extra headroom for when the action gets intense and the frame rate drops a bit. You might not notice a drop from 200-150fps but you will REALLY notice 60fps-30fps...
(John Carmack talks about this in a
The aic78xx driver is kind of a special case - ego conflicts and lapses in communication between Justin Gibbs (the driver author) and the rest of the Linux kernel crew have caused repeated problems with that driver. If nothing works try getting the latest aic78xx driver from Justin's site.
Of course, I understand the silliness of all this - why should Linus or Redhat let internal conflicts cause the quality of released drivers to suffer? Well, such is life in the free software world.
I think PRMan has two characteristics that reduce its memory usage below other renderers: first, the texture tile cache means that only a small, fixed amount of memory (well under 100MB) needs to be devoted to textures. Second, unless you are using raytracing PRMan does not need to keep all the finely-tesselated geometry in memory at once. (although AFAIK geometry is the limiting factor on memory in Pixar's scenes - due to PRMan's bucketing algorithm it does need to keep at least bounding boxes for the whole scene in memory).
Last SIGGRAPH a developer from Pixar hinted that they are working on a new architecture that "streams" all geometry through the pipeline without retaining any of it (sort of like modern OpenGL cards, or setting PRMan's bucket size so that the entire image is in one bucket). This kind of renderer would require only a constant (albeit large) amount of memory for the frame/Z buffer, regardless of scene complexity. It makes sense because future scenes will get more and more complex, but frame resolution seems to be holding steady (there are very few situations where you'd really need more than 4K or even 2K pixels, at least for the next few years...)
Well I know a bunch of people who have left California because of its strict gun laws, and I personally won't consider moving there unless both the gun laws and state/local taxes were moderated. Those are the same reasons why I'm leaving New York State in the near future...
Many video editing programs on Windows have trouble with >4GB (or >2GB) AVI files. There is an extension to the AVI file format that allows 64-bit file lengths, but not all Windows software supports it.
In fact, Apple's own Quicktime framework cannot handle >4GB AVI files on Windows!
I learned this the hard way when trying to compress a 6GB AVI file to Quicktime. The encoder did the worst thing possible - not only did it chop off the video as it went past the 4GB mark, it didn't give any kind of warning or error message either!
You might brag to them that the Linux DV system is much less likely to drop frames during FireWire capture or plaback (as long as you're using my dv1394 driver)... dv1394 is designed so that even if it drops a frame, which is unlikely with a properly-written player, the application can notify you immediately - so you can be sure your tapes come out looking good without having to check them over manually...
I'd say there is a fair chance this is just a typo... My guess is they were updating each browser-customized version of the main page, made a typo in the Opera version, and neglected to test it. (I doubt anyone at MS has Opera, anyway...).
:). Or that time they used a reserved field in the Kerberos protocol which broke compatibility with non-MS Kerberos software...
As far as "deliberate attempt to destroy another's product", how about giving away IE for free
NT gurus correct me if I'm wrong, but I'm pretty sure "C$" is the default share for the C drive, just like any other SMB share. i.e. it's not doing anything magical with the filesystem, it's just a plain shared drive that happens to be called "C$"... (ever notice when you go to share a drive for the first time, it's always shared as C$ already? That's the default share)...
Don't quote me on this but I'm pretty sure modern Pentiums and Athlons already keep a cache of branches taken and use it to predict future branches...
The IA-64 instruction set embeds branch likelihood in the opcodes. You (or the compiler) can explicitly tell the CPU whether you think the branch is likely to be taken.
SSE gives the PIII and later a full set of eight explicitly-addressable floating-point registers (xmm0-xmm7). Although SSE is targeted towards SIMD code, you can certainly compile regular floating-point code for it. I'm pretty sure recent versions of GCC can do this already.
MP3.com has zillions of legally downloadable MP3s.
(however, redistributing them or spidering the website to gather the files might violate their TOS)
Right but the ownership of these industries still lies in US hands. The US is the world's leading supplier of entrepreneurship - which is not just an abstract concept, it has a concrete meaning - i.e. people willing to risk investing time and money with the expectation of future returns. Many of these overseas operations would not exist without US capital investment.
glibc 2.3 breaks static binaries. You read that right: some (not all) programs that were compiled statically with glibc 2.2 or earlier WILL NOT RUN on a system with glibc 2.3. Now THAT is breakage of the first class kind.
/lib/libc*' you will see only one libc.so, which may (or may not!) be compatible with whatever other software you have. It's Russian roulette whether anything works at all, especially after you've upgraded different parts of the system. (e.g. on many distros you have to upgrade glibc and locales together, otherwise "bad things" happen...). What I would prefer to see in /lib is something like this: /lib/libc1.so.42 /lib/libc2.so.19 /lib/libc3.so.3
IMHO the correct solution is to freeze all APIs that enter common use. Once an API (say, "glibc 2.x" or "libstdc++ 2") escapes from development into the world at large, it should NEVER be changed in a way that is backwards-incompatible.
It is perfectly fine to start over again with a new API, just as long as it's named differently. If backwards-compatibility gets ugly, then you need to start a completely separate line of development (e.g. "glibc 3", "libstdc++ 3"). No monkeying around with sub-version numbers.
On most Linux systems if you 'ls
i.e. one distinct library for each API, which can be upgraded to fix bugs or add backwards-compatible features without ANY worry that existing software will break.
The root problem with glibc is that it includes too much stuff at different stages of development - e.g. malloc(), printf(), and friends are pretty much set in stone for the rest of time. But the pthread and DNS functions still change quite often. IMHO glibc needs to be split into several libraries, e.g. one for core stuff that will never change, like malloc and stdio, and one or more libraries for the unstable stuff like pthreads.
Don't even get me started on the very subtle and confusing interactions betwen pthreads, glibc, and gcc. The interfaces between these three systems have never been stabilized, so again it's Russian roulette when upgrading one of them - sometimes it works and sometimes BANG! all threaded software now crashes. Or all C++ software crashes. (both things have happened on my systems, I'm speaking from experience here...)
Distributing Linux software that uses C++ or pthreads without statically linking everything is asking for trouble. When was the last time you couldn't run a Windows program because it was missing the right C++ runtime library??
BTW, I give very high marks to the Debian maintainers for understanding all of this. Debian is the only Linux distro I consider safe enough that I can install or upgrade things without worry. Redhat is a complete farce, it's far worse than Windows in this regard.
I actually think OSS has the opposite problem - library developers are too willing to change the API. I am ok with cleaning up APIs, but only if you rename the library so old software continues to work. Some packages are smart enough to do this (and Debian enforces it even if the developers get it wrong), however LOTS of free software APIs break without warning. And the worst offenders are the core things like glibc and libstdc++! You can hardly upgrade one of those packages without upgrading practically everything else on your system. (the kernel does a really good job - you can pretty much drop in any kernel and everything will continue to work - the only incompatible change I can remember was modutils, I think)
Yes, sometimes proprietary APIs get pretty clunky for backwards-compatibility reasons (consider all the Win32 structs where you have to put the size of the struct in a member, to differentiate between different versions). But I'm a lot happier with Windows because I know I can upgrade most DLLs without worrying about the system breaking.
The DVIator website doesn't actually state the details of how one might get it to work on a PC (understandable, since Apple might sue them...). So, I ask, has anyone actually done it?
Does anybody know if it is possible to drive one of these displays from a standard PC graphics card with a DVI output? Is there such a thing as a DVI-to-ADC adaptor?
I found the URL (or at least a similar one):
m ti ps/downup.html
http://homepage.ntlworld.com/robin.d.h.walker/c
And here's the Linux solution, a script that configures traffic shaping ("Wonder Shaper"):
http://lartc.org/wondershaper/
I found a very interesting document on this problem (I REALLY wish I had the URL handy, sorry)... There ARE things you can do on your side that will avoid extreme latency when someone is downloading from your server.
The problem is that cable modem/DSL "capping" is implemented by the modem itself - internally it keeps a large buffer of outgoing packets, and only lets packets trickle out to the ISP at a predefined rate. You see horrible latency during uploads because your web browsing/game packets (which tend to be small) are stuck in the queue behind your upload packets (which tend to be large). i.e. the cable modem, through its buffering mechanism, introduces a delay of up to several seconds for outgoing packets.
The document I found described a way to solve this problem using a traffic shaper. If you can find out exactly what your bandwidth cap is, you can set up an IP traffic shaper (e.g. with the Linux packet filter/shaper code) to not release packets to the modem at a rate that will cause the internal queue to build up. By doing the capping "yourself," you give the network stack the feedback it needs to avoid extreme latency (e.g. by forcing the file server to block rather than continue transmitting packets that will only end up plugging the modem's queue). You can also set the packet shaper to prioritize UDP and "interactive" TCP traffic (i.e. games and ssh) higher than bulk TCP traffic (big downloads).
Also, the crappiness of RPM-based distros isn't Linux's fault, it's the fault of careless distributors. Move to Debian and you'll see a huge improvement.
I'm pretty sure PRMan, RDC, and 3Delight texture files *are* TIFFs. If you run 'tiffinfo' on them it spits out what looks like a list of mip-map tiles. (this works with the 'tiffinfo' from the standard libtiff distribution, not just the one included with PRMan). I have not actually tried to read pixels from one of these, but I bet it would work...
Running txmake doesn't bother me except sometimes it takes a loooong time...
Tiled TIFFs are used by PRMan and other RenderMan-type renderers to store texture maps. But there are very good reasons for this - mip-mapping and cache locality - and nobody edits the tiled files directly, they just work on a master non-tiled file and convert it to the tiled format before rendering.
Hi Mike, it's Dan Maas :). Totally agree - I am NOT excited about the current state of LCDs. What bothers me most is the refresh rates and phosphor persistence (or whatever the LCD term is) - I really prefer 100Hz over 85Hz, which is the fastest LCD I've seen. (yes I can tell the difference between an 85Hz display and a 100Hz display). Ghosting is just yucky, compared to the virtually instant response of a good CRT.
:)
I am also a big fan of Sony's high-end CRTs. Unfortunately the one I'm using developed some kind of problem where it goes fuzzy from time to time, and it's never as sharp as when I first got it. It's out of warranty now so I suppose I'll have to get a new one at some point. (there's one good thing about LCDs - they drive down the prices of "old-fashioned" CRTs
It's been my opinion that if you really need tiles, you can always do it as an additional layer on top of the image file format. Rather than hacking tiles into the format (and all the complexity that involves), just store each image as a directory containing one tile per file.
I don't know about Shake but I know Nuke is completely scanline-oriented. Processing in scanlines makes sense because each line fits in the CPU cache, whereas an entire image does not. Performing repeated ops on a single scanline without leaving the cache is a huge performance win. I don't see as clear a benefit for tiling horizontally also, except in specialized cases where you are working on HUGE images (like that 40Kx20K Earth mosaic) or using lots of sub-regions of larger images.
I've been reading over the code - anyone who wants to study good C++ style should definitely check this out, even if you aren't interested in graphics! The ILM libraries make good use of templates, exceptions, operator overloading, and iostreams - in ways that are clear and easy to understand (as opposed to many other C++ libraries I've seen...). You'll have to look hard to find a more appropriate application of C++ features.