Jump to content

  • Log In with Google      Sign In   
  • Create Account


SDL + OpenGL + OSX + Multithreading


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
4 replies to this topic

#1 Raptisoft   Members   -  Reputation: 171

Like
0Likes
Like

Posted 15 June 2013 - 03:27 PM

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!

 

 

 

 

 

 



Sponsor:

#2 swiftcoder   Senior Moderators   -  Reputation: 8148

Like
1Likes
Like

Posted 15 June 2013 - 10:06 PM

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 - SDE II @ Amazon - swiftcoding        [Need to sync your files via the cloud? | Need affordable web hosting?]


#3 Raptisoft   Members   -  Reputation: 171

Like
0Likes
Like

Posted 16 June 2013 - 04:58 AM

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



#4 Raptisoft   Members   -  Reputation: 171

Like
0Likes
Like

Posted 16 June 2013 - 09:37 AM

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



#5 swiftcoder   Senior Moderators   -  Reputation: 8148

Like
0Likes
Like

Posted 16 June 2013 - 10:25 AM


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 - SDE II @ Amazon - swiftcoding        [Need to sync your files via the cloud? | Need affordable web hosting?]





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS