# Vulkan Bindless Native Plugin for Unity 6

**URL:** https://discussions.unity.com/t/vulkan-bindless-native-plugin-for-unity-6/1731496
**Category:** Device, Driver, & APIs
**Tags:** Textures, Vulkan, Conversation, unspecified-version
**Created:** [July 20, 2026, 12:07am UTC](https://discussions.unity.com/t/vulkan-bindless-native-plugin-for-unity-6/1731496 "2026-07-20T00:07:37Z")
**Posts on this page:** 5
**Page:** 1

<div class="post-metadata">

### Author: ![saivs1](https://dub1.discourse-cdn.com/unity/user_avatar/discussions.unity.com/saivs1/32/1018331_2.png) [@saivs1](https://discussions.unity.com/u/saivs1)
#### Post date: [July 20, 2026, 12:07am UTC](https://discussions.unity.com/t/vulkan-bindless-native-plugin-for-unity-6/1731496/1 "2026-07-20T00:07:37Z")

</div>

Hey everyone!

I’ve just released a free open-source native plugin that adds **bindless textures** to Unity on Vulkan - something the engine doesn’t expose in any form.

**GitHub:** [GitHub - saivs/com.saivs.plugin.bindless.vulkan: A native plugin that brings true bindless textures to Unity (Vulkan) · GitHub](https://github.com/saivs/com.saivs.plugin.bindless.vulkan)

## What is bindless, in plain words?

Normally, before every draw call the CPU has to tell the GPU exactly which textures that draw is allowed to use: “slot 0 is the albedo, slot 1 is the normal map”. Textures are part of the draw’s _state_ - so every object with a different material needs its own draw call, and the CPU pays for every rebind. Half of what batching systems do is fighting exactly this.

**Bindless flips it.** All your textures live in one big table on the GPU, bound once. A shader picks any texture at runtime by a simple integer index:

```hlsl
half4 albedo = BINDLESS_SAMPLE(material.albedoSlot, uv);

```

The texture stops being state and becomes plain _data_ - a number you can store in buffers, pass around, and change per instance.

## What can you actually do with it?

- **Render thousands of objects with different materials in a single draw call.** The GPU reads each object’s texture indices from a buffer and samples the right textures itself. This is the missing companion to indirect rendering - it pairs perfectly with my [Multi-Draw Indirect plugin](https://github.com/saivs/com.saivs.plugin.mdi).
- **Forget atlases and Texture2DArray restrictions.** Any mix of resolutions, formats and compression in one table - and every texture keeps its _own_ sampler (filter/wrap/aniso from its import settings).
- **Texture streaming becomes trivial.** Registering and unregistering is a cheap descriptor write at runtime - load what the camera needs, evict what it doesn’t. No atlas repacking, no material changes.
- **GPU-driven material systems.** Materials become plain structs in a `StructuredBuffer` with texture indices inside.

## Integration is two lines

```csharp
uint slot = VulkanBindless.Register(texture); // C#: texture goes into the global heap

```

```hlsl
half4 color = BINDLESS_SAMPLE(slot, uv); // shader: sample it by index

```

Texture lifetime is handled for you - editor re-imports are picked up automatically, destroyed textures free their slots, and a stale slot samples white instead of crashing. A runnable sample (a cube grid drawn with one `RenderMeshIndirect` call, every cube with its own texture) ships with the package.

## Requirements

- Unity **6000.0+** , **Vulkan** graphics API
- A GPU with descriptor indexing: effectively any desktop GPU from the last decade; on Android - Adreno, or Mali from Valhall on
- Windows and Android binaries included (Linux planned)

## ⚠ Disclaimer

The plugin integrates seamlessly - no engine modifications, your project code only sees a tiny C# API and one shader include. **But under the hood it works at a very deep level** (it intercepts Unity’s Vulkan device creation and patches pipeline layouts and shader modules on the fly). It’s freshly released and validated on a limited set of hardware so far.

**Please don’t ship it in production just yet.** Try it in experiments and prototypes, and if something breaks - the plugin has a built-in diagnostics panel and captures its native log, so please open an issue on GitHub with that output. Reports from different GPUs/drivers are the most valuable thing right now.

Feedback, questions and contributions are very welcome!

---

<div class="post-metadata">

### Author: ![mgeorgedeveloper](https://dub1.discourse-cdn.com/unity/user_avatar/discussions.unity.com/mgeorgedeveloper/32/397509_2.png) [@mgeorgedeveloper](https://discussions.unity.com/u/mgeorgedeveloper)
#### Post date: [July 20, 2026, 1:31pm UTC](https://discussions.unity.com/t/vulkan-bindless-native-plugin-for-unity-6/1731496/2 "2026-07-20T13:31:33Z")

</div>

Honest question - if this is so obvious and powerful, why isn’t this provided by Unity and across different graphics APIs that support it? Is there some constraint holding them back, e.g. no easy way to have it working automatically and in a general-purpose way that is compatible with the material / renderer paradigm?

A good fit seems to be BRG / GRD which seems to be the core upgrade over regular SRP Batcher where they do all the instanced stuff and lean into big persistent graphics buffers.

---

<div class="post-metadata">

### Author: ![saivs1](https://dub1.discourse-cdn.com/unity/user_avatar/discussions.unity.com/saivs1/32/1018331_2.png) [@saivs1](https://discussions.unity.com/u/saivs1)
#### Post date: [July 20, 2026, 2:12pm UTC](https://discussions.unity.com/t/vulkan-bindless-native-plugin-for-unity-6/1731496/3 "2026-07-20T14:12:28Z")

</div>

Hello! Since I worked on this plugin and the MDI plugin, I can answer this question with certainty (however, I may be wrong). Unity doesn’t implement this technology because it’s not supported at all on some devices and graphics APIs. For example, on old phones from 5-10 years ago, the web interface doesn’t support it at all, and OpenGL and D3D11 also don’t support bindless. I draw this conclusion because everything Unity currently supports is supported on most devices. So, this is most likely a business decision. Unity is primarily a cross-platform engine, so almost all features should work on most devices. I think they could implement a flag like they did for SystemInfo.supportsComputeShaders, but for features like Bindless.

Specifically, Vulkan supports Bindles on most modern devices, even budget ones.  
Bindless is a feature that can do many things, such as eliminating atlases entirely while still allowing you to stream every texture in any format. It also opens up the possibility of full-fledged raytracing on mobile devices.

Regarding BRG / GRD, I’m not entirely sure, since these systems are a compromise that essentially just combines drawcalls (objects with the same mesh and material are rendered together) and gives developers control over rendering and culling, but this does not reveal the full potential of GPU-Driven rendering, that is, it seems to me that BRG was created for a slightly different purpose.

---

<div class="post-metadata">

### Author: ![Manuel\_H](https://dub1.discourse-cdn.com/unity/user_avatar/discussions.unity.com/manuel_h/32/613841_2.png) [@Manuel\_H](https://discussions.unity.com/u/Manuel_H)
#### Post date: [July 20, 2026, 7:07pm UTC](https://discussions.unity.com/t/vulkan-bindless-native-plugin-for-unity-6/1731496/4 "2026-07-20T19:07:00Z")

</div>

You managed to solve the last piece of the puzzle as well, amazing news. I’ll definitely be integrating and testing this when I’m done with my current workload. Does your API expose some check for whether bindless is supported on the current system? Because I’ll need to fall back to texture arrays when it’s not, to still be able to dispatch mdi calls spanning multiple textures. On your mdi plugin you can fall back to a managed draw loop in the plugin (which is great since it saves me handling this case myself) but since I’m guessing the fallback here would be one call per texture I’d rather handle this myself with a runtime texture array.

Regarding Unity not implementing this themselves, I’m not giving them the benefit of the doubt this time. These are render features that have been widely supported by hardware and graphics APIs for a long time, and Unity has pumped huge sums of money into features with limited platform support like entities or vfx graph. Even with their latest dabble into gpu driven rendering (with their gpu resident drawer - another system with limited support) they have not bothered exposing mdi and/or bindless textures for users not wanting to be confined to their systems.

Anyway, thank you so much for advancing graphics programming in Unity. I’ll report back when I’ve had time to test it.

---

<div class="post-metadata">

### Author: ![saivs1](https://dub1.discourse-cdn.com/unity/user_avatar/discussions.unity.com/saivs1/32/1018331_2.png) [@saivs1](https://discussions.unity.com/u/saivs1)
#### Post date: [July 20, 2026, 7:19pm UTC](https://discussions.unity.com/t/vulkan-bindless-native-plugin-for-unity-6/1731496/5 "2026-07-20T19:19:51Z")

</div>

Yes, there is an option to check support.

```auto
if (!VulkanBindless.IsSupported)
    return; // fall back — see GetDiagnostics() for the reason

```

I actually have an idea for how to support limited Bindless on devices that don’t support it without TextureArray. So I’ll try to implement fallback support without changing the API.  
I’m currently working on RenderTextures support.

EDIT: Just made an update with RenderTextures support. However, this feature requires testing.
