|
|
Subscribe / Log in / New account

The perils of federated protocols

The perils of federated protocols

Posted May 20, 2016 8:28 UTC (Fri) by niner (subscriber, #26151)
In reply to: The perils of federated protocols by khim
Parent article: The perils of federated protocols

Odd, I cann use WebGL, WebRTC and HTTP/2 just fine while I can use neither Metal nor Vulkan right now. Your examples seem to express the opposite of what you intended.


to post comments

The perils of federated protocols

Posted May 22, 2016 16:54 UTC (Sun) by jospoortvliet (guest, #33164) [Link] (6 responses)

I guess the point parent wanted to make is that while webGL, WEBRTC etc are already very old they still don't work everywhere while Vulkan, not more than a year old, is announced to be supported almost everywhere. I agree with you that doesn't mean it IS. Time will tell if it will go as expected...

The perils of federated protocols

Posted May 22, 2016 17:35 UTC (Sun) by flussence (guest, #85566) [Link] (5 responses)

I remember all the hand-wavy hype about GPGPU and OpenCL when AMD opened up all the R600 hardware docs. Ten years later, still no sign of it ever becoming usable. One day Vulkan might work, but I'm not holding my breath for it.

The perils of federated protocols

Posted May 22, 2016 19:34 UTC (Sun) by mathstuf (subscriber, #69389) [Link]

I've done some OpenCL on R600 hardware. It works, but is not complete by any means. This was probably 2.5-3 years ago now.

The perils of federated protocols

Posted May 23, 2016 14:16 UTC (Mon) by khim (subscriber, #9252) [Link] (3 responses)

Ten years later, still no sign of it ever becoming usable.

Define “usable”, please. All the HPC is built today around GPGPU and similar architectures (things like Xeon Phi, it's used on your mobile phone (to process photos in real-time and do other compute-intensive things) and so on.

The fact that Linux distros (and desktop in general) are no longer in the center of this development is unfortunate (especially since lots of development is based on Linux), but it does not mean that all that development have just stopped and disappeared.

One day Vulkan might work, but I'm not holding my breath for it.

Vulkan works today (although not that many apps use it), Metal is used by real apps, too (look here - there are links to appstore where they could be found). Sure, you couldn't use it on your device if your insist on 100% OS but most users out there don't care and use it just fine.

And while WebGL is usable today don't forget that we are talking about technology which is almost two decades old (DirectX was released in 1996 and OpenGL is even older then that).

Sure, you could counter that other unfederated APIs (things like Glade, e.g.) have died—but there are emulators and people still play these games.

My point was that most platforms had 3D by the end of XX century while Web needed another decade before it got it and, ironically enough, exactly when web finally, finally, arrived on that decade-old platform the rest of the world already moved and shifted to significantly different 3D API! When would web have things like Metal, Renderscript or Metal? My guess is: most likely answer is “never”—and if Android will, indeed, arrive on desktop even WebGL and WebRTC could become unavailable eventually (since people would use native apps instead of webapps for things like videocalls or maps)—although that is not guaranteed, freeze a-la SMTP is more likely.

The perils of federated protocols

Posted May 23, 2016 15:52 UTC (Mon) by pizza (subscriber, #46) [Link]

> Define “usable”, please. All the HPC is built today around GPGPU and similar architectures (things like Xeon Phi, it's used on your mobile phone (to process photos in real-time and do other compute-intensive things) and so on.

I think it's fair to say that GPGPU is only now becoming "usable" without relying on (highly) proprietary software stacks.

The perils of federated protocols

Posted May 24, 2016 22:43 UTC (Tue) by flussence (guest, #85566) [Link] (1 responses)

> Define “usable”, please.
In the way VDPAU is today. Able to do more than run the demo/test code shipped with Mesa. Reducing power consumption by offloading work to an appropriate device instead of increasing it by being dead weight to compile.

> things like Xeon Phi, it's used on your mobile phone
I don't think my phone has a 300W processor (it seems to cope with image/photo editing fine regardless). Did you mean to say Someone Else's Computers? Those kind of services are best enjoyed as schadenfreude.

The perils of federated protocols

Posted May 25, 2016 1:24 UTC (Wed) by nybble41 (subscriber, #55106) [Link]

>> things like Xeon Phi, it's used on your mobile phone
> I don't think my phone has a 300W processor

Indeed, a mobile phone with a 300W Xeon Phi processor would last about five seconds before either draining the battery or setting itself on fire, whichever comes first. Possibly both.

There should have been a closing parenthesis after "Phi". That was meant to be read as "GPGPU is used on your mobile phone".


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds