JavaKazRace - Playable Java racing game demo
PSEmu Pro GPU plug-in
DOSX Utils
SHLight 2004
JavaKazRace DSharingu PSEmuGPU DOSX Utils SHLight 2004

Between a driver and an hard place

Davide's picture

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'

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

yeah stop feeding those fat

yeah stop feeding those fat drivers!!

This is why I dislike PC

This is why I dislike PC development. I remember working on a game several years back in which it took me literally 3 work days to track a crash down to an audio driver issue! It turned out that one of the songs used this MIDI SysEx command which the driver (for whatever reasons) didn't handle which caused the game to crash.

I suppose those drivers you are using weren't tested with data of that high of a poly-count. Either way, if you're 開発'ing on a PC, expect pain. Though I'm not sure if that's any worse that working around nasty hardware bugs on a console ... 8P

Seems like nowdays the gap

Seems like nowdays the gap between PC and console is not as big as it used to be. Consoles also have the OS layer and although the driver layer is much thinner, it is still there.

It wasn't so much the

It wasn't so much the technology gap back then as the fact that usually bugs that showed up in your console project were "easy" to hunt down ... unlike my experience on the PC tracking down a serious bug only to find out it was a driver issue.

Having said that, there is a console I worked on (name withheld) that had this very subtle hardware bug ... I can still feel the pressure that was on me to prove to the management that it was a hardware bug and not my code. Fortunately, I was able to make a sample that reproduced bug ... Seems like these esoteric bugs hunt me down or something. 8P

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <b> <i> <img> <table> <tr> <td> <ul> <li> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <blockquote> <div> <pre> <font> <h1> <h2> <h3> <h4> <h5> <h6>
  • Lines and paragraphs break automatically.
  • You may use [inline:xx] tags to display uploaded files or images inline.

More information about formatting options

CAPTCHA
This question is for testing whether you are a human visitor and to prevent automated spam submissions.
1 + 4 =
Solve this simple math problem and enter the result. E.g. for 1+3, enter 4.