With bevy can you access the underlying opengl pipeline?

[green schooner]

So if I wanted to use it in conjunction with Iced or have some C or C# or for a whole host of reasons I can connect to or access the opengl context/pipeline

[winter chasm]

No, because we don't target opengl. While it's technically possible to tell wgpu to target opengl this is not a supported target for bevy and the opengl backend isn't a priority for wgpu

[green schooner]

If not opengl, then vulkan? Or what type of graphics library does bevy use. That you can make a shared context or pipeline top

[winter chasm]

we use wgpu which targets vulkan/dx12/metal on desktop platforms and webgl/webgpu on the web

we don't target a single graphics api

although, on native it defaults to vulkan everywhere except macos

[green schooner]

So, if you were to use bevy to target vulkan, is there a shared vulkan context or pipeline you can establish?

For uses across libraries or languages

[winter chasm]

not sure @hardy iris might have an answer though. IIRC they did things that used the vulkan context

[hardy iris]

You can get the underlying device, queue, etc that wgpu uses. But until wgpu 25 / bevy 0.17, there won't be any facilities in wgpu to add your own barriers. So you won't be able to synchronize your own work alongside wgpu properly.

It's coming though, I have a PR under review

Which I intend to use to add DLSS support to bevy

[winter chasm]

don't you mean 0.16?

[hardy iris]

No 0.16 is going to ship with 24, right?

Rn 0.16-dev is on 23

My pr hasn't been merged yet, it's not in 24

[winter chasm]

Oh, yeah, wgpu is on 24 right now

I thought the last release was 25

then 0.17 is a good estimate yeah

[green schooner]

Can you link the PR please?

[hardy iris]

https://github.com/gfx-rs/wgpu/pull/6678

Actually @prisma heron would there ever be an issue where you need a pure barrier, but not a resource transition when doing interopt with native? I could see there being an issue where wgpu omits the barrier because the texture is already in the correct state, but the user actually wanted an execution barrier... We might need to redesign the API in my pr

[prisma heron]

if you transition from -> to the same format, but that format is read/write and does not have a hardware defined order, we'll always insert a barrier

to STORAGE_WRITE -> STORAGE_WRITE still includes a barrier

[hardy iris]

Oh phew, thanks for letting me know

[prisma heron]

wgpu wouldn't work otherwise

[hardy iris]

Yeah makes sense when I think about it