Tweet
Originally posted by yoshi314
View Post
A tool won't tell you if a game slowdown is because of a bug, a design flaw in the driver, or the studio just doing something stupid with their buffer management code (I've seen all three, actually, over the years...)- or if it's two of the aforementioned problems.
For example...
Vertex Buffer Objects.
They allow you to store the vertex information for pieces of the scene or the whole scene into memory that's resident ON the card. They allow you to pre-load this information at the beginning of a level so you're not pushing the vertex data across the bus, which slows things down. Unfortunately, it's a limited resource. There's several ways to utilize this resource. You can do the "reccomended" way of doing things, per the ARB, which is to allocate a new allocation of VBO space for any new set of vertex data and let the driver's memory management handle it. Unfortunately, this isn't terribly practical on anything with a dedicated memory space of any less than 128Mb of RAM, so most developers used a feature which allows you to manipulate the buffer object's space by mapping it temporarily into the Host's memory space. Now, how you handle this mapping action determines how well everything works- both on the driver and on the applicatrion's side of things. Typically, what you do is wait until the frame is rendered, map the VBO, flush new vertex data to it, then render with the VBO. Some card drivers have smart enough memory management to allow you to map and remap the buffer with impunity so long as the GPU isn't actively using the same. Some card drivers have, unfortunately, been written to stall the pipeline when you map the buffer as they, either because of a lack in hardware, lack of support in memory management, or both, are unable to track which VBOs are actively in use and which ones are not.
Some studios have written their code so that they map the VBO, flush the new data to the buffer, render, then recycle the buffer several times with several different VBO sizes. To get peak framerates out of anything, the GPU has to work MOSTLY asynchronously against the backdrop of the CPU's work. The CPU needs to be able to push the frame to be rendered immediately and then be able to push the next frame(s) while the other one is rendering, such that the CPU is not waiting for the GPU except at end of a frame (if that) and the GPU is never allowed to be idle. A stall of a millisecond or so can drop framerates by as much as half what they might be. With the games in question, if the driver's implementation stalls for engine idle on a mapping operation, they drag the gameplay to the slideshow framerate territory on ANY hardware you care to mention.
In the aforementioned case, it's not as good a design as it possibly could be on the driver's part (The driver should know, within reason, what VBOs, etc. are in play at any given time...) and it's very poor code on the studio's part as the spec explicitly states that a driver "may" wait until engine idle when a map call is made on a VBO.
In the aforementioned case, who's at fault? The studio. But the problem is blamed on the driver and the GPU because the other vendor's code handles the bad behavior of the game much, much better.
Who should fix it? The studio ought to, but it typically falls to the vendor to fix the problem.
That's the kind of world NVidia, Intel, and AMD live in and a testing tool won't help you- you actually need to understand the innards of the driver to be able to find out what's actually busted in many cases, believe it or not.
Comment