!FZyQrssSlHEZqrYcOb:matrix.org

In WebGPU we Rust

1343 Members
wgpu 0.20! https://redd.it/1cfixie84 Servers

Load older messages


SenderMessageTime
24 May 2024
@kpreid:matrix.orgkpreidspecifically, it exists because different implementations are chosen at run time19:33:44
@kpreid:matrix.orgkpreid* I haven't actually worked on that part of the internals in any detail, so I cannot tell you19:34:08
@coderdude123:matrix.orgcoderdude123
In reply to @kpreid:matrix.org
specifically, it exists because different implementations are chosen at run time
I see that from looking at the source.
19:38:12
@coderdude123:matrix.orgcoderdude123
In reply to @kpreid:matrix.org
I haven't actually worked on that part of the internals in any detail, so I cannot tell you
who does?
19:38:16
@kpreid:matrix.orgkpreid Well, someone here probably does. But the data you want may not even be present 19:39:22
@kpreid:matrix.orgkpreidYou seem to be picturing the situation as "wgpu has all the data I originally provided; I just need to dig into the data structures until I find it". That's not the case. Only the data needed for validation and for platform API adaptation is retained, and the rest lives in the GPU and/or GPU driver.19:40:45
@cwfitzgerald:matrix.orgcwfitzgeraldEither way, on WebGPU we can only give you what the api allows us20:19:47
@cwfitzgerald:matrix.orgcwfitzgeraldYou should generally treat resources as black boxes20:20:26
@wsi:matrix.orgwesellinsurance joined the room.21:07:43
@coderdude123:matrix.orgcoderdude123
In reply to @cwfitzgerald:matrix.org
You should generally treat resources as black boxes
beyond WGPU not being able to do that, whats the reason for this?
21:35:48
@coderdude123:matrix.orgcoderdude123
In reply to @cwfitzgerald:matrix.org
You should generally treat resources as black boxes
* beyond WGPU already doing that, whats the reason for this?
21:36:01
@coderdude123:matrix.orgcoderdude123 * beyond WGPU already doing that, whats the reason for this? wgpu_hal seems to give access to the unerased types. 21:37:45
@coderdude123:matrix.orgcoderdude123 * beyond WGPU already doing that, whats the reason for this? wgpu_hal seems to give access to the unerased types 21:38:07
@groves:matrix.orggroves
In reply to @coderdude123:matrix.org
beyond WGPU already doing that, whats the reason for this? wgpu_hal seems to give access to the unerased types

Most of the types are just handles to other types managed by your graphics driver or some internal state tracking.

A lot of the stats you’re asking about are available in graphics profilers provided by your GPU vendor (like nvidia nsight) but not really available in regular graphics APIs like wgpu, Vulkan, dx12, etc

23:23:22
@groves:matrix.orggroves You can do some rough tracking cpu-side by keeping track of what commands you’ve submitted vs waiting on, but I’m not sure if that’s ok for the level of tracking you’re asking about 23:24:42
@groves:matrix.orggrovesIt would probably be easier to intercept the calls from bevy for that kind of tracking (instead of trying to query it from wgpu after the fact, which wgpu doesn’t really track)23:26:17
@ralith:ralith.comRalithgraphics profilers/debuggers are getting it by intercepting API calls themselves, after all23:27:25
25 May 2024
@groves:matrix.orggrovesyeah at least to a certain extent. I'm thinking about driver-level stats, like hardware profiling in nsight, metal captures in xcode, etc.03:02:02
@coderdude123:matrix.orgcoderdude123
In reply to @groves:matrix.org
It would probably be easier to intercept the calls from bevy for that kind of tracking (instead of trying to query it from wgpu after the fact, which wgpu doesn’t really track)
that sounds painful to program. I was assuming the state was kept somewhere is WGPU but wgpu_core seems to just delete pipeline data after turning it into ObjectIds so until I figure out how wgpu_hal works, the pipeline is inaccesible after its created beyond deleting it.
06:54:29
@coderdude123:matrix.orgcoderdude123
In reply to @ralith:ralith.com
graphics profilers/debuggers are getting it by intercepting API calls themselves, after all
I wasn't looking for vendor specific api calls, I was trying to see if I could get the WGPU pipeline data in its typed form after its been created, but it seems thats not possible in wgpu_core.
06:56:05
@coderdude123:matrix.orgcoderdude123
In reply to @groves:matrix.org
It would probably be easier to intercept the calls from bevy for that kind of tracking (instead of trying to query it from wgpu after the fact, which wgpu doesn’t really track)
* that sounds painful to program. I was assuming the state was kept somewhere is WGPU but wgpu_core seems to just delete pipeline data after turning it into ObjectIds so until I figure out how wgpu_hal works, the pipeline is unreadable
06:57:44
@coderdude123:matrix.orgcoderdude123 * that sounds painful to program. I was assuming the state was kept somewhere is WGPU but wgpu_core seems to just delete pipeline data after turning it into ObjectIds so until I figure out how wgpu_hal works, the pipeline is unreadable after its created 06:57:58
@kpreid:matrix.orgkpreidSomething in the works for someday is custom backends for wgpu (not compiled into wgpu itself. If that becomes available, you could write a backend that forwards to another backend while tracking the info you want. This would still be a lot of code but perhaps less awkward than wrapping the API surface of wgpu itself.15:21:59
@sagu:mozilla.orgSamsonWith https://github.com/gfx-rs/wgpu/pull/5570 ComputePass now immediately takes (shared) ownership of resourced passed in, but apart from other similarly objects, this one does not returns id on creation. I think ComputePass should also have own Id, as this would be aligned with other APIs (and we would need this in servo; currently we were able to bypass this because ComputePass was serializable).18:03:18
@groves:matrix.orggroves
In reply to @coderdude123:matrix.org
that sounds painful to program. I was assuming the state was kept somewhere is WGPU but wgpu_core seems to just delete pipeline data after turning it into ObjectIds so until I figure out how wgpu_hal works, the pipeline is unreadable after its created

The general idea is that wgpu takes in detailed descriptions of everything as you're setting things up, then immediately passes it all to your graphics driver, and tries to avoid holding onto anything except the pieces it absolutely needs (e.g., for tracking whether resources are currently in use, whether certain things are complete, etc.).

So if you try to ask it something like "tell me all pipelines that are currently being used by draw calls on the gpu at this instant" then wgpu doesn't really have a good way to do that. That happens at the driver level as deciding how to schedule/execute the commands wgpu has submitted to the graphics driver

18:08:22
@groves:matrix.orggrovesYou could do rough approximations depending on your exact use case though. If you need more detail you could use the vendor-specific profiling that have ways of querying stats like this directly from your graphics driver18:11:25
@andar1an:matrix.organdar1an set a profile picture.18:55:49
26 May 2024
@wumpf:matrix.orgwumpf ErichDonGubler: got the next pr of the lifetime removal series out of draft, made sure that the commits make more sense this time https://github.com/gfx-rs/wgpu/pull/5620 11:09:23
@erichdongubler-mozilla:mozilla.orgErichDonGublerWoot! Excited to get to it during my work cycle. Mine starts on Tuesday this week. 🤘🏻11:44:14
@wumpf:matrix.orgwumpfEnjoy the day off!12:50:48

There are no newer messages yet.


Back to Room ListRoom Version: 5