Skip to content

Conversation

niklaspandersson
Copy link
Member

@niklaspandersson niklaspandersson commented Jun 26, 2025

  • Add texture property to const_frame that references the texture on the gpu
  • Replace GPU-CPU-GPU copy with GPU texture in screen consumer
  • With this, a screen consumer is more or less free if used in combination with any other consumer

@niklaspandersson
Copy link
Member Author

Doesn't work on Linux as is, because on linux we use different opengl "wrappers" in the accelerator and screen consumer.
If I build the accelerator using the sfml context like on windows (just removing the conditions in the accelerator cmakelists file, it works.

@Julusian, why do we have a separate context (using EGL) on Linux? I'm guessing there is a reason...

@niklaspandersson niklaspandersson marked this pull request as draft June 26, 2025 18:54
@Julusian
Copy link
Member

That was a recent change to support environments where X11 is not available #1624

But maybe that can be reshuffled to choose at runtime based on whether it is found to be available rather than being hardcoded this way.

@niklaspandersson
Copy link
Member Author

That was a recent change to support environments where X11 is not available #1624

But maybe that can be reshuffled to choose at runtime based on whether it is found to be available rather than being hardcoded this way.

Yea, I just had a look in the commit history and realized I should have looked there before asking :)

A runtime check sounds like the correct fix. I'll have a go at that...

@niklaspandersson niklaspandersson force-pushed the feat/gpu-screen-consumer branch from 39af23c to 89c130b Compare June 28, 2025 18:40
@niklaspandersson
Copy link
Member Author

I think this works now. I'm on vacation and haven't got access to my linux workstation. It runs fine(ish) in WSL, and selects context implementation based on the presens of a DISPLAY env var.

The screen consumer actually works in WSL now, with the sfml context. ...when using the EGL context it crashes in WSL, but that is not specific to this PR.

@niklaspandersson niklaspandersson marked this pull request as ready for review June 29, 2025 17:55
@niklaspandersson niklaspandersson marked this pull request as draft July 3, 2025 14:40
@niklaspandersson
Copy link
Member Author

There seems to be some issues with this still. Marking as “draft” until I’ve sorted it out

@niklaspandersson niklaspandersson force-pushed the feat/gpu-screen-consumer branch from 89c130b to a63ac5f Compare July 3, 2025 19:13
@TomKaltz
Copy link
Member

@niklaspandersson what issues were you having?

@niklaspandersson
Copy link
Member Author

@niklaspandersson what issues were you having?

My client had issues with glitching when he used this together with ndi- and decklink producers. I haven't been able to reproduce, but I've seen a video.

I just noticed that I was missing a fence to protect the gpu textures while rendering. I'll have him try it again now...

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

Successfully merging this pull request may close these issues.

3 participants