Threaded blit

SDL Development
1

Hi all,

In a multi-threaded application with concurrent access to SDL_Surface’s (including the display),
which may include blit, update, or even direct access to pixels, what would you suggest to
prevent inconsistent blits ?

My idea was simply to wrap operations on surfaces involving pixels with:

SDL_LockSurface()
( ... operation on pixels like direct access or blit or update ... )
SDL_UnlockSurface()

In every concurrent routine. Maybe SDL already take care of multi-threaded problems already ?

Thank you for your advice.

Regards

Julien_____________________________________________________________________________
Envoyez avec Yahoo! Mail. Une boite mail plus intelligente http://mail.yahoo.fr

2

Sorry to be a pedant, but not having multiple threads which blit would be the best solution?

I always have one thread which blits, and other threads handling I/O.

Threads can be scary when debugging so I just use the KISS principle :-p

Ed> ----- Original Message -----

From: clementj2005@yahoo.fr (Julien Clement)
To: SDL
Sent: Tuesday, 24 June, 2008 10:04:07 AM
Subject: [SDL] Threaded blit

Hi all,

In a multi-threaded application with concurrent access to SDL_Surface’s (including the display),
which may include blit, update, or even direct access to pixels, what would you suggest to
prevent inconsistent blits ?

My idea was simply to wrap operations on surfaces involving pixels with:

SDL_LockSurface()
( ... operation on pixels like direct access or blit or update ... )
SDL_UnlockSurface()

In every concurrent routine. Maybe SDL already take care of multi-threaded problems already ?

Thank you for your advice.

Regards

Julien

Envoy? avec Yahoo! Mail.
Une boite mail plus intelligente.

  __________________________________________________________

Sent from Yahoo! Mail.
A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html

3

Hi.

SDL_LockSurface has nothing to do with concurrency. When you “lock” a
surface, you are really just obtaining a pointer to the surface
contents in system memory, if the surface was in graphics memory.
Hence the macro SDL_MUSTLOCK.

Lets say you replaced the locking in the snippet you gave with actual
concurrency primitives. In this case it is debatable whether you would
gain much from multi-threading, as you could be suffering from locking
contention. Excessive locking can make the code run in a single
threaded fashion - or slower (due to context switching overhead). It
can also produce deadlocks etc.

The proper way to do multi-threading is to see:

  • which algorithms can be parallelised by itself
  • which algorithms can be done concurrently without breaking things

Graphics usually can be - this is why graphics cards tend to have
hundreds of cores. Doing it correctly is challenging. It depends on
what you are doing.

Firstly, is performance a problem? If so, are you sure that the
blitting is the bottleneck?

There are options other than having many blit threads. Perhaps you
could do all the blitting in one thread and concurrently run the game
logic in another thread, etc. I believe that some windowing systems,
like Windows, forces all screen blits to occur in the main thread
anyway. I think you should be safe using SDL’s software blits
outside the main thread. In general though it might be easier to keep
all graphical stuff in a single thread.

The alternative for heavy rendering would be to use OpenGL, thus
taking full advantage of any hardware in an asynchronous fashion.

Its hard to give concrete advice on a subject as complex as
multi-threading without additional information. There is no one true
way, each case needs to be examined individually to see how it can
make the most of multiple threads.On Tue, Jun 24, 2008 at 10:04 AM, julien CLEMENT wrote:

Hi all,

In a multi-threaded application with concurrent access to SDL_Surface’s
(including the display),
which may include blit, update, or even direct access to pixels, what would
you suggest to
prevent inconsistent blits ?

4

SDL_LockSurface has nothing to do with concurrency. When you “lock” a
surface, you are really just obtaining a pointer to the surface
contents in system memory, if the surface was in graphics memory.
Hence the macro SDL_MUSTLOCK.

It’s also used to deal with various encodings, for example an S3TC
surface needs to be uncompressed, and even in system memory, a surface
using RLE encoding to optimize blitting, while it doesn’t need to be
decoded, would get corrupted if you changed the pixel values without
its knowledge (when locking, it tells SDL that anything might happen
now to the pixels, and when unlocking, it recomputes the RLE
encoding).

In fact, relative to the previous code example, doing blits while a
surface is lock is actually forbidden! The documentation for
SDL_LockSurface tells you not to do any system calls or library calls
(a bit excessive, but you have to be careful, in any case), and the
documentation for SDL_BlitSurface specifically says that it should not
be called with locked surfaces.On Tue, Jun 24, 2008 at 10:00 AM, Brian <brian.ripoff at gmail.com> wrote:

–
http://pphaneuf.livejournal.com/