GL 3 + 4 support about syphon-framework

[bangnoise]

Yo - no core profile support yet. 3rd-party forks include

https://github.com/insidMWM/Syphon-OpenGL-3.2-core/
https://github.com/GameClay/syphon-framework/

Obviously support is on our todo list...

[casey]

Gotcha, thanks a bunch for the links!

[bangnoise]

What needs to be done:

• Client - minimal changes
• Server
  • split GL code into a separate class, of which a suitable subclass is created depending on the GL version of the context used to create the server
  • subclass for Legacy profile
  • subclass for Core profile (single for 3 + 4?)

[vade]

👍 !@!@#

We should also think heavily about we pass textures in / out. We might want to offer an FBO BLIT possibility for both Legacy and 3&4, so you can bind an already existing FBO that the app has, and blit it to Syphon (this is a faster mem copy and doesnt involve the actual rendering /rasterization pipeline to my knowledge), and possibly offer an FBO Blit for the client as well.

In theory those passes could improve performance as well as offer GL 2 Legacy and GL 3/4 Core Profile support in a single API.

Of course we leave the legacy API intact.

[bangnoise]

Ya sure FBO blit, given it its own issue #14

[rsodre]

Hi guys! Any news on this? I finally took courage to delve into GL3.
Looks like GL_TEXTURE_RECTANGLE_ARB has limited support on GL3, and GL_TEXTURE_2D accepts NPOT textures. Do you see Syphon going for GL_TEXTURE_2D, at least client-wise?

[vade]

IOSurface only supports texture rectangle last I checked so internally rect support need - :)

://:; mbl.dev.

On May 16, 2015, at 12:43 PM, Roger Sodré [email protected] wrote:

Hi guys! Any news on this? I finally took courage to delve into GL3.
Looks like GL_TEXTURE_RECTANGLE_ARB has limited support on GL3, and GL_TEXTURE_2D accepts NPOT textures. Do you see Syphon going for GL_TEXTURE_2D, at least client-wise?

—
Reply to this email directly or view it on GitHub.

[pizthewiz]

@eromanc's fork is said to support both legacy and core profile too.

[vade]

• - finish the state capture and restore code path
• - performance analysis on the shared context
• - performance analysis on state capture vs no capture

[bangnoise]

work in progress in core-profile branch

[bangnoise]

I cannot measure a performance penalty using a shared context and switching to it. I very much favour this as an approach as we needn't interfere with caller state. I would propose that all our GL work is done in the shared context with the exception of -bindToDrawFrameOfSize: and -unbindAndPublish - these would affect the caller's context, but only the FBO binding (which would be bound to the default 0 framebuffer on unbind). All preparatory work to build our FBO and attachments would be done in our private shared context. In the case of -publishFrameTexture:... we would switch to our private context prior to the bind/unbind, so no changes would be made in the caller's context.

Unless @vade or anyone has objections I will go with this and perhaps feedback from testers will affect the final decision on this.

[bangnoise]

Closing this as it's merged to master - alpha release is available, will move to final release soon unless any issues pop up.