Because they’re TERRIBLE at it. Yesterday I got a bug report about Gorgon displaying nothing but corrupted garbage on an Intel 945 Express chipset. Of couse my alarm bells when off when I read the word “Intel” and I immediately set out to find someone else to confirm this. Of course, finding someone with these older chipsets is like trying to find gold in my toilet and thus I had no way to confirm or even know where to start.
That is, until today when I remember that the machines in the office all have onboard video in addition to having Radeons. I checked the computer next to me and lo and behold it had an Intel 82865 integrated nightmare. So I set it up for development with Gorgon and found the issue that was causing the corrupt graphics. Lo and fucking behold. It turns out to be, wait for it… a driver bug.
Here’s what went wrong:
My code creates one vertex buffer to display the sprites. It never, ever, ever, changes the structure of the buffer, nor does it have any other reason to re-create the buffer. All it does is modify the contents of the buffer. So with this in mind, I only call SetStreamSource once for the lifetime of the application (except in cases of a device reset) – this is a performance thing, while not terribly slow, it still helps speed things up a tiny bit.
So in my search to find what’s wrong I run the ball demo through PIX (which is godly) and get a snapshot of my vertex buffer in action. For my test I had set up 2 sprites, each using a different texture so it’ll force a flush of the renderer. Sprite 1 was sized 64×64, sprite 2 was 200×56. The first sprite was displayed in the upper left of the screen at (0, 0) and the 2nd was place at the lower right (600, 544). When viewing the contents of the vertex buffer when it was submitted to DrawIndexedPrimitive I saw this for the first sprite:
- Left, Top coordinates: 0, 0
- Right, Bottom coordinates: 64,64
That’s correct for the first sprite, but here’s what I got in the vertex buffer for the 2nd sprite:
- Left, Top coordinates: 0, 0
- Right, Bottom coordinates: 64,64
Clearly the second sprite is not writing to the buffer. But why? So on a hunch i found culprit: SetStreamSource. Like I said earlier, it’s only called once to bind the vertex buffer. So I set it to be called every frame and sure enough, the application worked.
Here’s why it’s Intel’s fault:
On some advice I ran the program with the reference rasterizer and using the debug runtimes (which I always check first anyway).
The reference rasterizer is the guide to indicate how D3D is SUPPOSED to behave. And when an app doesn’t behave the same way on the refrast as the hardware, then the drivers are in question.
Anyway, I was concerned that I was doing something wrong by only calling SetStreamSource once, even though it worked on just about -every- piece of hardware that I’ve been using. So I ran my original code through the refrast and sure enough – it worked. Thus, the intel driver is broken.
I think for any other projects that I publish (not including Gorgon since I’m already in too far), I won’t be supporting Intel’s buggy drivers.