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.

How Old ATI GPUs Can Be Faster On Open Drivers

02-13-2011, 10:50 AM

Phoronix: How Old ATI GPUs Can Be Faster On Open Drivers

A few days ago when publishing the results of benchmarking a lot of graphics cards on their Gallium3D drivers (about a dozen graphics cards) this left a number of people surprised. A number of these results from the open-source Gallium3D drivers illustrated the older graphics processors as being much faster than the newer hardware, even though the newer hardware is far superior to the vintage products. This shouldn't have been a surprise if you stay up-to-date with the Linux graphics news on Phoronix, but it comes down to features found in the older Gallium3D drivers not yet implemented in the newer open-source drivers...

Comment

Will AMD ever bind selling of new cards to opensource driver development?
This seems as extremely critical to me now, as kernel devs claim themself that hardware gets more complex with each release.
The opensource driver development vector should at least keep the pace with new hardware development vector.
Otherwise all opensource community ends in situation of perfect opensource driver for the card that is not sold, or even not compatible with modern hardware anymore.
There is no point in such software and the whole effort can be considered as wasted then.

Comment

Will AMD ever bind selling of new cards to opensource driver development? This seems as extremely critical to me now, as kernel devs claim themself that hardware gets more complex with each release. The opensource driver development vector should at least keep the pace with new hardware development vector. Otherwise all opensource community ends in situation of perfect opensource driver for the card that is not sold, or even not compatible with modern hardware anymore. There is no point in such software and the whole effort can be considered as wasted then.

Crazycheese, same answer as the last few times you asked...

If there was a reliable and reasonably accurate way to track opensource driver usage (one which was reasonably immune to being gamed or scripted) then I'm sure that information would get considered in our development plans at some point. I haven't heard of or seen any approaches which meet those criteria yet. Self-selecting mechanisms such as response forms aren't even close. Let's say we get 23,654 responses all saying "I only use open source drivers" - 100% of users, right ? Now, let's look at that in the context of say 100M units sold per year - now we're down to 0.025% market share, which means we have too many developers working on Linux already.

That said, our commitment is to provide documentation and/or sample code and developer support to let the driver dev community build good open source drivers without having to reverse-engineer the hardware, not to develop those drivers ourselves, and we have been doing that for a few years now, so I'm not sure why you feel it is so important for us to provide additional developers.

It seems to me that the first thing you are asking for is a wholesale change in strategy, maybe the "give up on the workstation market and focus our efforts on the consumer Linux client business so we can justify diverting more resources to open source drivers" approach ?

Comment

Why are the open source drivers unable to implement S3TC? As long as its use is restricted to hardware where the manufacturer paid the licensing fees, there should not be a problem.

I vaguely remember one of the devs saying something about that. I think it was something like this: the hardware S3TC support doesn't necessarily work for all operations allowed by the spec (e.g. all combinations of texture formats and textures/pbuffers located in system vs. GPU memory), so S3TC support would require a separate software implementation as a fallback, and then Mesa is basically shipping its own implementation rather than just supporting the hardware implementation, which complicates things.

Comment

We need a GPU openhardware to evolve as fast and well as opensoftware does.
At least Open specifications.
The first company doing it will earn a lot of money, even if they also have propietary products.

Comment

We need a GPU openhardware to evolve as fast and well as opensoftware does.
At least Open specifications.
The first company doing it will earn a lot of money, even if they also have propietary products.

openhardware doesn't matter that much (at least for the end user)

What would seem like a "feasible" thing to do is, for a manufacturer, to move its driver development to G3D on all operating systems (it is portable afaik). But i don't thing none of the big 3 (nv, ati, intel) are going to do it (or can ) .

Comment

VMWare already uses Gallium for their drivers on all platforms. At least one incarnation of the Poulsbo driver uses Gallium on Windows and Linux. If the appropriate kernel piece and winsys were written, all nouveau drivers, r300g, and r600g, could be ported to Windows. Nobody cares about Windows enough to make it happen.

Stop talking about S3TC. We already have done as much as we can.

Also, I'm going to sum up the article as: Nobody pays the community developers to write code that makes GPUs more efficient. I'm sure this'll start a flame war, but whatever.