kvark

24 ms·

241.
by kvark 6y ago
Shipping compiled shaders is a feature request that pops up from time to time in gfx-rs land [1]. So far, we have been skeptical about this. Something like a serializable pipeline cache would help, but not entirely solve the shipping binary
242.
by kvark 6y ago
That paints Apple in a wrong light. They agreed on the WebGPU Shading Language proposed by Google (!) (previously called "Tint"). This is something Google is interested in, as well.
243.
by kvark 6y ago
It's not 1st party. Up to the very recent, the whole SDK was a "LunarG SDK" for a reason - it wasn't 1st party either. It's basically just somebody packing up a bunch of useful libraries together.
244.
Point of WebGPU on Native(kvark.github.io)
5 points by kvark 6y ago|0 comments
245.
by kvark 6y ago
That's worrying! Mozilla gfx team would be interested in fixing that, as we are trying to roll WebRender on more platforms.
246.
by kvark 6y ago
I don't know why it wouldn't work on Wayland. We are currently using "software" presentation, which is a CPU roundtrip, as described in the article. This means we don't depend much on the actual Linux compositor. As
247.
by kvark 6y ago
Right. I think, if by 1.0 we aren't able to show significant performance gains in a wide sense (latency, frame stability, and the actual frame time), it will be a failure.
248.
by kvark 6y ago
The binding model of WebGPU is nothing like OpenGL. I don't know where you get that idea, especially considering a dedicated section in the article describing this. Metal binding model works well because each buffer can contain referen
249.
by kvark 6y ago
Safari implements a large surface of the API ([1]), but they don't accept SPIR-V shaders. When WGSL design is complete, and we have it supported in the browsers, it will be time for truly cross-browser applications. [1] https:/&#
250.
by kvark 6y ago
Yes, we are fully aware of that. There must be a line drawn somewhere between work that we can make portable, and the work that is platform-dependent. Enforcing any ordering on storage writes is completely unfeasible.
251.
by kvark 6y ago
This isn't JS to Vulkan. You are talking about the Obsidian proposal [1] that was not accepted or implemented. WebGPU is higher level. High enough to hide the most nasty aspects of Vulkan, yet low enough to still extract the performanc
252.
by kvark 6y ago
We are exposing writable storage buffers and textures in all shader stages (there is a caveat discussion [1] on the topic though), which means you can write data out directly. Sharing data between shader threads can be efficiently in the co
253.
by kvark 6y ago
It's up to the browser to decide if it's enabled by default at some point in the future. There is nothing in a Web API saying that it has to be forcefully enabled. I do share the concern that security of talking to the GPUs is har
254.
by kvark 6y ago
It's really hard to estimate without implementing alternative paths that are more direct and yet fairly optimized. For example, since Intel and AMD have open-source drivers on Linux, somebody could write respective wgpu-core implementa
255.
by kvark 6y ago
I drew this on the whiteboard within Mozilla a few times, and I agree it would be nice to make it more accessible and hosted at gfx-rs repository or the blog. There is a few scattered sub-diagrams on the topic, buried in the various slide d
256.
by kvark 6y ago
We've yet to see a proper business notebook with those Ryzen H series APUs. So far, the manufactures have been eager to put it into gaming machines with a discrete GPU on board.
257.
by kvark 7y ago
Many Web applications will just ship WGSL. This includes everything going through Three.js, Babylon.js, and hand-written web apps. It's not even clear if Chrome or Firefox will accept SPIR-V binary as an extension at this point. Anyway
258.
by kvark 7y ago
Apple vetoes SPIR-V binary as an option. Google develops a language based on SPIR-V semantics that we agree on. It's clear that at least today, Google is mainly driving WGSL. They also see the value in WGSL outside of WebGPU context. C
259.
by kvark 7y ago
There are no technical issues with us having an extension that allows SPIR-V binaries to come in. It's a political issue, however, since it weakens WGSL positions. We'll be talking about this more with Google.
260.
by kvark 7y ago
I was in the minutes. Just because it's text doesn't mean it's driven by Apple.
261.
by kvark 7y ago
How are you suggesting to write shaders in the browser if they are expected to be in a binary form? WebGPU community group is open to anyone interested: https://www.w3.org/community/gpu/
262.
by kvark 7y ago
Err, WGSL is essentially renamed from Tint, which was developed and proposed by Google. Where do you see Apple the driver?
263.
by kvark 7y ago
In one of the futures, our shader translation infrastructure will support GLSL input and produce WGSL output :)
264.
by kvark 7y ago
What I wanted to say is that we as a group want people to be able to use the browser and nothing else to develop WebGPU if they want. WASM by itself doesn't provide new APIs, it's still just a different way to expose the Web platf
265.
by kvark 7y ago
The funniest (and saddest) thing about WGSL is that we realized there is a lot of confusion and tried to make a FAQ quickly to address that, but it got split and stuck in reviews: https://github.com/gpuweb/gpuweb/p
266.
by kvark 7y ago
That is correct, in theory, but there is a large gap between theory and practice. How practical would it be for, say Three.JS to generate shader bytecode? Would it need to depend on a sophisticated WASM module that allows to build such byte
267.
by kvark 7y ago
I think the counter-argument to "but WASM?!" is that on the Web you still can use text to describe the behavior. WASM is optional. At the same time, if WebGPU picked SPIR-V binary, it wouldn't have a built-in way of programmi
268.
by kvark 7y ago
It has an outdated programming model, no multi-threading, no compute (portably supported everywhere), limited access to the hardware, etc
269.
by kvark 7y ago
It's not driven by Apple, please double check your sources.
270.
by kvark 7y ago
Apple and Microsoft investigated the possibility of specifying WebHLSL tightly. The main concern was that it's a ton of work in terms of semantics. At the same time, SPIR-V semantics is fairly well specified, so we as a group figured t

More ›