ATI Linux / FreeBSD Questions #2

FrgMstr

FrgMstr

Just Plain Mean
Staff member
Joined
May 18, 1997
Messages
55,762
Now that we have gotten an open line with ATI on this issue and you see that they will respond, let's pull together some more questions for them as surely this interview spawned a few more folks to get involved.



Post your questions here in clear and concise manner with attention given to both grammar, spelling and punctuation please.
 
Here's some for you:

In the previous set of questions, you stated you want to keep a 2 months schedule of release drivers instead of "when they are done", but you have yet to hit a release date. How can you defend a consistent release date when you yourself cannot hit it?

When will the basic feature set be complete, such as "Big Desktop" mode with different sized monitors. Fully accelerated 2D, the return of SSE/3DNow optimizations, which were removed from the "release" in February.

What is the status of your beta program, how many testers in the community, and why do you have an NDA on it?

Why has there been 0 feedback or dialog with the community in the last 3 releases?

What is the status on X.Org support? It has been out for almost a year and is now the default windowing system for multiple big name distros, yet you have no support.

When will the issues with Cedega be fixed, or are you even working with them on it?

Justify to the linux comminty why, given the state and history of your drivers and the state and history of your cometitors drivers, we should continue to purchace your cards? IE, what do we have to look forward to and why should we trust you, and unproven, over a proven?
 
Does ATI have any design method to offer a similar codebase as the windows driver so that there is not such a huge performance gap? If stability is a major concern, why not offer more compliant drivers so that games dependant on certain features such as vertex buffer objects don't have stability issues?

edit: odoe - just cleaned up
 
Will there be support for FreeBSD within a reasonable time frame?
(This alone will probably decide who makes my next card.)

Has the linux driver team looked at the state of nvidias drivers lately?
(IOW, do they know what standards they are held to?)

Also, Kihaji's entire post. :D
 
Will ATI ever work with Ryan C. Gordon to help get Linux games working properly? More importantly the Unreal games. I don't see how the driver team themselves can manage this. And has ATI ever been testing games with their drivers? Without the VBO's and lack of OpenGL 1.0 spec support, I highly doubt much testing was ever done, else you would of found all these bugs.
 
What with the imminent release of Xorg 6.8, when will the ATI Linux drivers finally support this new standard? XFree86 has been deprecated by all major distros, including Fedora Core 2, Slackware, and Gentoo, all of which now use Xorg.

When can we expect 64-bit linux drivers?

When will the SSE/3dNow! optimizations return, and why were they removed in the first place?
 
I would like to second spyke's question about Ryan Gordon (of www.icculus.org)
I feel that's a very valid and important question, has ATI had any Linux developer outreach for requesting features of the OGL driver?

@ odoe - thanks dude, it does read better, sorry for drifting OT.
 
When can we expect to actually have a full OpenGL feature set?

Can we expect a good hardware accelerated render extension for X, and are you planning to make your drivers work with the new X.Org server's support for Cairo and Glitz as a back end? At the very least, can we expect some acceleration of the 2D desktop? Currently, the ATI driver is significantly slower than the open source Radeon driver.

Without the non-answer of "we're aiming for stability right now", when can I expect to see performance that's reasonably close to Windows 3D performance? The stability answer doesn't work, as anyone who's actually tried to use the ATI driver knows full well - you're currently more likely to find that more OGL apps don't work than do, and virtually none of the advanced features of X work correctly.

I apologize for the tone if this is a bit harsh, but after reading the first answers, I honestly feel about the same as I did a few months ago when I read someone on the IE development team ask what improvements we'd like to see in IE7. One person said "better HTML/CSS standards support" and was told that that was too broad a request. It wasn't, and neither is the request for a driver that actually works. If you're not going to actually meet real world needs, let us know - leading us on is only going to make the inevitable backlash worse.

I know ATI can do better than they are; I've seen the improvement in their Windows drivers between the Rage 128 and the 9600XT I currently have. They just have to be willing to actually put a little money into it.
 
64-bit was already mentioned, but I'd like to add "MOBILE" as a modifier to that. :)

Thanks!
 
Although I realize we are in a ultra-minority, but what about us PowerPC Linux users with ATI chipsets? Any plans for releasing PPC binaries?
 
Why do people say an Opensource driver is impossible? This is something I don't get. We are buying the HARDWARE acceleration, if I wanted to use my CPU to do it (software) I would by a cheaper card. If the hardware is different from NVidia, for example, what would exist in the driver that would make it so valuable that it cannot be shown? The reverse is also valid, I'm no here to blame ATI (I own a 9800Pro) alone but the culture that hiding the driver implementation gives any edge over competition.

I do remember to have read an article that questioned the motivation behind closing the drivers, specifically graphic card's drivers. Some arguments were that it could be related to OpenGL implementation where ATI falls miserably behind NVidia or image quality where NVidia falls miserably behind ATI, other arguments related to possible adjustments for specific games that would favor Nvidia or other competitors if shown but the real argument that made all sense to me was that the driver does contain some "tricks" that would be very badly received when people realise that they were so much close to cheating (or more than close, in some cases).

Again, we are buying the hardware to offload the CPU from the duty of processing graphic processing, the software should just complement it. And since it's a complement, not the core of the product, why not opensouce it? Or just release enough info (without NDAs, of course) so the brave (crazy?) developers out ther could do it themselves?

That said, what are the real arguments that ATI could put forward to explain their unwillingness to opensource the drivers or release the hardware details? In light of the paragraphs above, does it make sense to hide something that a competitor cannot use since the hardware IS different?
 
Boogah. This is somewhat a long one, but I'm specifying a specific example since this class of question has been either poorly answered or worded in the past:

- "How, and when, do ATI plan to improve their Linux community relations and support? Does ATI actually read the Linux DFeedback, and if so why cannot a simple acknowledgement of a reported issue be provided?

For example, myself and many others have an issue which have been reported countless times. This is a lockup within sometimes minutes of starting X. This unknown issue renders my card (R9200) unusable except using the feature-lacking-but-stable DRI drivers. ATI has never ever acknowledged this bug, not was it fixed in any of the four driver releases since. I can't use it, I can't find out WHY I can't, nor can I even obtain a refund for a more compatible replacement.

What if I had brought (and nearly did, apart from a chronic lack of money) a far more expensive higher-end card and had to shelf THAT? Although the lack of progress on the driver has alienated many, customers like myself are more driven away by the simple lack of any communication or acknowledgement than having to wait a few months for a fix we know is coming!"
 
ftcsm said:
That said, what are the real arguments that ATI could put forward to explain their unwillingness to opensource the drivers or release the hardware details? In light of the paragraphs above, does it make sense to hide something that a competitor cannot use since the hardware IS different?
Click to expand...

Patents are the main reason that 3D drivers with sufficiently advanced capabilities cannot be released open-source. ATI must license a lot of patents, both software and hardware, to produce a viable commercial product. Nvidia has the same restriction, since a lot of graphics technology is patented by various organisations. This includes various compression methods for getting data to the card fast enough, certain visibility and culling modes, various lighting calculations, etc). Remember that although the GPU handles most functionality, the drivers function is to convert information and commands from a standard API (OpenGL or DirectX, for example) into GPU operations. This involves more than just passing the command directly to the hardware or poking the right magical register. Things are more complex now, more-so thanks to the US Legal System :)
 
Even with patents, you could have an open source driver; it just wouldn't be GPL compatible. If patent licenses were renegotiated to allow it (and this is possible, even if ATI doesn't want to do it), an open source driver could be released with a license that only allowed the code to be used with ATI hardware. Since the patented technologies are still protected, if they later showed up elsewhere because someone had copied them, the owner of the patent could prosecute for damages; it still makes business sense.

The real problem is trade secrets, but again, these could be patented and the code copyrighted to prevent competitors from using it.

As the lifespan of a patent far outweighs any number of generations of graphics cards, this seems to make sense to me.
 
Please fellas. Let's keep this thread for mainly questions. It will make sifting through the post to select questions much easier.
 
I'm going to repost Thetargos post from the other thread, since I think it has some very good questions that haven't been touched upon yet.

Thetargos said:
Hi all, I'm a regular at the Rage3D forums and well, some fellow there posted a link to this thread.

Reading through the various posts you guys have made here, and having also read the request Catalyst Maker (Terry) made about the drivers and what would the ATi on Linux users would like to see in upcoming driver releases, well I felt compelled to write this rather rough compilation of known issues and bugs we at Rage3D have collected. Since I have not experienced many of these (fortunately), I could not say of any way (if any) to work around them. The following list is relevant to drivers 3.11.1, which are the latest, I'll devide this list into two sections: Known issues (such as rendering problems in some applications, application compatibility, etc) and bugs (what the driver actually does, but does the wrong way or in an unexpected way).

Known issues:
  • Two monitors display is not fully supported. You cannot have a two monitors setup with bigdesktop configuration if you have two monitors of different size, and have to use one resolution in one and another in the second. However this works if you have the two of them set to the same resolution.
  • You cannot have 3D acceleration in a setup like 2560x1024 or 2560x960, you have to use 2048x1024 (I have no way to confirm that, since I could not make my display work with this resolution) or 2048x768. The maximum the R300+ support is 2560x2560 rendering, so this is a driver issue. If you choose to use Xinerama, you lose 3D acceleration.
  • Certain Window Managers and/or Desktop Enviroments (especially those based on the QT toolkit) like KDE have problems when rendering the mouse pointer near the upper left corner of the screen, where an offset draw of about 20px will occur. This also happens in applicatios like Blender3D, despite the WM.
  • Overall 2D perfromance is slow, especially when compared to the DRI Radeon driver, but it is also somewhat slower than the generic X VESA driver.
  • Xv support is not very well implemented, especially when you use Xorg instead of XFree86. The problem is apparent intermittent utilization of the extension in programs like mPlayer or Xine, some folks also say this problem is present in later implementations of XFree86 4.3, like 4.3.99 (XF4.4RC2). A problem common to any two head configuration has to do Xv extention and a two head configuration, which will make it only be available in the primary head.
  • Lack of support for certain AGP chipsets with the internal AGP controller. This is not a problem per se since you can expect a certain degree of motherboard HW incompatibilities, however using the kernel's AGP driver sometimes results in applications running slower or other problems (see later).
  • Lack of implementantion or badly implemented certain OpenGL extensions, like ARB_vertex_buffer_objects (ATi has admitted they have currently problems with VBOs) and others (ARB_fragment_program and ARB_vertex_program, these are not confirmed by ATi as problematic, though).
  • Some Mobility chipsets have lock the computer when returning from a suspeded state, this is apparently corrected in the latest drivers, but only for APM based power management, and some Laptops require ACPI.
  • The problem of not being able to run two instances of the X server is still present with the 3.11.1, though you can now work with the second X server, when you shut down that session, the computer will freeze. Apparently only affects KDE users (I have not seen this problem in GNOME, except for screen corruption).
  • There are still some problems regarding TV-Out, like resolution, missing image, etc.
  • When using Fedora, RHEL or any other distro that will use an X based graphical boot, if you boot with this feature, when your actual X session kicks in the driver will have 3D disabled, and the worst part is that any attempt at running any glx application (even glxinfo or fglrxinfo) will result in a lost of signal from the monitor (blank screen) plus a hard system lock up. Hard reboot plus disabling graphical boot, required (this only happens with the 3.11.1 drivers, previous versions did not have this problem).
  • Related to the above problem, when you kill X via ctrl+alt+backspace, loss of 3D capabilities may occur, due to the driver not being completely unloaded as revealed by lsmod where the count of the "used by" field regarding the fglrx driver will be greater than 1 and will increase with each kill of X with this method, leading to a possible memory leak.
  • If you use the Radeon FB as the framebuffer for the console in the kernel, the programs Konsole (KDE) and GNOME-Terminal may present screen corruption. Only work around is to use the VESA framebuffer device or to disable the framebuffered console altogether.
  • Issues with the RANDR and DGA extensions of X wich are not very well supported. The first is NOT supported in HW by the fglrx driver (apparently it is supported with the DRI Radeon driver) and the second is poorly supported.
  • Lack of 16-bit and 8-bit color support. Though this is not a critical issue, the fact that some programs (especially DOS emulators) require these lower bit colors.
  • Problems with Radeons 9000 and 9600, which prevent these cards to successfully activate FSAA
  • Memroy leak in the Neverwinter Nights game for Linux. This problem was not corrected with the latest driver and it seems only to be affecting ATi hardware, since I have not seen this problem with nVidia hardware.
  • Lack of FontPaths in the generated XF86Config-4 file, especially true for Red Hat based systems (where the FontPath should read "unix/:7100"). This leads to X not being able to use all installed fonts (unless added this line).
  • The fireglcontrol program broke in release 3.9.0 because it searched for a library that did not exist (libpng10.so), this was easily solved by linking your existing libpng with this name.

Installation issues (part of known issues)
  • With many distros, Red Hat included, many different patches should have to be applied to the driver's DRM module source in order to successfully build it. This is especially true for 2.6 kernels and some later 2.4 based kernels.
  • Such patches had to be developed by the community rather than ATi, so they should accknowledge the potential of the community.

Bugs
  • Artifacts in UT200x based games, most noticeably Amrica's Army and some UT2004 maps (especially the AS-FallenCity.ut2 map). Screenshot
  • Since version 3.9.0 there are a series of artifacts in UT99 (AKA Classic), especially in the player skins and flag when playing CTF maps. Screenshot
  • When a 3D application dies unexpectedly, the driver is not able to re-scale the desktop to the original viewport resolution.
  • Cedega and WineX problems with games, many of which will complain about a problem with ATIFGRLXDRI.
  • Artifacts in the game Enemy Territory (especially with older drivers). I must confess I never saw such artifacts, but based on various reports, I add this here.

Many of the above mentioned issues and bugs also affected Red Hat distros, so stating that the ATi driver is optimized for only Red Hat is not true. I had Red Hat 9 and the drivers had many of the issues and bugs described above, also regarding performance the drivers tended to perform better in my Gentoo installation than my Red Hat one. Later I found many of the performance issues I was having were due to libGL.so files under /usr/X11R6/lib/tls, when removed performance was on par with Gentoo, but still (much) slower than Windows and needless to say compared to an equivalent nVidia card.

Items for a wishlist are many, starting by solving the above issues, improving speed, unlocking features (such as FSAA, AF, and Smart Shaders*). Also better documentation as to what each of the Options for the driver do, giving a little more chance to tweak them to find an optimal balance in quality-performance, improved communication with the community and maybe giving us access to BETA drivers as you did with the Cats 4.9 for Windows, with a disclaimer similar to that. With public access to BETA drivers, we could help you reporting bugs that some official Beta Testers have skipped, because of various reasons, including not enough samples of Linux distributions and such. But this Wishlist is topic for another thread. I just wanted to point out what the problems with the drivers are at present time.

If you read this Catalyst Maker and Kyle, could you forward this list to the ATi Linux driver team?

Thanks for the attention given to this post. By the way, I run Fedora Core 2 with a Radeon 9500 NP 128.

*Making these available from the control panel and not requiring a restart of X to have them enabled, i.e using a system similar to the nVidia drivers with environment variables, this is an OS features NOT an nVidia drivers feature ;)

Gian Paolo Mureddu
AKA Thetargos.
Click to expand...
 
ATI - instead of asking if you plan to make tarballs available instead of rpm's, I'm going to ask you TO make tarballs instead of rpm's available. If we want rpm's, let someone else volunteer to do that, I hate unpacking files from an rpm.

ATI - Would you please get in touch with the gentoo ebuild maintainers and let them show you how to make a good self installing package script? Would you please allow a script to apply patches, or for that matter, release drivers that don't require patches to work on a "standard Linux-type installation" so that Suse, Gentoo, and Mandrake don't need to repackage your drivers?
 
Really looking forward to this :D When can we expect this interview to be conducted/edited/printed?

And so this post is not completely worthless I've another q;

What's the approximate size of the Linux team, including developers and QA people? The Windows team is somewhere around 100, I forget but Terry once mentioned it.
 
Here my questions to the ATi people:

Do you realize that writing drivers for the x86/amd64 part of the Linux kernel is just a glimpse of what open sourced drivers could do?

I mean with proper information one could write a driver that runs on every computer hardware that features a PCI/AGP bus. Not to mention the various operating systems - it is not just GNU/Linux out there! Providing what most forum members call "a 32 and a 64 bit version" of the driver does not solve the problem. It just reduces the amount of people complaining. Additionally careful administrators will not accept binary-only drivers since they are like a secret compartment in their system which can be a source of 'surprising' problems. Debugging closed source software (especially drivers) is a very time-consuming and rather fruitless affair.

But ...

I understand ATi's problem regarding the technological race and how keeping secrets preserves advantages over competitors. That is why I suggest a compromise:
Release only a subset of the specifications of the newest hardware. That way open source development efforts could focus on bringing initial support for that hw and stabilizing older features. When some time has passed (2-3 years) ATi releases the remaining specs and the open source driver(s) can catch up. With this model it is at least possible to use the hardware in some suboptimal way.

What about this?
 
Hi all,

This is not going to be a question, more a suggestion.

Currently all Graphics Drivers in X are implemented in userspace because Linux (and *BSD?) lack a unified
Graphics Architecture (like what ALSA is to sound). X itself is quite old and does not take advantage of even
most of the 2D accelerator functions, let alone 3D.
Now, some of the X.Org developers have realized that and have published a paper
( http://keithp.com/~keithp/talks/xarch_ols2004/xarch-ols2004-html/ )
where they suggest to try to run X as another GL application.

So now here comes my suggestion: Why don't you (ATi and nvidia for that matter) team up with those X.Org
devs and design a new graphics infrastructure? An infrastructure where the gfx driver sits in the kernel
(where it belogs IMO, to abstract gfx access) and X sits in userspace and uses that infrastructure to do its job.

Now, I dont have any concrete ideas how to do that (you know better what is needed to do gfx) and it is
going to be long-term, but in the end I think the result is going to be MUCH better than the current mess with
X and DRM.

thanks,
--
MLa
 
Linus Torvalds and the other linux gurus that write the kernel would never allow closed-source ANYTHING in the kernel. Not going to happen unfortunately.
 
black hole sun said:
Linus Torvalds and the other linux gurus that write the kernel would never allow closed-source ANYTHING in the kernel. Not going to happen unfortunately.
Click to expand...

Loading closed modules seems to be accepted, which is what one would end up doing.
It would be a massive amount of work, though. (And do we want yet another thing in the kernel?
 
My questions for ATI:

1) When do they believe they got the vt switching causes a distorted X to be fixed (note: I'm not referring to the colour fix they had in the last
release when switching between vt's and X)

2) secondly, one of their earlier replies was that they have had zero patches or feedback whatsoever to the open sourced control panel. I'd like to point out that that's not so strange, because: _where in heavens name can you send a patch to? _ . There is no mailinglist, there is no website, there is no direct contact whatsoever. Ofcourse, there's a feedbackwebpage, but that's totally not suited for sending in a patch. Now I'm not suggesting I got tons of patches lying around here, I'm just pointing out that any coder who just as much as tries to get in touch with the developers end up in a dead alley.

After all, if it's GPL'ed, why not just open up a sourceforge account and
put the code there?

kind regards,

Grachtbaas
 
Grachtbaas said:
2) secondly, one of their earlier replies was that they have had zero patches or feedback whatsoever to the open sourced control panel. I'd like to point out that that's not so strange, because: _where in heavens name can you send a patch to? _ . There is no mailinglist, there is no website, there is no direct contact whatsoever. Ofcourse, there's a feedbackwebpage, but that's totally not suited for sending in a patch. Now I'm not suggesting I got tons of patches lying around here, I'm just pointing out that any coder who just as much as tries to get in touch with the developers end up in a dead alley.

After all, if it's GPL'ed, why not just open up a sourceforge account and
put the code there?
Click to expand...

Hey I second that question BIGTIME. I also feel that is a VERY important and valid question. He/we aren't asking for a direct public avenue of communication, but for ATI to have a developer mailing list, or sourceforge account set aside for coders to cooperate with would be VERY useful. This would also take a very short amount of time to coordinate.
 
theBohemian said:
Here my questions to the ATi people:

Do you realize that writing drivers for the x86/amd64 part of the Linux kernel is just a glimpse of what open sourced drivers could do?

I mean with proper information one could write a driver that runs on every computer hardware that features a PCI/AGP bus. Not to mention the various operating systems - it is not just GNU/Linux out there! Providing what most forum members call "a 32 and a 64 bit version" of the driver does not solve the problem. It just reduces the amount of people complaining. Additionally careful administrators will not accept binary-only drivers since they are like a secret compartment in their system which can be a source of 'surprising' problems. Debugging closed source software (especially drivers) is a very time-consuming and rather fruitless affair.

But ...

I understand ATi's problem regarding the technological race and how keeping secrets preserves advantages over competitors. That is why I suggest a compromise:
Release only a subset of the specifications of the newest hardware. That way open source development efforts could focus on bringing initial support for that hw and stabilizing older features. When some time has passed (2-3 years) ATi releases the remaining specs and the open source driver(s) can catch up. With this model it is at least possible to use the hardware in some suboptimal way.

What about this?
Click to expand...

a neat idea, i'm totally with you man. my next video card will probably be a RADEON 9200 or another card supported by the dri project.

and it is not a matter of open source zealotry, it is a matter of pragmatism.

opensource drivers means the possibility of support for freebsd and other systems, support for powerpc, support for 64bit architectures. bugs can be squashed faster (i waited 4 month to see a small but annoying problem solved in the nvidia drivers).

opensource drivers means support out of the box and ease of installing, old radeon cards have working 3d even in knoppix, no browsing ati site, no downloading, no installing, no configuring, nothing.

opensource drivers means less cheats or no cheats on rendering (for examples look at this 1999 quote from john carmack http://www.shacknews.com/ja.zz?comments=3395 or this more recent quoting still from carmack http://www.oc-zone.com/modules.php?name=Articles&rop=conteudo&id=65&page=2) and on benchmarks (think about the infamous drivers that looked for a certain name of a program in execution)

opensource drivers means that users are not left without choice if the company stops supporting them or goes out of business, and these kind of thing happens...
opensource drivers are often the only existing reasonable way to make a product work on more than 1 or maybe 2 operative system. i understand that the situation with 3d opensource drivers is problematic for manufacturers partly because of the tecnology involved, but a binary only driver for a network card, an audio card or an ide controller are aberrations and must be avoided at alla cost. that's why i wouldn't bring as example of open source commitments an alsa update for an audio card or some kernel patches for an ide controller, because that is the bare minimun needed to make the hardware usable.

i don't care about the 3d performance, i will stick with my old games if i have to, i'm tired of all the problems the closed source nvidia drivers are giving me (and i'm sure ati proprietary drivers aren't better), and i will not make the same error again. if ati won't give me now this kind of support for their recent products, i won't buy them until they do.
i really appreciated to get some feedback directly from ati, but unfortunatly they were not the responses i hoped for.
 
tapeworm said:
i really appreciated to get some feedback directly from ati, but unfortunatly they were not the responses i hoped for.
Click to expand...

That's what this thread is for. If you have a question to pose to ATI, then please post it. Once these questions go out and if people still are not satisfied with the quality of the questions, then you honestly have no one to blame but yourselves. Spread the word, let others know that this opportunity is here to post questions to ATI.

But please keep it to questions. Do not rant in this thread.
 
jmahler said:
64-bit was already mentioned, but I'd like to add "MOBILE" as a modifier to that. :)

Thanks!
Click to expand...

1) Exactly as was mentioned by jmahler, when are you going to release AMD64 drivers? I am quite sure that many OSS entheusiasts will be purchasing AMD64/EMT64 machines, and thus I was suprised to learn there were absolutely no ATI drivers to support them.

2) Again, as others have mentioned, please: major_performance++;

3) Why should we hold ATI to a different standard than certain other competitors in regards to their Linux support?

4) When is Xv acceleration going to be optimized on ATI cards? Currently, watching a DVD on an Nvidia card leads to <3% CPU usage, while an ATI card is much higher.
 
Q1: Sporadic artifacting in Enemy Territory is still present in the 3.12 driver (has been since 3.9, I believe). I can at least confirm this with my Radeon 9800XT. Are there any plans to fix this issue?

Q2: The NeverWinter Nights game has had a memory leak with ATI's linux driver since...forever :p When is this going to be fixed?

Q3: Less serious a question, what distro do the ATI developers prefer? :p
 
Another question for you guys: (Hope I haven't run out of questions already.)

Are there any plans to create an X-control-panel like the fancy one you just recently released for Windows? Surely many (former) windows users appreciate your excellent control panel, and would like to see something similar in Linux.
 
I agree whole-heartedly with HHunt. ATI needs to get native FreeBSD support. I for one am tired of having to mess with getting their linux drivers to work and having to live with reduced performance. The fact that nVidia has native support will play a major role in my next purchase decision.
 
whynot? said:
I agree whole-heartedly with HHunt. ATI needs to get native FreeBSD support. I for one am tired of having to mess with getting their linux drivers to work and having to live with reduced performance. The fact that nVidia has native support will play a major role in my next purchase decision.
Click to expand...

I was just responsible for someone buying a geforce fx5900 instead of the originally planned 9800 pro for this exact reason. It's a real, though perhaps small, issue.
 
HHunt said:
I was just responsible for someone buying a geforce fx5900 instead of the originally planned 9800 pro for this exact reason. It's a real, though perhaps small, issue.
Click to expand...

I myself have been in this same situation. I would have much rather purchased a 9700 Pro, but not only can I not find one anymore, but ATI Linux drivers allow this card to perform like an Nvidia TNT2, rendering the 9700 Pro useless.

In the end, I had to settle on an FX5800. :(
 
I have been away from Linux (Gentoo) for about 5 months because I got tired from switching back and forth to play games due to the ATI drivers. I have been an avid fan, but alas I finally bought a new video card BFG FX6800. I really hope ATI gets in gear and fixes there problem and won't lose anymore customers, but I hate to say that I am not going back :(.
 
Ok, it's been over four months since this thread was started. I would personally like to see some plans for the new year from Ati, especially one that includes good FreeBSD drivers.
(Two improbable things for the price of one. Yay.)

Has there been any contact lately? Is this a good or bad time time for a new batch of questions? Could Kyle ship the distilled essence of this thread off to them anytime soon?

In short, what is the current status?

(For the record, I still use my 9800 in FreeBSD. With xinerama and in x.org, even. Absolutely no trace of 3d acceleration, and an i865 feels faster in 2d, but it lets me do something productive when I feel the need.)
 
I am also curious as the outcome of this. Is the [H] still persuing or are you not receiving feedback from ATI?
 
Try the new drivers this coming monday. If they still suck go for a second interview.
 
OK I'm a linux gnuub, I'm looking for drivers for my 9700Pro All-in-Wonder. Will ATI ever release drivers, or support the community that does (ala MythTV)

My machine dual boot, but over the past couple of weeks I've really grwon to appreciate Fedora Core 3, all I need to turn my windows partition into a "game only"OS is to get my AIW up and running.

First it's knoppix, then it's knoppix with a USB flash drive, now it's sucking away my life.... so many cool toys - so little time!
 
You must log in or register to reply here.
Back
Top