Advertisement

SDL + OpenGL + OSX + Multithreading

Started by June 15, 2013 09:27 PM
3 comments, last by swiftcoder 11 years, 5 months ago

Hi all,

I understand there's issues with OpenGL and Multithreading, but what I want to do seems so simple that I feel like there MUST be a simple way to do it.

Here's what I do:

1. My game starts, and loads up some loader display graphics immediately, in main thread.

2. A thread is started to load a bunch of graphics. None of these graphics will be displayed at any point during all of this.

3. BUT: OpenGL renders the loader graphics (along with a progress bar) in main thread.

Special notes: ALL rendering is done in the main thread. The secondary thread is *only* to load bitmaps and push them onto OpenGL textures.

This works flawlessly on Win32 using DirectX. But using OpenGL, I get a crash. I've been googling for any information about how to make OpenGL handle this, but everyone seems to be addressing problems much more complex than mine-- that is, OpenGL trying to render/show from multiple threads.

I don't want to do that-- all I want to load is load textures (and bind them) in a seperate thread, with the program aware that it can't render any of these until the thread completes.

But surely there's a way for me to do this using OpenGL, right? Note that I am using SDL in my mac port, so the OpenGL subset might be a little different. But this is a such a basic and necessary task that I can't imagine it not being possible and easy... right?

Thanks in advance!

What exactly is crashing?

There are two general approaches to accomplish what you are trying to do:

  • Create a shared context for the second thread to load the resources into, or
  • Load the resources into memory on the second thread, but upload them to OpenGL on the primary thread

Which approach are you using?

Tristam MacDonald. Ex-BigTech Software Engineer. Future farmer. [https://trist.am]

Advertisement

Hi, thanks for the response.

It's crashing in different places-- but always in the openGL libraries. I know why-- it's because I haven't lifted a finger yet to try to make the OpenGL multithreaded, because I have no idea what the commands are.

I want to go with the shared context approach, but I don't know enough to even google the commands and syntax I'll need for that. Trying to find the information just gets me tons of pages saying "use a shared context" without the specific code to do it.

(I've done the resource load/bind later method before, but I want to go with the shared context approach to avoid having nasty split up spaghetti code... want all my texture loading in one easy to find place and invocation).

Hey, SwiftCoder, your post made me able to google the right thing somehow. So I have it loading threaded now. Wow, what a lot of thread lock/unlock commands one needs with OpenGL....


Wow, what a lot of thread lock/unlock commands one needs with OpenGL...

That's because OpenGL is fundamentally single-threaded. You have to call OpenGL functions from exactly one thread at any time.

Which usually means that it's safest/easiest to have a single thread that does all communication with OpenGL, and have your worker threads just hand that thread data, when they need something to be uploaded.

====

The other approach (with the shared context), shouldn't require very much locking at all. When you create your context, create a second context, that shares resources with the first. Loading into either context should cause resources to appear in both.

Unfortunately, because your primary context is being managed by SDL, that may be rather difficult to set up...

Tristam MacDonald. Ex-BigTech Software Engineer. Future farmer. [https://trist.am]

This topic is closed to new replies.

Advertisement