Digging Deeper Into AMD's UVD Code Drop

[bridgman]

How do you enforce a price difference if the drivers for the different price points are all free and everything else is identical other than simple things like device IDs ?

If you can't enforce the price difference then your market segmentation is not effective.

[chithanh]

I gave the example of Digium already. Market segmentation is done by supporting Product 1 only in configuration A and Product 2 in configuration B. All with free software. Some users won't mind and enjoy their freedom. Others will insist on not losing vendor support.

[bridgman]

Digium doesn't seem to be doing market segmentation with software, in fact their web site specifically says that they do not. My question was how you maintain different price points for different market segments with the same underlying hardware, and I don't think Digium is an example of that.

[chithanh]

Digium sells Asterisk based VoIP gateway appliances (G100, G200) with support for a certain number of concurrent users. To my knowledge, this number is enforced even for SIP-to-SIP calls.

Edit: Maybe the example does not quite fit. But there free software is used for market segmentation here. By hacking the software you can achieve a higher number of concurrent calls that is otherwise reserved to the more expensive model.

If you want examples of identical hardware sold with different software at different price points, look no further than servers with bundled RHEL / RHEL AP. The software is free (as in speech), but if you choose to add AP features over the base version, you will lose manufacturer support.

[droidhacker]

Digium sells Asterisk based VoIP gateway appliances (G100, G200) with support for a certain number of concurrent users. To my knowledge, this number is enforced even for SIP-to-SIP calls.

Edit: Maybe the example does not quite fit. But there free software is used for market segmentation here. By hacking the software you can achieve a higher number of concurrent calls that is otherwise reserved to the more expensive model.

If you want examples of identical hardware sold with different software at different price points, look no further than servers with bundled RHEL / RHEL AP. The software is free (as in speech), but if you choose to add AP features over the base version, you will lose manufacturer support.

Your problem is that what is being sold, is neither software, nor hardware. RHEL sells *support*. Same probably with Digium. What support would you propose that AMD would be selling for GPU's? As I see it, end users really don't get any support to begin with, at least not from a contractual point of view, unless, of course, they subscribe to RHEL support (or similar). Then, of course, that support isn't provided by AMD, but by Red Hat.

[bridgman]

The boxes for different numbers of users seem to include significantly different hardware (eg memory/processor, redundant power supplies for largest unit etc..).

You need to buy a separate per-user subscription and if it expires then some of the software stops working (the part that is hosted through Digium) and the rest has its configuration frozen.

This doesn't sound at all like what you described, where hardware is the same and only software differences separate the different price/feature points.

[duby229]

I'm still a little confused as to what you guys are talking about. Years ago when R300 was still the shit and was kicking the GF4Ti around, I bought a R9500Pro. I bought it becuase someone figured out how to convert it into a 9700Pro. It simply required a solder point to be made and then the 9700Pro bios could be flashed to the card. It worked perfectly. After that it -was- a 9700Pro. Not too much later somebody figured out how to make a softmod that did more or less the same thing. (I also soldered rheostats to the voltage regulators so I could adjust core voltage and memory voltage. It was pretty cool stuff at the time)

It sounds to me like you guys are talking about something like the above, but making it official in the OSS driver. Obviously that is not something that AMD will ever endorse.

[bridgman]

AFAIK it's still a series of hypothetical scenarios trying to explain why binary microcode in ROM is OK but binary microcode in RAM is bad.

[nadro]

UVD support in open source drivers is big step forward. Thanks to AMD devs for do a great job.

BTW. Discussion about firmware is really funny. Bridgman is right, who cares where microcode is stored (software or hardware), just only a few peoples which think that every soft may be open source, but it's not true. Closed source software haters should look how many contributors from open source projects works at full time on closed source software, because those guys need money for their job. In current world both closed source and open source software has pros and cons. Without closed source software open source software can't exist, because too many programmers will be lose job, so those programmers will be not provide commits for open source projects too.

[curaga]

Let's run with your analogy for a minute anyways. Finance says you need an average $100K selling price to cover costs and make a small profit. Rather than selling a single model at $100,000 you sell the 4-speed version for $80,000 (with an appropriate final drive ratio) and the 5-speed for $120,000, appealing to two different groups of customers. I'm assuming equal per-model sales for simplicity.

All is well, except a group of people on a popular car forum think there's something wrong with the practice and that you should be forced to offer only a single model with all 5 speeds enabled, and assume they would get that model for $80,000. What do you tell them ?

The correct way would be to fit the 4-speed model with an engine that can only do 4 speeds, and then sell it at the $80k. I'm probably not good at car analogies :P