But, the stikiest of sticky points is this -- display link causes your rendering to be performed in a separate "high-priority" thread. This is fine, and my simple test app already successfully renders, but it does cause problems.

1) In my resize callback, gl explodes. The reason why is simple -- the NSOpenGLView -reshape method is called on the main thread ( not the display link thread ) and in my test app, some GL functions are invoked, specifically, regarding FBO creation/deletion/etc.

2) In my game logic, running from a timer on the main thread, it is possible that gl code may be invoked periodically. For example, loading a texture for a particle system created in response to a collision.

Generally my code-base keeps GL code inside of the rendering loop. But loading textures, shaders etc can and does happen in the game logic loop now and then. In principle, I could rewrite my code to lazily note that said resources must be loaded and then load them in my rendering loop. But it would be nice to know if there's a way to lock access to GL in my game loop to safely access these resources.

Anybody here have any experience with display link? Any general notes on how to not shoot your toes off?

It's been a while since I tried DisplayLink, but here's what I recall:

1) For me, it didn't do squat in terms of being less jerky than a 1k timer. "high priority" timer only means that you don't need to over-rev it like a 1k timer, which is technically more efficient in terms of system usage, but it doesn't change the core issue of synching drawing perfectly with the display refresh.
2) I seem to recall you have to lock the context before touching the GL or things can go bonkers because of the threaded nature of the DisplayLink. (CGLLockContext/CGLUnlockContext every time you touch GL)

Unless I pull anything that invokes GL out of my game/event loop I will have to have a very coarsely-grained lock on the gl context; resulting in completely synchronized rendering, losing any benefits of the display link approach.

Not to mention the complexity of making certain that the rendering thread can either locklessly render the scene while it may be mutated by the game thread, or having -- again -- a very coarsely locked mutex wrapping the whole shenanigan.

I had the large majority of my GL code localized, minus a few loading routines, so a simple, "coarse", once per frame lock worked fine for me (plus locking around the loaders of course). YMMV, but like I said, I didn't get any magic boost in smoothness from DisplayLink, so if it's too much trouble for you to implement, I'd wager you're probably not missing much.

I'm planning on staying the course for this testbed -- see if I can make it work, sans any crashes, using coarse locking. If it works, Then I'll decide if it's worth it...

But, man, lots of crashes. I'm porting my CSM demo app from last year to display link and basically everything crashes (10% of the time). Changing the shadow mapping technique, for example, causes new shaders to be loaded on the main thread ( not rendering thread ) so BOOM.

It's advisable to be generous with locks and setting the current context (which is per thread). Another clever scheme is to use a shared gl context to load the resources, and another to render from, as (supposedly) synchronization of the two contexts is taken care of in the driver.

As far as DisplayLink goes, your only advantage is that you can minimize the time spent blocking for a VBL in the best case. DisplayLinks use some black-box method to estimate when you need to start rendering to output a frame right on time, which is if course wildly inaccurate when your physics loop is also triggered by the DisplayLink callback, or you are maxing out the CPU anyway.