What is wrong with my Threads?

Hi, I’m new around here, but I could see that many people around here knows a lot about threading in OpenGL. I have this slight problem using threads in a GLUT based program.

You see I use GLVU provided by UNC as a platform for my GLUT program, since I usually use GLUT, I don’t think that device context or pixel format descriptors is a necessity or should ever be shared between windows and all.

I only used threading to calculate some other process in the background. Now here is my little problem.

In a simple program that I have just done, I generated 5000 sphere randomly in 3D Space.I tried using 3 threads, 1 thread for generating the random position of the sphere in 3D Space which run once in the beginning of the program, 1 thread is used to calculate the View Frustum planes for the use of Frustum Culling, and 1 last thread for generating a list of sphere visible in View Frustum.

Here’s the problem, why is it that if I turned on my thread for Frustum Calculations and List Generation the FPS drops instead of climbing. I thought that threading was supposed to make an application runs faster, but obviously been in this situation, I was wrong.

I tried many ways like to bypass the thread if it already runs etc. But it doesn’t change anything. Any ways I can counter this? I would really appreciate any suggestions. By the way, here is the display part of my code.
Please HELP!!!

 
void MyDisplay(void){
	glutSetWindow(MainWindow.GetWindowID());
	int i;
	MainWindow.BeginFrame();
	glClear(GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT);
	if(UseViewFrustum->get_int_val()){
		if(ThreadedViewFrustum->get_int_val()){
//			if(ReCalculateFrustum){
				MyThreads[1] = CreateThread(NULL,128,UpdateFrustum,NULL,NULL,NULL);
//				ReCalculateFrustum = false;
//			}
		}
		else{
//			ReCalculateFrustum = true;
			float ProjectionMatrix[16];
			float ModelViewMatrix[16];
			MainWindow.GetProjectionMatrix(ProjectionMatrix);
			MainWindow.GetModelviewMatrix(ModelViewMatrix);
			MyFrustum.CalculateFrustum(ProjectionMatrix,ModelViewMatrix);
		}
		if(UseVisibility->get_int_val()){
//			if(UpdateVisibility){
				MyThreads[2] = CreateThread(NULL,0,UpdateVisibleSphere,NULL,NULL,NULL);
//				UpdateVisibility = false;
//			}
			for(i=0;i<VisibleCount;i++){
				glPushMatrix();
				glTranslatef(VisibleSphere[i].x,VisibleSphere[i].y,VisibleSphere[i].z);
				glutSolidSphere(0.3,30,30);
				glPopMatrix();
			}
		}
		else{
			for(i=0;i<SPHERECOUNT;i++){
				if(MyFrustum.PointInFrustum(SpherePosition[i])){
					glPushMatrix();
					glTranslatef(SpherePosition[i].x,SpherePosition[i].y,SpherePosition[i].z);
					glutSolidSphere(0.3,30,30);
					glPopMatrix();
				}
			}
		}
	}
	else{
		for(i=0;i<SPHERECOUNT;i++){
			glPushMatrix();
			glTranslatef(SpherePosition[i].x,SpherePosition[i].y,SpherePosition[i].z);
			glutSolidSphere(0.3,30,30);
			glPopMatrix();
		}
	}
	MainWindow.DrawFPS();
	MainWindow.EndFrame();
}

Maybe you are using mutexes.

I thought that threading was supposed to make an application runs faster, but obviously been in this situation, I was wrong.
Nope. Threads do not accelerate the CPU or any part of the hw.

Originally posted by Genocide:
I thought that threading was supposed to make an application runs faster, but obviously been in this situation, I was wrong.
Threading can make application run faster if that application is properly designed to take advantage of it. This also requires that problems solved by the application can be paralelized to some degree maybe with exception of situation when program is run on multi CPU system with vastly different capabilities of each CPU (something like PS3).

There are generaly two areas in which threaded application may run faster.

1. Application uses api which sometimes pasively waits for external event and there is something that can be done while another thread is waiting for that event. Example of such api are file manipulation functions (except for reads and writes used together with overlapped io).

2. Application runs on system with multiple CPUs or multiple CPU cores or to some degree on systems supporting Hyperthreading.

If threaded application runs on system with single CPU and all threads do intensive calculations, it is likely that there will be performance loss caused by thread managing and thread switching overhead.

It seems to me that there are several problems with code from your post.

• It seems to me that you try to use threads as if that were call to corresponding function. Because of the next problem this does not work and even if it were there would be no speed gains on ordinary PC (even the multi-CPU one unless there is difference between capabilities of various CPUs which is unlikely) because nothing would be done in parallel and there would be performance loss because of thread managing overhead.[] There is no synchonization between threads so you may get various incorrect results because you are not waiting until thread does its job. For example in for(i=0;i<VisibleCount;i++) you may draw from array that was not fully initialized yet.[] You are creating threads in every frame which causes relatively high overhead.[*] You are not calling CloseHandle on handle returned by CreateThread so you are leaking handles. This may cause thread creation to take more time each time it is called (this is true for W95, I do not know if that is also true for WNT) and eventually you may run of memory reserved for handle allocation so further thread creation will fail.

Well, thanx for the info guys, I really start to think there’s no way for an OpenGL Application to take advantage of multithreading capabilities, haha :/, is there any other way to enhance the capabilities of an OpenGL application in Windows? Besides all those Display List, Vertex Array, and Backface culling things? Any other way to use Multithreading in an OpenGL application?

Of course there are ways to increase the performance using multithreading, but calling CreateThread just like that is not the way to do it.

Seems to me that you don’t really understand what multithreading is about in the first place. It’s not about creating a thread to call a function and then wait for the thread to end to process the result.

In your code, for example, you create a thread for (judging by the name) updating the frustum, and then another thread to determine which spheres are visible, and last you draw them. This is a defined sequence of operations, and is definitely not a situation where you want to split the operations into different threads. It is possible, but you will have to deal with serious synchronization issues as the different threads tries to operate on the same sets of data with high inter-thread dependence. Unless you have a strong experience in multithreading, this is going to be a real nightmare for you.

Multithreading is a really difficult beast do correct.

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.