kvark

37 ms·

361.
by kvark 8y ago
Sure! I'm just pointing out that your earlier statement was off the mark, and it posed Metal as "something new that could be better than Vulkan".
362.
by kvark 8y ago
This is sadly a common misconception, partly due to Khronos messaging. MoltenVK is sponsored by Valve, not Khronos. Both gfx-rs and MoltenVK are working in Vulkan Portability TSG, and both are promoted by the slides/talks if you read c
363.
by kvark 8y ago
Metal isn't new, it's older than Vulkan, and by some metrics I would consider it better. For one, the learning curve is much smoother: you can get something up on screen quickly, but only later discover the advanced features like
364.
by kvark 8y ago
> projects like Metal on Vulkan (MoltanVK) It's not Metal on Vulkan, it's the other way around. Also, kind of strange to bring this up when the topic is about gfx-portability progress (which is competing with MoltenVK).
365.
by kvark 8y ago
Well, at least now your know that there is an alternative. For a Rust ecosystem project, really, there shouldn't be a need to use MoltenVK.
366.
by kvark 8y ago
You can also try one of the Vulkan Rust libraries (ash, Vulkano). Later you'd have easier time migrating to gfx-hal, or alternatively can just run over gfx-portability.
367.
Portability benchmark of Dota2 on MacOS(gfx-rs.github.io)
187 points by kvark 8y ago|27 comments
368.
by kvark 8y ago
I think the time will come for it when we prove ourselves useful on Metal/D3D12 and get those developer partnerships in the first place.
369.
by kvark 8y ago
Unless it's Librem-5 ( https://puri.sm/shop/librem-5/ ), although we've yet to see what comes out of it
370.
by kvark 8y ago
gfx-rs does expose Vulkan frontent: https://github.com/gfx-rs/portability I'd love to get started on GNM but licensing is tricky, given that gfx-rs is a community project.
371.
by kvark 8y ago
gfx-rs Metal backend can be powerful and faster
372.
by kvark 8y ago
Both gfx-rs and MoltenVK are in that technical subgroup within Khronos.
373.
by kvark 8y ago
TOML is a great format, but it can not universally replace JSON, because it's designed for small nested depth. I've been trying to push RON as an alternative, and it works very well for WebRender, Amethyst, and other projects in R
374.
by kvark 8y ago
I'd be very interested to look into that, haven't seen it being stuck for minutes anywhere. Do you still have this profile around? or maybe just the URL?
375.
by kvark 8y ago
We used YAML from the start in Wrench tool for writing reftests for WebRender[1]. Currently looking into a prospect of migrating all of them to RON[2] as a better alternative, which has proven itself useful in WebRender captures. [1] ht
376.
by kvark 8y ago
https://github.com/gfx-rs/portability may be relevant out side of Rust, since it's a linkable C library.
377.
Gfx-rs Vulkan portability status(gfx-rs.github.io)
5 points by kvark 9y ago|0 comments
378.
by kvark 9y ago
That's what I've been afraid of. When epochs were announced, I thought it is kinda nice to have backwards compatibility while introducing breaking changes. It's a good technical concept. Trying to change it's role into &
379.
by kvark 9y ago
What I'm missing here is why we need to market it as a distinct Rust 2018 release. Do we have breaking changes that require a new epoch/edition? The "Language improvements" section doesn't clarify that. I just hope
380.
by kvark 9y ago
I'd say Khronos is doing an entirely different thing for DX12 since there is no existing library to open source :)
381.
by kvark 9y ago
Vulkan Portability subset is excluding the following features (at the moment!) from core Vulkan: - triangle fans - separate stencil reference values - events There are also extra limitations to things like the maximum buffer size
382.
by kvark 9y ago
Windows 10S, future Windows Polaris, and XBox One don't allow for native Vulkan/GL drivers.
383.
by kvark 9y ago
This is called GPU virtualization, and there have been experiments ("Sugar" [1]) of using it for WebGL. We looked into it, consider it promising but not urgent. It addresses some of the security concerns at the cost of performance
384.
by kvark 9y ago
If you just care about GPU compute and not much about the shape of the API or it's overhead, then something like OpenGL ES 3.1 Compute Shaders or WebCL would be much easier to reach than WebGPU, technically.
385.
Feasibility of low-level GPU access on the Web(kvark.github.io)
128 points by kvark 9y ago|128 comments
386.
by kvark 9y ago
Well, error codes are not special constructs in any way. And exceptions can be easily overused. So you have to draw the line somewhere. Rust just choose the balance where facing an exception is truly exceptional :)
387.
by kvark 9y ago
I wouldn't say that we've crossed any significant milestone since Chicago F2F. There's been progress on the implementations, but conceptually the main questions about the API are still open.
388.
by kvark 9y ago
At this point, since there is no consensus on the shape of the API or even the concrete feature set/programming model, we decided to focus on the low-level graphics abstraction layer ([1]) instead of pushing the WebGPU-Servo prototype
389.
by kvark 9y ago
Apple's prototype is basically WebMetal, and the question about how well it maps to Vulkan is still open. Like, surely, there are hoops you've got to solve (w.r.t memory types, pipeline barriers, etc), but it's not clear how
390.
by kvark 9y ago
Metal the API has some elegance in it, but the target range of hardware is controllable and way more limited than what Vulkan was designed for. Apple can choose what graphics goes into their Macs and iPhones, collaborate with the mobile GPU

More ›