Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Shared Texture Support #6742

Open
sam20908 opened this issue Dec 3, 2022 · 8 comments
Open

Shared Texture Support #6742

sam20908 opened this issue Dec 3, 2022 · 8 comments
Milestone

Comments

@sam20908
Copy link
Contributor

sam20908 commented Dec 3, 2022

Since SDL3 has begun its development, this may seem like the best time to support this feature.

In my case, this is needed primarily for imgui's viewports with SDL_Renderer. But, I imagine it'll also be very useful for other situations.

The comment that explains the need for this feature is here: ocornut/imgui#5835 (comment)

Petition the SDL developers to add (or accept a PR to add) a new SDL_RENDERER_TEXTURESHARING capability flag and allow sharing textures between SDL_Renderer instances of the same driver when supported.
This is probably the correct solution but is definitely more effort than I have time for right now. (I only looked into this because I also thought it'd be relatively quick and easy.)

@sridenour
Copy link
Contributor

IIRC you can't share textures across multiple Metal contexts. IDK if you can have one Metal context that works across multiple windows.

@ligfx
Copy link
Contributor

ligfx commented Dec 19, 2022

Metal can share textures just fine, as long as each context has the same MTLDevice. You can test off the main branch by getting rid of the explicit "Texture was not created with this renderer" checks, and it will Just Work™.

@sam20908
Copy link
Contributor Author

Any updates on this?

@jrynkiew
Copy link

jrynkiew commented Mar 2, 2023

I am also interested in this topic. Is anyone working on this?

@sam20908
Copy link
Contributor Author

It's been a bit, any updates?

@slouken slouken added this to the 3.x milestone Aug 27, 2023
@slouken
Copy link
Collaborator

slouken commented Aug 27, 2023

Feel free to add a PR for this!

@ocornut
Copy link

ocornut commented Oct 5, 2023

This would be quite desirable to get e.g. dear imgui multi-viewports working with SDL_Renderer without requiring user to enforce an OpenGL backend with SDL_SetHint(SDL_HINT_RENDER_DRIVER, "opengl");

My assumption is that this is quite easy to achieve.

I believe the only design debate is whether this should be always on or opt-in. I would be in favor of always-on as I don't think any drawback and feel it would be simpler for everyone (users and implementations). With some backends it depending on how SDL implement its multi-window it might possibly even be extra work to guarantee a separation.

(In case this may be of any use: Dear ImGui Backends for Metal, DX11, DX12, Vulkan, OpenGL and other support the sharing of resources in its backends: https://github.com/ocornut/imgui/tree/docking/backends. It is often a few lines of code)

@ocornut
Copy link

ocornut commented May 15, 2024

I dug into this a little bit today.

First of all I made a branch with dear imgui multi-viewports support for SDL_Renderer3 (fyi this is what multi-viewports means for dear imgui). Branch is currently not working because of this issue and another, but I assumed having this as a test-bed might be useful to someone:

On this specific "shared texture support". In October 2023 I posted "My assumption is that this is quite easy to achieve." but I dug very briefly:

  • DX11: I realized that each call to e.g. SDL_CreateRenderer() in the case of a dx11 backend would create its own DX11 device, so resources are naturally not shared. Therefore adding support for this doesn't seem like a simple change here and there, and may affect wider architecture.

  • OpenGL: i tried calling SDL_GL_SetAttribute(SDL_GL_SHARE_WITH_CURRENT_CONTEXT, 1); in my app + enforcing "opengl" drivers in SDL_CreateRenderer(). To my surprise it didn't "just work" as I expected it too.

I think it would be an enabler and non-issue if all SDL_Renderer shared resources (when using same driver naturally), but I don't know how much work it would be for SDL_Renderer.

I presume that generally work on e.g shaders support for SDL will naturally lead in that direction, aka people creating multiple SDL windows and multiple renderers are likely to want to share resources such as textures and shaders.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants