Even if you put glass in front of it, this lets manufacturers of devices use the display in varying configurations with more or less curvature without needing a custom display solution. One company might use it flat, another highly curved, and they don't need expensive custom displays.
Boeing 787: Multiple fires out of 83 deployed vehicles. All fires happened without collision, one happened while vehicle was parked. Tesla Model S: One fire out of ~14,000 deployed vehicles. The fire happened due to a collision.
Yeah, I think Tesla's doing pretty well relative to Boeing here...
Are you saying it'll be twenty years before the spec sees the light of day, or before EME itself does? I might agree with you on the spec, but the spec isn't terribly relevant if most browsers have already implemented it.
And EME is Encrypted *MEDIA* Extensions. It works on the HTML media tag, for encrypting audio and video, not HTML. It has nothing to do with HTML, nothing to do with copying and pasting or saving text or documents.
Encrypted video support in browsers is going to happen, or rather already has happened since EME support is shipping in most browsers used today and is in active use on the web, whatever the W3C or Slashdot users think about it, because there is a huge amount of demand in the real world from users and content providers. If it's going to happen anyhow, shouldn't it at least be standardized?
Huh? EME is already supported in the shipping versions of Chrome and IE, with Safari coming soon, and is already in use in the real world by Netflix to deliver video to users of IE and ChromeOS. Firefox is the only major browser to have not implemented or begun implementing support for it, and with every other major browser supporting it, all that will accomplish is to marginalize Firefox amongst the average user. To them, the problem will be manifested as "Netflix doesn't work in Firefox".
Something like that, yes. But it was over a number of years, with a much larger number of employees (Valve has 300, Microsoft Entertainment and Devices Division most likely has something in the five figures), included R&D for a complete platform (Valve is leveraging a lot of existing stuff, more than Microsoft did using somewhat commodity hardware in the xbox), included selling the hardware at a loss (estimates are $125 per original xbox), and a large amount of first-party development (Valve does some games in house, but not to the extent Microsoft does).
Valve could probably afford to absorb those sorts of expenditures (five billion over five years), because they must have a pretty substantial amount of cash on hand at this point, but they haven't given any indications that they intend to sell Steam Machines at a loss (or even directly at all).
Estimates were that Steam had a total revenue of about a billion dollars in 2010, and Valve has been saying that Steam revenue has been growing at about 50% per year. That would put their 2013 revenue at somewhere between three to three and a half billion dollars. That's about half as much as Nintendo. Valve's cut is estimated to be 30-40%, and they likely don't have much in the way of costs (ironically because they aren't currently manufacturing hardware and have a tiny fraction as many employees as a company like Nintendo).
Valve could likely play with the console manufacturers in terms of marketing and subsidized hardware if they really wanted to.
Their specs indicate lower specific energy than lithium ion batteries, combined with a huge base unit. The end result is that you're going to end up with something that is heavier and bulkier than existing USB lithium ion batteries, making it just another gimmick.
I could see them having some success in much larger scale applications, though (like three orders of magnitude).
Re:"We believed we knew better what customers need
on
How BlackBerry Blew It
·
· Score: 3, Informative
Not sure if you're trying to be sarcastic and misunderstanding GP's meaning, or if you actually think the 5S's crazy high sales figures represent some sort of difficulty?
The basics of the first stage recovery were that it re-lit fine for re-entry, and re-lit for the deceleration burn, but developed a spin that exceeded the ability of the attitude control thrusters to counter, causing the fuel to be flung against the walls of the tank, starving the engine. It broke up on impact. SpaceX believes that the data gathered will be sufficient to solve the puzzle.
Sure, but a 10x performance increase beyond what you'd get by batching seems ridiculous to me. I'm not denying you're going to get extra performance and flexibility out of a lower-level API, but the AC who started this whole argument's claims that you'll see orders of magnitude greater performance don't fly.
And if you compare the MinnowBoard to the cost of a far more powerful NUC, it's not so cheap (the bare minnowboard costs more than an NUC with RAM and case and PSU).
Is it? A Celeron NUC looks to go for $177 at newegg, and the Minnowboard only has 1GB of RAM, which you can grab for the NUC for $17.99. That comes out as cheaper than a bare minnowboard, and the NUC includes the case and power supply to boot.
And this is why there are tons of ways to reduce draw calls using various batching techniques. Instancing, for example, or vertex buffers. If modern software drew every single piece of geometry or sprite or primitive using individual draw calls, then yeah, you'd see some massive speedups. But that's not what graphics engines are doing.
Here we are talking about performance factors that may be 10-100 times faster. A Mantle method could thus easily have a game running at unplayable frame rates if emulated under DirectX.
This statement is so mindbogglingly idiotic that it pretty much makes anything else you say meaningless by proving that you really have no idea what you're talking about. AMD claimed that MANTLE might enable up to nine times as many draw calls to be made per second under ideal circumstances, but draw calls are not that big a bottleneck. Thinking that somehow reduced overhead on draw calls could enable a one hundred fold performance increase on the same silicon that is today rather well utilized is akin to thinking that if you reduced the distance between cars on the highway, you could somehow increase the traffic capacity by one hundred times without increasing the speed of the cars.
So, you're convinced that the slight improvement in performance brought about by a reduction of software overhead is going to completely cripple nVidia? Yeah, sure.
Even if Mantle does produce faster performance (and there's no reason to doubt that it will), the advantages will be relatively small, and about all they might cause nVidia to do is adjust their pricing slightly. The won't be anything that you'll be able to accomplish with Mantle that wasn't possible without it, such is the nature of fully programmable graphics processors.
Game publishers, for their part, will hesitate to ignore the 53% of nVidia owners in favour of the 34% AMD owners. It's highly unlikely that this will cause a repeat of the situation caused by the Radeon 9700, which scooped a big win by essentially having DirectX 9 standardized around it. In that case, ATI managed to capture significant marketshare, but more because nVidia had no competitive products on the market for a year or two after. This time around, both companies have very comparable performance, and minor differences in performance usually just result in price adjustments.
You can compensate for the latency spikes somewhat by using a protocol without delivery guarantees and simply ignoring any packets that don't arrive quickly enough. You'd need to use an error-tolerant video stream, though. Perhaps some error correction, if you've got throughput to spare.
Of course, the solution to this could be as simple as Valve saying "streaming does not work over wireless".
Let's put it in context: BluRay has a maximum video bitrate of 40 Mbps. A typical modern home network runs at 1000 Mbps.
Even accounting for the lower efficiency of doing video encoding in real-time (modern GPUs all have dedicated hardware for this, even Intel's onboard graphics), that part isn't a problem.
If Valve was smart, they'd use an app-type approach, and then using something like XBMC could be as simple as choosing to use XBMC instead of the default app that Valve ships with. Similar to how I use Infuse for video playback on my iPhone instead of Apple's video player.
Except OnLive didn't use VNC, and the techniques used when targeting lossy 10 megabit internet connections is rather different than when targeting low-loss 1000 megabit home networks...
The WiiU, for all its flaws, uses miracast over 802.11n for the tablet thingy, with imperceptible latency (low enough to be perceptually instant, I think under 20ms is the accepted threshold for that, at least for VR). There's no reason that Valve shouldn't be able to accomplish latencies low enough to work for twitch gaming using wired gigabit ethernet.
The NUC would actually be great hardware for a mainly-streaming SteamBox, but the onboard graphics won't run much all that well. The best Intel iGPU (the Iris Pro 5200) is somewhere in between a GeForce 640 and 650 in terms of performance, so it's passable for low-detail 720p gaming, but not much more than that. It's not going to be a good gaming solution.
Now, something like the NUC with a discrete GPU shoved in there, that could be interesting.
Slashdot Mirror
Even if you put glass in front of it, this lets manufacturers of devices use the display in varying configurations with more or less curvature without needing a custom display solution. One company might use it flat, another highly curved, and they don't need expensive custom displays.
Boeing 787: Multiple fires out of 83 deployed vehicles. All fires happened without collision, one happened while vehicle was parked.
Tesla Model S: One fire out of ~14,000 deployed vehicles. The fire happened due to a collision.
Yeah, I think Tesla's doing pretty well relative to Boeing here...
Are you saying it'll be twenty years before the spec sees the light of day, or before EME itself does? I might agree with you on the spec, but the spec isn't terribly relevant if most browsers have already implemented it.
And EME is Encrypted *MEDIA* Extensions. It works on the HTML media tag, for encrypting audio and video, not HTML. It has nothing to do with HTML, nothing to do with copying and pasting or saving text or documents.
Encrypted video support in browsers is going to happen, or rather already has happened since EME support is shipping in most browsers used today and is in active use on the web, whatever the W3C or Slashdot users think about it, because there is a huge amount of demand in the real world from users and content providers. If it's going to happen anyhow, shouldn't it at least be standardized?
Huh? EME is already supported in the shipping versions of Chrome and IE, with Safari coming soon, and is already in use in the real world by Netflix to deliver video to users of IE and ChromeOS. Firefox is the only major browser to have not implemented or begun implementing support for it, and with every other major browser supporting it, all that will accomplish is to marginalize Firefox amongst the average user. To them, the problem will be manifested as "Netflix doesn't work in Firefox".
Something like that, yes. But it was over a number of years, with a much larger number of employees (Valve has 300, Microsoft Entertainment and Devices Division most likely has something in the five figures), included R&D for a complete platform (Valve is leveraging a lot of existing stuff, more than Microsoft did using somewhat commodity hardware in the xbox), included selling the hardware at a loss (estimates are $125 per original xbox), and a large amount of first-party development (Valve does some games in house, but not to the extent Microsoft does).
Valve could probably afford to absorb those sorts of expenditures (five billion over five years), because they must have a pretty substantial amount of cash on hand at this point, but they haven't given any indications that they intend to sell Steam Machines at a loss (or even directly at all).
Estimates were that Steam had a total revenue of about a billion dollars in 2010, and Valve has been saying that Steam revenue has been growing at about 50% per year. That would put their 2013 revenue at somewhere between three to three and a half billion dollars. That's about half as much as Nintendo. Valve's cut is estimated to be 30-40%, and they likely don't have much in the way of costs (ironically because they aren't currently manufacturing hardware and have a tiny fraction as many employees as a company like Nintendo).
Valve could likely play with the console manufacturers in terms of marketing and subsidized hardware if they really wanted to.
It doesn't look like they're refillable (these use a solid fuel that releases hydrogen gas when exposed to water, not a gas or liquid).
Their specs indicate lower specific energy than lithium ion batteries, combined with a huge base unit. The end result is that you're going to end up with something that is heavier and bulkier than existing USB lithium ion batteries, making it just another gimmick.
I could see them having some success in much larger scale applications, though (like three orders of magnitude).
Not sure if you're trying to be sarcastic and misunderstanding GP's meaning, or if you actually think the 5S's crazy high sales figures represent some sort of difficulty?
The basics of the first stage recovery were that it re-lit fine for re-entry, and re-lit for the deceleration burn, but developed a spin that exceeded the ability of the attitude control thrusters to counter, causing the fuel to be flung against the walls of the tank, starving the engine. It broke up on impact. SpaceX believes that the data gathered will be sufficient to solve the puzzle.
Sure, but a 10x performance increase beyond what you'd get by batching seems ridiculous to me. I'm not denying you're going to get extra performance and flexibility out of a lower-level API, but the AC who started this whole argument's claims that you'll see orders of magnitude greater performance don't fly.
And if you compare the MinnowBoard to the cost of a far more powerful NUC, it's not so cheap (the bare minnowboard costs more than an NUC with RAM and case and PSU).
Is it? A Celeron NUC looks to go for $177 at newegg, and the Minnowboard only has 1GB of RAM, which you can grab for the NUC for $17.99. That comes out as cheaper than a bare minnowboard, and the NUC includes the case and power supply to boot.
And this is why there are tons of ways to reduce draw calls using various batching techniques. Instancing, for example, or vertex buffers. If modern software drew every single piece of geometry or sprite or primitive using individual draw calls, then yeah, you'd see some massive speedups. But that's not what graphics engines are doing.
Here we are talking about performance factors that may be 10-100 times faster. A Mantle method could thus easily have a game running at unplayable frame rates if emulated under DirectX.
This statement is so mindbogglingly idiotic that it pretty much makes anything else you say meaningless by proving that you really have no idea what you're talking about. AMD claimed that MANTLE might enable up to nine times as many draw calls to be made per second under ideal circumstances, but draw calls are not that big a bottleneck. Thinking that somehow reduced overhead on draw calls could enable a one hundred fold performance increase on the same silicon that is today rather well utilized is akin to thinking that if you reduced the distance between cars on the highway, you could somehow increase the traffic capacity by one hundred times without increasing the speed of the cars.
So, you're convinced that the slight improvement in performance brought about by a reduction of software overhead is going to completely cripple nVidia? Yeah, sure.
Even if Mantle does produce faster performance (and there's no reason to doubt that it will), the advantages will be relatively small, and about all they might cause nVidia to do is adjust their pricing slightly. The won't be anything that you'll be able to accomplish with Mantle that wasn't possible without it, such is the nature of fully programmable graphics processors.
Game publishers, for their part, will hesitate to ignore the 53% of nVidia owners in favour of the 34% AMD owners. It's highly unlikely that this will cause a repeat of the situation caused by the Radeon 9700, which scooped a big win by essentially having DirectX 9 standardized around it. In that case, ATI managed to capture significant marketshare, but more because nVidia had no competitive products on the market for a year or two after. This time around, both companies have very comparable performance, and minor differences in performance usually just result in price adjustments.
It was at least half a decade before real-time 3D graphics were able to match Myst's pre-rendered ones.
You can compensate for the latency spikes somewhat by using a protocol without delivery guarantees and simply ignoring any packets that don't arrive quickly enough. You'd need to use an error-tolerant video stream, though. Perhaps some error correction, if you've got throughput to spare.
Of course, the solution to this could be as simple as Valve saying "streaming does not work over wireless".
Let's put it in context: BluRay has a maximum video bitrate of 40 Mbps. A typical modern home network runs at 1000 Mbps.
Even accounting for the lower efficiency of doing video encoding in real-time (modern GPUs all have dedicated hardware for this, even Intel's onboard graphics), that part isn't a problem.
If Valve was smart, they'd use an app-type approach, and then using something like XBMC could be as simple as choosing to use XBMC instead of the default app that Valve ships with. Similar to how I use Infuse for video playback on my iPhone instead of Apple's video player.
The PS4 is using OpenGL on FreeBSD, if memory serves. Doesn't seem like that big a leap from the PS4 to Linux.
Valve also charges a percentage for Steam sales.
Except OnLive didn't use VNC, and the techniques used when targeting lossy 10 megabit internet connections is rather different than when targeting low-loss 1000 megabit home networks...
The WiiU, for all its flaws, uses miracast over 802.11n for the tablet thingy, with imperceptible latency (low enough to be perceptually instant, I think under 20ms is the accepted threshold for that, at least for VR). There's no reason that Valve shouldn't be able to accomplish latencies low enough to work for twitch gaming using wired gigabit ethernet.
The NUC would actually be great hardware for a mainly-streaming SteamBox, but the onboard graphics won't run much all that well. The best Intel iGPU (the Iris Pro 5200) is somewhere in between a GeForce 640 and 650 in terms of performance, so it's passable for low-detail 720p gaming, but not much more than that. It's not going to be a good gaming solution.
Now, something like the NUC with a discrete GPU shoved in there, that could be interesting.