Games doesent work in Fedora test 3
Mike A. Harris
mharris at redhat.com
Wed Oct 22 18:37:08 UTC 2003
On Wed, 22 Oct 2003, joe wrote:
>Nobody is suggesting that this list troubleshoot nvidia driver issues,
>that would be pointless, since, as we all know, and as has been
>repeatedly stressed, nvidia controls the development of their drivers -
>so let them do what they do best, and report any nvidia driver problems
>to nvidia - what we do see, however, is users reporting problems with
>fedora core test, and they are immediately disregarded if it turns out
>that they are using nvidia cards/drivers - and that is not at all
>helpful, since the problems they are seeing are seldom if ever related
>to any flaws in the nvidia drivers, from what I can see.
Actually, that isn't the case. When someone reports an issue
they're experiencing in X or an X application which is IMHO
unlikely to be caused by the video driver itself, I routinely
tell people to report the bug regardless of wether they're using
Nvidia's proprietary driver.
For example: Someone just recently reported a problem where a KDE
application's window was not disappearing when they closed it,
and wondered if Nvidia's driver might be causing it. Since this
type of interaction problem is not at the video driver level, I
would be extremely shocked if it was a video driver problem. I
fully expect that it was a bug in the specific application or in
the window manager, and so I requested they file a bug report
against that application. To refuse their problems simply
because of their video driver, when from a technical perspective
it would be enormously unlikely the video driver would be to
blame, would be a bad idea, since the problem they're having is
most likely to be a problem for ALL users, and not just them.
>>Leaving the analogy for the moment, nobody has presented
>>evidence that the problem is not with the NVidia binary-only
>>drivers.
>
>What sort of evidence are you requiring from them? Most of the time it's
>something like "reproduce the error without loading the nvidia modules"
>which makes it impossible to reproduce the error since it only happens
>in some GUI application :\ Heck, these folks just want to find out how
>to work around the issues with a minimum of grief. More often than not,
>it turns out that someone on the list has found a solution and posts it,
>which fixes the problem for the original poster - no kernel debugging
>needed,
The bottom line, is that the majority of bugs reported by users
using Nvidia's binary only proprietary drivers, are due to one of
the following reasons:
- They did not properly install the Nvidia drivers correctly
and/or do not have the kernel modules properly built and
installed (although they often THINK that they do, and may
argue black is blue to no end about it)
or
- Their XFree86 is not configured properly to use the drivers
(although they often THINK that they do, and may argue black is
blue to no end about it)
or
- They are having Mesa libGL vs. Nvidia libGL conflicts due to
both being installed simultaneously, or by the Nvidia driver
installation blowing away various files installed via Red Hat
rpms for XFree86.
or
- They are using their own homebrew kernel, and may have any
number of problems because of that.
or
- The Nvidia kernel module was not ever built or tested by Nvidia
with the particular kernel they are using, and Nvidia
themselves might not guarantee or support the particular kernel
or
- One of hundreds of other possibilities.
We do not support the Nvidia proprietary drivers (or any other
vendor's proprietary drivers for that matter), and it is not our
responsibility to "prove" that the driver is causing the problem
or directly involved in the problem. If we spent our time
debugging and troubleshooting every single user reported
bug/problem with proprietary drivers, we'd largely be spending
99.9% of all of that time debugging users broken driver
installations and providing free technical support, as well as
discovering driver/kernel/XFree86 combinations which the driver
doesn't support, or which the hardware vendor does not support
nor test.
It is not possible to provide the resources to do all of this
troubleshooting, when we know right from the start that 99.9% of
the problems experienced are due to items in the list I posted
above the majority of the time. We also know that if a problem
really is caused by our kernel, or a bug in our XFree86 or
something else we ship, that either Nvidia themselves, or other
people in the community will narrow the problem down to that if
enough people are experiencing the problem. Once the REAL CAUSE
of the problem is known, if that cause is in our software, we
generally will investigate and fix it, however we aren't about to
dedicate 5 engineers to investigating every binary only driver
bug report that comes in, just to then have to help the person
reinstall their driver properly, or use the right kernel, or
tweak settings in their BIOS, or flash their video BIOS, or ...
the list goes on.
Unsupported, means 100% unsupported in every way. Reproduce the
problem with the "nv" driver after disabling the nvidia driver,
reinstalling the XFree86 rpms that Nvidia overwrites files in,
and doing a fresh reboot to reset the video card to it's power on
state having thus never been touched by the Nvidia X driver or
kernel module. If the problem can be reproduced that way, then
it probably isn't a bug in the proprietary driver. If it can't
be reproduced without using the Nvidia driver, then experience
and time shows, that it generally IS a problem/bug in the Nvidia
driver or in the user's installation of the driver.
There's nothing Nvidia specific about this however - the same is
true of all 3rd party drivers, including non-proprietary ones.
>>Do you know of any enterprises who care how well
>>games run on their enterprise desktops? For most, it's probably a plus
>>if they *don't* run well.
>
>If the games can't run on linux, then it's most likely that no other
>demanding 3D apps can run either :\
Not necessarily. 3D applications and 3D games generally have very
different requirements. Also, demanding 3D apps ran by demanding
3D users generally require complete OpenGL support and
compliance, and usually require support that the DRI open source
drivers do not have and probably never will due to IP concerns,
patents and other legal concerns companies out there have about
their IP. In short, demanding 3D users need to use proprietary
drivers in order to do what they need to do, so if they're using
Linux, they really have little choice. If they need support for
their drivers, they need to get that support from the video
hardware vendor that supplied them the drivers.
Do gamers and other end users telephone Microsoft on the phone
and/or use Microsoft bugzilla to report bugs in their binary only
Nvidia drivers they downloaded from Nvidia's website?
I don't think so.
High end corporate 3D users might, but they most likely will
contact their video vendor directly, whom is the most likely to
be able to support them regardless of which OS they use.
>>>Surely there is a happy medium here somwhere, and we'll need to find it
>>>if linux is to gain greater acceptance.
>>
>>Linux is gaining greater and greater acceptance every day just fine,
>>thank you.
>
>I've been using and administering linux for 10 years, so no need
>to bring me up to speed on that, and the progress has been
>remarkable - but I am far from happy with the rate of adoption -
>take a look around you? do you see a sea of ms windows pcs?
>Hello? getting hassled by vendors and isps because you're not
>running ms windows? That's far from "just fine" in my book.
I'm very happy with the rate of Linux adoption. The curve shows
no signs of slowing down at all. No complaints here.
>>Put responsibility for solving closed source problems where
>>they belong. That's all I'm saying (albeit, quite verbosely).
>
>We certainly agree on that - and nobody can deny that nvidia has
>been very responsive, and worked hard to make their drivers the
>best ones available for linux. I'm just saying, don't make this
>a witch hunt, give nvidia users the benefit of the doubt unless
>you have some reason to suspect their problem is caused by an
>nvidia bug.
That isn't the way it works. If the bug is in limbo, then it is
not our problem. Someone out there needs to troubleshoot a
problem to the point where the real cause is known. We wont
track down every problem reported just to be able to say "Yes, we
spent 3 days of one engineer's time debugging this issue for you,
and we have determined that, like 99% of all other bugs reported
with that driver, this one also is a bug/problem in the driver."
We don't have engineer resources to throw into the garbage can
like that. If a problem is not video driver specific, then
depending on the nature of the problem, most likely it is usually
reproduceable with any video driver. Reproduce it with a
supported driver on supported hardware, and then it wont be
considered a bug/flaw caused by the unsupported 3rd party
proprietary driver.
>BTW I'm running fc t3 with nvidia geforce 2, nvidia accelerated
>drivers, and multimedia applications - it's very snappy, solid,
>and I haven't had any problems so far, other than having to
>tweak a few things to get the GL screensavers to use nvidia
>drivers instead of mesa software gl. I will give it the q3a test
>later.
Great, since the Nvidia proprietary drivers work good for you, we
should be safe assuming they work perfectly for everyone else
then. It should then be safe to assume any problems that people
experience are due to their own broken installation or
configuration (which is usually the case).
--
Mike A. Harris ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red Hat
More information about the fedora-test-list
mailing list