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.

fixed that for you o_O
actually im pretty impressed with some of the benchmarks.
1/4 of the catalyst performance is pretty good i think.
and afaik they havent really started doing any optimizations on the cards yet.
would have loved to see how the old catalyst drivers for r300 performed.
but thanks for the benchmarks michael!

Right, my impression of the performance with the r300g vs last working fglrx is simmilar in Nexuiz or Xonotic on Radeon 9600 and X300 but it needs to enable some performance improving features (not lowering picture quality though). Enabling GLSL shaders is one of the options that improves performance to something about twice as without it is most cases but the other options using more GLSL shaders should be used carefully to not drop performance too much.

Btw. the test should include the lowest and highest FPS, too and if it could be or where it could be possible to check - what FPS was in the most of the time (median) instead of arithmic average counted. I don't know if any game measures that but it would be useful to have such information, too.

I think it would be helpful to include a comparison of somewhat basic feature sets of the drivers being used for the benchmarks. So for example:

Catalyst:
Has Page Flipping
Has <insert feature here>

r300g:
Does not have Page Flipping (not enabled or whatever)
Does not have OpenGL 3 support
Does not have <insert feature here>

Just increases awareness and puts the OSS drivers in a better position in one way as they might be performing decently without the respective features.

Also, what would one have to go through to become a developer from scratch? As in if one does not know programming in the respective language and no knowledge of graphics programming, is not a university student but can spend some time as a part-time dev? I'm just thinking in terms of solving man power issues and spreading the development more into the community.

A good first step towards being a developer would be to learn some basic OpenGL programming. You can use OpenGL from a number of different programming languages but it's probably worth picking up C at the same time. You're going to start by copying sample code snippets anyways, so in a sense the programming language doesn't matter as long as you have a working compiler.

Alternatively, learning to build and install the drivers from source would be a good place to start.

catalyst uses multithreading, right?
what would be the results of the benchmarks without it? (assuming these have been made with multiple cores enabled)
could it be the oss drivers would be satisfactory if multithreaded?

catalyst uses multithreading, right?
what would be the results of the benchmarks without it? (assuming these have been made with multiple cores enabled)
could it be the oss drivers would be satisfactory if multithreaded?

Yes, the Catalyst driver hands off most of the rendering work to a separate thread, allowing it to return more quickly to the calling application.

The open source devs have done some preliminary testing with fglrx on a single core system -- right now the open driver with rendering stubbed out is still slower than fglrx running on a single core. The initial conclusion from that testing is that while multithreading will probably be part of the eventual solution there are other, bigger bottlenecks that need to be looked at first.

If multithreading were easy to implement in the open source drivers it would probably still be worth doing early because it would help to hide some of the other bottlenecks, but as I understand it the implementation is not considered to be easy at this point.

As time permits we are trying to dig into how the Catalyst driver state change logic is coded and see if there are ideas which can be applied to the open drivers. The open source driver code seems pretty efficient though, which is why there is some head-scratching going on.

There are other areas such as the shader compiler where everyone understands that the code could be made more efficient (with a lot of work), but we should be able to get higher performance than we are seeing today even with the current shader compiler.

I haven't gone through the current code in detail, but AFAIK there is still some gains to be had from work that is already underway. Things like tiling, page flipping and HyperZ are being worked on as time permits and I don't think they were all reflected in the current benchmark numbers. As an example, I think the open drivers currently use tiling for the colour buffers (ie the render target) but not for textures.

The unhappy thing about performance improvement is that you don't get big performance gains from one place -- you get gains in the 1-5% range from each of a number of areas, and each of those gains requires a lot of work and makes the code more complex to maintain and troubleshoot in the future.