AMD's R300 Gallium3D Driver Is Looking Good For 2011

[popper]

The open source drivers are not multi-threaded AFAIK, so single-thread CPU power probably makes a big difference in the performance results. It would be great if the same CPU could be used across a series of benchmarks so that the driver/hardware differences could be isolated.

"The open source drivers are not multi-threaded AFAIK" which is Very ODD Today if thats really the case, as NPTL(Native POSIX Thread Library)has been in since 2.6 started http://en.wikipedia.org/wiki/Native_...Thread_Library
"NPTL has been part of Red Hat Enterprise Linux since version 3, and in the Linux kernel since version 2.6. It is now a fully integrated part of the GNU C Library.[citation needed]
There exists a tracing tool for NPTL, called POSIX Thread Trace Tool (PTT). And an Open POSIX Test Suite (OPTS) was written for testing the NPTL library against the POSIX standard." ,not to mention there are several other optimized 3rd party threading libraries suitable for any such driver inclusion around too.

[mattst88]

It's not about the lack of a threading library. It's that drivers don't make use of threading. It's nod odd, it's the norm.

[marek]

Then how come ARB shaders work much faster using r300classic?

That's a real mystery to me.

Can't the developers use the assembly compiler of r300c in r300g?

Both the drivers have been sharing the same compiler backend since ever.

To Michael and the others: The article only benchmarks r300g and st/mesa. The changes made to the r300 compiler are not visible in the graphs, because all the new compiler optimizations are applied to both r300g and r300c. A benchmark of both the drivers with several different versions of Mesa would better show the overall improvement. Yes, r300c is getting faster as well through the compiler work.

[bridgman]

"The open source drivers are not multi-threaded AFAIK" which is Very ODD Today if thats really the case, as NPTL(Native POSIX Thread Library)has been in since 2.6 started

???

I don't think anyone is saying that the lack of a threading library is the issue. Someone actually has to do the design, implementation and testing work to make it happen, and once the work is done all of the developers and testers have to live with the additional debugging challenges. There are other tasks which need to be done first.

[popper]

???

I don't think anyone is saying that the lack of a threading library is the issue. Someone actually has to do the design, implementation and testing work to make it happen, and once the work is done all of the developers and testers have to live with the additional debugging challenges. There are other tasks which need to be done first.

your implication was that the open drivers were some how at a disadvantage compared to 'closed drivers that are threaded' in todays generic multi threaded CPUs market today, but perhaps it was a misunderstanding and you didn't actually mean that, but that's how it came across on first reading, fair enough.

[mattst88]

I think he _is_ implying that the closed-source drivers are multithreaded, and as such the open source driver are at a disadvantage.

I don't have any clue what you're confused about, or how that confusion could lead to your post about NTPL being around for years.

[bridgman]

I did mean that to a certain extent, but mostly relating to making benchmarks more meaningful for Phoronix readers.

The open drivers probably are at a disadvantage compared to the closed drivers as a consequence of being single threaded, but implementing multithreading is not a trivial task and the developer time is probably better spent on the development work that is being done today. Six months from now, who knows ?

Completing the move to the Gallium3D architecture needs to happen first, along with phasing out UMS other than for legacy distros, so that only one code base needs to be reworked. In the short term, adding support for the performance-related hardware features like tiling provides more end-user benefit relative to developer effort than multithreading, at least for typical end-user systems.

The important thing is that in a single threaded implementation the single-core CPU performance is a significant contributor to benchmark results, and comparing results across different benchmark articles is hard to do unless the same CPU/memory subsystem is used in both cases.

[popper]

It's not about the lack of a threading library. It's that drivers don't make use of threading. It's not odd, it's the norm.

dont you find that fact odd though? given virtually all dev's and end users today will be using at least a dual x86 CPU in 2010/11, but no matter, moving on....

[mattst88]

dont you find that fact odd though? given virtually all dev's and end users today will be using at least a dual x86 CPU in 2010/11, but no matter, moving on....

No, it's not odd or unexpected at all.

Most programs are single threaded because in most cases, it's really hard to figure out how to split work efficiently across multiple CPUs. It's a huge outstanding research problem at the moment and probably will be for some time to come.

[bridgman]

It's no more odd than any other tasks that will get done eventually as time permits. The developers are working on things based on (a) what delivers the most benefit to users and (b) the inherent dependencies that go along with any rearchitecture work (first you pillage, *then* you burn).

Popper, are you suggesting that multithreading should have been implemented before other tasks ? If so, which tasks do you feel should have been delayed in order to free up time for multithreading ?