-
Notifications
You must be signed in to change notification settings - Fork 80
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
Metal Syphon #56
Metal Syphon #56
Conversation
Looking forward to taking a look at this. Please can you move your demo apps out of this PR and into their own project (they'll be very useful, but this project only contains the framework). |
Thanks! Sorry for the delay! Im going to take a look at this today! Very much appreciate all the work and support! |
Hi. So firstly, thank you again for this work! I have a question or two - mostly a question regarding how the Metal API should be expected to be integrated into other apps. It looks like when initializing a Metal Client or Server, a device is passed in and an internal I am curious why not pass in an existing I may be overlooking some important use case that requires a separate For the client server, it might be helpful to manage an MTLHeap from which we manage textures from. I know this is helpful for managing the cost of allocations - but to be frank im not sure if IOSurface backed textures mitigate any of those gains, or if its helpful in any way, so feel free to ignore this paragraph :D Im going to attempt to use integrate your Metal Branch as is and report any issues. Another good note is, this looks very easy to wire in the experimental Float support from our old Float branch. Thanks again! |
Oh, one last note. It would be a nice quality of life addition if for the public headers there was some similar documentation in the code - but I understand thats a big ask w/o knowing if a PR will be merged. Maybe we can Q/A check this and add it later. More of a running TODO note. MSAA might be the only functionality blocker I see right now. And to be fair ive not experimented with that in Metal yet. |
Regarding my CommandQueue point: Pro: Users can create a command queue and a command buffer from it, submit their own commands, and then interleave a server publish command wherever they want. Their app only has a single command encoder (or as as many as they need) and a single command buffer for the frame. Con: Users of the API need to submit their command queue themselves. Is that a con? Thinking aloud. |
Hi, Regarding the
[syphonServer drawFrame:^(id<MTLTexture> syphonTexture, id<MTLCommandBuffer> commandBuffer) {
// Here : user renders into the syphon texture inside this block of code
// The provided commandBuffer is 'myOwnCommandBuffer'
} size:textureSize commandBuffer:myOwnCommandBuffer];
[syphonServer publishFrameTexture:theUserTexture];
// alternatively
CGRect region = CGRectMake(0, 0, serverTexture.width/2, serverTexture.height)
[syphonServer publishFrameTexture:theUserTexture imageRegion:region flip:YES]; For the What do you think about this API? And of course no problem to provide better docs once the API is validated! |
Hi there! I wanted to say thank you for all your hard work on this. We're in the process of updating QLab to use Metal, and had been expecting to have a tough slog ahead of us in getting Syphon updated, so this work is super appreciated! We've largely switched to using raw IOSurfaces internally, and we could manage to make that work with the current Syphon implementation for now, but it would be really amazing to be able to link to a pure Metal implementation instead. Personally, one minor thought I had is that the first API method would look a little more idiomatic if the block were the last argument (e.g. That said, we're using Objective-C, and would be using the I see what look like maybe hopeful hints of next steps in another PR, but in the meantime, is there anything we can do from our end to help validate this, aside from pulling it in and putting it through its paces? |
Using this and letting us know what makes sense for you API-wise would be a great help (plus noting any problems you hit). We've all had commitments elsewhere, but I'm aiming to spend some time on this in the next couple of weeks, it would be great to firm up a final API. |
This comment has been minimized.
This comment has been minimized.
Hi akuz, Two demo apps (server and client) are available on this commit: https://github.com/anome/Syphon-Framework/tree/11dc66758bc9142bb3a497ea774e473fafe5a7e2 Hope this helps! |
|
|
Hi, We have updated the PR
Updated demo apps : Waiting for your feedback |
Sorry I missed these questions! For our part, we don't have a use case for the |
Hi, I just wanted to put a plug in for this patch. We tested this last week on multiple computers running for an entire week with many simultaneous syphon servers/clients (eg. > 30) under very heavy load and it worked great - more stable than using OpenGL (That's not Syphon's fault in particular, mostly Apple's old OpenGL implementation). Thanks a lot for putting this together! |
I'm guessing that even once this has been merged and people start using it, it will be a long time before client apps can stop also looking for OpenGL servers? I'm assuming the Metal client isn't compatible with OpenGL servers? What's the strategy here? Is anybody thinking about how to abstract this concern (if that's even possible) to simplify migration? Providing documentation feels important here, e.g.
How much of this migration strategy can be abstracted away from developers and embedded into the framework, and how much is just tricky work that everybody needs to do? |
They are compatible. A metal client can see a OpenGL server and vice versa due to IOSurfaces underlying backing.
http://vade.info
… On May 21, 2022, at 12:10 PM, Michael Forrest ***@***.***> wrote:
I'm guessing that even once this has been merged and people start using it, it will be a long time before client apps can stop also looking for OpenGL servers? I'm assuming the Metal client isn't compatible with OpenGL servers?
What's the strategy here? Is anybody thinking about how to abstract this concern (if that's even possible) to simplify migration?
Providing documentation feels important here, e.g.
Minimal examples of how to capture OpenGL textures from legacy Syphon servers and convert these to Metal textures (based on this Apple document?) as a stop-gap to dropping OpenGL support in future
Best practices for consuming both types of server at once
Examples of how to migrate from OpenGL to Metal for server developers
How much of this migration strategy can be abstracted away from developers and embedded into the framework, and how much is just tricky work that everybody needs to do?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.
|
So both client and server developers can use whichever technology they want, and they'll all be able to see each other? Amazing! |
Correct!
http://vade.info
… On May 21, 2022, at 12:24 PM, Michael Forrest ***@***.***> wrote:
They are compatible. A metal client can see a OpenGL server and vice versa due to IOSurfaces underlying backing.
So both client and server developers can use whichever technology they want, and they'll all be able to see each other? Amazing!
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.
|
Hi... |
@smilingthax where are your IOSurfaces coming from? If you're able to work with the existing SyphonServerBase and the methods in SyphonSubclassing.h you'll see better performance as we can reuse a single IOSurface. |
Can SyphonIOSurfaceServer be its own PR anyway? I don't like it though for the above reason ^. This PR needs to be rebased to remove all the redundant commits with demo apps, etc. |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
a6ba9d5
to
cc4b564
Compare
A client may not have a surface if the server hasn't published yet, so don't treat it as an error
- also delete pointless mvars
- by locking around surface access it's trivial to allow thread-safe publishing from multiple threads
…m superclass - re-declare superclass' methods for easy reference from header
… access - missed from dfe3dfa
I've dropped the pre-subclassing commits from this, as well as the commits with the demo apps and some changes which weren't related to Metal. The final state at cc4b564 is identical to the original, minus the unwanted history. I've fixed a bunch of leaks of MTL objects (we will move the whole project to ARC after this is merged), added missing documentation, deleted some unused code, added synchronization around access to the surface in SyphonMetalServer so the class is completely thread-safe. @mto-anomes and @anome I'm adding copyright notices to the files you've added - it would be good to add your names. How would you like to be credited (ie by what names)? |
Hi @bangnoise, Thank you. Best. Philippe |
- SyphonMetal... classes were under deprecated headers - update overview in Syphon.h to use Metal - remove reference to Syphon forum - indentation fix
Massive thanks to @mto-anomes and @anome for the initial work on this, and to those who've offered suggestions and feedback. There are a few remaining potential enhancements which I've opened as #85 Use a single SyphonServerRendererMetal per MTLDevice Any comments welcome on those issues - I'll do #85 at least in the near future. Thanks all! |
Hi,
Here is our updated version of Syphon implementation for Metal using the new subclassing refactor.
I am of course welcoming your feedback to improve the PR !