I agree with you in general terms, but the fact is that if the BBC was a for-profit business then Dirac would not be GPLd. They'd be working on a closed, DRMd movie player in order to help them securely sell access to their archive online. Instead they're developing a free-as-in-beer, free-as-in-money codec in order to facilitate free public access to their archive.
I have to say, I'm pretty happy with how they spend my TV license fee generally.
That's like saying that Medicare/Social Security aren't paid for by the government, but by US citizens. True in one sense, but pedantic and moronic, especially since the relationship is understood.
But not by you, evidently. Medicare and social security are paid for (and run by) the the US government. The BBC is paid for by a license fee which comes directly from TV owners.
If it was a government funded body then it might have thought twice about attacking the government over their made-up WMD/Iraq claims, so I reckon the distinction is quite significant. Does that make me a pedantic moron too?
OpenGL 2.0 isn't a 'wow' if you're looking for pretty pictures, but it's what's going to make most of the realtime-rendering 'wow' moments possible for the next 10-15 years.
Maybe it's less interesting if you're not a coder, but personally this has got me seriously stoked - it is a big, big, big step forward. Huge. Really.
I can't wait to get playing with this; I've been revisiting all those old papers I mentally flagged as 'not realtime friendly', and a big proportion of them suddenly become possible.
Anyway, if you think FSAA is a bigger wow than this then you know nothing about graphics coding...you can find the non-photorealistic 'wow' images you crave here.
2. If Crick et al had been made their discovery today, could they have patented it? or could you only patent the technology used to make the discovery?
Patent #29381823: Method for discovering the helical structure of DNA using wire coat-hangers and pingpong balls.
The point of homebrew games is that you can't compete on production-values, so you'd better compete on gameplay. Although there are, of course, exceptions.
who doesn't know of the socket handle leak that MS can't fix because otherwise they'd break 1000's of apps
My sympathy levels for Microsoft engineers skyrocketted after reading this and this, detailing the horrors they have to deal with in the name of compatability.
100k is indeed pretty cheap, especially considering that a lot of this gear was never available to buy and sell normally.
For example, I was under the impression that you can't buy PS2 devkits, only borrow them from Sony (and pay heavily for the privilege). I'm pretty sure you can't just sell them on...makes me wonder how he got hold of them in the first place.
It's not about "obsessively tweaking the finest details", it's about optimising a small amount of code and getting disproportionately large performance gains. What's wrong with that?
I have very fond memories of writing pentium-optimised asm...the rules were complicated enough to make things interesting, but still comprehensible.
Nowadays, the x86 ISA is just an API...god knows how the core actually executes instructions and in what order, which makes it very hard to optimise code beyond a certain point. You get more mileage from optimising memory access patterns and doing other such dull, dull, dull work. I get my asm coding fix elsewhere nowadays.
[...] This means that running code that doesn't fit in the internal 96kbyte SRAM of the player is very inefficient, both in terms of CPU cycles and power. MP3 and AAC just about squeeze into the internal memory (one at a time, obviously!), but anything that didn't would result in a big power hit - my guess is 30-40%+.
Surely only code in external RAM would incur this hit. Vorbis decoders spend most of their time doing discrete cosine transforms, which would easily fit into 96K. As would a lot of other performance-critical routines, I'd imagine. So we're talking about a 40% hit on 5% of execution time, which seems pretty trivial, right? Or am I missing something?
You get way more mileage out of choosing an appropriate algorithm, e.g., an O(n log n) sort instead of O(n^2), than out of tweaking the code.
True, but that's pretty irrelevant here since the algorithm in the article is inherently O(n).
As for your 3 golden rules, perhaps you should investigate a recent innovation called 'modularisation'.
Anyway, a properly written TGA decoder will spend pretty much all of it's time waiting around for IO, so a much more realistic optimisation would be to address that by using a format with better compression like PNG.
Please explain to me why a dedicated rendering device from NVidia would be any better than your average UNIX or Linux machine?
Why do you think 3D hardware exists at all, when all it's doing is a load of integer maths? Surely a Linux machine is capable of adding numbers together, right? Obviously, dedicated hardware is faster, sh*tloads faster. Durr. The benefits to the artist's equivalent of the compile-edit-debug cycle are fairly obvious here, and worth rejigging the production pipeline to accomodate.
Anyway, you can bet nVidia has a Gelato-based Renderman implementation in the pipeline. nVidia's long-term goals were always 1. OpenGL in hardware (done) and then 2. Renderman in hardware.
So you can dump tons of data to the GPU but you can't get the data back for further processing fast enough, which defeats the purpose.
Fast enough for what exactly? What purpose does that defeat?
Compared to the cost of (eg) sending a frame across a LAN, the time taken to pull a frame across the bus would be utterly, utterly insignificant.
Slashdot Mirror
Yup.
I don't get why it makes a huge difference. Can you provide an example?
Certainly looks like it.
I agree with you in general terms, but the fact is that if the BBC was a for-profit business then Dirac would not be GPLd. They'd be working on a closed, DRMd movie player in order to help them securely sell access to their archive online. Instead they're developing a free-as-in-beer, free-as-in-money codec in order to facilitate free public access to their archive.
I have to say, I'm pretty happy with how they spend my TV license fee generally.
They've explicitly allow relicensing under the LGPL too.
That's like saying that Medicare/Social Security aren't paid for by the government, but by US citizens. True in one sense, but pedantic and moronic, especially since the relationship is understood.
But not by you, evidently. Medicare and social security are paid for (and run by) the the US government. The BBC is paid for by a license fee which comes directly from TV owners.
If it was a government funded body then it might have thought twice about attacking the government over their made-up WMD/Iraq claims, so I reckon the distinction is quite significant. Does that make me a pedantic moron too?
/mod me off topic if you want
Redundant also.
OpenGL 2.0 isn't a 'wow' if you're looking for pretty pictures, but it's what's going to make most of the realtime-rendering 'wow' moments possible for the next 10-15 years.
Maybe it's less interesting if you're not a coder, but personally this has got me seriously stoked - it is a big, big, big step forward. Huge. Really.
I can't wait to get playing with this; I've been revisiting all those old papers I mentally flagged as 'not realtime friendly', and a big proportion of them suddenly become possible.
Anyway, if you think FSAA is a bigger wow than this then you know nothing about graphics coding...you can find the non-photorealistic 'wow' images you crave here.
2. If Crick et al had been made their discovery today, could they have patented it?
or could you only patent the technology used to make the discovery?
Patent #29381823: Method for discovering the helical structure of DNA using wire coat-hangers and pingpong balls.
Not sure about that one.
Yeah, but my Windows popcorn maker's got a big, shiny on/off button instead of a command prompt.
Some details on Q3A's use of SMP:
1st attempt
2nd attempt
Just think how much more you'd get paid if you could match brackets.
The point of homebrew games is that you can't compete on production-values, so you'd better compete on gameplay. Although there are, of course, exceptions.
who doesn't know of the socket handle leak that MS can't fix because otherwise they'd break 1000's of apps
My sympathy levels for Microsoft engineers skyrocketted after reading this and this, detailing the horrors they have to deal with in the name of compatability.
100k is indeed pretty cheap, especially considering that a lot of this gear was never available to buy and sell normally.
For example, I was under the impression that you can't buy PS2 devkits, only borrow them from Sony (and pay heavily for the privilege). I'm pretty sure you can't just sell them on...makes me wonder how he got hold of them in the first place.
It's not about "obsessively tweaking the finest details", it's about optimising a small amount of code and getting disproportionately large performance gains. What's wrong with that?
I have very fond memories of writing pentium-optimised asm...the rules were complicated enough to make things interesting, but still comprehensible.
Nowadays, the x86 ISA is just an API...god knows how the core actually executes instructions and in what order, which makes it very hard to optimise code beyond a certain point. You get more mileage from optimising memory access patterns and doing other such dull, dull, dull work. I get my asm coding fix elsewhere nowadays.
The stories been dead for a day or two so I'm probably talking to myself here, but anyway...
1) I can't seem to find this 100k of data. All I see is ~8k of sin/cos tables. Are we're looking at different versions of tremor?
2) Regardless of that, yes, I was talking about code and not data. As was the original article, as far as i can tell.
'mdct.c' from tremor (an integer vorbis decoder) compiles to...[tappity-tap]...6808 bytes of code on MIPS.
[...] This means that running code that doesn't fit in the internal 96kbyte SRAM of the player is very inefficient, both in terms of CPU cycles and power. MP3 and AAC just about squeeze into the internal memory (one at a time, obviously!), but anything that didn't would result in a big power hit - my guess is 30-40%+.
Surely only code in external RAM would incur this hit. Vorbis decoders spend most of their time doing discrete cosine transforms, which would easily fit into 96K. As would a lot of other performance-critical routines, I'd imagine. So we're talking about a 40% hit on 5% of execution time, which seems pretty trivial, right? Or am I missing something?
Something similar was discussed and rejected by Linus on LKML.
Read the original thread, pointed to by several posters.
Are there a lot of overzealous gay rights activist moderators today?
"Homophobia is bad!"
Well, durr...
You get way more mileage out of choosing an appropriate algorithm, e.g., an O(n log n) sort instead of O(n^2), than out of tweaking the code.
True, but that's pretty irrelevant here since the algorithm in the article is inherently O(n). As for your 3 golden rules, perhaps you should investigate a recent innovation called 'modularisation'.
Anyway, a properly written TGA decoder will spend pretty much all of it's time waiting around for IO, so a much more realistic optimisation would be to address that by using a format with better compression like PNG.
Please explain to me why a dedicated rendering device from NVidia would be any better than your average UNIX or Linux machine?
Why do you think 3D hardware exists at all, when all it's doing is a load of integer maths? Surely a Linux machine is capable of adding numbers together, right? Obviously, dedicated hardware is faster, sh*tloads faster. Durr. The benefits to the artist's equivalent of the compile-edit-debug cycle are fairly obvious here, and worth rejigging the production pipeline to accomodate.
Anyway, you can bet nVidia has a Gelato-based Renderman implementation in the pipeline. nVidia's long-term goals were always 1. OpenGL in hardware (done) and then 2. Renderman in hardware.
So you can dump tons of data to the GPU but you can't get the data back for further processing fast enough, which defeats the purpose.
Fast enough for what exactly? What purpose does that defeat?
Compared to the cost of (eg) sending a frame across a LAN, the time taken to pull a frame across the bus would be utterly, utterly insignificant.