BHM File Format

[SpooK]

My recommendation for a windowing solution is to use SDL, since its already cross platform and the license is liberal, meaning one set of code will work everywhere.

If you want to abstract away different platforms and along with some OpenGL nuisances, SFML is a decent approach.

[Scali]

Speaking of OpenGL nuisances...
I tested my code with the same multithreaded window framework that I used for D3D earlier, and I ran into an interesting issue:


The framerates are very uneven, and the animation is not smooth either. This was on a GeForce GTX460. So I figured I'd also try it on some other machines, one with an ATi Radeon X1900XTX, and one with an AMD Radeon HD5770. Both ran more smoothly.
In D3D the GTX460 had no such problem, so I just reported it as a driver issue. I guess nVidia wants to prioritize OpenGL tasks... which works fine with a single task, but as Raymond Chen of The Old New Thing always says: What if TWO applications would do this?
Or in this case, just two or more threads from the same application.

Anyway, here's the binaries if you want to test it (Win32, .NET 4.0):
http://bohemiq.scali.eu.org/OGLMT.zip

[Homer]

Due to scheduling, using multiple threads to render a single frame is fraught with disaster and I would never recommend it. I would #1 recommend only EVER using one thread to perform rendering.
Now, I know you're thinking, what about background loaders and so on?
The render path can be controlled from other threads, this is not the same thing as PERFORMING rendering from multiple threads.
If you need to drive your visual object transforms from a thread other than the rendering thread, then you're going to need some way of synchronizing them other than a hard mutex, usually this will be based on time, and involve artificially lagging something.

Even setting your thread priorities won't save you from being scheduled.

[Scali]

Due to scheduling, using multiple threads to render a single frame is fraught with disaster and I would never recommend it. I would #1 recommend only EVER using one thread to perform rendering.

Firstly, did you even bother to look at the screenshot? It's not a single frame, it's 10 concurrent renderers. So your entire post does not apply. I am talking about completely different issues (as usual). I want to use multiple OpenGL/D3D windows from the same application, so that I can render to multiple GPUs and screens at the same time, and have additional accelerated windows inside the UI of the application. There is no rendering from different threads than the rendering thread, there are just multiple rendering threads. Which works fine in general, except that on nVidia there seems to be a driver glitch when using OpenGL (but not D3D).

Secondly, since D3D and especially OpenGL are connected to the window and thread they are created with, it is generally not even possible to use the same context from different threads (although D3D11 allows you to create additional contexts with limited functionality which you can use to prepare commands, which can later be executed by the main context in the main thread).
It's only logical, since the context is connected to one GPU (and SLI/CrossFire is also one GPU as far as the application is concerned, multiple GPUs are virtualized into a single one for the application), and you need to send commands in a strict order.

[Homer]

OpenGL also allows you to create multiple contexts, and to share resources across contexts, I'm not saying it can't be done, I'm saying one thread per context means no artificial stalling due to mutexing.

But I see you're already doing that, and the only reason that your windows are not rendering at the same rate is because the OS thread scheduler is not democratic, it performs poorly in terms of load balancing.

So I think my comments were in line.

[Scali]

But I see you're already doing that, and the only reason that your windows are not rendering at the same rate is because the OS thread scheduler is not democratic, it performs poorly in terms of load balancing.

Incorrect.
Because as I already said:
1) When using Direct3D on the same videocard, there is no issue with load balancing:

I have also done tests with just rendering the windows with a framecounter in the title bar, and no D3D or OpenGL rendering at all. The OS scheduler is not the problem.

2) I have tested on two other systems, which did not show the problem either. Even though they are slower systems, and the framerates were lower on average, the animation remained smooth because the load remained balanced properly.

So I think my comments were in line.

I don't. You were talking about, and I quote: "using multiple threads to render a single frame".
Which is the opposite of my situation: "Rendering multiple frames, with one thread each".
The rest of your post was just Captain Obvious on multithreading. I'm not sure with what intent you posted it, but if you think I didn't already know about that, you're sorely mistaken.

And this post again... If you bothered to READ my earlier post, you'd know that I had already eliminated the OS scheduler as the root cause, because, and I quote:
"This was on a GeForce GTX460. So I figured I'd also try it on some other machines, one with an ATi Radeon X1900XTX, and one with an AMD Radeon HD5770. Both ran more smoothly.
In D3D the GTX460 had no such problem, so I just reported it as a driver issue."

Next time, have the decency to READ a post before you reply.

[Homer]

I am absolutely certain that windows directx would be doing a GetDC(windowhandle) under the hood, because its GOT to query for the rendering surface before it can write to it, opengl is just exposing this factoid.
I like that you bothered to re-post about the thread latency issue, blaming the drivers doesn't mean s***, they are chained, are they app level? running already and concurrent with the os (bet theres still balancer on it)? etc surely u took some time to qualify ur results and didnt merely observe ?

[Scali]

I am absolutely certain that windows directx would be doing a GetDC(windowhandle) under the hood, because its GOT to query for the rendering surface before it can write to it, opengl is just exposing this factoid.

No it doesn't.
A DC is just a GDI-specific object.
DirectX is implemented at the same level as GDI:
http://msdn.microsoft.com/en-us/library/windows/desktop/ff729480(v=vs.85).aspx
In fact, since Vista, GDI is actually running on top of Direct3D, at least, when using Aero.
So there is no reason why you would need a DC object whatsoever for Direct3D. ANd likewise you would not need one for OpenGL either in theory.
As I said, the DC thing is probably a legacy thing. OpenGL has been around on Windows NT longer than Direct3D has, and was originally a software-only implementation. In that light, its ties with GDI are more logical.

I like that you bothered to re-post about the thread latency issue, blaming the drivers doesn't mean s***, they are chained, are they app level? running already and concurrent with the os (bet theres still balancer on it)? etc surely u took some time to qualify ur results and didnt merely observe ?

Excuse me if I don't play along with your little charade.

[Homer]

I perform a bunch of concurrent threaded operations in my framework, each has a spend limit and can bail out early if the limit is breached, subject to the minimum cap on framerate. OpenGL contexts are device contexts, the DC isnt deprecated, its a thing.

[Scali]

OpenGL contexts are device contexts, the DC isnt deprecated, its a thing.

OpenGL contexts are OpenGL contexts, . They are *a* context, not *the* Device Context as defined by GDI and GetDC().
Which should be quite obvious, since GDI and GetDC() are Windows-specific, and OpenGL is not.
And even on Windows, the OpenGL context is NOT the DC (as pointed out, DCs are not persistent, unlike OpenGL). An OpenGL context is referred to by a HGLRC (handle to a GL rendering context) in Windows, not by a HDC.

http://msdn.microsoft.com/en-us/library/dd374379(v=vs.85).aspx

Remarks
 
A rendering context is not the same as a device context.

[Homer]

Under opengl, its like Lua contexts - you create a master context, and register all resources there, and notify the system that you intend to share them to a set of child contexts. So the problems of multithreading (almost) go away.

[Scali]

nVidia just released a driver update: 296.10.
The starving issue is still there though.
nVidia has not responded to my bug report yet either.

[Scali]

Just got a reply from nVidia. They confirmed the bug and said that the engineers already identified the problem in the driver. A fix will be made available in a future release. Cool!

[Scali]

Just installed the new 301.42 driver.
And they fixed my bug! That was quick!

[Homer]

very cool!