Forum Replies Created
-
Posts
-
This is fixed/updated in the PSW-OpenGL3 branch. I added GL3-friendly macros in the style of CGLMacro.h to SyphonServer.m GL2 uses the EXT version of VAOs, and the ARB version won’t work, whereas GL3 uses the ARB version and the EXT won’t work.
Resolume Avenue 4 still needs the current context set. They are not using texture-publish, but instead using the framebuffer bind, and doing their own rendering/blitting/whatever. They also appear to be using GLEW so who knows what is going on. VDMX, CoGe, and the test apps are all fine with the changes.
Re: The performance thing. I’d be really interested to see how that actually plays out. Since context is per-thread, it must be using TLS to store the active CGL context. Accessing a TLS variable is not all that expensive, so I’d be really surprised if there was significant performance overhead. That being said, it was interesting to poke through and see where the GL2/3 difference was in VAO’s, and since Syphon uses the CGLMacro style, I have no problem matching that style.
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.
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.
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.
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.
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.
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.
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 😉
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.
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
