I remember when we all loved that video decoding was being offloaded to GPUs, or that real modems had become cheap enough that we could get away from "soft" modems. Aaah. You are talking about doing things in software on a generic CPU vs using dedicated ASICs for sound/graphics/modem/etc. TFA is talking about merging cpu and gpu silicon on a single core, not about implementing a gpu as software on a generic cpu.
For decades we've been moving things away from the CPU to separate, dedicated chipsets We have? Which parts of the MOS 6502 or MC68K are today handled by dedicated chips?
Cause a new PC would be so expensive? Yeah, I'm sure buying a new motherboard will be reeeeeal expensive compared to the cost of the first sticks of Racetrack RAM you buy.
Anyway, if people bothered to RTFA (hey, one can wish) they would see that they expect racetrack memory to first be used for storage - which means you will connect the stuff through sata/pci/pci-e or other existing buses. Using Racetrack as a replacement for RAM is in the 7year+ range.
It is quite obvious what the gp was hinting at, so answering "Turing Machine!" is firmly in the whoosh, missed the point, Mr. Obvious, no really?, duh, fail category.
Kinda sorta. Splitting rendering across multiple GPUS has afaict become much harder lately. GPUs used to be mostly fixed function pipelines, while the current generation has more in common with programmable stream processors (e.g., shader programs).
My first thought was: "NDS got geolocation support? Duh, that would be silly."
My second was: "Ah, so obvious - they just added a GPS to Netware servers. Now we won't have to trace the ethernet cable to find that 10 year old server that suddenly went down."
But I'm having trouble reconciling this with how, for example, a GPU doesn't run (generally) at the same clock as the CPU, and yet they (seem to) get along just fine.
That's because the CPU and GPU are not as tightly coupled, you have at the very least a PCI/PCI-E/AGP bus between them.
To do the same inside a single chip, you need to define a communications interface between the separate modules. It is really a cost/benefit thing, you will gain performance by having some parts of the chip running at a higher clock but you will have to spend transistors on implementing the interfaces.
High-gain antennas focus, sending that 1W in a more intense beam. FCC and equivalent regulators usually set limits on intensity and not on power.
In the US 2.4GHz point to multipoint (your typical access point) is limited is 36dBm EIRP. Which can be reached by f.ex. a 15dBm (30mW) radio and a 21dBi antenna or a 30dBm (1W) radio and a 6dBi antenna.
For point to point, the base limit is also 36dBm (30dBm radio, 6dBi antenna). But for every 3dB over the 6dBi antenna, you only need to subtract 1dB of input power. ex: 24dBi antenna, 24dBm radio.
However, it should be possible for someone who knows the chip interfaces related to this unlocking mechanism to work backwards from them and find where to tie things off to make the chip work.
From my quick glance a the paper it looks like they scatter a bunch of XOR gates around the chip in non-fastpath areas. Chip won't work correctly unless those gates are set correctly. Those settings are transmitted to the chip using some sort of pki.
Even if you identify all the XOR gates, you'd have to brute-force test all combinations. 2^64 can get expensive really fast, especially if you only have access to the masks and have to manufacture test-chips instead of running the brute-force in a software simulation.
Seems more bother to back-engineer a chip than to do it clean.
Semiconductor Inc. in the US designs a new flash memory chip. They license production to a fab in China. Fab pays licensing fees for 5 million chips. Fab produces 7 million chips, selling 2 million on the grey market. Alternatively, unfaithful employee of fab sells chip masks to other fab.
Anyway, reversing a blueprint isn't that straight forward. In terms of software, the blueprint is hand-tweaked machine code that you need to reverse to high level language source code. In case of generic components (ram, flash, etc), it is a lot more cost efficient to simply copy the masks ("blueprints") and make exact duplicates.
Trouble is, you need sufficient production volumes to get cheap mesh networking. Current consumer-level wireless chips (i.e., 802.11a/b/g/n) are less than well suited for mesh.
Personally I think it is because people don't have maps and uh I believe that our education like such as in South Africa and the Iraq everywhere like such as and I believe that they should our education over here in the U.S. should help the U.S. or should help South Africa and should help the Iraq and the Asian countries so we will be able to understand thermodynamics.
The *total input* of energy is 327-something Joules caused by the weight moving down and releasing its potential energy. You can never get more useful energy out than that. In fact, you can actually never get 100% efficient conversion from one to an other form of energy, but I digress.
That some of the energy is converted to heat due to friction does not mean that you have more energy, it means that some of that 327 Joules you start with has been turned into a form of energy (heat) that is rather hard to convert to useful kinds of energy like electricity or mechanical. It is in effect wasted energy. The 327 Joules minus what is wasted by friction/heat is then available for turning the motor that converts mechanical energy into electricity.
Dude, I got a perpetual motion bridge sitting at the Swiss seafront that I don't need. Wanna buy?
The energy that runs the generator comes from the potential energy released when the weights move down. Knowing mass, distance and gravity it is easy to calculate the total energy that will be released when the weight drops to the bottom of the shaft. ~327.8 Joules.
Divide by time, and you get how much energy is released each second. ~0.0228 Watts.
The spin won't make any additional energy (if that was the case, making a perpetual motion machine would be dead simple), at best it will just convert some of the energy to heat due to friction thus making the system less than 100% efficient. The entire system is powered by the weight falling. There is no other source of energy. The path the weight takes from top to bottom, or the motion of other parts of the system caused by the weight moving down does not in itself magick up more energy.
Slashdot Mirror
As for PCI, I doubt you'll find anything usable.
For AGP, the highest specced fanless card I can find on newegg is a 7600gs. Dunno if it is fast enough for FF XI, though.
Anyway, if people bothered to RTFA (hey, one can wish) they would see that they expect racetrack memory to first be used for storage - which means you will connect the stuff through sata/pci/pci-e or other existing buses. Using Racetrack as a replacement for RAM is in the 7year+ range.
Explaining an obvious joke should really be modded redundant.
It is quite obvious what the gp was hinting at, so answering "Turing Machine!" is firmly in the whoosh, missed the point, Mr. Obvious, no really?, duh, fail category.
"Lego Turing Machine" is fun/informative.
the weak link is always driver support
Kinda sorta. Splitting rendering across multiple GPUS has afaict become much harder lately. GPUs used to be mostly fixed function pipelines, while the current generation has more in common with programmable stream processors (e.g., shader programs).
My first thought was: "NDS got geolocation support? Duh, that would be silly."
My second was: "Ah, so obvious - they just added a GPS to Netware servers. Now we won't have to trace the ethernet cable to find that 10 year old server that suddenly went down."
But I'm having trouble reconciling this with how, for example, a GPU doesn't run (generally) at the same clock as the CPU, and yet they (seem to) get along just fine.
That's because the CPU and GPU are not as tightly coupled, you have at the very least a PCI/PCI-E/AGP bus between them.
To do the same inside a single chip, you need to define a communications interface between the separate modules. It is really a cost/benefit thing, you will gain performance by having some parts of the chip running at a higher clock but you will have to spend transistors on implementing the interfaces.
It employs many design concepts from *Nix that weren't present in 9X
VMS, surely?
High-gain antennas focus, sending that 1W in a more intense beam. FCC and equivalent regulators usually set limits on intensity and not on power.
In the US 2.4GHz point to multipoint (your typical access point) is limited is 36dBm EIRP. Which can be reached by f.ex. a 15dBm (30mW) radio and a 21dBi antenna or a 30dBm (1W) radio and a 6dBi antenna.
For point to point, the base limit is also 36dBm (30dBm radio, 6dBi antenna). But for every 3dB over the 6dBi antenna, you only need to subtract 1dB of input power. ex: 24dBi antenna, 24dBm radio.
He still does.
The issue is the native size of the screen
And changing to a non-native resolution fixes this how?
However, it should be possible for someone who knows the chip interfaces related to this unlocking mechanism to work backwards from them and find where to tie things off to make the chip work.
From my quick glance a the paper it looks like they scatter a bunch of XOR gates around the chip in non-fastpath areas. Chip won't work correctly unless those gates are set correctly. Those settings are transmitted to the chip using some sort of pki.
Even if you identify all the XOR gates, you'd have to brute-force test all combinations. 2^64 can get expensive really fast, especially if you only have access to the masks and have to manufacture test-chips instead of running the brute-force in a software simulation.
Seems more bother to back-engineer a chip than to do it clean.
Semiconductor Inc. in the US designs a new flash memory chip.
They license production to a fab in China.
Fab pays licensing fees for 5 million chips.
Fab produces 7 million chips, selling 2 million on the grey market. Alternatively, unfaithful employee of fab sells chip masks to other fab.
Anyway, reversing a blueprint isn't that straight forward. In terms of software, the blueprint is hand-tweaked machine code that you need to reverse to high level language source code. In case of generic components (ram, flash, etc), it is a lot more cost efficient to simply copy the masks ("blueprints") and make exact duplicates.
Trouble is, you need sufficient production volumes to get cheap mesh networking. Current consumer-level wireless chips (i.e., 802.11a/b/g/n) are less than well suited for mesh.
IOMMU
iPhone "most open"?
Huh? What country do you live in?
Hack into it?
You do know that in the developed world, most phones support installing 3rd party software without the need for hacks?
The compression goes way beyond gzip. It essentially pre-digests the webpages.
* Fast pipe.
* Always on.
* Get out of the way.
I saw that just after I clicked submit, curse the lack of edit.
You're right. watt = j/s, or newton*m/s.
Personally I think it is because people don't have maps and uh I believe that our education like such as in South Africa and the Iraq everywhere like such as and I believe that they should our education over here in the U.S. should help the U.S. or should help South Africa and should help the Iraq and the Asian countries so we will be able to understand thermodynamics.
Asleep when they covered thermodynamics?
The *total input* of energy is 327-something Joules caused by the weight moving down and releasing its potential energy. You can never get more useful energy out than that. In fact, you can actually never get 100% efficient conversion from one to an other form of energy, but I digress.
That some of the energy is converted to heat due to friction does not mean that you have more energy, it means that some of that 327 Joules you start with has been turned into a form of energy (heat) that is rather hard to convert to useful kinds of energy like electricity or mechanical. It is in effect wasted energy. The 327 Joules minus what is wasted by friction/heat is then available for turning the motor that converts mechanical energy into electricity.
Dude, I got a perpetual motion bridge sitting at the Swiss seafront that I don't need. Wanna buy?
The energy that runs the generator comes from the potential energy released when the weights move down. Knowing mass, distance and gravity it is easy to calculate the total energy that will be released when the weight drops to the bottom of the shaft. ~327.8 Joules.
Divide by time, and you get how much energy is released each second. ~0.0228 Watts.
The spin won't make any additional energy (if that was the case, making a perpetual motion machine would be dead simple), at best it will just convert some of the energy to heat due to friction thus making the system less than 100% efficient. The entire system is powered by the weight falling. There is no other source of energy. The path the weight takes from top to bottom, or the motion of other parts of the system caused by the weight moving down does not in itself magick up more energy.