I've had a great time troubleshooting the old Intel lock up problem, caused by the driver going into an infinite loop. I'd long suspected that the command buffer was overflowing, and have peppered a few calls to "glFinish" around the code, which not only fixes it, but also seems to confirm my suspicions. So now I detect if we have an Intel card on the premises at startup, and enable a "degraded mode" (i.e. lots of glFinish's all over the place) if so.
It doesn't run too bad - I can get about 20-40 FPS in most scenes on an Intel 915 in this "degraded mode", which is not too far off what the card is capable of anyway.
I've also been working on better capabilities enumeration. It's frustrated me that OpenGL doesn't have a proper capabilities API - you've got a few glGets, but they're severely limited, and in a lot of cases the only way to really find out if something is possible is to actually try it and see what happens.
Of course some might say this is preferable, that you know for certain whether something will work, and that certain vendors may lie about their capabilities when queried, but even so, there's basic stuff that not even "try it and see" covers, like whether you have hardware T&L or how much video RAM you have (although you can make a good guess at that by creating small textures until one fails...)
Anyway, I've stuck in a few Direct3D and DirectDraw calls at startup to get these capabilities. They don't need to be tied to a window, as you're only creating the objects, not the devices, but I've also added a splash window in case I ever do want to create a device for something.
One interesting side-effect of this is observing the interaction between Direct3D and DirectInput. This ties in with my observations on potential threading issues in VCPP 2005/2008 earlier on, as it now appears obvious that DirectX in a multi-threaded environment needs very careful handling otherwise it will go all over the place. The really weird thing was that the issues persisted even after the Direct3D object was released and NULL'ed. And I don't even startup DirectInput until well after that. So one would reasonably expect that this should have never happened. Anyway, I've resolved it by sending the Direct3D and DirectDraw stuff off on it's own thread, so that the processes are kept isolated from DirectInput.
The Win32 threading API is nice and neat by the way. Very easy to use, and takes up minimal lines of code. I'm sure that there's other places in the engine where performance would benefit from being able to run batches of code at the same time.
Sunday, July 27, 2008
More fun and joy
Posted by
mhquake
at
1:06 AM
Subscribe to:
Post Comments (Atom)
0 comments:
Post a Comment