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

GL 3 + 4 support #13

Closed
casey opened this issue Apr 9, 2014 · 12 comments
Closed

GL 3 + 4 support #13

casey opened this issue Apr 9, 2014 · 12 comments
Assignees
Milestone

Comments

@casey
Copy link

casey commented Apr 9, 2014

I'm using GLFW on Mavericks with an OpenGL core 4.1 context with forward compatibility turned on.

After my first call to bindToDrawFrameOfSize:, glGetError() returns GL_INVALID_OPERATION. Subsequent calls produce no error.

Everything still works as expected, however, and I can see my published frames in the Simple Client.

My guess is that something in setupIOSurfaceForSize: is causing problems, perhaps glPushAttrib, which is deprecated.

I would prefer to use publishFrameTexture:, but it doesn't work at all, I suspect because it makes much more extensive use of deprecated functions. Is there a branch lurking out there that fixes this, or a suggested workaround?

@bangnoise
Copy link
Member

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...

@bangnoise bangnoise changed the title bindToDrawFrameOfSize: results in GL_INVALID_OPERATION GL 3 + 4 support Apr 9, 2014
@casey
Copy link
Author

casey commented Apr 9, 2014

Gotcha, thanks a bunch for the links!

@bangnoise
Copy link
Member

bangnoise commented May 22, 2014

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
Copy link
Member

vade commented May 22, 2014

👍 !@!@#

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 bangnoise mentioned this issue May 22, 2014
@bangnoise
Copy link
Member

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

@rsodre
Copy link
Contributor

rsodre commented May 16, 2015

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
Copy link
Member

vade commented May 16, 2015

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
Copy link

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

@vade
Copy link
Member

vade commented Oct 12, 2016

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

@bangnoise
Copy link
Member

work in progress in core-profile branch

@bangnoise
Copy link
Member

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
Copy link
Member

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

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

No branches or pull requests

5 participants