• Advertisement
Sign in to follow this  

Data organization with graphics front-end

This topic is 897 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello,

 

I am wondering what the common approaches to following problem are:

 

Imagine an application that does some sort of computation or simulation on a complex data structure (e.g. several hundreds of different objects types). That application can run in headless mode (i.e. without GUI or graphics fron-end). Imagine also that this application just needs a single thread. In case of a game, this thread would handle the game logic and read/write the data.

 

Above is not too complicated, but what happens when we want the user to be able to constantly visualize the data structure (e.g. display the game evolution in 2D/3D for instance). Imagine that for this part, a second thread is used.

 

Now, how can we optimized everything for fastest and safest operation? I mean, the graphics thread and the computation thread cannot access the data at the same time, unless we read it only, which is not the case (or rarely).

 

So I see several options:

 

1. The two threads access the same data alternately, but never at the same time. This is not very elegant, since the two threads would have to wait for each other.

 

2. The computation thread duplicates the complex data on a regular basis, and the graphics thread only accesses the duplicate portion of the data. My worries here is that the duplication process could take time (even if in the end it is just a complex memory copy operation).

 

3. The computation thread simply sends messages to the graphics thread when it modified something: we would have a kind of complex synchronization process that can easily break down. My worries here are: the synchronization can break if not very carefully implemented and the implementation is quite complex.

 

So my question is: what would be the best solution generally speaking? Or is there another solution to my problem?

Share this post


Link to post
Share on other sites
Advertisement
They are all valid solutions.

1. Is useful if the shared data is not needed all the time by the computation (ie it computes something complicated that takes time)

2. Is useful if the computation constantly needs all (or most) the data. Without copy, you would never be able to draw anything. Biggest advantage is that the state of all data is consistent after the copy.

3. Is useful if few changes are made. The gui could simply update the parts that got changed, for example.

Other options

4. Not use a thread, screen display will stay on the screen all by itself, and it avoids copying.

5. Do fine grained locking (lock only small parts at a time).

6. If all data gets updated, write a second copy after N iterations, then notify the second thread the second copy was updated.

Share this post


Link to post
Share on other sites


Imagine an application that does some sort of computation or simulation on a complex data structure (e.g. several hundreds of different objects types). That application can run in headless mode (i.e. without GUI or graphics fron-end). Imagine also that this application just needs a single thread. In case of a game, this thread would handle the game logic and read/write the data.
 
Above is not too complicated, but what happens when we want the user to be able to constantly visualize the data structure (e.g. display the game evolution in 2D/3D for instance). Imagine that for this part, a second thread is used.

 

Congratulations, you've just described pretty much every modern 3d game! :)

Share this post


Link to post
Share on other sites

It's unlikely that the simulation and the renderer are going to use the same representation of the data anyway, so you'll need two copies regardless. The renderer might have two copies of its data as well if it wants to perform interpolation while the simulation build the next frame. It then becomes a question of how and when you synchronize the simulation state with the renderer state. This is where you can utilize dirty flags and other techniques to only synchronize state that changed.

Share this post


Link to post
Share on other sites

Thanks for the interesting replies!

 

A question related to my first question: next to the graphics visualization, the GUI is in my case also running in a different thread (actually in the same thread as the graphics). How do people usually do? Query the calculation thread for the info that needs to be displayed, and then, if something was changed, send the update back to the calculation thread so that it can update its objects? Just wondering since the GUI thread has one requirement less, and one requirement more compared to the graphics thread:

 

1. The GUI thread doesn't need to refresh that often (less constraining than for the graphics thread)

2. But the GUI thread needs to send back changes to the calculation thread (that constraint doesn't exist for the graphics thread)

 

Thanks

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement