Friday I got to test a new model that I'll have to use for my current project.
The unoptimized model had over 1M polys (it's a small one 8). I went on to display it with the DX10-based engine and it crashed the (NVidia) driver.
The model is actually composed of many smaller models, so it's not like there is a huge vertex buffer. It also had no textures and I was using a simple common shader.
The only issue I can think of is the range of coordinates which it's relatively very large. It's a laughable supposition, but everything points to that. I'll have to debug to find a workaround.. but it's not easy considering that those driver crashes force me to reboot almost every time ! (Vista stays up, but I can't do 3D anymore).
This is a really bad setback. For the test I eventually displayed the model with my ultra-basic software renderer... no crashes there ;) ..and if there were, I could have fixed them myself.

Another thing that bothers me about DX10 and drivers in general, is how one has to guess performance, because the internals are obscure.
For example, using an NVidia 8800, I noticed that performance is a lot worse when using buffers flagged as "dynamic".
This whole "static" vs "dynamic" thing is apparently part of DX10 and Vista's driver model. Somebody, somewhere, probably decides to put the buffer in system memory (as opposed to GPU memory) under the assumption that the buffer needs to be touched frequently. Only, I may want to change it rarely, and also I was sort of expecting for the buffer to be allocated directly in the GPU memory and only be mirrored in system memory if I ever tried to read from the buffer (which I wouldn't dare to).

So, I have to be really careful and only use the "dynamic" flag for things that change frequently.. and possibly forget about building a flexible system that uploads textures and geometry on-demand.. which is otherwise theoretically very possible with no (not much ?) performance degradation.
As it stands, it seems almost that dynamic buffers are being uploaded per-frame, regardless of the fact that they aren't being modified per-frame.
..this is all speculation of course.. but that's what I really don't like about this: having to spend time trying to guess what those drivers do behind my back.. and hope that different drivers on different card will behave similarly (crashes aside ;).

For this reason I hope that the time will come when game companies can write complete graphics pipelines again. Either in-house or licensing code, but staying away from closed-source drivers, so that one won't have to debug and profile in the dark.

Some are worried that they couldn't possibly do much better than what card manufacturers already do with those drivers.. I think that there is plenty to improve by just getting rid of those fat drivers that have been plaguing PCs ever since 3D cards came out.

ole'

A few days ago I was talking about real-time 3D moving towards programmability and now Intel comes out with a more detailed report of their upcoming Larrabee technology. Basically Intel extending CPUs towards the GPU domain.

This is all very cool, but I don't see any mention on actual software technology. We know that Intel has been doing research on Ray Tracing, but the real issue for 3D in games is productivity. Not an easy problem because it involves tools and artists and programmers together.

With all this quality, productivity, predictions, etc, kind of topics floating around, recently, I've been using wikis, PowerPoint and Excel a lot more than compilers 8(