611–620 of 650 posts
Earlier quoted context omitted.
Common usage of crooked practices doesn't mean anyone likes them. Let alone encourage any of such trash.
I didn't say people liked it, I said they were used to it. It's the status-quo so it doesn't get questioned the way it would if it was a completely new concept.
Earlier quoted context omitted.
The persons in favor of Vulkan in this thread don't have to prove their point, you have. Their solution works, is battle tested, is cross platform and almost an industry standard. Unless you backup the Apple proposal with serious evidences such as : - hard metrics on performance benefits, why you need them, and why you can't improve vulkan to get them; - demonstration of blatant issues with the vulkan API and very go…
> On this one, you are guilty until proven innocent, I'm sorry Or rather, he's got to refute the null hypothesis.
Earlier quoted context omitted.
Apple will always be taken seriously since they are not just a major mobile vendor but the only vendor capable of getting any technology widely deployed. Your arguments are very reminiscent of the "Apple must adopt Flash" era. And as we've learn Apple was 100% right to dump that technology as it was simply a poor fit for mobile. I've seen nothing about Vulkan that indicates it has some inherent qualities that make it…
> I've seen nothing about Vulkan that indicates it has some inherent qualities that make it suitable as a Javascript API. And you are qualified to make this assertion because? It would make an awesome JavaScript API. It is well defined, well supported, well documented low level API for graphics. It would easily be exposed within JavaScript.
Everyone I know who's ever coded using Vulkan has found it unpleasant, and even Khronos is considering a higher level API (more along the lines of Metal) because Vulkan is just too hard to use.
Earlier quoted context omitted.
Yes, you are right, but solving the problem of adversarial input is probably NP. A validation layer can intercept every API call and validate it. It's probably the best you can do. The nice thing about it, is that you could actually use it in many different contexts, since, you know, Vulkan makes it a standard feature of the driver.
It's not NP (whatever that means) if you're allowed to change the API instead of just inserting checks at each call. Besides, Javascript doesn't really need driver support to intercept function calls...
> if you're allowed to change the API instead of just inserting checks at each call.
The only case is where you simply make the API so limited that it becomes decidable, e.g. remove all backwards flow control and recursion.
> Besides, Javascript doesn't really need driver support to intercept function calls...
Nope, it doesn't, but it makes for a more flexible approach when there is an existing model and implementation (validation layer) which supports this approach.
Improving the quality of the validation layer means that everyone benefits. It's also a massive job and thus, that something already exists, and is standardised, is a good approach.
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!
Earlier quoted context omitted.
I said: > In terms of performance, I don't think Metal is even a contender, given how bad macOS hardware is compared to Wintel. The response was: > It makes no sense to judge the quality of an API by the power of the available hardware it might be running on. You are right, that my statement is not very clear. The key point here is that I'm not judging the quality of an API by the power of the available hardware, but…
You need to provide some evidence that function dispatch is a limiting factor for Metal, if you're going to argue that it is a limiting factor. Also you seem to be under the impression that because a machine is expensive it is destined for gaming.
Without investing a lot of effort, the best I have is this: http://www.codeotaku.com/journal/2009-05/run-time-polymorphi...
In addition, my entire lament is that it's not easy to compare Metal to anything else. Ideally, this would tell you whether function dispatch was REALLY a big issue or not.
> Also you seem to be under the impression that because a machine is expensive it is destined for gaming.
No, that's not a valid assessment of my position.
I have an expensive desktop, and I use it primarily for work. Even the Mac Pro performs poorly when compared to an equivalently priced PC. Even just for work related scenarios. Some good comparisons on YouTube :D
Earlier quoted context omitted.
> Just because it was designed to be high-performance doesn't mean it automatically wins on platform support and implementation quality. I never asserted that. I didn't even qualify what I meant by "BEST". But, let's evaluate the qualities you mention: > platform support Vulkan objectively wins here, supporting Windows 7/8/10, Linux, macOS/iOS with a wrapper, Android, etc. Intel has unofficial drivers for their x86 i…
By "platform support," I was not referring to the number of platforms supported by the API, but the quality of support for the API provided by the platform(s). Vulkan objectively loses to D3D and Metal here. We absolutely know the implementation quality of D3D- you don't have to see the source to see its performance, its stability, or its adherence to the spec. On the whole, it's far more consistent and stable than O…
Earlier quoted context omitted.
Good point. But, that's assuming that it's not possible to write a wrapper on top of DX (for Xbone) that proves a Vulkan API. It's already been shown to be possible to do something similar, with MoltenVK. The ball would be in Microsoft's court for this one.
> But, that's assuming that it's not possible to write a wrapper on top of DX (for Xbone) that proves a Vulkan API. Is this not how Vulkan on Windows works? Given how many OpenGL drivers were just shims over DirectX in the past, I wouldnt be surprised if the same course was charted there.
Earlier quoted context omitted.
Is it your position that the only drivers worth using are those produced by the operating system's vendor? While I suppose this would make sense to Apple, it sounds entirely crazy to me. IMHO, it makes much more sense for the hardware vendor to write the drivers.
The web is supposed to be a universal platform. It doesn't make much sense to limit a feature to the subsection of web users who install graphics drivers.
On the flip-side of that, the web is supposed to be a universal platform. It doesn't make much sense to limit a feature to the subsection of web users who have hardware that supports 3D acceleration. :)
Earlier quoted context omitted.
What do you mean by "unofficial drivers"? Looking at the support matrix on Wikipedia, it seems that both NVIDIA and ATI support it in their official Windows drivers.
I guess he means that Microsoft isn't aggressive enough in distributing these drivers via Windows Update. Definitely the case with older Windows versions like Windows 7 where Windows Update doesn't seem to offer GPU driver updates at all if you have manually installed something like the driver cd that was in the GPU box. However with Windows 10 they have gotten more aggresive in updating these drivers. [1] Still, a l…
My guess would be that these same drivers would be out of date enough not to contain DX12, so if that's really the target, then there needs to be a fallback to OpenGL and/or an older DirectX.