Wednesday, April 20, 2011

DirectQ Update - 20th April 2011

This was going to be a discussion of some of the choices, and the reasons behind them, for the underwater fog implementation I did lately, but I'm holding back on that one until later as there is something more important that you need to know.

For the first time ever on this blog I've deleted a person's comment (one that wasn't spam anyway) and have gone back and edited an old post to read differently than it previously did (I have deleted posts before where events have overtaken their contents).

This was not something that I did lightly, and it was not on account of the person's comment, which was a perfectly valid and fair question. It was instead on account of my own realisation that the way I had worded something was open to misinterpretation. My screw-up in other words.

I'm not going to hide this, but I do want to discuss it a little more in context. It's only right that you know about what it was.

The original post (made yesterday) contained a discussion of changes made to video startup code that I had felt to be safer, owing to the fact that the new code always started in a non-exclusive non-fullscreen mode. Exclusive video modes made me slightly paranoid as they mean that the program now has sole ownership of the video hardware. Any fuck-up I make in code could have implications for stable running of your PC. That's obviously not a good thing.

The most likely place for such a fuck-up to occur is during video startup. DirectQ is reading in your cvars, it doesn't know what values you're using, it doesn't yet know your hardware capabilities, and - in theory - potentially anything could happen. In practice there are a LOT of safeguards in place, both within D3D and within my own code, to ensure that the possibility of this happening is significantly lower than the possibility of you winning the national lottery. But I still had this slight nagging doubt. What if I missed something?

Once video startup completes and the engine is up and running this possibility more or less vanishes. Every previously unknown factor is now known, and the situation is no worse than with any other Quake engine.

As things turned out this description is actually no longer relevant; it's been overtaken by events and the restructured video mode handling code I also did has made those changes completely unnecessary. But in the interests of fairness and openness it's only right that you know the background.

The comment was a question along the lines of "so does this mean that D3D can lock up your GPU?" I consider that a perfectly fair and valid question given the original wording I had used in my original post. However it does not describe the full story, and a reply I made to it only made the possibility for misinterpretation worse. I want to avoid that, but I also want to be open about stuff.

When starting up D3D one of two things can happen. It can succeed or it can fail. If it succeeds then there is nothing you need to worry about; startup has completed and everything has made the transition from unknown to known. If it fails there is also nothing you need to worry about - it won't even get exclusive access to the video hardware (for fullscreen modes only; windowed modes never have exclusive access), so there is no possibility of GPU lockups there.

Yes, D3D can lock up your GPU. So can OpenGL. I've seen it happen with D3D when you try to read back the result from an occlusion query that hasn't yet been issued. I've seen it happen with OpenGL when you update a dynamic lightmap on Intel drivers (that was actually part of the original reason for why DirectQ exists).

This is however all down to bad code or bad drivers, and is not an inherent feature of either D3D or OpenGL. That's the important thing to realise. This kind of thing gets caught in testing and is fixed. Otherwise both APIs are incredibly robust - I've actually made past releases that contain horrific things - like reading well beyond the end of a vertex buffer - but which have had no ill effects whatsoever during runtime. D3D is actually incredibly good at the "crash early and crash hard" philosophy, and has excellent debugging tools (which I regularly use) to ensure that these things get caught.

So that's about where we're at now, and I hope this clarifies a few things. Next up - the fog discussion.

2 comments:

Coranth said...

Sir,

I'm sorry if I caused you or the people here offense; it was -my- comment that you deleted! Good to know that things have been made clearer, though! Thanks.

mhquake said...

No offense caused mate. ;)

What you did do was highlight for me that I hadn't explained stuff well enough, and I'm grateful for that.