If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Define that... You can be a real gamer while playing 2D games, and all of those are well supported by OSS drivers.

Indeed, although I do play 3D games with R600g and I do tend to consider myself as being an enthusiast gamer. Now, I am an enthusiast Linux gamer, and this does limit the section of titles I can play somewhat, but for the most part I am quite happy of the performance of my Diamond Radeon HD 4670. Over the past year I have played through titles such as Enemy Territory: Quake Wars, Prey, Trine, Trine 2, and Amnesia: The Dark Descent with acceptable performance, and the only game I have not been able to launch ostensibly due to graphics issues is Bastion, and the only game where I have really performance problems is Pshyconauts, but this is due to bugs in the port and not my driver setup.

And this is on an, admittedly updated, Fedora 16 setup. I am waiting to see if I will get performance improvements when I update to Fedora 18 or not.

So to take that one step further, what you are implying, is that PTS is doing something that is crippling the results and is therefore NOT a valid benchmark. I wonder if that would be an oversight, of if the results are intentionally sabotaged...?

I've never taken PTS seriously.

I've finally managed to make Reaction Quake pick up the PTS config and I can now reproduce the low framerate. Sorry for the noise.

Once the GPU HARDWARE gets the data, it will do it at the same speed. It's just that getting the right data to the hardware at the right moment takes longer with the open driver -- and that one runs on the CPU.

Not at all. The CPU driver has a huge impact on what the GPU hardware can do. The driver has to configure a lot of functionality, control clock gating, optimize the shader programs, etc. There are still entire swaths of features on all three major lines of hardware that the FOSS drivers don't enable and the lack of which seriously impacts performance. Examples of such features recently brought up right on this very site are texture tiling, hierarchical Z-buffering, higher PCI transfer speeds, and power state control.

You can also easily measure where the bottleneck lies. If your CPU is pegging 100%, the driver (or the app itself) is the bottleneck. If the GPU is pegging 100%, it's the hardware. Any recent tests I've seen have shown that the CPU usage with the FOSS drivers is not all that terrible (though not great) and yet the FPS is extremely worse. Clearly, then, the GPU hardware is the bottleneck; in this case, not because the hardware itself is bad, but because it's running in a race with its hands tied behind its back and one leg chopped off.

Does anybody know what the fundamental reason for the speed difference is? The proprietary driver is at least 3X faster on all tests - that is not something that you can achieve only with incremental code tweaking.

From the perspective of the 3D engine, there are not really that many additional features missing between the open and closed driver. At this point about all that is missing is HiZ. PCIE 2.0 is now enabled by default in recent kernels and now that mesa 9.0 is out, 2D tiling is enabled by default in xf86-video-ati (not sure if it was enabled in these tests or not). What there is is 15+ years of optimizing memory managers, driver heuristics and micro-optimizations in the closed driver. A lot of what helps performance is driver heuristics for things like buffer placement or minimizing extra transfers of data. E.g., forcing some buffers to prefer vram rather than gart increases performance by a factor of 4x:http://lists.freedesktop.org/archive...er/029415.html

Speaking of Piglit tests, are there any OGL conformance tests that work on Catalyst? It would be interesting to compare how both conform to standards.

Mozilla had a WebGL conformance test and a lot of the proprietary drivers have historically failed it, such as the last proprietary Catalyst driver available for R300 hardware.

The proprietary Catalyst driver for R300 hardware got blacklisted by Mozilla for WebGL while the open source r300g driver isn't blacklisted and works fine. You can force your way past the blacklist when using the proprietary driver, but then the PC just locks hard when it hits some WebGL. I think there is also some 2D acceleration blacklists too because scrolling in firefox is a *LOT* faster on the open source r300g driver than the old proprietary driver on pages with lots of images.

Examples of such features recently brought up right on this very site are texture tiling, hierarchical Z-buffering, higher PCI transfer speeds, and power state control.

Like Alex says, most of this is finished for radeon cards. Perhaps not turned off by default on most distros, but it's been written.

And yes, optimizing shaders can bring huge gains, but Quake3 doesn't need much of that, and it's still slower.

You can also easily measure where the bottleneck lies. If your CPU is pegging 100%, the driver (or the app itself) is the bottleneck. If the GPU is pegging 100%, it's the hardware. Any recent tests I've seen have shown that the CPU usage with the FOSS drivers is not all that terrible (though not great) and yet the FPS is extremely worse. Clearly, then, the GPU hardware is the bottleneck; in this case, not because the hardware itself is bad, but because it's running in a race with its hands tied behind its back and one leg chopped off.

I don't know much about GPU drivers to argue with you about this. It will depend on how often the GPU has to wait for the driver to finish doing its stuff, and I can think of scenarios where this induces delays even when CPU is far from 100% load, I get this regularly when running OpenCL software. But like I said, I'm not a driver guy, so I have no clue how it is really done.