OpenGL process lock up

[vince]

Hi,

I'm not sure this is really a OpenGL or an Windows topic. But I'm sure you'll let me know ;-)

I have 3 processes running. Only one is having a window and OpenGL calls. The other 2 processes use the same shared memory. The problem is when one of the none OpenGL process is doing some tasks, it will randomly freeze my OpenGL window for about 1 frame.

The funny thing is the OpenGL process is using it's own CPU, with real time priority. The other 2 processes are using a different process.

Would anybody know why my OpenGL process locks like that while the other 2 processes don't? Does it have anything to do with the fact that only me OpenGL process is using lots of Kernel operations?

BTW, I'm using windows 2000 and the problem is the same on either a GeForce 5900 or a Radeon 9700.

Thanks

[SirKnight]

Sounds like the Opengl process is getting starved or something. Perhaps the other process s hogging the bus not letting the opengl process use it.

-SirKnight


[This message has been edited by SirKnight (edited 01-09-2004).]

[V-man]

>>>Would anybody know why my OpenGL process locks like that while the other 2 processes don't? Does it have anything to do with the fact that only me OpenGL process is using lots of Kernel operations?<<<

What kernel operations are you doing in the GL thread?

If the other 2 threads are not sharing a resource with the later and you aren't doing the lock yourself, then no lock ups will occur. That's obvious.
So is the GL thread totally independent of the first 2?

You are running the GL thead on CPU1?

[vince]

I'm not doing kernel operation myself. Juste normal GL calls, but the driver does kernel operations.

All 3 processes are sharing the same ressources. That's why I don't really understand why only one process gets locked. But only the GL process does kernel operations and one of the other 2 does the I/O.

The GL process is running alone on CPU2, and the others are on CPU1, but I tried all combinations of affinities and priorities but it always produces the same results (i.e. locks on the GL process)

[V-man]

I'm not an expert on the internals of Windows but doing GL calls doesn't mean a kernel operation will occur, it just means it will eventually occur.*

I beleive the OS (NT multiprocessor) will choose a processor to run itself. If multiple CPU intensive threads are running on the same CPU, some degradation will occur.

Try swapping CPUs or at least give your GL thread normal priority (and let's hope Windows is smart)

* http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/010226.html
has some interesting things about drivers.

PS: Dorbie, notice what evanGLizer says about the Farhenheit fiasco. Like I said ...