34 ms·

Apple proposes new web 3D graphics API

• wnevets 10y ago
  As someone whos knows almost nothing about 3d graphics and its APIs, how does Vulkan play into all of this? Why should this new API be used instead of adding Vulkan's API to the browser?
  • corysama 10y ago
    This is intended to be WebVulkan|WebDX12|WebMetal with room for other possible underlying implementations. In general, Vulkan was not designed with the web in mind. For example: Vulkan's design intentionally has a whole lot of undefined behavior. Instead of strictly specifying what happens in all possible accidental cases, they strictly specify what is defined and provide debug layers that help you identify during development when you are unknowingly stepping into bizarro land. Also, I expect Vulkan was designed with the expectation of process-level isolation being the end-all of security concerns. That's not sufficient for single-process, multi-tab browsers.
    • JoshTriplett 10y ago
      > Also, I expect Vulkan was designed with the expectation of process-level isolation being the end-all of security concerns. That's not sufficient for single-process, multi-tab browsers. Chrome has process isolation, and Firefox is developing process isolation right now. I don't think it makes sense for a new technology stack to go out of its way to support single-process multi-tab browsers.
      • pygy_ 10y ago
        But even in chrome, several tabs can share the same process, which means that information can be leaked, cross-tab.
        • saurik 10y ago
          You say "can", but unless you have a very small number of tabs, the correct phrase is "many tabs share the same process". I am currently averaging 10 tabs per process.
        • nkkollaw 10y ago
          Really? I thought each tab had its own process.
  • jra101 10y ago
    It is higher level than Vulkan as you don't need to allocate or manage GPU memory, the implementation handles that for you. You also don't need to worry about transitioning render surfaces between different states (D3D12 and Vulkan). It does allow you to create pipeline state objects ahead of time like Vulkan and D3D12 but they only include a subset of state (shader + antialiasing state + color/depth attachment state). The rest of the state is set when recording the command buffer.
• bobajeff 10y ago
  So is this supposed to be like a WebVulkan?
  • suyash 10y ago
    No it's WebGPU like it shows in the code. Vulkan is a competing standard and technology.
    • bobajeff 10y ago
      You misunderstand. I wasn't asking what it's called. I was asking if the idea here is a Vulkan like API for the web.
      • suyash 10y ago
        I answered that in the second statement.
        • zero_iq 10y ago
          No, you really didn't.
        • corysama 10y ago
          You were having too much fun being pedantic to answer the question. It is not WebVulkan. It is "like a WebVulkan".
      • om2 10y ago
        Our proposal is a little higher-level than Vulkan but it's the same basic idea.
        • bobajeff 10y ago
          So if it higher level than Vulkan where does it fit in with WebGL? I mean can't you pretty much already use low level GPU tech like Vertex Buffers and Shaders already?
• walterbell 10y ago
  Could this be adapted for graphics virtualization, e.g. allowing several VMs to securely and performantly render 3D workloads on a single physical GPU?
  • xigency 10y ago
    If they were running a web browser...
• mbrookes 10y ago
  Hey Apple, how about developing your browsers to support modern web technologies first?
  • Benjamin_Dobell 10y ago
    The latest Safari release is actually ahead of the game in a lot of areas. I don't run it as my primary browser still, but it does look like at least someone within Apple cares.
  • proyb2 10y ago
    Isn't Safari Technical Preview supported 100% ES6? https://news.ycombinator.com/item?id=11708840 https://news.ycombinator.com/item?id=11708840
    • saurik 10y ago
      Apple definitely keeps up with core JavaScript and CSS support, but essentially anywhere the web undermines their attempt to maintain control over a protocol, file format, or API--or for anything that makes the browser fundamentally more powerful (which undermines their attempt to get developers to focus on native applications, and which stuff like ES6 is fundamentally not an example)--they invest only a token amount of effort at best and at worst they seem to actively cause more fragmentation (by pushing Safari-only proprietary and sometimes even patent-encumbered alternatives).
      • paulddraper 10y ago
        Have you examples?
        • saurik 10y ago
          Service Workers, Pointer Events, Web Notifications, WebRTC... I could probably go on, but these are the ones everyone generally has at the top of their heads and which I can just rattle off without thinking about it much (and which have already been mentioned by other people on this very threads, and so absolutely should not require listing :/). The story of IndexedDB vs WebSQL (with Safari developers apparently being extreme zealots for the latter and essentially refusing to implement the former for years) is another great example. I recommend doing some basic searches using Google, as there is tons of great commentary on how Safari is "the new IE6" or is simply holding back the web.
• vvanders 10y ago
  Anything that's not based on the Vulkan spec is just a land-grab by Apple to push their own technologies. As someone who spends a lot of time in that space I don't really see what this is solving, WebGL is good enough and anyone serious about performance/compute are going to drop down to native anyway.
  • droithomme 10y ago
    Yeah,what is wrong with WebGL anyway? It seems to work pretty well.
    • corysama 10y ago
      WebGL is pretty great. But, like GLES, it requires a lot of API calls to get stuff done. Hopefully, with a Vulkan-like API, you should be able to move a whole lot of that work to initialization time and make the act of actually drawing stuff frame-by-frame require very little API activity. In the extreme case you get stuff like "GPU-Driven Rendering Pipelines" described in http://advances.realtimerendering.com/s2015/ http://advances.realtimerendering.com/s2015/
    • sydd 10y ago
      lots of things: - Implementing OpenGL drivers is very complicated, this leads to huge drivers full of bugs and performance issues. Just look at something like this: https://dolphin-emu.org/blog/2013/09/26/dolphin-emulator-and-opengl-drivers-hall-fameshame/ https://dolphin-emu.org/blog/2013/09/26/dolphin-emulator-and... - OpenGL's state machine logic is outdated and horrible to debug. We need something more modern. Basically its carrying cruft from the last ~20 years. - It can be very slow compared to Vulkan/Metal/DX 12. - It doesnt allow modern features like GPGPU. this would allow is to truely use the GPU for computing stuff (e.g. AI, novel shaders, new graphics pipelines etc.)
  • JoshTriplett 10y ago
    > As someone who spends a lot of time in that space I don't really see what this is solving, WebGL is good enough and anyone serious about performance/compute are going to drop down to native anyway. Not true at all; if your primary performance bottleneck is the GPU code, not CPU code, you could use a better web API modeled after Vulkan, for the same reason people switch from GL to Vulkan. In general, if there's ever something where people feel they "have to" use native instead of web, that needs fixing in the web platform.
• Benjamin_Dobell 10y ago
  I feel like Apple are just trying to get in early with a proposal so they don't get forced into supporting Vulkan (and wasting all that effort on Metal). Mind you, it does at least look like they're trying not to be jerks about it (even if the motivation is somewhat selfish). They specifically mention the competition to Metal and how "webgpu" is ideally an abstraction that'll sit on-top of Vulkan, Metal and Direct3D 12. It'll be interesting to see how this pans out. Vulkan, Metal and Direct3D 12 are all intentionally very low level, adding a wrapper of any kind may be seen as non-ideal by all parties.
  • revelation 10y ago
    It is not "seen as non-ideal", it was the very point of existence for all of those standards. Graphic apis had become a leaking abstraction of non-standardized driver behavior with single-digit FPS lurking around every non-popular feature corner. It is a joke to suggest putting another abstraction over the low-level api. That is squarely the domain of libraries and frameworks.
    • sipos 10y ago
      > It is a joke to suggest putting another abstraction over the low-level api. That is squarely the domain of libraries and frameworks. That's fine for native apps when the libraries and frameworks can be native and thus high performance but, on the web, these have to compile to JavaScript and, while that can be very fast, a native framework is going to be faster than one running in JavaScript ontop of a lower-level API. This is a problem with the web though.
  • om2 10y ago
    Is that really a "just" or is it the right thing to do? Working on top of all the major APIs is the right thing for the web. We've discussed our proposal a lot with key players in this space (including other browsers, GPU vendors, relevant ISVs) and we're pretty sure a cross-API abstraction is the way to go. Some even want to build a form of cross-API abstraction at the native C/C++ level.
    • 10y ago
• NickGerleman 10y ago
  "The major platform technologies in this space are Direct3D 12 from Microsoft, Metal from Apple, and Vulkan from the Khronos Group. While these technologies have similar design concepts, unfortunately none are available across all platforms." So Apple, the only company not supporting Vulkan on their platforms, is complaining that there isn't a cross-platform solution?
  • mwkaufma 10y ago
    Seriously, even fricken Nintendo is on board with Vulkan: http://www.gamasutra.com/view/news/287995/Nintendo_Switch_to_support_Vulkan_OpenGL_45_and_OpenGL_ES.php http://www.gamasutra.com/view/news/287995/Nintendo_Switch_to...
    • pjmlp 10y ago
      Kind of, they have their own API that has better capabilities to expose the graphics hardware called NVN.
  • philipp-spiess 10y ago
    I doubt it's up to the webkit team to make this decision. Anyway, Apple adopting would make things easier
  • om2 10y ago
    We're not complaining, we're explaining the lay of the land. Working on top of all three of these APIs is totally doable and will result in a better API for the web. Things worth noting: - We believe other browser vendors agree with us that the web API should work on all three of the major native APIs. - The web has security requirements which force us to go a bit higher-level than Vulkan anyway. I understand your desire to have Vulkan on Apple platforms, but it's really a separate issue from the right target for WebGPU.
    • Nullabillity 10y ago
      > We're not complaining, we're explaining the lay of the land. No, you're stating your own company's ambition.
• shmerl 10y ago
  Will it be patent encumbered, like Apple's "proposal" for touch events API? > Meanwhile, GPU technology has improved and new software APIs have been created to better reflect the designs of modern GPUs. These new APIs exist at a lower level of abstraction and, due to their reduced overhead, generally offer better performance than OpenGL. The major platform technologies in this space are Direct3D 12 from Microsoft, Metal from Apple, and Vulkan from the Khronos Group. While these technologies have similar design concepts, unfortunately none are available across all platforms. Oh, really? And who is to blame, that Vulkan is not available on Apple platforms?
  • netule 10y ago
    Not only that, but Apple seems to have decided to stop supporting open graphics standards altogether, including OpenGL [1]. Apple used to be quite vocal and influential as part of the ARB, not sure what caused the shift of the last few years. [1] https://www.g-truc.net/doc/OpenGL%20Drivers%20Status.pdf https://www.g-truc.net/doc/OpenGL%20Drivers%20Status.pdf
    • shmerl 10y ago
      Yes, they clearly are deeply into their usual NIH routine. So it's highly hypocritical for them to complain, how open APIs aren't cross platform enough.
      • scholia 10y ago
        Apple supported Blu-ray and even took a seat on the Blu-ray board. How many Blu-ray drives did Apple ship?
    • jsheard 10y ago
      The shift was especially jarring on the compute side of things. Apple literally started the OpenCL initiative, then decided to completely abandon their OpenCL driver in favor of Metal Compute.
  • stupidcar 10y ago
    The group's draft charter[1] proposes that contributing organisations would be required to agree to the W3C Community Contributor License Agreement[2], which includes a patent licensing commitment for all essential claims. So, if a specification came out of this, then it would not be patent encumbered; at least not by any patents held by Apple. I'm willing to give Apple the benefit of the doubt on this. Like any big tech organisation, I'm sure they have people who want to do the wrong thing, and people who want to do the right thing. Everyone supporting Vulcan would be nice, but a standardised, patent-free, cross-platform, web-enabled, low-level GPU API would still be a major step forward. [1] https://gpuweb.github.io/admin/cg-charter.html https://gpuweb.github.io/admin/cg-charter.html [2] https://www.w3.org/community/about/agreements/cla/ https://www.w3.org/community/about/agreements/cla/
• suyash 10y ago
  This is a great move by Apple. Webkit team is thinking ahead about power of GPU's and opening it up for more than just 3D graphics. GPU are already being utilized for AI and ML. Web developers need better access to low level computation and simple api's.
• thedjinn 10y ago
  The API looks like a direct port of Metal to JavaScript.
  • shmerl 10y ago
    As such, it should be rejected by W3C. Let Apple get behind Vulkan, instead of proliferating clones of Apple only APIs.
  • acqq 10y ago
    "We don’t expect this to become the actual API that ends up in the standard, and maybe not even the one that the Community Group decides to start with, but we think there is a lot of value in working code. Other browser engines have made their own similar prototypes. It will be exciting to collaborate with the community and come up with a great new technology for graphics." Also, Metal was announced June 2014, released September 2014. Vulkan was announced March 2015, released Feb 2016. I don't see any reason for favoring Vulkan specifically for Web when compared to Metal I can read: "Metal still does a lot of hand holding and behind-the-scenes management for you, while with Vulkan you are responsible for — literally — everything. And man they were NOT kidding when they said that the API is explicit. Its actually quite ridiculous how difficult and detailed the API is." (1) 1) https://forums.developer.apple.com/thread/38469 https://forums.developer.apple.com/thread/38469
    • SquareWheel 10y ago
      >Also, Metal was announced June 2014, released September 2014. Vulkan was announced March 2015, released Feb 2016. It was rebranded then, but OpenGL Next was announced in August 2014. http://www.anandtech.com/show/8363/khronos-announces-next-generation-opengl-initiative http://www.anandtech.com/show/8363/khronos-announces-next-ge...
• AndrewKemendo 10y ago
  Biggest questions I have are: 1. What is the (proposed) backward compatibility across devices? 2.Given that it is structured for Metal shaders, what are the plans for other, non-apple devices? I see the hat tip to D3D and Vulkan, but I assume they need to get on board first - any early takers? After all common standard means cross-platform hardware support, something Apple has never really embraced.
  • eridius 10y ago
    The blog post explicitly says that they think that discussion around the shading language to be "one of the most fun parts of the standardization process" (i.e. most contentious), and they explicitly said they're deferring the issue of shading language and just accepting an existing language "for now", and that they picked the Metal Shading Language because the authors of the proposal here are using Apple platforms. I think the implication is clear that they don't expect the Metal Shading Language to actually be the final shading language after the proposal has gone through the standardization process.
    • AndrewKemendo 10y ago
      Yea I saw all of that, I'm wondering if it's just lip service or if they did any outreach beforehand.
• whyileft 10y ago
  That is a very deceptive way to put it. https://jakearchibald.github.io/isserviceworkerready/ https://jakearchibald.github.io/isserviceworkerready/ Safari is intentionally crippled in several areas. Its very specific and obvious. It is dishonest for you to at this point pretend Apple is going full force for web standards while they are explicitly not implementing features that are available everywhere else. And how those specific features line up directly as features which allow web apps to compete with its native application market. Edit: To anyone seeing this down-voted. Apple employees typically down-vote stuff like this so please do not take this being greyed as anything but manufactured opinion.
  • Benjamin_Dobell 10y ago
    Wait... what? Deceptive... really? Come on now. http://caniuse.com/ http://caniuse.com/ In terms of tracked features they're ahead of Edge with both their stable release and in development (TP) builds. Don't let your own prejudices distort reality.
    • whyileft 10y ago
      http://caniuse.com/#feat=notifications http://caniuse.com/#feat=notifications Every. single. other. browser. Including desktop Safari.
      • Benjamin_Dobell 10y ago
        I can play that game too: http://caniuse.com/#feat=es6-module http://caniuse.com/#feat=es6-module Like I said, "ahead of the game in a lot of areas", not every area.
      • MBCook 10y ago
        As an iOS and MacOS user..... GOOD. I hate websites trying to give me notifications. I like that I don't get stupid prompts from mobile Safari about that kind of thing.
        • 10y ago
• DigitalSea 10y ago
  Another anti-competitive initiative disguised as "Apple-led innovation" - maybe Apple should get on board with Vulkan, everyone else has, instead of complaining about there being no cross-platform solutions.
  • eridius 10y ago
    How is this anti-competitive? They're explicitly trying to create a cross-platform JavaScript API for graphics, one that can be built on top of whatever platform-specific low-level APIs that exist. This seems to be the exact opposite of anti-competitive.
    • nkkollaw 10y ago
      Because it's their own. How convenient to propose your own standard as the standard, made specifically for your own engine...
      • vlozko 10y ago
        Do you know what a proposal is, by definition? Such things tend to go through a number of web standard committees and are often changed throughout the process. It's not like Apple can directly dictate web standards and expect everyone to fall in line.
        • nkkollaw 10y ago
          I know, but they could make a proposal based on what most people already agree on, instead of their own thing made for Metal.
          • xenadu02 10y ago
            That's not true because there is no alternative standard proposed for low-level graphics on the web. None. Zero. Zilch. Nada. DOES. NOT. EXIST. The major browser vendors have basically already committed to this sort of effort and the GPU vendors are signed on as well. The blog post even says they don't expect the final syntax to look like their proposed syntax. It's called a prototype for a reason and it helps inform the thinking around what to do and what not to do. This is just HN anti-Apple mania. If you have a bone to pick about Vulkan support then go file a radar. Email DTS. Email Apple leadership and lay out your case in detail for why Apple should support Vulkan. None of that has anything to do with trying to standardize low-level graphics on the web.
• TazeTSchnitzel 10y ago
  That API looks potentially more pleasant to use than WebGL, which is a nice surprise given it's purportedly more low-level.
  • om2 10y ago
    That's one of the benefits of designing an API for the web from the get-go, instead of just literally copying an API that's meant to be used from C. It makes for a cleaner and nicer API, even though some lower-level details are exposed.
    • flohofwoe 10y ago
      It's basically a webified Metal API, similar to how WebGL is a webified OpenGL, so I wouldn't say it was designed from the get-go for the web. And as far as I can see from the proposal, WebGPU will still be well usable from C (this is important for talking to it from asm.js / WebAssembly)
      • om2 10y ago
        It's Metal-inspired, but we tried to use JS API design idioms where possible. It does help that Metal is already an object-oriented design instead of bare functions passing around primitive values and structs.
        • flohofwoe 10y ago
          Ha, sorry I wasn't aware that you're on the WebGPU team when I replied. Please don't forget about us emscripten users, I'd love to give WebGPU a whirl with my C++ mini-3D-framework (http://www.github.com/floooh/oryol http://www.github.com/floooh/oryol), would be interesting how the C/C++ code would differ from the Metal rendering backend, and how performance compares to WebGL on one hand, and Metal / GL on the other.
          • om2 10y ago
            I'm being a little generous to myselff with saying "we". I'm on the WebKit team and I followed this project but I wasn't personally involved in implementing it.
• sova 10y ago
  Go for it! I would love to see more focus on browser-based what-the-future-of-code-may-look-like. That said, I don't think that 3D interfaces are the only kinds that need good language / representation. Not that the rules should be really rigid, but I think that if we pursue the notion of reversely symmetric UI-languages we can make a lot of progress. Imagine that you have a 3D scene, what is the minimal language you need to describe it? How can we make it so that language/code is not only minimised but extensible? We must strike a balance. I would like to have such simplicity in a potential language that when I see a scene in my minds' eye, it's really easy to transfer to the digital realm. I think the simplicity of representation is key. Being a web dev on my own hours for the past several years now has given me a pretty solid grip of all the needs of an interactive application, and I can say that there has to be some way for users to easily interact and offer all the possible inlets for the information. Starting a 3D-internet movement might require rethinking the inputs. Won't we just use holo-wands to navigate vast swathes of data rapidly? Run through this field of data sheets... So yeah, rethinking the medium will naturally come up as a question in conversations around this, and I think that it's simply a matter of keeping "user input" as straightforward and easy as possible, in the local _and_ distributed sense. With that as a foundational block, the rest of the 3D scene can start to make sense.
  • kazagistar 10y ago
    Is this some kind of procedurally generated programming related nonsense?
    • sova 10y ago
      After reading it over a couple times I realize it may read that way. Just a (terse) synopsis of some of my thoughts on the state and future of UI "programming"
• varenc 10y ago
  I'd rather Apple implement getUserMedia in Safari first. Currently, it's not possible to access a user's microphone or webcam in Safari (desktop and iOS). They're the major outlier when compared to other browser vendors: http://caniuse.com/#search=getusermedia http://caniuse.com/#search=getusermedia
• deleted 10y ago
  [deleted]
• hacktually 10y ago
  We don't need more new standards. We need concise, clear and coherent code.
  • paulddraper 10y ago
    It doesn't matter how well-built your house is, if you build it on limestone in a flood zone.
• ctdonath 10y ago
  Any word from Carmack on this?
• surfmike 10y ago
  How is this on security? Vulkan API is built on being able to modify command buffers and pass parameters by directly writing to memory, rather than the client/server model of OpenGL. I could see that being an issue with the sandboxed model of the browser. Disclaimer: haven't read the new Apple web 3D spec, just curious about others' opinions.
  • om2 10y ago
    We haven't yet solved all the security problems, but we're aware of and thinking about them. We expect threadsafety, memory safety, data validation, and memory protection for the shader language to be the big issues.
    • hrjet 10y ago
      Why are you proposing a new standard when you are still thinking about security?
      • om2 10y ago
        Thoroughly solving the security problems will require more eyes on it than just ours. Which is why we're proposing a starting point for a standard, and a process to work on it, not an endpoint.
        • hrjet 10y ago
          Thoroughly solving security problems would of course take time. But the parent comment asked a very high level question: How does the security of this new proposal compare to a client-server model such as that of OpenGL? One can simulate one model over another, but in that case, performance can suffer due to overheads. This sort of thing needs to be addressed at the outset, because graphics needs performance and the web needs security; neither can be compromised upon.
          • om2 10y ago
            I don't think passing command buffers or structures in memory will be an obstacle to security. The main security issues will likely be: * Avoiding out of bounds memory reads * Avoiding threadsafety issues * Figuring out lifetime for everything to avoid enabling out of bounds memory reads * Coming up with a safe and validatable shader format (probably a binary one, which makes validation harder) * Checking correctness of things enough to avoid making drivers completely choke We haven't figured out a lot of these deeper issues. We don't believe the basic model is intrinsically harder to secure than OpenGL though. In fact, OpenGL's complex drivers make security harder, because exploiting the driver means a kernel exploit, so you have to be super paranoid about what you pass to the OpenGL API. Modern graphics APIs have thinner drivers so there's less risk.
• greggman 10y ago
  This probably doesn't matter but one of the advantages of WebGL is it's just OpenGL ES so porting to it is relatively simple. On the other hand all the big engines already support multiple backends so adding another for yet another API is probably not a problem
• deleted 10y ago
  [deleted]
• Girlang 10y ago
  I hope it will be as successful as Quickdraw 3D was! https://en.wikipedia.org/wiki/QuickDraw_3D https://en.wikipedia.org/wiki/QuickDraw_3D
• phkahler 10y ago
  I don't agree with this. The web does not need a 3D rendering API. If you think "web apps" are an appropriate thing, then perhaps it makes sense. Ignoring that, the web to me is still a way to view content and as such I can see a use for having navigable 3D scenes, environments, or content, but the rendering would be left to the browser much the way rendering HTML is left to the browser. I really don't like the amount of code running in my browser and see no need to add more.
  • monocasa 10y ago
    VRML (and most of the scene graph style 3D apis) died in the 90s for a reason.
• neom 10y ago
  Kicking and dragging on WebRTC, WebCL, Vulkan. Business interests much?
  • gcp 10y ago
    WebCL is dead AFAIK. None of the browser vendors is interested in it. They'd rather have compute shaders from OpenGL 3.2 in WebGL. Note that on desktop, OpenCL is dead for NVIDIA too (they've been stuck on 1.2 for ages, they removed their profiler, ...), and AMD's new stuff also dropped OpenCL 2.0 support. I like OpenCL but it doesn't look like it's going anywhere. The unified compute+graphics APIs are king.
• msie 10y ago
  MS doesn't support Vulkan! Why are many people bashing Apple as the sole company not supporting it??? MS has abandoned OpenGL in support of D3D. Why have people forgotten this???
  • jsheard 10y ago
    Microsoft doesn't need to support Vulkan, because Windows is flexible enough that GPU vendors can expose other APIs like OpenGL or Vulkan without Microsoft's permission. It's a very different situation to macOS, where Apple are the sole gatekeepers of the graphics stack and nothing can ever happen without their direct support.
    • vlozko 10y ago
      Not every GPU vendor or all the cards of a vendor support Vulkan. Even new ones being sold today. The adoption is broad but not complete for Windows. I guess the argument can be made that vendors ought to support it but that would vastly expand the scope of any web API Vulkanization efforts.
      • jsheard 10y ago
        Support for Vulkan on Windows is pretty extensive - AMD and Nvidia are retroactively supporting their hardware back to 2012, and Intel back to 2015, all of them on Windows 7 and up. Considering the lengthy turn-around time for these APIs (WebGL 2.0 took four years to get from a draft spec to enabled in some browsers by default), any Windows machine that couldn't run WebVulkan would be rather long in the tooth by the time the standard sees any real world use.
    • msie 10y ago
      Ok, thanks. Although I'm curious about the exact details preventing it.
  • 21 10y ago
    MS might have abandoned OpenGL, but you can use the latest OpenGL version on Windows if you have an NVIDIA/AMD/Intel GPU and driver, unlike on macOS (4.1 on macOS vs 4.5 on Windows)
• deleted 10y ago
  [deleted]
• SquareWheel 10y ago
  I'm glad to see Apple getting interested in web standardization again, but I'm not a big fan of this one. Wouldn't a WebGL 3.0 based on Vulkan make more sense? I'd much rather see Apple warming up to Vulkan rather than have so much Metal influence on a common web API. From a dev perspective my thinking is this. If I were to learn a 3D graphics API for the web I'd like that knowledge to be transferable to native development as well. An API built on Vulcan - even if abstracted - would be more pertinent and more compatible with existing tools than one built on Metal. I'll be curious to see comments from other committee members as they'd have more insight on the subject.
• nkkollaw 10y ago
  Apple proposing standards is ridiculous. They only care about standards when they're basically forced to adopt/support them, or they're their own. These are the same guys that: - use lightning instead of mini USB - removed the headphone jack - are creating yet another proprietary connector for accessories - don't allow their OS on third-party hardware - only allow developing for iOS from macOS - only allow apps on iOS if you install from the App Store - only allow their own browser engine on iOS - etc. Everyone wants their own standard to be the standard, if they really cared about it they would contribute to Vulkan and create WebVulkan.
  • sxcurry 10y ago
    I'm disappointed that I had to scroll this far down to get to the real heart of the matter - Apple removing the headphone jack!
  • phaed 10y ago
    This should be the top comment. Apple has no ground to stand on on this. Their self-serving intentions are plainly clear.
  • Tagbert 10y ago
    Apple’s “new” UAC port wasn’t made by Apple, and it isn’t new https://arstechnica.com/apple/2017/02/no-apple-isnt-developing-an-all-new-port-for-accessory-makers/ https://arstechnica.com/apple/2017/02/no-apple-isnt-developi...
    • igravious 10y ago
      Eh? Seems you're _both_ wrong according to an Ars commenter[1]: “It seems many people are missing the point of this. 3rd party cable makers want to make certified cables that are Lightning to UAC port so people can plug in iPhones and iPads into cameras that use these ports. Apple isn't wanting to use this port, it is the cable manufacturers wanting to make adapter cables to plug more things into iPhones and iPads.” [1] https://arstechnica.com/apple/2017/02/no-apple-isnt-developing-an-all-new-port-for-accessory-makers/?comments=1&post=32776495 https://arstechnica.com/apple/2017/02/no-apple-isnt-developi...
• botverse 10y ago
  101 mentions of Vulkan so far
• ytugiuyghvk 10y ago
  Related reading re. Vulkan "What a WebGL2 successor could look like and why it can’t be WebVulkan" - https://floooh.github.io/2016/08/13/webgl-next.html https://floooh.github.io/2016/08/13/webgl-next.html See also the the author's sketch of a next-gen web graphics API on top of WebGL (https://floooh.github.io/2016/10/24/altai.html https://floooh.github.io/2016/10/24/altai.html) which is (perhaps unsurprisingl) broadly similar to the sketch given the article (minus command queues, shader libraries, ...).
  • phire 10y ago
    Everyone here (including me) is upset that Apple are refusing to support Vulkan (or even improve their existing OpenGL support). They haven't even made a public statement. And now we get the news that they are working on another API. It doesn't really matter that the new API is targeting a completely different market to Vulkan. It doesn't really matter that a WebVulkan can't really exist in the first place. It doesn't matter if this is probally the correct starting point for a NextGen web graphics API. It doesn't even matter that the team at apple proposing this API is not the same team that would be responsible implementing Vulkan in OSX. People just want Vulkan on MacOS and/or IOS.
    • nicky0 10y ago
      And you're going to derail every thread until you get it?
    • MBCook 10y ago
      So, you're mad about a desktop API choice and therefore any discussion involving graphics API and Apple in any context must devolve into a fight over what you care about? Not the topic at hand even if it is "probably the correct starting point for a NextGen web graphics API"? The Apple employees posting in here posting some really interesting stuff, but it's all being drowned out by this noise that has little to do with the topic at hand.
    • simonh 10y ago
      > It doesn't matter if this is probally the correct starting point for a NextGen web graphics API. Scads of this thread are giving me that signal loud and clear. Not HN at it's best.
• jgord 10y ago
  Now that Apple has all power and wealth, they arrogantly push an api nobody wants, resulting in man-centuries of wasted effort and frustration .. instead of listening to their users [ in this case developers ] We have seen this before - fortunately no matter how much money they put behind this bad idea, the internet is larger than apple, and open standard apis and choice will eventually win. I don't want an apple api, I don't want yet-another-kool-language-fad they will drop in the next marketing cycle, I want old style javascript to run fast and be standards compliant on mobile, including on iOS devices.
  • threeseed 10y ago
    And yet Apple is proposing creating a fast, open, standards complaint Javascript API.
• natvert 10y ago
  How about just implementing serviceworker first?
• ClassyJacket 10y ago
  "The major platform technologies in this space are Direct3D 12 from Microsoft, Metal from Apple, and Vulkan from the Khronos Group. While these technologies have similar design concepts, unfortunately none are available across all platforms." Vulkan isn't available on the Mac huh? Yeah Apple, and just who's fault is that??
• vilya 10y ago
  All of you complaining about this proposal not being based on Vulkan seem to be overlooking the fact that Vulkan is actually quite cumbersome to use. Metal, on the other hand, is a really well designed API and in my opinion strikes just the right balance between performance and usability. If it was available for non-Mac platforms too, it would be my first choice of graphics API every time. So for me, a cross platform web graphics API based on Metal is really quite an exciting prospect - much more so than one based on Vulkan - and I applaud Apple for proposing it.
  • panic 10y ago
    Yeah, have the people arguing for Vulkan on the web actually experienced what it's like to use Vulkan? Here's a small taste: https://renderdoc.org/vulkan-in-30-minutes.html https://renderdoc.org/vulkan-in-30-minutes.html
    • filwit 10y ago
      There are many third-party libs which make using Vulkan much easier, all the way up to Game Engines which abstract everything. That isn't a argument against Vulkan. A good graphics API, even a web one, is one that provides good control over the GPU.. and to have sane standards which limit future implementation fragmentation (like shader byte-code instead of a specific shader language), and to have good debugging tools, etc.. That's what Vulkan is, regardless of how verbose it is in comparison to OpenGL. I'm not saying you can just make Vulkan run on the web, but I'm certainly in favor of a Vulkan-subset (using SPIR-V as a shader base) becoming the successor to WebGL over one inspired by Metal and MSL.
• dzhiurgis 10y ago
  So much more value would be created if iOS supported Android-style progressive web applications...
• binarymax 10y ago
  Lots of negativity in this thread related to non-adoption of Vulcan. But we've been waiting too long for generic compute and the sooner Apple leads something to the browser for GPGPU then maybe it will get everyone else to finally act - competing standard or not.
• intrasight 10y ago
  If Apple has like 4% of the OS market and seems to be abandoning the desktop, why do we really care what Apple thinks?
  • MBCook 10y ago
    Because of the fact they helped usher in the modern web with WebKit and they're the ones in charge of this very popular thing called iOS?
    • intrasight 10y ago
      Everything I'm reading in this thread pertains to Mac OS, so I'm sticking with my assertion.
      • MBCook 10y ago
        You mean people complaining about the lack of Vulcan on OS X? I mean if we're only paying attention to desktops than this whole discussion is moot. Safari on the desktop has a pathetically small market share, Chrome and various versions of IE easily dominat it. There's no reason to think that even if we ended up with the equivalent of WebMetal that would seriously boost desktop Safari's market share. iOS, especially given the rules around alternate browsers, is the reason this discussion is important at all. Those hundreds of millions of devices or where this may matter.
        • intrasight 10y ago
          On iOS, Apple is going to do it's own thing and that's that.
    • robert_foss 10y ago
      WebKit came from the Linux Open Source landscape. It was created withing KDE. Re: iOS being popular; You're in a bubble, the iOS market share as of 2016Q3 is 12.5%.
• cfv 10y ago
  I think it's fine, if they can manage to polyfill this fucker. Otherwise it's just an incompatible wart like the getUserMedia implementation was for years, like webaudio still is, and like some of their latest hardware ideas have been. Polyfill first, engine bloat later
• deleted 10y ago
  [deleted]
• normalperson123 10y ago
  what a coincidence. just the other day i kind of stumbled across the situation with apple and vulkan and was totally mystified. why would apple, who was a supporter of vulkan, not implement drivers for it, and in effect block the possibility for a universal webvulkan standard and all the glorious benefits of it? lo there was a reason! i have to say that i think apple is being a complete dunce. so they refuse to implement vulkan drivers, or even modern gl drivers, and now their next move is to create yet another graphics api? the success of which would depend on everyone else supporting it when apple wouldnt support stuff? apple has enough money (tax dodgers) to support other standards. they should probably do that and do it well before telling everyone else what to do. /rant
• sowbug 10y ago
  I find Apple Inc. as annoying as the next geek does, but I agree with them here. It's rarely -- possibly never -- a good idea to tie a web API design to a desktop API (see, e.g., WebSQL). The web platform is too different from desktop platforms for any nontrivial functionality to port slavishly to it. Moreover, web standards last much longer than typical desktop APIs. Do we really want to take a snapshot of Vulkan's API today and live with it on the web for the next couple decades, as desktop Vulkan continues to evolve? It's better to build a web API that is fluent for its target platform, taking care that it's possible to implement it performantly on foreseeable host platforms. Let Apple lock themselves in if they want. Don't lock the web into Vulkan.
• kin 10y ago
  The Safari API is severely lacking relative to Chrome/Firefox. It would be great if Apple would spend some time getting Safari up to parity so devs can create a more consistent user experience for their browser.
• Zafira 10y ago
  I think this is a fruitful and promising discussion on the part of the WebKit team. The biggest problem here is that the antipathy towards Apple in response to the perception that Apple management thinks the Macintosh is a dead-end and this is starting to infect other discussions. As someone else noted, Apple created OpenCL, helped make it a standard and dumped it. It embraced OpenGL when Mac OS X first came out and now it can't be bothered to implement anything beyond 4.1. All of these little irritations serve to remind people of the Apple of yore that had NIH in extremis and was the gang that couldn't shoot straight. The hostility is unfortunate, but I fear it's going to become more frequent if Apple's senior management thinks the ship is fine.
• watertom 10y ago
  Apple can't even ship up to date desktop and laptop hardware, and own such a small percentage of that market, it makes the proposal almost laughable.
• watertom 10y ago
  Apple can't even ship up to date desktop and laptop hardware, and own such a small percentage of that market, it makes the proposal almost laughable.
• doggydogs94 10y ago
  Yet another fine API.
• berry_sortoro 10y ago
  I don't actually understand why web 3d APIs need to exist? Why is WEBGL not as feature rich as OpenGL? Cant there be JS bindings or something to just use OpenGL or now Vulkan? I think Apple can go foff. I don't really care so much for 3D in the browers anyway but if there will be a new API I hope it will be Vulkan based.
• unsigner 10y ago
  "Only platforms without Vulkan are Apple's" is most certainly NOT true. The Xbox One is a widely available platform for which a lot of 3D effort is invested, and rewards this effort really well - much better than other platforms (like desktop Linux or old versions of Windows) that are frequently thrown around as arguments for "Vulkan everywhere". It is a common observation among game developers who have really tried both that Metal is a much more accessible API than Vulkan; "90% of the performance for 10% of the effort".
  • xxs 10y ago
    >>It is a common observation among game developers who have really tried both that Metal is a much more accessible API than Vulkan; "90% of the performance for 10% of the effort". Any citation on the matter?
    • unsigner 10y ago
      No, sorry, this particular quote is from a private channel. But see this: https://twitter.com/aras_p/status/749546349474054144 https://twitter.com/aras_p/status/749546349474054144 https://twitter.com/aras_p/status/767740566792724480 https://twitter.com/aras_p/status/767740566792724480 and this: http://zeuxcg.org/2016/12/01/metal-retrospective/ http://zeuxcg.org/2016/12/01/metal-retrospective/ and this: https://twitter.com/search?q=from%3Azeuxcg%20metal%20vulkan https://twitter.com/search?q=from%3Azeuxcg%20metal%20vulkan
• _ph_ 10y ago
  For all arguing "to use Vulcan": the API proposed is a high-level API which could be implemented on top of Vulcan. Or any other lowlevel API like DirectX or Metal. When designing an API, you have to take the characteristics of the calling language into respect. Especially when you are trying to achieve the highest possible performance. You can define highlevel APIs, which try to minimize the amount of computation in the calling language, or a more lowlevel API, which gives only very basic operations, and the client has to implement more logic themselves. When targeting "fast" languages like C/C++ you tend to design more lowlevel APIs, assuming that the client can implement abstractions more efficiently as they are more tuned to his needs. When targeting slower languages, you want to do more computation in the API. So for designing a new Web API, you both have to consider that Javascript is slower than compiled C and on top of that, you have to consider security requirements. Your API should not create an attack vector to your device. This means, the best Web API would be an abstraction on top of the native low level API and the only question with respect to those would be: can the proposed API be implemented well and efficient on e.g. Vulcan?
  • madeofpalk 10y ago
    > assuming that the client can implement abstractions more efficiently as they are more tuned to his needs. off topic, but who is the client?
    • _ph_ 10y ago
      The part of the software calling/using the API. So, if you are writing a C++ application targeting the API, you should be able to implement high level abstractions at least as efficient than an API provider could. Possibly more efficient, as you can tune your abstractions to your very non-generic needs. An API provider though has to implement the more common use cases which might bring inefficiencies. However this turns around 180 degrees, when talking about a language like Javascript, which despite all JIT enhancements does not produce as efficient low level code. There you want to put as many of the computations as possible into your API so the resulting application runs faster.
      • 10y ago
• jolux 10y ago
  Why exactly are we laying it on thick against Apple here when they have the support of other browser vendors in proposing this and are trying to fix a legitimate problem? All of the comments seem to be "well wouldn't it be nice if they used WebVulkan instead" when WebVulkan doesn't fucking exist. If it were so obviously superior why isn't it in the pipeline already? Apple is not the only company that can propose standards, if there was really such an immense appetite for WebVulkan I think it would already have been proposed! This doesn't even touch the reasons it hasn't been, and the most important of these for me is security. "Well yes, it's extremely low level and admittedly very dangerous, but we can make it secure enough to expose to the most hostile environment in the history of computing" is how we ended up in the mess we are in right now security wise. You want a secure system, you have to build it that way from the start preferably in languages that don't let you decapitate yourself like Rust. I'm pretty sure it's a consensus that it's impossible to write secure C code these days, so why is everyone so convinced we could sufficiently harden a low level graphics API for web use? This is like if when NetScape proposed JavaScript if everyone went "well you're just trying to dominate it, we already have C89 just put that in the browser." Fucking NO. When are we as an industry and a discipline going to learn our lesson with this "code first, secure later" crap? And again, if this could be done and it's such a great idea, why is this the first proposal and not actual WebVulkan? The argument here is not WebVulkan vs WebGPU because again WebVulkan does not fucking exist. When or if it does, perhaps we can argue about why Apple won't support it if they don't, but until then, you're shooting down one attempt at a standard API with a hypothetical thing that does not exist and which a lot of experts in the field seem to think is a bad idea from several angles. I will reiterate this one last time because it seems like everyone has missed this: there is currently no cross-platform solution for next-gen web graphics except for this proposal. Put up or shut up.
• deafcalculus 10y ago
  This is awesome. IMHO, reducing the complexity of resource management in the app is the right way to go for a web API, and Metal is closer to what a web API should be than Vulkan. Porting an app from OpenGL to Metal is much easier than porting to Vulkan. A naive port to Metal often performs better than the GL version, whereas getting performance out of a Vulkan port is a lot harder [1]. So, I really hope the proposed API will be a C-based API that can also serve as a middle layer on top of Vulkan/D3D12 for lesser mortals like me in writing cross-platform native apps. [1] aras-p is a Unity dev: https://twitter.com/aras_p/status/628569113053528065 https://twitter.com/aras_p/status/628569113053528065 and https://twitter.com/aras_p/status/628569238794543104 https://twitter.com/aras_p/status/628569238794543104
• gfwilliams 10y ago
  I'd like to see Apple implement Safari's missing functionality before they try and come up with a replacement for WebGL. Where are getUserMedia, MediaRecorder, WebRTC, filesystem, vibration, screen orientation, Service Workers, Web Bluetooth ? What about WebGL 2? I'm sure there are a few more I missed too. Those are things that are really holding the web browsing experience back on iOS/MacOS, not an extra 20% 3D performance and slightly shinier graphics. Or why not lift the app store restrictions so that Google/Mozilla can actually ship non-crippled web browsers and implement it all for you?
  • om2 10y ago
    We are working on many of the things you list. We are able to work on more than one thing at a time though.
    • robert_foss 10y ago
      The features on that list are industry standard everywhere else. You 'working' on them is not entirely convincing. The sudden interest in a web graphics api is somewhat conspicuous coming from a company known not to adhere to web standards. There must be some reason for apples sudden interest in this stuff. Knowing apple they're interest probably isn't aligned with their users interest.
      • gerardnll 10y ago
        "Knowing apple their interest probably isn't aligned with their users interest." Explain cases please.
        • robert_foss 10y ago
          While going in-depth with this would be fun, it think mentioning some of the proprietary cables they force onto their users is one simple example: * Non-standard headphone connectors (to force license costs onto manufacturer) * Proprietary bluetooth codec (to force license costs onto manufacturers) * Not using USB connectors on phones even though they were a part of the EU group that concluded that all phones have to have USB connectors
• amelius 10y ago
  > Apple proposes new web 3D graphics API Which works only on one size of screen? :)
• ino 10y ago
  If this takes off, what are the chances it will spread out of the web and be the new standard way we draw graphics, the new abstraction available almost everywhere, the successor to OpenGL?
• warrenpj 10y ago
  An obvious use case for this API is to allow native games that use Vulkan to be ported to the Web without a proprietary abstraction layer. (The abstraction layer would be in the emscripten standard library rather than the game engine.) But is this a legitimate use case that someone actually needs? I can see two views here. Firstly, that as the open standard, Vulkan should have a privileged position and be supported from the Web side, to make the Vulkan -> Web -> Native abstraction layer standard, small and efficient. As a developer you would just implement the necessary algorithms for your application once, using Vulkan. The alternative view is that Vulkan is just too low level and doesn't fit in the web security model. Then, the purpose of WebGPU is not to implement Vulkan in Javascript. Instead, it's another target in addition to the existing three: Apple, Microsoft, Kronos, and web. To get maximum performance, developers must write an application-specific, high level platform abstraction layer, and implement that interface for each supported platform. It seems to me that this article is of the latter view, especially as it doesn't put Metal in a strategically weaker position than Vulkan. If you don't need state of the art or original rendering techniques and algorithms, I think there is already a high level abstraction which is compatible with the web: OpenGL ES 2, and soon OpenGL ES 3. (WebGL & WebGL 2).
• douche 10y ago
  Is it maybe time to step back and think about whether having a low-level 3D graphics API in the browser makes any sense at all? I know, we HAVE to run every conceivable thing out of the browser and on Javascript possible. But just maybe building native apps would be easier than trying to shoehorn an API into browser specs, where not only will you have to deal with hardware variations, there will be the inevitable incompatibilities between the implementations by each browser vendor.
• hutzlibu 10y ago
  It is so sad to see this whole discussion. Because I usually think, HN is different, from the angry, uninformed mobs out "on the streets". I mean, I don't know much about low level graphic API's, I read about them, but I don't work with them directly. But apparently most of the people here don't know either! They basically seem to know that they like open standards (so do I) and that Vulkan is a open Standard and they heard of a possible WebVulkan so that must be the solution then. Or just continue using WebGL. Because it works, right? What they didn't heard of and what I came up with a bit of reading, before posting anything, is that WebVulkan first of all don't exist and secondly probably shouldn't exist mainly because of security. And that it is very, very low level. (e.g. https://floooh.github.io/2016/08/13/webgl-next.html https://floooh.github.io/2016/08/13/webgl-next.html) And that WebGL in itself has some flaws, so it makes sense to design a new API for the future, without them. Because even though WebGL is working and awesome right now, that's not a reason to not evolve ... But why bother reading and really discuss a new WEB proposal, when "People just want Vulkan on MacOS and/or IOS."?
  • lucideer 10y ago
    These are good points, but here are some more to consider: - Apple, particularly recently, have been terrible on supporting modern web proposals. Worse than anyone. Much worse than the typical historical reputational lower bar that is Microsoft. - Apple's record on proposing new web standards has been demonstrably aggressively anti-open and not generally condusive to promoting interop https://www.w3.org/2012/te-pag/pagreport.html https://www.w3.org/2012/te-pag/pagreport.html - Apple's general record on cross-platform development is pretty much non-existent. To the contrary, much of their business decisions are specifically based on limiting interop with non-Apple platforms. I think on a holistic level, if you take Apple's record into account at all, any criticisms from them of a cross-platform proposal of any kind need to be taken in context. Before you even start considering the pros and cons of Vulkan or WebVulkan, there's a very blatant case of cui bono to examine behind this. Even if you do get past that, the points about commonality between native and web APIs are growing more and more relevant every day as Emscripten, WebAssembly and other such tech brings the two worlds closer to each other. Cross-compilation efforts will invariably be made easier with a more consistent API between (web and native) platforms.
• HelloNurse 10y ago
  The discussion about Apple not supporting Vulkan is irrelevant because the point of this Webkit proposal is replacing WebGL 2 for web applications, not replacing the sadly fragmented "real" GPU APIs for native applications. As a WebGL replacement and as a 3D API in general, many details of the proposal are strange. >Since we were building on Apple platforms we picked the Metal Shading Language. Mature and portable technology... >pipelineDescriptor.colorAttachments[0].pixelFormat = "BGRA8Unorm"; No enumerations? Are they going to validate strings? >let vertexData = new Float32Array([ /* some data */ ]); >let vertexBuffer = gpu.createBuffer(vertexData); >commandEncoder.setVertexBuffer(vertexBuffer, 0, 0); No internal structure? >commandEncoder.drawPrimitives("triangle", 0, 3); One triangle? No index buffers? I don't understand whether they are offering an insultingly dumbed down overview of a rather complete (but presumably ugly) proof of concept implementation or throwing around gratuitously WebGL-incompatible ideas to dominate the standardization process.
  • om2 10y ago
    It's really hard to make the example complex enough for experts without completely losing most people. This is deliberately a simple example. The string thing is the way enums tend to be done in modern JS APIs. It's not really a bottleneck but if it turned out to be, we'd go a different way.
• elFarto 10y ago
  I'm not quite sure what Apple were expecting, when they have shown a clear contempt for OpenGL by leaving it at version 4.1 (while everyone else is up to 4.5, even Mesa). But to the people saying use Vulkan for the web API, that wouldn't be a good idea. Vulkan is a very verbose low level API. Here[1] is a sample for the most basic of renderers (renders a single triangle). That's 1,000 lines of (commented) code. It's not a good fit for web development. A far better solution would be to evolve the current WebGL API, than shoehorn Vulkan into somewhere it was never meant to be. [1] https://github.com/SaschaWillems/Vulkan/blob/master/triangle/triangle.cpp https://github.com/SaschaWillems/Vulkan/blob/master/triangle...
• macawfish 10y ago
  Hey Apple, where's your Web Midi support at?
  • exodust 10y ago
    Wow, I never knew that was even a thing. The idea of turning a knob on my midi controller and having the web app respond is very cool.
• giridhar50 10y ago
  this might be interesting.
• swipecity 10y ago
  I'm new to this, but does it mean that Apple is preparing for some AR stuff ? Thanks.
• socmag 10y ago
  First of all I'd agree with everyone that if any new Web 3D API should come to fruition, it should be based on a Vulkan like state model. That said, from what I read of the proposal there were some interesting and useful ideas. So take those ideas and start going to the meetings to build consensus with the open standards instead of trying to co-opt it (which is how this comes off). In addition, Apple might want to consider getting WebKit in line with the existing web standards before throwing curve balls. Currently lagging way behind in many areas, which means we have to do much more work for Webkit based browsers than anything from Mozilla, Microsoft or Google, and support for some features isn't even possible. Don't mean to be a Debbie Downer, and I'm sure the team itself has good intentions, but come on.. Like everyone says the last thing the world needs right now is yet another proposal for a modern Web 3D. It will reset the clock. Again!
• filmywap 10y ago
  Thanks for sharing this valuable information to our vision. You have posted a trust worthy blog keep sharing. Nice article i was really impressed by seeing <a href="http://googlepc.org/filmywap-apk-app-2017-android/">filmywap http://googlepc.org/filmywap-apk-app-2017-android/">filmywap app</a> this article, it was very interesting and it is very useful for me.
• filmywap 10y ago
  http://googlepc.org/filmywap-apk-app-2017-android/ http://googlepc.org/filmywap-apk-app-2017-android/
• kappalavinod 10y ago
  Great blog with very useful information provided http://techvinn.com/filmywap-download-2017/ http://techvinn.com/filmywap-download-2017/
• kappalavinod 10y ago
  Download pokemon gio hack here http://techvinn.com/pokesniper-apk-app-download/ http://techvinn.com/pokesniper-apk-app-download/