!MFogdGJfnZLrDmgkBN:matrix.org

WebGPU

216 Members
The future of graphics and compute on the Web! Related rooms: https://matrix.to/#/#webgraphics:matrix.org31 Servers

Load older messages


SenderMessageTime
20 Oct 2021
@jasperrlz:matrix.orgjasperrlzIf we disallowed accessing VertexIndex on instanced draw calls, does that help?17:20:44
@jasperrlz:matrix.orgjasperrlzor is the validation still expensive17:20:54
@cwfitzgerald:matrix.orgcwfitzgeraldit'd still need a compute shader to validate, unless we could get some indication from the api that reading from out-of-bounds indices/vertices returned something sane17:21:54
@jasperrlz:matrix.orgjasperrlzerm, not instanced draw calls, draw calls with vertex bases, but yeah17:21:58
@cwfitzgerald:matrix.orgcwfitzgeraldif I'm reading it right RBA2 would let implementations drop validation for at least vertices, not sure about indices17:30:07
@kvark:matrix.orgkvark
In reply to @cwfitzgerald:matrix.org
it'd still need a compute shader to validate, unless we could get some indication from the api that reading from out-of-bounds indices/vertices returned something sane
and this would still be RW-RW, because the validation would need to have an option to set the instance count to 0 if it sees out of bounds
17:33:33
@kvark:matrix.orgkvarkis your concern about running compute work, or about RW-RW sync? On the surface, neither of those seem to have major affect on render passes, assuming there is only a few of them per frame (that use indirect, anyway).17:34:19
@cwfitzgerald:matrix.orgcwfitzgerald I mean a bit of both, but the more I think about it, I don't think there's anything we can actually do about it in web land, as the validation must be there anyway, so a bit of rewriting indirect buffers won't kill us either. 17:46:58
@cwfitzgerald:matrix.orgcwfitzgeraldThere are solutions in native land to these problems, but only because we don't have to assume our user malicious 17:48:35
@mrshannon:matrix.orgmrshannon

On the surface, neither of those seem to have major affect on render passes, assuming there is only a few of them per frame (that use indirect, anyway).

This is concerning, considering we plan for nearly all our render passes to use indirect (multi-draw-indirect where available). We are either culling geometry on the GPU (requires indirect) or generating geometry on the GPU (requires indirect). Pretty much the only time this is not true is for text/UI and post processing.

20:07:21
@kvark:matrix.orgkvark mrshannon: how many renderpasses do you foresee using the indirect? 20:15:03
@mrshannon:matrix.orgmrshannonKinda hard to say at the moment as there are cache benefits to having more render passes (with compute generate, render consume models) but at a minimum 3 or 4 per view (average of 4 views) plus shadow passes. Short answer is every pass that renders geometry.20:18:33
@mrshannon:matrix.orgmrshannonNOTE: That is passes, not draws or pipeline states.20:19:33
@kvark:matrix.orgkvarkwell, shadow is using the same geometry, so you aren't going to modify the indirect buffers just for it, and it's "free" in a good implementation20:19:42
@mrshannon:matrix.orgmrshannonThat works assuming the validation does not run again. But that requires keeping track of changes to the indirect buffers.20:20:48
@mrshannon:matrix.orgmrshannon * That works assuming the validation does not run again. But that requires keeping track of changes to the indirect buffers.20:21:13
@kvark:matrix.orgkvarkyep. It sounds like something we'd be interested to do (in wgpu land), but right now we aren't doing anything20:21:47
@kvark:matrix.orgkvark * yep. It sounds like something we'd be interested to do (in wgpu land), but right now we aren't doing anything20:21:52
@mrshannon:matrix.orgmrshannonAlso, shadow mapping does not always use the same geometry. That is only the case in a fused culling step where the geometry is culled to all frustums at the same time. While popular it is not the only method.20:23:26
@kvark:matrix.orgkvarkright, that makes sense20:23:55
@kvark:matrix.orgkvarkyour application will be a good stress test for indirect draws20:24:12
@mrshannon:matrix.orgmrshannonYep, still waiting on first-instance-indirect so we can start writing the main pipeline though.20:25:36
@mrshannon:matrix.orgmrshannonI assume the validation would be per pass and not per indirect draw, otherwise multi-draw-indirect becomes a whole lot more important.20:27:55
@cwfitzgerald:matrix.orgcwfitzgeraldit should be max one compute dispatch per buffer, assuming bindless/buffer-device-address isn't available/used20:48:18
21 Oct 2021
@kangz:matrix.orgKangz
In reply to @kvark:matrix.org
your application will be a good stress test for indirect draws
+1, we're currently implementing this as well, and I think it could be made pretty efficient (still more overhead than 0 overhead) by inserting the validation pass in earlier points in the command buffer. austineng FYI
00:22:51
22 Oct 2021
@kvark:matrix.orgkvark Question to Apple (cc litherum ): can we have a place where older MSL specs are stored? If Apple doesn't host them, can we host them somewhere? It's really hard to talk about, say, MSL 2.0 support without an accessible spec. 14:19:06
@francesco.cattoglio:matrix.orgfrancesco.cattoglio joined the room.14:27:28
@litherum:matrix.orglitherum
In reply to @kvark:matrix.org
Question to Apple (cc litherum ): can we have a place where older MSL specs are stored? If Apple doesn't host them, can we host them somewhere? It's really hard to talk about, say, MSL 2.0 support without an accessible spec.
We have them but they’re not in a form we can share publicly
17:53:16
@litherum:matrix.orglitherumI’m happy to answer questions though18:01:22
@kvark:matrix.orgkvarkWe have them too, but would like to avoid hiding them:)18:38:41

There are no newer messages yet.


Back to Room List