- This topic has 20 replies, 3 voices, and was last updated 8 years, 7 months ago by
.
-
Posts
-
While integrating Syphon, I’ve been running into an issue which I am having trouble tracking down. The texture sent to the Test Client is missing a triangle-shaped chunk at the top.
Inspecting the texture in the OpenGL Profiler shows no issues, and I am using this texture in my application as well and it also appears fine there as well. After a few debugging dead ends, I’m wondering if this could be because I’m using an OpenGL 3.2 CGL context.
This is a screenshot of the issue: http://yfrog.com/ntn3gcp
Almost certainly due to 3.2. We haven’t done anything to support 3.2 yet. Encouraging it even works a little! If you have the time and inclination to take a look at the framework code then patches would be most welcome.
No changes needed to SDK, but (as far as I can tell) the best way to do this is to publish the frame by calling bindToDrawFrameOfSize/unbindAndPublish then use glBlitFramebuffer to copy your framebuffer into the Syphon one. This eliminates all unsupported, fixed-function API calls.
My solution( https://gist.github.com/3156964)
CGLLockContext(_syServer.context);
CGLSetCurrentContext(_syServer.context);
[_syServer bindToDrawFrameOfSize:_syTexSz];
GLint syFBO;
glGetIntegerv(GL_FRAMEBUFFER_BINDING, &syFBO);
glBindFramebuffer(GL_READ_FRAMEBUFFER, _blitTarget->framebuffer);
glBindFramebuffer(GL_DRAW_FRAMEBUFFER, syFBO);glBlitFramebuffer(0, 0, _blitTarget->width, _blitTarget->height,
0, 0, _blitTarget->width, _blitTarget->height,
GL_COLOR_BUFFER_BIT, GL_LINEAR);
[_syServer unbindAndPublish];
CGLUnlockContext(_syServer.context);It could be useful to add a -[SyphonServer publishFramebuffer:imageRegion:textureDimensions:] method, something like this maybe: https://gist.github.com/3156985
This is an interesting proposal. Blitting to/from an FBO is probably going to be faster (assuming that there is no swizzling between formats, and sizes).
Definitely something to look at. Thanks.
I’ve got a GitHub branch of that proposal working, and I’m going to poke at a GL 3.2 friendly version of texture publishing via VAO and non-fixed function calls. Blitting will also resolve any kind of MSAA going on with that FBO.
The 2.x version should work via the APPLE extensions, and controlling shader code via the __VERSION__ macro. I’ll do a post once I have that branch uploaded.
I was speaking with @bangnoise about this a touch earlier today.
I’m not 100% up on all of the 3.2 nuances, but is there a way to have the same code path work in 3.2 and 2.1 ? My understanding is generic vertex attributes replace all vertex/texture coordinate/normal etc matrices, modes, like OpenGL ES 2.0. This means we’d need a custom shader, shader loading, and additional state management in the framework, correct?
Do you mind putting a giant caveat on the git page for that Syphon Framework that states its not to be used with any shipping code? We’ve tried to do a really good, conservative job with not letting too many pre-release code bases get out in the wild, since compatibility is key. Just saying 🙂
Thanks for tackling this! We definitely want 3.2 compatibility, so any input / insight on this is huge. Thanks again!
Sure thing, will do. Also all work I’ve done is in a different branch, the ‘master’ branch is SVN trunk imported straight from the Google Code repo.
As far as the code path that works for 3.2 and 2.1, that should be entirely possible. The shader code can work in 2.1 and 3.2 and do conditional compilation based on the ‘__VERSION__’ macro. The other code is shared. As far as I’ve found, the only GL function pointers that are different are the VAO pointers (which is kind of odd). Otherwise it’s all going down to the same driver, and the names of the functions (with ‘EXT’ appended or not) doesn’t actually matter. The #defines are the same (for example GL_TEXTURE_RECTANGLE, GL_TEXTURE_RECTANGLE_EXT and GL_TEXTURE_RECTANGLE_ARB all boil down to the same value), so it shouldn’t be a problem.
The state management could be an issue. There is no longer any kind of glPushAttrib() stuff in 3.2, so that could be problematic depending on what people are relying on.
Bottom line though is that the framework, as is right now, will work with OpenGL 3.2 provided that you don’t use ‘publishFrameTexture’ since that uses the fixed-function path. Pulling a texture out of Syphon works just fine, and like I said GL_TEXTURE_RECTANGLE boils down to the same value, and works without issue (at least on my GeForce MX260).
I’ll keep you guys updated when I can get a chance to poke at this again, since the weekend is now over 😉
Had some time today. This branch has a version of publishFrameTexture which is both OpenGL 3.2 and 2.1 friendly: https://github.com/GameClay/syphon-framework/compare/PSW-OpenGL3 (Diff view)
Here it is all working: http://yfrog.com/z/mgc2wvp
My app is using an OpenGL 3.2 context and my modified version of Syphon publishing using the publishFramebuffer method I added. The Simple Server is using an OpenGL 2.1 context and my modified version of Syphon using the modified publishFrameTexture. The Simple Client is the pre-compiled Syphon example using the current downloadable framework version.I’m not 100% solid on this, since I’ve only run it on 10.7, but it should run just fine, or require very few changes.
Nice.
Looking at this, I think checking the context version via the CGLContextObj’s pixel format, which lets you query kCGLPFAOpenGLProfile / either kCGLOGLPVersion_Legacy or kCGLOGLPVersion_3_2_Core.
Secondly, I think state is going to need to be tracked *really* tightly. Shader loading, VAO / VBO /VA attribute caching / re-binding for pointers, error checking, etc. Its a lot.
I am almost wondering if a second compatible share context should be setup, so OpenGL state cannot be corrupted in the parent applications context that Syphon was initialized with. That has drawbacks (state switching, etc), but grants us some potential leniency.
@bangnoise is out until next week – He has done a lot of amazing re-engineering of Syphon, and frankly has better fundamentals than I. I am curious of his thoughts. What is your timeframe for your app, out of curiosity?One thing you can do, is attempt to swap in your Syphon framework in Apps that are Syphon aware, and see how they run. VDMX, Mad Mapper, Resolume Avenue 4, and CoGe all come to mind to test, as they have a lot of different OpenGL state assumptions to juggle.
Good notes, I agree about that 3.2 detection via the CGLContext. Way better way of doing it.
A second context is something I have in my app so that resource loading can take place on other threads. The only issue is that I have found FBO’s need to be created/updated on the main context. There could be a creation parameter I am missing though so I’m not certain.
Agreed on the state caching. I *think* I nailed all the states in my implementation, and made sure to not corrupt any VAO state by having the existing VAO bound during any function calls which modify VAO state. It’s really hard to know for certain, though.
I don’t really have a timeframe for my app. I’d like to get a version 1 out early next year. My company does game development and contracting primarily, this is just something I’ve been thinking about for several years and the other guys at the company think is cool and maybe get a revenue stream out of it.
I’m planning on grabbing those programs and doing just that once I make a few more changes and adjustments to what I’ve got so far. I’ll likely do that in the upcoming weekend.
Hopefully this bears fruit. Like I said in the first post, I can publish from OpenGL 3.2 using the unmodified libs using the pasted code, so I’m not too worried. Both of you have done great work on Syphon, and I was pretty damn excited that I could make my app more targeted and focus on what it’s good at, instead of trying to create a whole suite that can compete with the existing players in the market.
Quickly, re: FBO’s, I am pretty sure Apple has notes about that, and that you have to do a GLFlush, or a glFlushAppleRenderer (which is a touch more lightweight as I understand it), to get cross thread/context state changes synced. I’m pretty sure that should work.
Hah, well I’ll be damned…glFlushRenderAPPLE() was the droids I was looking for.
I’ll see how creating a different context goes. That could be the cleanest solution and thread-friendly to boot.
Edit: Well that was easy. Works great. I was able to nuke all the state store/restore stuff and simply get/restore the CGL context instead. Changes pushed to PSW-OpenGL3 branch on GitHub (Diff). Also it seems to be a performance increase, but that could just be subjective. I’m tempted to do some profiling.
I pulled down the demo for those apps and copied in my modified framework. It works without issue in: Resolume 4, CoGe, and VDMX5.
Mad Mapper did not seem to load the plugin at all. I’m not sure why. No crash, Syphon just didn’t show up as a source, nor did it produce output. Nothing useful in the Console either, didn’t seem to even try and create objects.
I’m working my way up this thread backwards as I catch up – first of all thanks @ZeroStride for all your work. I haven’t looked at your changes yet but excited to get to that.
MadMapper uses a newer version of the framework – it’s on google code as a branch (public-beta-2-gc). Your version is probably failing due to missing symbols from that version. We need to integrate those changes back to trunk.
Using <OpenGL/CGLMacro.h> you don’t need to get/store/set the CGL context at all – just make sure the variable named cgl_ctx is the one you’re drawing into and the macros will direct glFunction calls to the appropriate context. Otherwise at first glance I heartily approve these changes.
ORLY? That sort of magic frightens and confuses me, but ok. I’m used to things biting me in the ass when I don’t do them exactly correct.
That makes sense about the other branch, I’ll give that a try later and see if Mad Mapper is happy.
I’m still toying with the VAO-based draw for publishFrameTexture. I’m curious to know if it’s faster to calculate tex-coords on the CPU and then update the buffer, or if I should be doing it in the vertex shader with shader constants. I strongly suspect that it doesn’t matter, but I am curious.
EDIT: Removing the get/set/restore stuff for the CGL context worked ok in CoGe but VDMX5 did not like it at all. Reverting those changes made VDMX5 happy again.
Then something is wrong. Using cgl_ctx for and CGLMacros should always be used, it makes can make a large difference end of day. We can eventually take a look and see whats up.
I haven’t used CGLMacros because it errors if you include gl3.h, and doesn’t have any GL3 functions exposed.
Interestingly enough, after digging through headers, gliDispatch.h (definition of struct for GL function pointers) there are pointers for up through OpenGL 3.3 in there. Each of the CGLMacros evaluates to looking up the function pointer, and then auto-passing the renderer in as the first parameter to that function pointer, followed by the standard GL args.
It seems like support could easily be added for the GL3 functions to this. I’m wondering what Mountain Lion looks like (I haven’t upgraded). This is interesting stuff.
- You must be logged in to reply to this topic.