The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.

The guides and libSDL documentation I have seen warn me that it is Bad Juju to have more then one thread render stuff at the same time.

I wondering is this applies to OpenGL rendering with libSDL aswell, and ifso, to what extent.
Would it be OK as long as you guarantee that 2 threads never touch the same pixel at the same time?
Would it matter if you use SDL 1.2 or 1.3 for multi-thread OpenGL rendering?


Thanks in advance!

In case of OpenGL it is not even possible to issue GL commands to renderer from within other thread that the one that created OGL rendering context. Only OGL driver implementation that is thread safe (it is possible to issue commands from many threads) is on Mac OSX so it is safe to say that there is no portable library that will allow doing it safely in general.

If you really need "threaded renderer". Spawn new renderer thread, create OGL rendering context from it, then talk to the context only from that thread. Main thread communicates with renderer thread with safe message que.

Hello,


I did this exact thing for my OpenGL GUI. You can use it from multiple threads, but all OpenGL commands are pushed as events to the queue and main thread is executing them through OpenGL... works quite good and I don't see any overhead.


Pavel

On 18.4.2010, at 11:50, hardcoder wrote:


---
Pavel Kanzelsberger
http://www.kanzelsberger.com
E-Mail:
Jabber:, ICQ: 20990633

This is the best way of doing it. Let just one thread take care of drawing, and send update requests
to him from another threads.

No need to complicate things.

DirectX 11 supports multithreading rendering, but I doubt there is much to gain from it, when compared
with a proper separation of the application subsystems across processors.

--
Paulo

On Sun, Apr 18, 2010 at 12:39 PM, Pavel Kanzelsberger wrote:

As I understand it, most of the actual hardware rendering is done in parallel by a multicore array of GPUs anyway. The DX or GL drivers take the rendering instructions in and parallelize them under the hood. This being true, there's not much to be gained from actually issuing the instructions in parallel, right?


From: Paulo Pinto
Subject: Re: [SDL] [OpenGL] Multi-thread renderer a good idea?

This is the best way of doing it. Let just one thread take care of drawing, and send update requests
to him from another threads.

No need to complicate things.

DirectX 11 supports multithreading rendering, but I doubt there is much to gain from it, when compared
with a proper separation of the application subsystems across processors.

There's much more to a rendering subsystem then issuing instructions for the GPU.

On 18/04/2010 14:47, Mason Wheeler wrote:

On Sun, Apr 18, 2010 at 12:47 PM, Mason Wheeler wrote:

That is correct. Each primitive, say a triangle, may have its vertices
transformed by different processors. Once it is broken up into
fragments each fragment may be processed by a different shader.
Processing primitives can be done in an extremely parallel way.

What is hard, and what makes sending operations to the same context
from multiple threads a truly nasty thing is that the *order* of
operations must be maintained. The order must be maintained because of
things like alpha blending and matrix multiplication where the
operations are non-commutative.

If you are building code with a separate rendering thread, which is a
good idea, you might run into problems if the rendering command you
can send to that thread allow you to change the context because a
command from one thread may change the context so that, oh say, they
foreground color is blue, and then draw a line. At the same time
another thread sends commands to set the foreground to red and then
draws a line. If the changes to the foreground color both complete
before the lines are drawn then both lines will be draw the same
color, but you can't predict which color. You have to block the
message queues based on something similar to the OGL begin and end
functions so that you process all only complete sets of commands and
you process them completely before you switch to another queue of
commands.

If you use that approach, and you do a lot of context changes, I've
found it is a good idea to build a context property cache into your
rendering thread. If, for example, you keep track of the background
color in your thread then when a command comes in to change the
background color you can check to see if it is already that color. If
it is, you don't have to send the command to the context. In some
cases using a property cache can really speed up your rendering.

Bob Pendleton





--
+-----------------------------------------------------------
+ Bob Pendleton: writer and programmer
+ email:
+ web: www.TheGrumpyProgrammer.com
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

On Sun, Apr 18, 2010 at 12:52 PM, Andre Leiradella
wrote:

That depends entirely on your definition of the term "Rendering subsystem". :-)

If it consists of nothing much but the interface between OpenGL and
the GPU, then no, there is not much else. If it include the entire
windowing system then yes, there is a lot more to it.

The term has different meanings to different people and its meaning
can change for the same person depending on the context of a
discussion. Sort of a useless term really.


One more thing. The maximum rate at which the GPU can process
rendering commands is the maximum rate at which the CPUs can generate
commands. Yeah, doh! Obvious, right?

Ok, in a multiprocessor system with a killer GPU it is possible that
you could wind up with a GPU that can render commands faster than a
single processor can generate commands. In that case, it would make
sense to have multiple threads sending commands to the GPU.

Is this likely to every happen? Sure, but that just means that the GPU
has enough left over cycles to keep up with other applications.

Bob Pendleton




--
+-----------------------------------------------------------
+ Bob Pendleton: writer and programmer
+ email:
+ web: www.TheGrumpyProgrammer.com
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

So it seems the best thing to do is have many threads that do the 'pre-rendering logic' and one thread that does nothing more then issue the final OGL commands.
Yeah, that sounds like a solid design that will work nicely.

Thanks for the replies. You all have been very helpful.

There is certainly value in multithreading the software side of a rendering engine (for example visibility determination, LOD switching, etc), but the driver still wants things in a nice serial stream
with a minimum of state changes.

So the entire premise of combining multiple command buffers is hostile to the GPU, and the driver, simply because when switching between command buffers generated from one thread and another, it may
have to upload a significant amount of state, and more importantly it does not easily know WHICH state is different, so it would end up uploading the entire state again, this is commonly known as a
context switch and is far from fast (depends on OS and hardware).

Rendering is not necessarily a serial process but our current interface to the hardware is serial, therefore we must optimize solely for this current approach.

Handing processing jobs off to other threads is how console games function in general and I see much value in this approach, but in the end you still want to render your world, your effects, your
lights, and so on in a particular order (lest you end up with flickering due to render order).

On 04/18/2010 01:37 PM, Bob Pendleton wrote:


--
LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged demo." - James Klass
"A game is a series of interesting choices." - Sid Meier

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

I've implemented something like this: smplayer2 - a scriptable mediaplayer that uses OpenGL textures to display video and graphics. Maybe you can use the sources as a reference for your own project.
The system did handle multi-HD streams to dual-projector output and was using several threads: one core renderer, one thread for each Lua based visualizer script as well as threads for stream IO. Lot's of threads.
http://www.ferzkopp.net/joomla/software-mainmenu-14/4-ferzkopps-linux-software/94-smplayer2
(The index link points to a folder with additional documentation as pdf.)

On 4/18/10 5:50 PM, bobdevis wrote: