You are correct that FBDev consists of graphics drivers in the kernel. However, there is no accelerated interface to be found for FBDev. Its as slow as a snail, unless you happen to have a matrox card. When I say fast 2D alpha blts, I mean hardware assisted. Not software read/modify/write style blts. I don't think there are any interfaces in Linux that can do that (other than X in some cases). And your assertion that more card will be supported in the future might not be true. I would LOVE for that to be the case, but Linus really doesn't seem to like the idea, and as long as everyone views X as good enough, there wont be any pressure to add support.
Your also right about the GGI. What I said was actualy about the KGI, which is "almost" a different project now. I use the GGI in about half my graphics code, the other half uses the SDL. I havn't picked a favorite yet though.:)
There are a couple major problems with letting X do all the graphics driver management, instead of placing minimal graphics support in the kernel.
The first issue is functionality. There is no standard way to write a graphics program under Linux currently that doesn't have to have X under it. This is a big problem for me and other graphics happy programmers. It turns out that X11 has a terrible interface for high speed graphics. Yes, there are a couple drivers here and there that can use the FBDev, but thats not accelerated. I want FAST 2D alpha BLTS under Linux. And I dont want to have X in my way.
The other problem is stability. I dont care how good X is, it still crashes, and when it does it takes the rest of the system down with it. Sure, if you have another computer handy you can telnet in and fix the problem, but thats hardly something to expect your mom to do. The basic problem is that a kernel should manage resources. Thats its only job. And the video card is a pretty big resource for a desktop computer. The idea that the kernel has no way of returning a video card to a usable state when a program tanks and leavs you in graphics mode is just dumb.
Now, dont get me wrong. I dont want to see X11 linked into the kernel. Thats just as stupid as having no drivers in the kernel. It is totaly possible to write device drivers where most of the device specific code is in User Space. And only a small portion of the device driver runs in the kernel. Just enough to make it SAFE. This is the direction that the GGI is/was heading. I say was there because I dont know if they are still with us. Its a real shame, they were doing some awsome work. I know I probably lost points with a bunch of readers by mentioning the GGI, but please think about what I have said, you might find that it makes sense.
Why care about features when performance is so low
on
GeForce3 and Linux
·
· Score: 1
I notice that alot of people are complaining that they cant get access to the features of the card under Linux. I would think that we should really get the performace up before we care about features. For instance, they didn't mention how fast it could do 2D blts, but I can tell you that its MUCH slower than on windows, so are most cards in Linux. How about reading back from the frame buffer? NVidia has been known to be really slow here.
Its amazing to me that people dont pay attention to 2D performance any more. I know alot of you are going to say that its good enough, and that X windows works just fine for you. But really, think about it, your wasting thousands, no millions of clock cycles waiting around for blts. And dont even think about getting hardware accelerated alpha transparent blts. I have been looking around for any support under Linux for that and it just dosn't exist.
I have read "Developing USB PC Peripherals" by Wooi Ming Tan and "USB Design by Example" by John Hyde. They both have lots of good info. I cant say whether or not its all correct because I have never used either to make a USB device, but they are pretty easy reads, and probably worth the time. Also you can look at Microchips site and Atmels site. They both make cheap microcontrolers with built in USB hardware. It's trivial to wire up too, a connector and a resistor.:) Happy hacking.
Actualy, they still have ISA support and its the bane of us OS programmers. ISA is alive and well in the south bridge. Dual PIC interrupt controlers, Real time clocks, serial, parallel, keyboard and mouse just to mention a few devices. They all run off the ISA bus. Blehhh..... I personaly want ISA to really go away. And I am also a hardware hacker who has used the ISA bus for random projects, so I am not discounting that utility. As far as I am concerned, USB all the way. You can use AVR or PIC microcontrolers to impliment a simple USB device and its great.:)
Re:So where does the information come from?
on
A Map to Nowhere?
·
· Score: 1
You may be correct, however I tend to think that people dont pay enough attention to emergent properties of itterated non-linear systems, of which growth is certainly one.
It is amazing the amount of information that can be "pulled from thin air". When in fact its not any information at all but just the manifestation of a simple itterated system. A great if overused example is the IFS Fern. I admit it dosn't exactly mimic its natural counterpart, but its quite a bit more complex "looking" than the set of three or four affine transforms that make it up.
Another piece of the puzzle comes from chaos theory, that (forgive me everyone) basicaly says that small changes in the initial conditions of chaotic systems result in drasticly different outcomes. So alot of the diversity we see in humans I would claim comes from our environment (nature vs. nurture). These (not so subtle) differences in our upbringing lead to very different people, even if they start as identical twins.
In reality, our makeup is a combination of both out genetic foundation and our environment as we grow up.
In conclusion, I claim that we are more complex than a copy of Windows, not because we start with more information, but because we learn as we age, and our mind changes with what we learn.
As many people will probably mention I didn't even scratch the surface of meme's and thier role.
I can give this a shot. My knowledge is not complete in this subject, but I know a bit. First of all, yes, you are correct that SRAM and CPU's use a simmilar components and DRAM's use capacitors for each memory cell. Thats why DRAM has to be refreshed every so often, the capacitors lose there charge (They are really small). In order to store one bit in and SRAM cell you need to have a feedback circuit consisting of a couple gates. Basically you need a flip-flop.
Now here is where I dont know exact numbers. There are all kinds of tricks once you are playing with the silicon that make circuits designed at that gate level smaller than they would be if you actualy made each gate and connected them together. There is a great example of a 2-to-1 Mux that can be made in quite a bit less space by using a pretty cute trick.
Anyway, you need a couple transistors to make this flip-flop (or whatever the SRAM cell is) and some connections (lets ignore the connections for now). So, lets say you need 8 transistors (random guess, couple for the actual bit of state, and some to enable reading and writing the data). Current CPU's are up to tens of millions of transistors (the thunderbird has something like 37 million transistors). Thats only 4 megabits of SRAM, or 512KBytes. This number is not right, you also have to take into account the fact that its MUCH easier to route signals in a RAM chip. So it might be off by and order of magnitude or two. But even if it is thats still not much RAM.
I hope that helps, and I hope I havn't completetly messed something up. Well, I am sure someone more knowledgable can correct me where I am wrong, and will.:)
Just point out that you will probably lose more than five customers if you spam 50,000. People really dont like spam, and your likely to lose more than you gain.
I dont have any numbers to back this up, but they probably dont have any for thier arguments either.
I think you might be beeing a bit restrictive. I will agree that what they have done is nothing new (but fun none the less), but a system such as this does scale well in theory. Sure the building blocks are macroscopic right now, but would you be making the same claim if their software was connected to a nano-assembler and it was spitting our enourmously complex objects out of only C, H, N, O...? All they would need to do is change thier physical model to account for atomic interaction. So yah, they would need a supercomputer (or at least a PSX2).
Someone else already posted mentioning Complexity theory, but I think it deserves reitteration. The concept of simple building blocks (functions in the case of fractals) generating wildly complex macroscopic structures really does apply here.
I will not say I am an expert on any of this, but I do have some background in the field, and have done some reasearch into evolving robots. I evolved a caterpillar robot in a physical simulation and then transfered the "brain" over to a hardware version that I constructed. Not self assembly I know, but I think it gives a bit of credability, even if my spelling dosn't.:)
I don't believe that these chips will be replacing the HC11 just yet. There is a very important feature that none of these have that the HC11 has. They don't have on-chip memory. I realize that they HC11 only has 2K of EEPROM, well the HC811E2 that is (I think thats the correct prefix). But that 2K was enough to impliment a preemptive multitasking "kernel" and basic interpreter to control my robots. I would LOVE to see one of these chips with a couple K, maybee only 16K (about the size of most of thier L1 caches), of onboard memory. Nothing beats the simplicity and ease of use of a chip that literaly requires a couple resistors, a crystal oscillator, and power to run. Thats what will keep the HC11 going. Oh yah, that and its got programmable I/O and A/D converters on-chip too.:)
EInk is actualy a fairly different technology. One more suited for the kind of things that everyone has been suggesting (Billboards, wallpaper, books...). It is static in that you only have to apply an electric field once and the pixel stays on (or off). It is also reflective (not specular, its just not emissive), and it has an extreamly high contrast (good for small fonts, like books). It is also kinda slow, and monochrome. You could do color about the same way that Seiko is doing it (RGB pixels). The ink itself is a bunch of small spheres that have a dark liquid in them and some white charged particles that can be pulled to one side of the sphere or the other. Thus, white or dark (whatever color is in the sphere). Well, I hope I have been informative and you don't think me a fool for my spelling and grammer.:)
It sure might. But not all the time. Cache is important too. Depending on what you are doing you may be in a tight computation loop that only accesses small sections of memory, or moves through memory in cache sized chunks. It sure would be nice to have main memory run at full speed, but its not really that practical. I would rather have a bit more cache and twice the execution units on my CPU.
I had been wondering about the image at every pixel and every pixel displaying a different color in every direction as well. I did some calculations given the order of magnitude numbers from Drexlers nanomanufacturing book (I can get you a reference if you like). He suggests that a 1000 Mips nanomechanical computer would take up only about 400 nm on a side, this is plenty small enough to sit next to a pixel on a display. And since it only draws around 60 nW there is no problem powering one at each pixel on the screen. Gota love nanotech. Oh there is the problem of transmitting light in each direction, I dont know exactly how that would work, but if you are ok with the display beeing a bit larger and the "LCD" (yah right) screens beeing a couple inches away from your eyes, then the angle that the display needs to work at is reduced considerably.
Almost forgot, you can then use the computer to raytrace or whatever you like into a scene description and come up with the correct light in each direction from that pixel.
Oh and I found my copy of Nanosystems, ISBN 0-471-57518-6 its by K. Eric Drexler, and its a pretty good book. I especialy like the beginning where he talkes about how different forces scale as you change in size by orders of magnitude. Its interesting to see how some forces just arent a consideration when you get smaller (or larger).
I cant confirm this, because I dont know where I got the information in the first place. Your brain has a mapping from parallax distance to focal length. That is it uses the parallax distance of an object to determine how to focus on it. With head mount displays "everything" is in focus (not just things at a given depth). There were some kids early on that were using this sort of technology (as part of a study or something) and after a while they lost that mapping (to some degree I am sure), and where unable to correctly focus on objects in the real world. One solution to this is to use gaze tracking to change the focal length of the image dynamicly, but I dont know if that would even work. I imagine you would need to have a sytem that can track the users gaze and change the focal length faster than a human can change the shape of the lense in thier eye. Unfortunately there are other such mappings that we dont have an understanding of and well have to find them out as well.
As a continuation, I had always thought that a solution could be doing depth of field in software and displaying the resultant image. You still need the gaze tracking hardware to figure out what the user is looking at and thus what depth should be in focus, but you wouldn't need the extra optical hardware, but now that I think about it this is of no use at all (well it would probably look pretty). The problem is that the blured image would still be completely in focus everyware. And once again, since your mind no longer has to keep track of focal lengths... disaster.
As to your question about the PSII being 128-bit, that depends on what part you are looking at. If you look at the bus to video memory its 2,560 bits wide. Internaly the system runs a 128-bit databus at 150 MHz though. The superscalar core runs at twice that speed (300 MHz) and its got gobs and gobs of other computational units. Everything from a MPEG macro-block decoder to multiple vector units (Think SIMD, that is G4, MMX, KNI...) This information comes from Microprocessor Report, April 19, 1999.
CPU Core: MIPS III, MIPS IV subset + 128b SIMD two 64-bit integer units and an FPU. 16K of scratch RAM, this is cool because its basicaly cache that you get to hand optimize.
The real power shows up in the Vector units Unit 0 has 4 FMAC's (Floating point multiply accumulate, a += b * c), and one Divider. The second Vector unit has 5 FMACS and 2 Dividers.
And of course everyone loves the 3.2 GBytes/second main memory bandwidth, and the 48 GBytes/second video memory bandwidth (remember those 2,560 bits of video memory data bus).
There are plenty more fun facts to be had, but I have gone way past your question...
I dont know but the release notes for 3.9.17 say they added support for the GeForce. That might just mean 2D or it could mean some DRI stuff, its not very clear.
Oh now thats just getting anoying, I know I was logged in when I started writing that post, but by the time I posted the message about the wavelets and what our retina does/. thought I was an AC... Hrumf.
Actualy there are O(N) multiplication algorithms. Take a look in Knuth Vol. 2 (Seminumeric Algorithms). Section 4.3.3 has an algorithm that does it in exactly N steps (not O(N)). It's really cool, its called a bit-serial-multiply and each bit only has to talk to its two neighbors at each step. It also starts clocking out an answer one clock cycle after you start clocking in the operands.
If I recall correctly, you have to structure your quantum algorithm so that the solutions to the problem enforce one another and the anti-solutions?? interfere. Exactly how this is done I am not sure.
Well, they are only seperate in name. The X server runs as root and has full access to the hardware on the system, it can even disable and enable interrupts whenever it likes. Thus, a bug in its low level driver code would be the same as a bug in the kernel. It could happily walk all over kernel data structures. Or even if the driver was ok and the code that called it was buggy and told it to DMA a chunk of video memory into kernel space, there would be nothing to stop it.
I dont know that Accelerated X is any better in terms of overall design. I imagine that they are still running as root and directly talking to the hardware. The only way to get a really stable server in my opinion would be to have the kernel in charge of the video system, just like any other resource. The folks over at GGI are doing this and have an X server that runs on thier video drivers.
I am fairly certain that Armor of God 2 and Operation Condor where the exact same movie, Operation Condor was just the US release. Armor of God one was better, but Drunken Master one is his beast (Who am I rates up there too.)
Hmm, not really, the wireless taser needs an atmosphere to ionize. None of that in space. Thus no conduction.
I just wonder how safe this is, they say "safe" levels of radiation, but if the station is in a non geosync orbit it will have to store its power and then dump it to the power station. So multiply the area of the collectors by the time it collects and divide by the time it actualy transmits energy to the earth and the width of the beam and I would guess you have a pretty powerfull beam. On the other hand the frequency of Microwaves that they use may be less dangerous to us. Interesting none the less.
Slashdot Mirror
You are correct that FBDev consists of graphics drivers in the kernel. However, there is no accelerated interface to be found for FBDev. Its as slow as a snail, unless you happen to have a matrox card. When I say fast 2D alpha blts, I mean hardware assisted. Not software read/modify/write style blts. I don't think there are any interfaces in Linux that can do that (other than X in some cases). And your assertion that more card will be supported in the future might not be true. I would LOVE for that to be the case, but Linus really doesn't seem to like the idea, and as long as everyone views X as good enough, there wont be any pressure to add support.
:)
Your also right about the GGI. What I said was actualy about the KGI, which is "almost" a different project now. I use the GGI in about half my graphics code, the other half uses the SDL. I havn't picked a favorite yet though.
Thanks for the good response.
There are a couple major problems with letting X do all the graphics driver management, instead of placing minimal graphics support in the kernel.
The first issue is functionality. There is no standard way to write a graphics program under Linux currently that doesn't have to have X under it. This is a big problem for me and other graphics happy programmers. It turns out that X11 has a terrible interface for high speed graphics. Yes, there are a couple drivers here and there that can use the FBDev, but thats not accelerated. I want FAST 2D alpha BLTS under Linux. And I dont want to have X in my way.
The other problem is stability. I dont care how good X is, it still crashes, and when it does it takes the rest of the system down with it. Sure, if you have another computer handy you can telnet in and fix the problem, but thats hardly something to expect your mom to do. The basic problem is that a kernel should manage resources. Thats its only job. And the video card is a pretty big resource for a desktop computer. The idea that the kernel has no way of returning a video card to a usable state when a program tanks and leavs you in graphics mode is just dumb.
Now, dont get me wrong. I dont want to see X11 linked into the kernel. Thats just as stupid as having no drivers in the kernel. It is totaly possible to write device drivers where most of the device specific code is in User Space. And only a small portion of the device driver runs in the kernel. Just enough to make it SAFE. This is the direction that the GGI is/was heading. I say was there because I dont know if they are still with us. Its a real shame, they were doing some awsome work. I know I probably lost points with a bunch of readers by mentioning the GGI, but please think about what I have said, you might find that it makes sense.
I notice that alot of people are complaining that they cant get access to the features of the card under Linux. I would think that we should really get the performace up before we care about features. For instance, they didn't mention how fast it could do 2D blts, but I can tell you that its MUCH slower than on windows, so are most cards in Linux. How about reading back from the frame buffer? NVidia has been known to be really slow here.
Its amazing to me that people dont pay attention to 2D performance any more. I know alot of you are going to say that its good enough, and that X windows works just fine for you. But really, think about it, your wasting thousands, no millions of clock cycles waiting around for blts. And dont even think about getting hardware accelerated alpha transparent blts. I have been looking around for any support under Linux for that and it just dosn't exist.
Well, thats enough ranting for me.
I have read "Developing USB PC Peripherals" by Wooi Ming Tan and "USB Design by Example" by John Hyde. They both have lots of good info. I cant say whether or not its all correct because I have never used either to make a USB device, but they are pretty easy reads, and probably worth the time. Also you can look at Microchips site and Atmels site. They both make cheap microcontrolers with built in USB hardware. It's trivial to wire up too, a connector and a resistor. :) Happy hacking.
Actualy, they still have ISA support and its the bane of us OS programmers. ISA is alive and well in the south bridge. Dual PIC interrupt controlers, Real time clocks, serial, parallel, keyboard and mouse just to mention a few devices. They all run off the ISA bus. Blehhh..... I personaly want ISA to really go away. And I am also a hardware hacker who has used the ISA bus for random projects, so I am not discounting that utility. As far as I am concerned, USB all the way. You can use AVR or PIC microcontrolers to impliment a simple USB device and its great. :)
You may be correct, however I tend to think that people dont pay enough attention to emergent properties of itterated non-linear systems, of which growth is certainly one.
It is amazing the amount of information that can be "pulled from thin air". When in fact its not any information at all but just the manifestation of a simple itterated system. A great if overused example is the IFS Fern. I admit it dosn't exactly mimic its natural counterpart, but its quite a bit more complex "looking" than the set of three or four affine transforms that make it up.
Another piece of the puzzle comes from chaos theory, that (forgive me everyone) basicaly says that small changes in the initial conditions of chaotic systems result in drasticly different outcomes. So alot of the diversity we see in humans I would claim comes from our environment (nature vs. nurture). These (not so subtle) differences in our upbringing lead to very different people, even if they start as identical twins.
In reality, our makeup is a combination of both out genetic foundation and our environment as we grow up.
In conclusion, I claim that we are more complex than a copy of Windows, not because we start with more information, but because we learn as we age, and our mind changes with what we learn.
As many people will probably mention I didn't even scratch the surface of meme's and thier role.
I can give this a shot. My knowledge is not complete in this subject, but I know a bit. First of all, yes, you are correct that SRAM and CPU's use a simmilar components and DRAM's use capacitors for each memory cell. Thats why DRAM has to be refreshed every so often, the capacitors lose there charge (They are really small). In order to store one bit in and SRAM cell you need to have a feedback circuit consisting of a couple gates. Basically you need a flip-flop.
:)
Now here is where I dont know exact numbers. There are all kinds of tricks once you are playing with the silicon that make circuits designed at that gate level smaller than they would be if you actualy made each gate and connected them together. There is a great example of a 2-to-1 Mux that can be made in quite a bit less space by using a pretty cute trick.
Anyway, you need a couple transistors to make this flip-flop (or whatever the SRAM cell is) and some connections (lets ignore the connections for now). So, lets say you need 8 transistors (random guess, couple for the actual bit of state, and some to enable reading and writing the data). Current CPU's are up to tens of millions of transistors (the thunderbird has something like 37 million transistors). Thats only 4 megabits of SRAM, or 512KBytes. This number is not right, you also have to take into account the fact that its MUCH easier to route signals in a RAM chip. So it might be off by and order of magnitude or two. But even if it is thats still not much RAM.
I hope that helps, and I hope I havn't completetly messed something up. Well, I am sure someone more knowledgable can correct me where I am wrong, and will.
Just point out that you will probably lose more than five customers if you spam 50,000. People really dont like spam, and your likely to lose more than you gain.
I dont have any numbers to back this up, but they probably dont have any for thier arguments either.
I think you might be beeing a bit restrictive. I will agree that what they have done is nothing new (but fun none the less), but a system such as this does scale well in theory. Sure the building blocks are macroscopic right now, but would you be making the same claim if their software was connected to a nano-assembler and it was spitting our enourmously complex objects out of only C, H, N, O...? All they would need to do is change thier physical model to account for atomic interaction. So yah, they would need a supercomputer (or at least a PSX2).
:)
Someone else already posted mentioning Complexity theory, but I think it deserves reitteration. The concept of simple building blocks (functions in the case of fractals) generating wildly complex macroscopic structures really does apply here.
I will not say I am an expert on any of this, but I do have some background in the field, and have done some reasearch into evolving robots. I evolved a caterpillar robot in a physical simulation and then transfered the "brain" over to a hardware version that I constructed. Not self assembly I know, but I think it gives a bit of credability, even if my spelling dosn't.
I don't believe that these chips will be replacing the HC11 just yet. There is a very important feature that none of these have that the HC11 has. They don't have on-chip memory. I realize that they HC11 only has 2K of EEPROM, well the HC811E2 that is (I think thats the correct prefix). But that 2K was enough to impliment a preemptive multitasking "kernel" and basic interpreter to control my robots. I would LOVE to see one of these chips with a couple K, maybee only 16K (about the size of most of thier L1 caches), of onboard memory. Nothing beats the simplicity and ease of use of a chip that literaly requires a couple resistors, a crystal oscillator, and power to run. Thats what will keep the HC11 going. Oh yah, that and its got programmable I/O and A/D converters on-chip too. :)
EInk is actualy a fairly different technology. One more suited for the kind of things that everyone has been suggesting (Billboards, wallpaper, books...). It is static in that you only have to apply an electric field once and the pixel stays on (or off). It is also reflective (not specular, its just not emissive), and it has an extreamly high contrast (good for small fonts, like books). It is also kinda slow, and monochrome. You could do color about the same way that Seiko is doing it (RGB pixels). The ink itself is a bunch of small spheres that have a dark liquid in them and some white charged particles that can be pulled to one side of the sphere or the other. Thus, white or dark (whatever color is in the sphere). Well, I hope I have been informative and you don't think me a fool for my spelling and grammer. :)
It sure might. But not all the time. Cache is important too. Depending on what you are doing you may be in a tight computation loop that only accesses small sections of memory, or moves through memory in cache sized chunks. It sure would be nice to have main memory run at full speed, but its not really that practical. I would rather have a bit more cache and twice the execution units on my CPU.
I had been wondering about the image at every pixel and every pixel displaying a different color in every direction as well. I did some calculations given the order of magnitude numbers from Drexlers nanomanufacturing book (I can get you a reference if you like). He suggests that a 1000 Mips nanomechanical computer would take up only about 400 nm on a side, this is plenty small enough to sit next to a pixel on a display. And since it only draws around 60 nW there is no problem powering one at each pixel on the screen. Gota love nanotech. Oh there is the problem of transmitting light in each direction, I dont know exactly how that would work, but if you are ok with the display beeing a bit larger and the "LCD" (yah right) screens beeing a couple inches away from your eyes, then the angle that the display needs to work at is reduced considerably.
Almost forgot, you can then use the computer to raytrace or whatever you like into a scene description and come up with the correct light in each direction from that pixel.
Oh and I found my copy of Nanosystems, ISBN 0-471-57518-6 its by K. Eric Drexler, and its a pretty good book. I especialy like the beginning where he talkes about how different forces scale as you change in size by orders of magnitude. Its interesting to see how some forces just arent a consideration when you get smaller (or larger).
I cant confirm this, because I dont know where I got the information in the first place. Your brain has a mapping from parallax distance to focal length. That is it uses the parallax distance of an object to determine how to focus on it. With head mount displays "everything" is in focus (not just things at a given depth). There were some kids early on that were using this sort of technology (as part of a study or something) and after a while they lost that mapping (to some degree I am sure), and where unable to correctly focus on objects in the real world. One solution to this is to use gaze tracking to change the focal length of the image dynamicly, but I dont know if that would even work. I imagine you would need to have a sytem that can track the users gaze and change the focal length faster than a human can change the shape of the lense in thier eye. Unfortunately there are other such mappings that we dont have an understanding of and well have to find them out as well.
As a continuation, I had always thought that a solution could be doing depth of field in software and displaying the resultant image. You still need the gaze tracking hardware to figure out what the user is looking at and thus what depth should be in focus, but you wouldn't need the extra optical hardware, but now that I think about it this is of no use at all (well it would probably look pretty). The problem is that the blured image would still be completely in focus everyware. And once again, since your mind no longer has to keep track of focal lengths... disaster.
As to your question about the PSII being 128-bit, that depends on what part you are looking at. If you look at the bus to video memory its 2,560 bits wide. Internaly the system runs a 128-bit databus at 150 MHz though. The superscalar core runs at twice that speed (300 MHz) and its got gobs and gobs of other computational units. Everything from a MPEG macro-block decoder to multiple vector units (Think SIMD, that is G4, MMX, KNI...) This information comes from Microprocessor Report, April 19, 1999.
CPU Core: MIPS III, MIPS IV subset + 128b SIMD
two 64-bit integer units and an FPU.
16K of scratch RAM, this is cool because its basicaly cache that you get to hand optimize.
The real power shows up in the Vector units Unit 0 has 4 FMAC's (Floating point multiply accumulate, a += b * c), and one Divider. The second Vector unit has 5 FMACS and 2 Dividers.
And of course everyone loves the 3.2 GBytes/second main memory bandwidth, and the 48 GBytes/second video memory bandwidth (remember those 2,560 bits of video memory data bus).
There are plenty more fun facts to be had, but I have gone way past your question...
I dont know but the release notes for 3.9.17 say they added support for the GeForce. That might just mean 2D or it could mean some DRI stuff, its not very clear.
Oh now thats just getting anoying, I know I was logged in when I started writing that post, but by the time I posted the message about the wavelets and what our retina does /. thought I was an AC... Hrumf.
Actualy there are O(N) multiplication algorithms. Take a look in Knuth Vol. 2 (Seminumeric Algorithms). Section 4.3.3 has an algorithm that does it in exactly N steps (not O(N)). It's really cool, its called a bit-serial-multiply and each bit only has to talk to its two neighbors at each step. It also starts clocking out an answer one clock cycle after you start clocking in the operands.
Thats anoying, I must have hit post anonymously or something. That was actualy posted by me, not an Anonymous Coward.
If I recall correctly, you have to structure your quantum algorithm so that the solutions to the problem enforce one another and the anti-solutions?? interfere. Exactly how this is done I am not sure.
Well, they are only seperate in name. The X server runs as root and has full access to the hardware on the system, it can even disable and enable interrupts whenever it likes. Thus, a bug in its low level driver code would be the same as a bug in the kernel. It could happily walk all over kernel data structures. Or even if the driver was ok and the code that called it was buggy and told it to DMA a chunk of video memory into kernel space, there would be nothing to stop it.
I dont know that Accelerated X is any better in terms of overall design. I imagine that they are still running as root and directly talking to the hardware. The only way to get a really stable server in my opinion would be to have the kernel in charge of the video system, just like any other resource. The folks over at GGI are doing this and have an X server that runs on thier video drivers.
I am fairly certain that Armor of God 2 and Operation Condor where the exact same movie, Operation Condor was just the US release. Armor of God one was better, but Drunken Master one is his beast (Who am I rates up there too.)
Hmm, not really, the wireless taser needs an atmosphere to ionize. None of that in space. Thus no conduction.
I just wonder how safe this is, they say "safe" levels of radiation, but if the station is in a non geosync orbit it will have to store its power and then dump it to the power station. So multiply the area of the collectors by the time it collects and divide by the time it actualy transmits energy to the earth and the width of the beam and I would guess you have a pretty powerfull beam. On the other hand the frequency of Microwaves that they use may be less dangerous to us. Interesting none the less.
You have to check out the developers section. Its pretty funny.