Re: [opensuse] Fw: Driver Repository for openSUSE / SuSE Linux Enterprise (nVidia)
I see, and that's why Novell does not allow to host the interface module on their server (which in fact would be the only thing that has to be compiled for eatch and every kernel).
Actually I think the interface module is GPLed, it's the driver that isn't. SUSE used to distribute the shim with their kernel which was how YOU could install it without having to recompile anything (take a look at the script YOU used to install it). AFAIK nvidia's driver doesn't violate the GPL because they use a GPLed shim, this doesn't mean it's morally right though. benji --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
B.Weber@warwick.ac.uk wrote:
AFAIK nvidia's driver doesn't violate the GPL because they use a GPLed shim, this doesn't mean it's morally right though.
With that reasoning, every software license would be meaningless. The Linux kernel is GPLed. "Shim" modules that link into it automatically have to be GPLed as well. So the kernel and the shim module together form a GPLed work. How exactly are you going to tell a court that the GPL suddenly didn't apply anymore? Speaking as a private individual (not for any employer) and kernel developer, I hope somebody has the time and money to sue certain GPL violators. Suing works well for userspace programs and embedded devices (see http://gpl-violations.org/ for details), so why not for certain kernel modules, too? I admit that for a few persons the eradication of closed source kernel modules may be somewhat unpleasant, but in the longer term it is the only feasible way. The unavailability of said modules will make people more willing to test reverse engineered drivers, leading to greater driver quality overall. Regards, Carl-Daniel --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Carl-Daniel Hailfinger wrote:
B.Weber@warwick.ac.uk wrote:
AFAIK nvidia's driver doesn't violate the GPL because they use a GPLed shim, this doesn't mean it's morally right though.
With that reasoning, every software license would be meaningless. ... Speaking as a private individual (not for any employer) and kernel developer, I hope somebody has the time and money to sue certain GPL violators. Suing works well for userspace programs and embedded devices (see http://gpl-violations.org/ for details), so why not for certain kernel modules, too?
That money would better be invested into writing a reverse engineered 3D capable driver for nVidia GPUs. What's next, sue the "mad" project ?
I admit that for a few persons the eradication of closed source kernel modules may be somewhat unpleasant, but in the longer term it is the only feasible way. The unavailability of said modules will make people more willing to test reverse engineered drivers, leading to greater driver quality overall.
"unpleasant" is not the right word. Where are the reverse engineered drivers for nVidia ? Where is a capable graphics card with 100% GPL drivers ? Not nvidia, not ati, not intel, so ... ? I'm not whining, just pointing you to the current situation as far as hardware accelerated 3D GPUs are concerned on Linux. Is there any good 3D GPU that has a 100% GPL driver ? Is there any WLAN chipset that you can buy today and that has a 100% GPL driver ? (well, there is, the one that has been dropped from 10.1) I totally understand your point, but it's also about being somewhat realistic. The fact that obviously you nor any other kernel developer needs or uses a hardware accelerated 3D GPU is one thing, but not letting people live with a far from perfect but functional situation is another. Freedom and GPL are invaluable, but bigotry doesn't help anyone. Would it be so bad to have a repository hosted outside of novell.com/opensuse.org that ships nVidia's driver as an RPM instead of having people go through compiling it themselves ? Certainly would be a big help for a lot of users. Yes, we can currently use nVidia's repository for SLED, but that is just a "by chance" side-effect, there is no guarantee whatsoever that we will still have that option in a near future. cheers - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ <pascal.bleser@skynet.be> <guru@unixtech.be> _\_v The more things change, the more they stay insane. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFE/KKfr3NMWliFcXcRAkyaAKCDofuhVO3o7zIv/1445lAH+ovgXACbBbqx /caGNxYd3M4iXA14tiYG724= =GGmO -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Tue, Sep 05, 2006 at 12:03:11AM +0200, Pascal Bleser wrote:
That money would better be invested into writing a reverse engineered 3D capable driver for nVidia GPUs.
I think this is a bit short-sighted. Developing a driver for a complex hardware device like a modern graphic card will always result in something that is behind the "original" driver. This will result in most people still just using the closed driver and frustration by those people developing the open driver because of lack of feedback and stuff like that. Your only chance to improve this situation is to force the hardware vendors to provide open specs or drivers. If you don't have the power to do so, you lost in the first place. Robert -- Robert Schiele Dipl.-Wirtsch.informatiker mailto:rschiele@gmail.com "Quidquid latine dictum sit, altum sonatur."
Hello, * Robert Schiele <rschiele@gmail.com> [2006-09-05 01:01]:
Your only chance to improve this situation is to force the hardware vendors to provide open specs or drivers. If you don't have the power to do so, you lost in the first place.
Well, and what is if the hardware vendor develops _no_ driver at all for Linux after that? Regards, Bernhard -- Melchior FRANZ wrote: [Unsinn] -- Melchior Franz in suse-linux
Bernhard Walle wrote:
Hello,
* Robert Schiele <rschiele@gmail.com> [2006-09-05 01:01]:
Your only chance to improve this situation is to force the hardware vendors to provide open specs or drivers. If you don't have the power to do so, you lost in the first place.
Well, and what is if the hardware vendor develops _no_ driver at all for Linux after that?
Regards, Bernhard
It is simple, if they can afford that than good. The only thing that we can do is to accept their decision, include such hardware in Linux Incompatible list, and advertise that list all over the place, to prevent people from buying a lemon. -- Regards, Rajko. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sep 05, 06 19:34:36 -0500, Rajko M wrote:
The only thing that we can do is to accept their decision, include such hardware in Linux Incompatible list, and advertise that list all over the place, to prevent people from buying a lemon.
And prevent many users from actually using Linux at all, because there is *no* really fast 3D hardware with OS drivers. It's not so simple. Matthias -- Matthias Hopf <mhopf@suse.de> __ __ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ mat@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ labs www.mshopf.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Matthias Hopf wrote:
On Sep 05, 06 19:34:36 -0500, Rajko M wrote:
The only thing that we can do is to accept their decision, include such hardware in Linux Incompatible list, and advertise that list all over the place, to prevent people from buying a lemon.
And prevent many users from actually using Linux at all, because there is *no* really fast 3D hardware with OS drivers.
It's not so simple.
It Matthias. If we start to run to get more users as the only goal that we going to loose even existing base. Linux picks up computer users that know for sure that they don't want what is offered in other environments. One of "don't like" is what you mentioned in another post
There are no specs, so they cannot be published.
Release cycles are too fast, there is no documentation even within ATI or NVIDIA.
That is the same as there is airplane without plans. Do you need this in Linux? Open source has problems with documentation too, but at least, the ultimate specification, source code is open, so you can compare to the real world. Once upon a time computer did exactly what is specified. If not vendor was laughed out like an incompetent bunch of amateurs. No one wanted such reputation because it meant no customers. You can imagine how sounds "it is normal that first released version is buggy". If first is buggy, and release cycles are so fast, what version will have no bugs? The one that is not released? While for multimedia computers some bugs are not important, for computer as machine that is meant to compute exact values, almost any bug is important. It indicates that program is not properly tested, and user can't trust that it will perform as designed in important functions. -- Regards, Rajko. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Rajko, On Sep 08, 06 19:44:10 -0500, Rajko M wrote:
And prevent many users from actually using Linux at all, because there is *no* really fast 3D hardware with OS drivers.
It's not so simple.
It Matthias. If we start to run to get more users as the only goal that we going to loose even existing base. Linux picks up computer users that know for sure that they don't want what is offered in other environments.
I know. I'm not saying I'm all for binary modules, not at all. I'm just saying the world isn't black and white.
There are no specs, so they cannot be published.
Release cycles are too fast, there is no documentation even within ATI or NVIDIA.
That is the same as there is airplane without plans. Do you need this in Linux?
It is *definitvely* not the same. - If a plane crashes people die. This is typically not the case if a graphics driver crashes. - Planes don't get obsolete after 2 years. - Planes cost a bit more than 200-500 bucks. - The airplane market is a little bit bigger than the graphics hardware market. - It is also a little bit more regulated than the graphics hardware market. Do I need high-performance graphics in Linux? *YES* Wouldn't have my job, wouldn't have my PhD without.
Open source has problems with documentation too, but at least, the ultimate specification, source code is open, so you can compare to the real world.
Then what? Why is the r200 driver in such a bad shape? It's open source, and many people are working on it. For complex hardware w/o docs with erratas you need direct access to the hardware engineers. Which, of course, is only possible in-house. Other than that you're right, we DO want open source drivers. But not if that means the producers just kick out the code and abandom it. Because without input from the original developers they start falling to a silent, miserable death. We want something like the intel drivers, which are still mostly being worked on by intel (not directly, but who cares).
Once upon a time computer did exactly what is specified. If not vendor was laughed out like an incompetent bunch of amateurs. No one wanted such reputation because it meant no customers.
Once upon a time a computer had 640KB of memory, because that was more than was ever needed. Don't, just don't compare the complex beasts we have nowadays with a PC of 1980 or even a ZX-1 or an old SuperMicro.
You can imagine how sounds "it is normal that first released version is buggy". If first is buggy, and release cycles are so fast, what version will have no bugs? The one that is not released?
Software has bugs. Period. This is a lema in computer science, like it or not: All even modestly complex software has bugs. Read: helloworld.c has (hopefully) no bugs, all others have. It's just the number and severence of bugs we are finding in some products at release time that may really get on one's nerve. On mine, too, of course.
While for multimedia computers some bugs are not important, for computer as machine that is meant to compute exact values, almost any bug is important. It indicates that program is not properly tested, and user can't trust that it will perform as designed in important functions.
No, typically >90% of all bugs will never ever be encountered, or they will have no side effects (which is close enough to not being a bug, I admit). Yes, the space shuttle and ariane software has bugs as well. Only those that showed up bad (read: destroying the aircraft) are noticed by the public. Matthias -- Matthias Hopf <mhopf@suse.de> __ __ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ mat@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ labs www.mshopf.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Matthias Hopf wrote:
Rajko,
On Sep 08, 06 19:44:10 -0500, Rajko M wrote:
And prevent many users from actually using Linux at all, because there is *no* really fast 3D hardware with OS drivers.
It's not so simple. It Matthias. If we start to run to get more users as the only goal that we going to loose even existing base. Linux picks up computer users that know for sure that they don't want what is offered in other environments.
I know. I'm not saying I'm all for binary modules, not at all. I'm just saying the world isn't black and white.
So, we agree, I just said in different words "it is not that simple" :-)
There are no specs, so they cannot be published.
Release cycles are too fast, there is no documentation even within ATI or NVIDIA. That is the same as there is airplane without plans. Do you need this in Linux?
It is *definitvely* not the same.
- If a plane crashes people die. This is typically not the case if a graphics driver crashes.
- Planes don't get obsolete after 2 years.
- Planes cost a bit more than 200-500 bucks.
- The airplane market is a little bit bigger than the graphics hardware market.
- It is also a little bit more regulated than the graphics hardware market.
I expected such answer. It was probably wrong example. Important is that product without exact plans takes too much time to make usable.
Do I need high-performance graphics in Linux? *YES* Wouldn't have my job, wouldn't have my PhD without.
I agree that we need. Problem is that if any drivers have to break whole concept of open source than it is the same as when Ariane breaks because of some stupid bug.
Open source has problems with documentation too, but at least, the ultimate specification, source code is open, so you can compare to the real world.
Then what? Why is the r200 driver in such a bad shape? It's open source, and many people are working on it.
There is so many pieces of software out there, many people are working on it, but not everyone is able to organize work properly, nor to produce good code. But you know that.
For complex hardware w/o docs with erratas you need direct access to the hardware engineers. Which, of course, is only possible in-house.
That is one of reason that kernel developers want GPLed software, not proprietary accompanied with NDAs that one day can explode and run them out of business.
Other than that you're right, we DO want open source drivers. But not if that means the producers just kick out the code and abandom it. Because without input from the original developers they start falling to a silent, miserable death. We want something like the intel drivers, which are still mostly being worked on by intel (not directly, but who cares).
Intel can make the difference in other companies habits. If Intel can find financial interest to play on open source market, others will rethink about own Linux strategy.
Once upon a time computer did exactly what is specified. If not vendor was laughed out like an incompetent bunch of amateurs. No one wanted such reputation because it meant no customers.
Once upon a time a computer had 640KB of memory, because that was more than was ever needed.
Don't, just don't compare the complex beasts we have nowadays with a PC of 1980 or even a ZX-1 or an old SuperMicro.
I compared beasts of today with oldtimers few times. In examples I used where 1970's mainframes specifications. I compared how many people were active in maintenance and programming, and how many today. It is funny that machines, that were smaller than your examples, used to keep up and running few engineers and more technicians, programmers, accountants. Today one man, that often has no basic knowledge about computers, is all that operates "the beast".
You can imagine how sounds "it is normal that first released version is buggy". If first is buggy, and release cycles are so fast, what version will have no bugs? The one that is not released?
Software has bugs. Period. This is a lema in computer science, like it or not: All even modestly complex software has bugs. Read: helloworld.c has (hopefully) no bugs, all others have.
Depends on compiler :-)
It's just the number and severence of bugs we are finding in some products at release time that may really get on one's nerve. On mine, too, of course.
Number and severance. First we never know, second ... actually we don't know that either. We know about discovered bugs. How many is left, and how severe they are we will never know. What we can say is that major roads are without holes, side roads, we don't care.
While for multimedia computers some bugs are not important, for computer as machine that is meant to compute exact values, almost any bug is important. It indicates that program is not properly tested, and user can't trust that it will perform as designed in important functions.
No, typically >90% of all bugs will never ever be encountered, or they will have no side effects (which is close enough to not being a bug, I admit).
The 90% will never be seen, but it will make program load tons of unneeded junk, crash occasionally, loose data, take more and more memory as time passes, have security holes, to mention few of the most known invisible bugs that come in mind. You probably can list much more.
Yes, the space shuttle and ariane software has bugs as well. Only those that showed up bad (read: destroying the aircraft) are noticed by the public.
I played with simple programming on occasions, and I know how many versions was produced before program (again, very small) worked as I wanted, so I can imagine what is happening when in play comes project deadline, marketing department, family that has needs and wishes, and much more. I don't think that old time goals are possible anymore, but as time passes and we get used to "some bugs are not that bad", it will bring more bugs with the time. This is entropy as it applies to software. It will come time when software will be useless, but we should not speed that up. -- Regards, Rajko. Visit http://en.opensuse.org/MiniSUSE --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sep 11, 06 23:51:20 -0500, Rajko M wrote:
So, we agree, I just said in different words "it is not that simple" :-)
Peace :-) The world is a lovely place ;)))
I expected such answer. It was probably wrong example.
Thanks :)
Important is that product without exact plans takes too much time to make usable.
Yes, but the company internally obviously has a plan, as the drivers (the binary ones) hit the street just in time when the hardware is available. We're not on their radar.
For complex hardware w/o docs with erratas you need direct access to the hardware engineers. Which, of course, is only possible in-house.
That is one of reason that kernel developers want GPLed software, not proprietary accompanied with NDAs that one day can explode and run them out of business.
There are other issues why the source cannot easily be open sourced, especially third party IP, signed non-disclosure contracts, and being worried about potential patents. Intel has enough cross-license agreements, so they probably don't have to worry. Maybe the AMD/ATI merger could help here. Not so much with NVidia, though. M$ has tons of patents regarding 3D hardware, bought from SGI (when they were still written in capital letters).
Software has bugs. Period. This is a lema in computer science, like it or not: All even modestly complex software has bugs. Read: helloworld.c has (hopefully) no bugs, all others have.
Depends on compiler :-)
I said hopefully :-P Well, helloworld links libc, which uses the kernel, which uses drivers, which accesses hardware. I guess there *is* a bug lingering in that link... somewhere... CU Matthias -- Matthias Hopf <mhopf@suse.de> __ __ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ mat@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ labs www.mshopf.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sep 05, 06 01:01:21 +0200, Robert Schiele wrote:
Your only chance to improve this situation is to force the hardware vendors to provide open specs or drivers. If you don't have the power to do so, you lost in the first place.
There are no specs, so they cannot be published. Release cycles are too fast, there is no documentation even within ATI or NVIDIA. Matthias -- Matthias Hopf <mhopf@suse.de>, SuSE labs, Zimmer 3.2.06, Tel. 74053-715 --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Fri, Sep 08, 2006 at 04:36:22PM +0200, Matthias Hopf wrote:
On Sep 05, 06 01:01:21 +0200, Robert Schiele wrote:
Your only chance to improve this situation is to force the hardware vendors to provide open specs or drivers. If you don't have the power to do so, you lost in the first place.
There are no specs, so they cannot be published.
Release cycles are too fast, there is no documentation even within ATI or NVIDIA.
You want to tell me that the driver developers at these companies work with the trial-and-error method? --- Well, at least that would explain the quality of their drivers... Robert -- Robert Schiele Dipl.-Wirtsch.informatiker mailto:rschiele@gmail.com "Quidquid latine dictum sit, altum sonatur."
On Fri, 8 Sep 2006, Robert Schiele wrote:
On Fri, Sep 08, 2006 at 04:36:22PM +0200, Matthias Hopf wrote:
There are no specs, so they cannot be published.
Release cycles are too fast, there is no documentation even within ATI or NVIDIA.
You want to tell me that the driver developers at these companies work with the trial-and-error method? --- Well, at least that would explain the quality of their drivers...
Yes, actually, Matthias is exactly right. The graphics hardware industry is in a miserable state for exactly this reason: they *can't* collaborate. Their only reason for being in business is to sell hardware, and to sell that hardware they must have value-add. And since it's hard to produce *real* value-add, they instead play silly games with drivers. Which is why Intel's move into this space is so important. They know that, in this case, open source *is* the value-add. A good article on this topic: http://news.com.com/Intel+aims+for+open-source+graphics+advantage/2100-7344_... --g ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
2006/9/8, Greg DeKoenigsberg <gdk@redhat.com>:
On Fri, 8 Sep 2006, Robert Schiele wrote:
On Fri, Sep 08, 2006 at 04:36:22PM +0200, Matthias Hopf wrote:
There are no specs, so they cannot be published.
Release cycles are too fast, there is no documentation even within ATI or NVIDIA.
You want to tell me that the driver developers at these companies work with the trial-and-error method? --- Well, at least that would explain the quality of their drivers...
Yes, actually, Matthias is exactly right.
The graphics hardware industry is in a miserable state for exactly this reason: they *can't* collaborate. Their only reason for being in business is to sell hardware, and to sell that hardware they must have value-add. And since it's hard to produce *real* value-add, they instead play silly games with drivers.
Which is why Intel's move into this space is so important. They know that, in this case, open source *is* the value-add. A good article on this topic:
Good but Intel only produce integrated graphics chips and with the worst performance in the market. Yes i know Intel is the bigger graphics chips vendor, but when people actually need real 3D acceleration, Intel is not a choice, they compete in a specific segment of the market, where 3D acceleration high performance is just not important. They don't need to take care about industrial secrets in theirs cards, because there is just no secrets in those specifics cards, they have just nothing nvidia or ati would like to copy. The real value-add in ATI and nvidia is performance. Take the time to see reviews on the net with Intel 3D performance, is just miserable if you compared with ATI's or nvidia solutions even in integrated mother boards. Release cycles are too fast, because ATI and nvidia compete with each other to have the better performance and yes is normal even in windows word that the first drivers of a new release are chonky. You can probably say's that computer is for serious business, not for games and you probably right if we are talking about companys, but home computers are a complete different story, home computers are used in several ways including games. There is just no open source solution to high performance 3D acceleration in Linux, is because of linux developers ? or Graphics cards vendors ? or too fast Release cycles ?, i don't know, and people who actually buy this cards just don't care, they want the performance they buy for. And btw Intel open source graphics are not completely open, they have some binaries for functions like Macrovision. And I'm not trying to say here, that suse or kernel developers must add ati's and nvidia drivers in the kernel, I understand why they can't and don't want to do that, but if you are waiting to ATI or nvidia to open their drivers, then i hope you have a really long life to make the waiting. -- Marcel Mourguiart
On Fri, 8 Sep 2006, Marcel Mourguiart wrote:
The real value-add in ATI and nvidia is performance. Take the time to see reviews on the net with Intel 3D performance, is just miserable if you compared with ATI's or nvidia solutions even in integrated mother boards. Release cycles are too fast, because ATI and nvidia compete with each other to have the better performance and yes is normal even in windows word that the first drivers of a new release are chonky.
This is certainly true today. Which means that the open source model has something to prove: if we have access to Intel, can we help them do better?
And I'm not trying to say here, that suse or kernel developers must add ati's and nvidia drivers in the kernel, I understand why they can't and don't want to do that, but if you are waiting to ATI or nvidia to open their drivers, then i hope you have a really long life to make the waiting.
Ultimately, the goal is to route around ATI and nVidia as damage. That's what open source does -- if you believe in it. :) --g ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
And btw Intel open source graphics are not completely open, they have some binaries for functions like Macrovision.
And I'm not trying to say here, that suse or kernel developers must add ati's and nvidia drivers in the kernel, I understand why they can't and don't want to do that, but if you are waiting to ATI or nvidia to open their drivers, then i hope you have a really long life to make the waiting.
I have heard that Intel 3D drivers can be used without the proprietary parts. Is this going to be included in openSUSE ? Or is this already included in alpha 4 ? --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sep 08, 06 12:14:10 -0400, Marcel Mourguiart wrote:
Good but Intel only produce integrated graphics chips and with the worst performance in the market. Yes i know Intel is the bigger graphics chips
True, but it's getting better. For desktop uses and older games it's certainly enough now.
There is just no open source solution to high performance 3D acceleration in Linux, is because of linux developers ? or Graphics cards vendors ? or too fast Release cycles ?, i don't know, and people who actually buy this cards
Probably all of that.
And btw Intel open source graphics are not completely open, they have some binaries for functions like Macrovision.
True, but that doesn't add any real value.
And I'm not trying to say here, that suse or kernel developers must add ati's and nvidia drivers in the kernel, I understand why they can't and don't want to do that, but if you are waiting to ATI or nvidia to open their drivers, then i hope you have a really long life to make the waiting.
I still haven't abandomed all hope ;) Matthias -- Matthias Hopf <mhopf@suse.de> __ __ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ mat@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ labs www.mshopf.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sep 08, 06 10:59:22 -0400, Greg DeKoenigsberg wrote:
On Fri, Sep 08, 2006 at 04:36:22PM +0200, Matthias Hopf wrote:
There are no specs, so they cannot be published.
Release cycles are too fast, there is no documentation even within ATI or NVIDIA.
You want to tell me that the driver developers at these companies work with the trial-and-error method? --- Well, at least that would explain the quality of their drivers...
Well, not exactly trial-and-error. They probably have design specs, but what is actually delivered in silicon is typically quite a bit off. Some things turn out not to be implementable, some trigger a slow path, some things are buggy. You have to work around in the driver, and I assume that approx. 30-50% of the code is about workarounds. This is only an educated guess, so don't take my words for granted. Of course some errors are only found by trial-and-error, but that is the case in the whole software industry. Even if you use formal methods, in that case the driver might do exactly what you specified, but what you specified is not necessarily what you actually wanted... Matthias -- Matthias Hopf <mhopf@suse.de> __ __ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ mat@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ labs www.mshopf.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Mon, Sep 11, 2006 at 06:43:19PM +0200, Matthias Hopf wrote:
Well, not exactly trial-and-error. They probably have design specs, but what is actually delivered in silicon is typically quite a bit off. Some things turn out not to be implementable, some trigger a slow path, some things are buggy.
Ah, now that again sounds a bit more realistic.
You have to work around in the driver, and I assume that approx. 30-50% of the code is about workarounds. This is only an educated guess, so don't take my words for granted.
Of course some errors are only found by trial-and-error, but that is the case in the whole software industry. Even if you use formal methods, in that case the driver might do exactly what you specified, but what you specified is not necessarily what you actually wanted...
Yes, this is true for (almost) the whole software industry. But you can partition the whole software industrie into two groups: The one that has so much clue that they update their specs or at least document the problems to prevent walking into their own trap again and the one that has not. --- From implementation reviews I must admit that the second group might be significantly larger... Robert -- Robert Schiele Dipl.-Wirtsch.informatiker mailto:rschiele@gmail.com "Quidquid latine dictum sit, altum sonatur."
On Sep 11, 06 19:21:05 +0200, Robert Schiele wrote:
On Mon, Sep 11, 2006 at 06:43:19PM +0200, Matthias Hopf wrote:
Well, not exactly trial-and-error. They probably have design specs, but what is actually delivered in silicon is typically quite a bit off. Some things turn out not to be implementable, some trigger a slow path, some things are buggy.
Ah, now that again sounds a bit more realistic.
Yes, but these design specs might even be incomplete, point to other specs that cannot be published (M$ internals), and are typically in a shape that you cannot deliver them outside (contradicting versions, maybe even had-written notes, etc.), under no circumstances. If you want to push the data out, you would have to clean up and check IP - which would cast about the same as creating them in the first place.
Yes, this is true for (almost) the whole software industry. But you can partition the whole software industrie into two groups: The one that has so much clue that they update their specs or at least document the problems to prevent walking into their own trap again and the one that has not. --- From implementation reviews I must admit that the second group might be significantly larger...
:-/ I assume so. Matthias -- Matthias Hopf <mhopf@suse.de>, SuSE labs, Zimmer 3.2.06, Tel. 74053-715 --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
participants (10)
-
Alexey Eremenko -
B.Weber＠warwick.ac.uk -
Bernhard Walle -
Carl-Daniel Hailfinger -
Greg DeKoenigsberg -
Marcel Mourguiart -
Matthias Hopf -
Pascal Bleser -
Rajko M -
Robert Schiele