2/27/2009

02-27-09 - Why is Intel selling me Software -

Intel used to do a pretty good thing where they would write nice like optimized widgets for their chips and give them out as source code to developers for free. Obviously that makes a lot of sense in their business, it sells more chips.

Now they want to charge me for the optimized math routines !? WTF Intel !? And even if I buy it, I don't get source code, I just get DLLs. Not just DLLs, a HUGE MESS of DLLs - 118 of them taking 283 Mega bytes !

Granted, the "IPP" does a whole lot of stuff. It's got jpeg, H264, MDCT, MP3, hell it's got CELP, BWT, it's got like every damn thing in the universe, but it's all useless because it's not cross-platform, it's not source code, and it's a huge complex system.

Give me little isolated code snippets that just do the one thing I want to steal. Don't force giant systems on me.

I want a good little nugget of *functionality* , not a framework. I have my own framework.


I've been thinking about this a lot recently because to some extent the way I'm writing Oodle right now it's becoming a framework. I think it's becoming pretty good, it's getting to be pretty easy to make really cool stuff happen, but nobody wants to buy a framework. Nobody wants to have to buy into a "system" that will make their life easier - they want to have their own framework and just call you for the little bit of hard stuff they don't want to bother with. I need to make sure Oodle does that.

The danger for me is that I really like writing framework code. The way I like to code, I build up a huge base of really strong fundamentals into a whole system that does everything I want, and then I can just easily tack bits together to make application functionality. So maybe 90% of the code is "library" or "framework" and the glue and application is minimized.

Like to do my new vert snapper for galaxy it was like - I already have my hash map, I already have my int geometry quantizer, boom tack it together, it's like 20 lines of code. That's awesome, but to share that code you have to buy into my framework - if you try to pull just the vert snapper, you find that it's got roots that go deep into the earth of the framework and cling onto the vector, the int vector, the int-float math, the hash map, the std::vector, my template util set, etc etc you probably wind up with 20 files.

I wish you could sell mesh algorithms. Just looking back at Galaxy to do the BMP triangle removal makes me miss it; the algorithms are really complex and interesting, the results are concrete and compelling, and there's so much more to do. I just don't see how to make it a product. Like for example a really good UV mapper I think would be a great product, it's hard to do, it doesn't really exist, and everyone needs it. But they don't know they need it.

4 comments:

castano said...

You could make a product that requires a UV mapper instead. For example, a light mapper. It seems that illuminate labs doesn't seem to have trouble selling theirs. Computing the lighting is fun on its own, but parameterizing the lightmaps in such a way that minimizes texture use while avoiding seams is a much more challenging problem.

cbloom said...

Yeah, I'd love to do a light mapper. I think there's a lot of interesting work to do in that domain. (signal-specialized parameterization and whatnot ; synthesis from photon casting, denoising, etc.)

BTW I saw the NVidia ray caster was announced publicly. That seems like a very nice utility.

castano said...

Yeah, I'd like to write a small raytracer myself. It will probably be one of my next free time projects.

The IRT API is very promising, we integrated it into our baker tool about a year ago, and were getting good speedups on G80 vs. the latest Core2 Duo. It was however very unstable.

I don't want to recommend it very highly until I revisit that code again and get some accurate performance numbers, though.

castano said...

Ugh, I meant "small lightmapper", instead of "small raytracer".

old rants