Radeon OpenGL 2.0 support

[bridgman]

This is not quite fair to say bridgman. The _external_ kernel API doesn't change frequently at all.

The _internal_ API of the kernel however does change in the way you describe. If your driver uses the external API of the kernel only (when it is in userspace) then your driver would only very infrequently need updates for changed APIs.

If your driver uses the internal API however, then yes, you'll have to deal with the internal API changes. That's the tradeoff. And yes I know, in order to get any performance at all you'll at least need part of your driver in kernel space.

This is a classical dilemma for proprietary drivers.
Which is also why open sourcing your driver/specs is such a good idea :-)

A number of OS functions (memory management is a good example) need to be implemented differently for graphics in order to provide optimal performance. As a result the graphics driver stack ends up having to re-implement some of the upper level OS functions and hook into the OS at a lower level than most other drivers.

Some OSes recognize this and offer a separate set of stable entry points for graphics drivers, while other OSes require that graphics drivers make use of "internal" functions in order to deliver the same level of performance and functionality. Linux follows the second approach - I'm not saying this is *wrong*, just that we need to recognize that there are some costs as well as benefits.

Also, comparing the Windows lifecycle with the Linux lifecycle is quite unfair as well, they are completely different. Linux thrives on the ability to change internal APIs as you well know. For example, how else could G3D ever have come to life?

Actually Gallium3D is a userspace change, similar to the architectural changes we made in our OpenGL stack a few years ago. No impact on kernel code or APIs, other than an implementation decision to only run over KMS/GEM/TTM/DRI2.

You can make a compelling argument that the Windows development cycle and the enterprise/LTS Linux development cycle are very similar, with a new release coming out every couple of years followed by updates which maintain all of the original APIs and core code. The Linux world adds a series of interim end-user releases between major enterprise/LTS releases, resulting in end-user-visible changes (ie the need for new drivers) every few months rather than every couple of years.

[nhaehnle]

This is not quite fair to say bridgman. The _external_ kernel API doesn't change frequently at all.

And this is not quite fair to say to bridgman - after all, he is quite aware of the different API types. He was merely stating the situation from a proprietary driver writer point of view.

(BTW, I tend to agree with the Linux kernel decision of not providing a stable (internal) API, because it makes sense from a technical POV. However, it does make life more difficulty for people who develop exokernel-style drivers like the graphics drivers, so even though I agree that it's the best choice for Linux as a whole, from a purely egoistic POV, I'm not entirely happy about it.)

[fhuberts]

And this is not quite fair to say to bridgman - after all, he is quite aware of the different API types. He was merely stating the situation from a proprietary driver writer point of view.

(BTW, I tend to agree with the Linux kernel decision of not providing a stable (internal) API, because it makes sense from a technical POV. However, it does make life more difficulty for people who develop exokernel-style drivers like the graphics drivers, so even though I agree that it's the best choice for Linux as a whole, from a purely egoistic POV, I'm not entirely happy about it.)

Yeah I know you guys understand it. Actually met bridgman on FOSDEM 2008. You guys are doing a great job.

My remark was merely meant to point out that there are more nuances to the story he is telling. It seemed a bit too much laying the blame with the kernel.

[Almindor]

Actually we dropped support for Linux and Windows at the same time. The issue, I think, is that new versions of Windows normally work with older drivers (eg Vista could use XP drivers and Win7 can use Vista drivers).

Linux changes more frequently, with API changes happening every few months rather than every few years, and requires constant driver updates in order to keep working with changed X and kernel versions. There is no attempt to make use of drivers which supported the previous API; drivers have to constantly change in order to keep working (unlike Windows where a driver from two years ago is often still useful).

The kernel changes are particularly expensive when functions the driver relies on are marked GPL-only, ie saying "binary drivers can't use this functionality any more, you have to redesign the bottom end of your driver and find another way to do the same thing".

I really don't want to start a needless argument, or alienate you guys, since I really like the work you're doing and even with the current state of things, feel very thankful. BUT you didn't get me here.

I know you dropped both windows and linux at 8.3. But if Windows service pack/vista/whatever caused the driver to stop working due to update you'd make a new one for the older cards (same features, just sort of recompiled). This didn't happen with the newer X (AFAIK it was only Xorg which caused problems?). That was my argument.

Anyways, once more, I don't want this to turn into some sort of blamefest, I'm not blaming you guys (at least not the devs) for anything.

[bridgman]

Yeah I know you guys understand it. Actually met bridgman on FOSDEM 2008. You guys are doing a great job.

My remark was merely meant to point out that there are more nuances to the story he is telling. It seemed a bit too much laying the blame with the kernel.

I certainly wasn't trying to "blame" the kernel, but I was trying to explain why we didn't feel that the approach we're using for Windows (quarterly updates, no support for new OS versions) would work as well for Linux.

The decision to constantly evolve APIs has significant benefits but it does have some costs as well, and the costs are probably felt the most in high end graphics, where the cost and complexity of an optimized driver stack makes it harder for open source drivers to replace proprietary ones in all scenarios.

[agd5f]

I know you dropped both windows and linux at 8.3. But if Windows service pack/vista/whatever caused the driver to stop working due to update you'd make a new one for the older cards (same features, just sort of recompiled). This didn't happen with the newer X (AFAIK it was only Xorg which caused problems?). That was my argument.

Both the kernel and newer xservers can be problematic for the proprietary driver since the graphics stack touches both. On the windows side the interfaces stay stable even with service packs.

[nanonyme]

I know you dropped both windows and linux at 8.3. But if Windows service pack/vista/whatever caused the driver to stop working due to update you'd make a new one for the older cards (same features, just sort of recompiled). This didn't happen with the newer X (AFAIK it was only Xorg which caused problems?). That was my argument.

I doubt that's even really possible for Windows. Windows graphics drivers get written against graphics API's that stay constant for usually more than one whole operating system version. Service packs should not be possible to break anything. I think they're currently going with http://en.wikipedia.org/wiki/Windows...y_Driver_Model

[Maxhysteria]

A number of OS functions (memory management is a good example) need to be implemented differently for graphics in order to provide optimal performance. As a result the graphics driver stack ends up having to re-implement some of the upper level OS functions and hook into the OS at a lower level than most other drivers.

And couldn't you have some sort of open-sourced wrapper making the junction between the non-stable internal API and your closed-source driver, allowing developers to maintain this wrapper for older drivers/newer kernels ?

[bridgman]

We already have that -- it's called the Kernel Compatibility Layer -- but it is not always sufficient to cope with big chunks of functionality being marked off-limits to binary drivers.

We would need to make the entire kernel driver open source, and that would mean that we could no longer share code with the drivers for other OSes (which is the big advantage of a proprietary driver in the first place).

This is one of the reasons we think switching to the open source drivers for older GPUs makes sense.

[spykes]

We would need to make the entire kernel driver open source, and that would mean that we could no longer share code with the drivers for other OSes

Why ? The code used within other OSes drivers cannot be open-sourced ?
Is it using some patented features, or things like that ?