Have the drm.git kernel modules been abandoned?

[agd5f]

So because a user would like to develop an app/game without giving up the source he shouldn't target linux?

I'm talking specifically about drivers. The kernel is open source and driver developers should target upstream inclusion if they want their driver to work well on Linux.

Home-user desktops also tend to be less tech-savvy and won't get through the trouble of compiling the latest DRM branch or install a new kernel.

They are not supposed to. They use whatever the oem puts on the system. In most cases this is windows. For those users wanting to try Linux, the distro packages everything for you. Until Linux gains more desktop market-share, there will tend to be a delay between desktop hardware availability and driver availability. If you want to use the bleeding edge now, you need to use development trees.

[Kjella]

Uh, YES. In fact I *DO* see AMD able, willing, and ACTIVELY DOING so... Did you read the front page news today? http://www.phoronix.com/scan.php?pag...item&px=NzU0Nw

With all due respect to what AMD is doing, they're building an open source driver that might be a little over half as fast as the blob when it's fully operational. That's kinda like telling you how to make a Formula One car go 100mph instead of 200mph. Which is just about any way you make it use the engine and not go out and push.

Certainly, it's very nice that they do give away that much and that they reveal the hardware interface at all, But I don't think that AMD is giving away any tricks that'll make them come out 2 FPS behind instead of 2 FPS ahead in the next GPU shootout. Those kinds of optimizations are in the blob and staying in the blob for the foreseeable future.

I think Linux would do better pushing for universal standards, like for example how all USB sticks conform to a USB mass storage device spec - no need for separate drivers. Same with webcams and USB video spec. Create a few more like those and there is little reason to have a million drivers in the first place.

[agd5f]

With all due respect to what AMD is doing, they're building an open source driver that might be a little over half as fast as the blob when it's fully operational. That's kinda like telling you how to make a Formula One car go 100mph instead of 200mph. Which is just about any way you make it use the engine and not go out and push.

It's not so much an information thing as an effort thing. Squeezing out every last drop of performance is a major amount of engineering. There's enough information out there to write a driver that comes close to the performance of the closed driver, but there are not enough developers to actually realize that. To use your analogy, the instructions and engine upgrades are there to go 200 mph, but there aren't enough mechanics to install it all. The cost of lots of extra mechanics is not justified if only 2 people are actually going to watch the race.

[bridgman]

With all due respect to what AMD is doing, they're building an open source driver that might be a little over half as fast as the blob when it's fully operational. That's kinda like telling you how to make a Formula One car go 100mph instead of 200mph. Which is just about any way you make it use the engine and not go out and push.

Certainly, it's very nice that they do give away that much and that they reveal the hardware interface at all, But I don't think that AMD is giving away any tricks that'll make them come out 2 FPS behind instead of 2 FPS ahead in the next GPU shootout. Those kinds of optimizations are in the blob and staying in the blob for the foreseeable future.

Just to be clear, the plan has always been that we provide documentation, sample/initial code and developer support, then the open source community writes and maintains the drivers. In the case of 6xx/7xx 3D, the community developers were mostly focused on other areas like KMS and GEM/TTM, so we offered to do most of the initial coding, and that is mostly completed. What happens next in terms of performance and features is up to you.

We are going to keep helping in what we see as key areas (which may include performance), and we are going to keep adding support for new hardware, but you should *not* be expecting us to write the drivers ourselves or complaining if we don't dump enough proprietary code into the open source stack. We have a proprietary driver for that.

I don't think anyone is trying to match the performance and features of the Catalyst driver BTW; the goal is to provide a driver set which meets the needs of most desktop users, which can stay current with (and be used for the development of) the evolving X/DRI framework, and which can be directly supported by Linux distribution developers.

[nanonyme]

Just to be clear, the plan has always been that we provide documentation, sample/initial code and developer support, then the open source community writes and maintains the drivers. Our job was to make sure there is enough information out there for the development community to program the hardware, *not* to write the drivers ourselves. I would rather have our team working on Evergreen or trying to open up UVD.

I at least appreciate the effort that's led into imo amazingly fast progress. You guys definitely got to my personal Wall of Beer. (members eligible for a round if they pop by )

[mdias]

I'm talking specifically about drivers. The kernel is open source and driver developers should target upstream inclusion if they want their driver to work well on Linux.

While I agree that drivers might be better on the kernel and open, we should allow for binary blobs to still exist and be compatible for as long as possible.

BTW, won't the kernel get to a point where there's just too many things to change when changing the interface? (because of the amount of drivers included).

They are not supposed to. They use whatever the oem puts on the system. In most cases this is windows. For those users wanting to try Linux, the distro packages everything for you. Until Linux gains more desktop market-share, there will tend to be a delay between desktop hardware availability and driver availability. If you want to use the bleeding edge now, you need to use development trees.

True.

[nanonyme]

BTW, won't the kernel get to a point where there's just too many things to change when changing the interface? (because of the amount of drivers included).

This is exactly why the drivers should be included in the kernel tree and adapt to changes change by change instead of eg every kernel version.

[agd5f]

While I agree that drivers might be better on the kernel and open, we should allow for binary blobs to still exist and be compatible for as long as possible.

Why other than that's what windows does?

BTW, won't the kernel get to a point where there's just too many things to change when changing the interface? (because of the amount of drivers included).

I don't really see that happening. Often times the changes can be made with simple search and replace. I think the argument is more relevant to keeping old internal interfaces around for backwards compat, eventually you have so may old interfaces the code gets unreadable and unmaintainable.

[lbcoder]

I never said I'd want to GPL my code if I were to release my device's driver...

If you don't want to GPL your code, then don't write kernel drivers. Fact is that the GPL *DEMANDS* that your code be compliant with the GPL, and writing non-GPL drivers is a violation of the GPL since that is what the kernel itself is under. And yes, the kernel interfaces written by AMD and NVIDIA for their blob drivers are GPL compatible (though it is debatable whether the blob part is compatible, which is part of the reason for migrating to open source drivers).

So because a user would like to develop an app/game without giving up the source he shouldn't target linux?

<<flush>> this has nothing to do with the discussion, which is about DRIVERS, not applications, which BTW need NOT be GPL.

You're right, I made a poor choice of words, I meant developers don't target linux so much.

??? I see no meaning or relevance to this statement.

Linux webservers certainly don't need bleeding edge technology, it doesn't need constantly updated drivers and kernerls to support those tasks.

RIGHT!!! so don't bother wasting your time on bleeding edge kernels if you don't need them! Nobody is holding a gun to your head telling you that you *must* run the latest of everything.

Home-user desktops also tend to be less tech-savvy and won't get through the trouble of compiling the latest DRM branch or install a new kernel.

No, they'll install whatever distro they like, which (depending on the maintainers) will include updates applicable based on the policies of that particular distro. If you don't like regressions, use a more stable distro. If you use the latest and bloodiest distro, chances are that you'll have the latest and bloodiest drivers. Case in point: Fedora Rawhide (what is to become Fedora 12) has Radeon R600/700 3D/KMS in it *right now*.

It's true that companies will do whatever it takes to get money, however they'll also choose the easiest way to do so, and unfortunately, currently that's on Windows. I'm hoping Gallium 3D will improve gaming on linux dramatically, however I wouldn't bet on that.

This is absolutely related to MARKET SHARE and has nothing to do with anything else.

on another note; who would be held responsible if my open source gfx driver wiped out the BIOS of the card?

Unless the author was a braindead monkey on drugs, the chances of this happening are *EXTREMELY* remote, and FYI: the chances are *equal* regardless of whether the drivers are open or closed source. No, scratch that, the chances are *GREATER* if the drivers are closed source since there are fewer eyes on the code to make sure that nothing stupid happens.

I'd love to use a stable, fast driver if it was closed source. At least I know I'd get support from that company even if I ever needed (they have their name to defend, unlike OSS devs).

You seem to have things backwards. You typically get BETTER support for open source drivers, faster updates, greater compatibility, less waiting before the driver is updated to support your favorite new bleeding edge distro, the possibility of FIXING IT YOURSELF if something is wrong, the security of knowing that if the manufacturer goes out of business that the whole code is still there to work with, the security of knowing that when the hardware goes "legacy" a year or two after it is manufactured, that it will continue to be supported (until it is so obsolete that you would have to be NUTS to try to use it), ...

Sure, fglrx sucks for the normal user and as such I currently use the open source drivers that are going strong

Always worked fine for me, but whatever...

Please don't get me wrong, I'm not saying the oss devs don't support the users; I'm saying that they don't HAVE to.

*OF COURSE THEY DO* -- the open source devs *work for someone* who's reputation *IS* on the line. In fact, sometimes MORE peoples'/organizations' reputations are on the line with the open source drivers than with the closed since open drivers may be developed by *MORE THAN ONE* organization, again case in point: Radeon R600/700 new stuff: AMD + Red Hat (+other?) vs. fglrx: AMD only (sure there may be IP from other groups in fglrx, but it is still just AMD on the front cover).

[nanonyme]

From radeon kernel drivers:
"Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:" followed by the "you must include this permission note and copyright clause with software" and "no warranty" conditions. Sounds plenty fair to me.