10 ms·

> What do they expect to get out of creating an API that is proprietary to their specific non-monopoly device, and that therefore very obviously nobody will eve

by adwn 6y ago

> What do they expect to get out of creating an API that is proprietary to their specific non-monopoly device, and that therefore very obviously nobody will ever actually use? You mean like Cuda, which is wildly successful, has a huge ecosystem, and which basically ensures you'll have to buy NVidia if you're serious about GPU computing?

derefr 6y ago
CUDA is, essentially, a B2B product-feature. A business is flexible when serving its own needs: if they want to do GPGPU computations, they can evaluate the alternatives and choose a platform/technology like CUDA to build on; and so choose to lock themselves into the particular GPUs that implement that technology. But that’s a choice they’re only making for themselves. They’re using those GPUs to compute something; they’re not forcing anyone else downstream of them to use those same GPUs to consume what they produce. The GPUs they’re using become part of their black box. Path shaders, on the other hand, would—at least as described in the article—be chiefly a B2C / end-user product-feature. They’d be something games/apps would rely on to draw 2D UI elements. But path shaders would need to be implemented† by the developers creating those games/apps. † (Yes, really, they would need to be implemented by the game/app developer, not game-engine framework devs. Path shaders are a low-level optimization, like Vulkan — something that is only advantageous to use when you use it directly to take advantage of its low-level semantics, rather than through a framework that tries to wrap it in some other, more traditional semantics. As with OpenGL, the ill-fitted abstractions of the traditional API were precisely what made it slow!) And those game/app developers, unlike the developers doing GPGPU computations, have to make a decision based on what devices their customers have, rather than what their own company can buy. (Or, if they think they have a “killer app”, they can try to force their customers to buy into the platform they built on. But most companies who think they’ve built a B2C killer app, haven’t.) For a B2B product-feature, a plurality position is fine. Even one forced to be permanent by patents. For a B2C product-feature, a plurality position by itself is fine, because rivals will just ship something similar and offer cross-support. But an indefinite plurality position is death. Compare, in the web ecosystem: • Features shipped originally in one renderer as “clean, standalone” ideas, e.g. -webkit-border-radius. These were cloned (-moz-border-radius, etc.) and then standardized (plain old border-radius.) • Features shipped in one renderer as implementations dependent on that renderer’s particular environment/ecosystem, e.g. IE’s ActiveX-based CSS “filter” stanza. Because of how they were implemented, these had no potential to ever be copied by rivals, so nobody outside of Microsoft bothered to use them on their sites, since they knew that only IE would render the results correctly, and IE at that point already had only a plurality position.

by adwn 6y ago

derefr 6y ago

CUDA is, essentially, a B2B product-feature. A business is flexible when serving its own needs: if they want to do GPGPU computations, they can evaluate the alternatives and choose a platform/technology like CUDA to build on; and so choose to lock themselves into the particular GPUs that implement that technology. But that’s a choice they’re only making for themselves. They’re using those GPUs to compute something; they’re not forcing anyone else downstream of them to use those same GPUs to consume what they produce. The GPUs they’re using become part of their black box. Path shaders, on the other hand, would—at least as described in the article—be chiefly a B2C / end-user product-feature. They’d be something games/apps would rely on to draw 2D UI elements. But path shaders would need to be implemented† by the developers creating those games/apps. † (Yes, really, they would need to be implemented by the game/app developer, not game-engine framework devs. Path shaders are a low-level optimization, like Vulkan — something that is only advantageous to use when you use it directly to take advantage of its low-level semantics, rather than through a framework that tries to wrap it in some other, more traditional semantics. As with OpenGL, the ill-fitted abstractions of the traditional API were precisely what made it slow!) And those game/app developers, unlike the developers doing GPGPU computations, have to make a decision based on what devices their customers have, rather than what their own company can buy. (Or, if they think they have a “killer app”, they can try to force their customers to buy into the platform they built on. But most companies who think they’ve built a B2C killer app, haven’t.) For a B2B product-feature, a plurality position is fine. Even one forced to be permanent by patents. For a B2C product-feature, a plurality position by itself is fine, because rivals will just ship something similar and offer cross-support. But an indefinite plurality position is death. Compare, in the web ecosystem: • Features shipped originally in one renderer as “clean, standalone” ideas, e.g. -webkit-border-radius. These were cloned (-moz-border-radius, etc.) and then standardized (plain old border-radius.) • Features shipped in one renderer as implementations dependent on that renderer’s particular environment/ecosystem, e.g. IE’s ActiveX-based CSS “filter” stanza. Because of how they were implemented, these had no potential to ever be copied by rivals, so nobody outside of Microsoft bothered to use them on their sites, since they knew that only IE would render the results correctly, and IE at that point already had only a plurality position.