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'

Portland_2008_01 (public)

I arrived in Portland (OR) a couple of days ago and I'm going back to Tokyo tomorrow !
It was my first time here, though I've been in Oregon before.
Compared to San Francisco, Portland looks a lot more safe. But also deadly cold. It seems that most people wear hats, and I can see why. One day I had my ears freezing from the cold wind.. so hats after all aren't just a fashion thing !!

I'm here for business, but I can't really talk about it. Exciting things, but I still think I'd be more excited if I got a substantial pay raise ;) ..cough cough !
I'll be back on Sunday and Monday already to work. I want to get busy with code, but instead there will be some management/business/financial things to talk about.

Talking about code. Just before leaving, I made some sensible changes to the engine I'm currently working on.
There really isn't a proper way to do anything. One can throw random polygons at a rasterizer and get terrible performance or group geometry (and textures) in a certain hardware-friendly fashion.
Depending on the file format and on the average organization of mesh data, one has to come up with the best compromise. So, for example, in most cases having every polygon listing a different material is a bad idea.
Then one can group polygon lists using the same material, but do those polygon lists all share a common vertex pool or should every polygon list have a separate vertex pool ?
If lists are few and made of many polygons, then it may be wiser to have separate vertex pools, this is also because if every list has a different material, different materials could imply different vertex attributes (if there is no texture, then there is no need for texture coordinates, etc).
This also reminds me of the pain of using uber-shaders (long shaders) with DX10. Sometimes long shaders will ignore some input vertex data, but feeding null buffers gets DX10 debug mode to spit out thousands of warning messages in the output console.
I dunno.. DX10 doesn't really seem like the ultimate solution. It shifts the weight of state changes towards the application program, which is nice and not so nice at the same time.

And finally, some great news ! I'm leaving in 5 hours and I still haven't lost my digital camera 8)

woooooo  read more »