Calling on yours and Kyle's support

Status
Not open for further replies.
Comments such as "ATi's drivers suck" are not welcome here. Post specifically an issue that you have or state your question in a rational manner.
 
firstly, THANK YOU TERRY AND KYLE, YOU GUYS ROCK

ok having said that i do have some very serious questions i hope they are worth submitting....

a) I find it curious as to why it is when you look at the performance of your r300 and up cards in linux they dont compare anywhere near where they do in windows. My concern here is my 9800xt i bought at its launch. its great in windows, but in linux, which i use almost exclusively now, ut2k4 performance is beat out by geforce 6800's (remember the old dustbuster?)? What can be done to improve performance here to where it at least resembles its performance in windows?

b) Why is it that even in Fedora red hat, your drivers need end user patches to get to work? If the drivers were designed for this platform, shouldnt they work right without any end user patches? (see the ati section of www.fedorafaq.org to see what im talking about with this)

c) Why is it that your drivers dont come w/ a complete guide for its options? Recently it was found that there were options that could have been enabled in the driver that would allow them to run video (Albeit not that fast) as well as 3d acceleration (I have recently found a tip to this bug: add Option "XaaNoOffscreenPixmaps" in the XF86Config-4 file). I dont know if you are aware, but the majority of linux users dont know about this and most either have setups that run video (by using the vesa driver) or just run 3d by using your driver. most arent even aware that its possible to run both. Why is this?

d) why is 2d performance so slow?

e) why dont you guys work with transgaming to get more games running in cedega and point2play? (winex)

f) why doesnt the ati control panel allow you to set ansiotropic, fsaa and other settings?

g) why dont you contact the major linux distrobution vendors to allow them to package your drivers along with their distributions to make it easier for your users to get up and running?

e) why isnt there a linux driver on the driver cd that people get when they buy your cards?

f) why isnt there an mmc type utility for linux?

thanks for taking the time to read my questions =)

-Me
 
emailthatguy said:
firstly, THANK YOU TERRY AND KYLE, YOU GUYS ROCK

ok having said that i do have some very serious questions i hope they are worth submitting....

a) I find it curious as to why it is when you look at the performance of your r300 and up cards in linux they dont compare anywhere near where they do in windows. My concern here is my 9800xt i bought at its launch. its great in windows, but in linux, which i use almost exclusively now, ut2k4 performance is beat out by geforce 6800's (remember the old dustbuster?)? What can be done to improve performance here to where it at least resembles its performance in windows?

b) Why is it that even in Fedora red hat, your drivers need end user patches to get to work? If the drivers were designed for this platform, shouldnt they work right without any end user patches? (see the ati section of www.fedorafaq.org to see what im talking about with this)

c) Why is it that your drivers dont come w/ a complete guide for its options? Recently it was found that there were options that could have been enabled in the driver that would allow them to run video (Albeit not that fast) as well as 3d acceleration (I have recently found a tip to this bug: add Option "XaaNoOffscreenPixmaps" in the XF86Config-4 file). I dont know if you are aware, but the majority of linux users dont know about this and most either have setups that run video (by using the vesa driver) or just run 3d by using your driver. most arent even aware that its possible to run both. Why is this?

d) why is 2d performance so slow?

e) why dont you guys work with transgaming to get more games running in cedega and point2play? (winex)

f) why doesnt the ati control panel allow you to set ansiotropic, fsaa and other settings?

g) why dont you contact the major linux distrobution vendors to allow them to package your drivers along with their distributions to make it easier for your users to get up and running?

e) why isnt there a linux driver on the driver cd that people get when they buy your cards?

f) why isnt there an mmc type utility for linux?

thanks for taking the time to read my questions =)

-Me
Click to expand...
Nice questions ;).

Reminded me of another issue.

That guy mentioned that the control panel is pretty much useless. On top of that, it doesn't like installing under KDE, my shell of choice. Is this a common problem and if so, why?
 
too all of those who can't get ati drivers to work in slackware or others, I have had no problems with slack 9 or 10 with my ati drivers (besides the 2.6.7 problem which was fixed with a patch). I do have some questions / performace requests. Gentoo users should have even less problems, since you just emerge ati-drivers.

1) when using the open source "radeon driver" fonts seem crisp and clear. When I load fglrx, It looks as if everything 2d (fonts) seem like they have AA on. (even when I turn it off in the fglrxconfig) Although this could be attributed to my lcd monitor

2) official x.org support (although 4.3.0 seems to work for now)

3) performace boots: so far it seems that 3.2.8 have been the fastest drivers so far, 3.7.0 was very slow (ut2k4) and 3.9.0 shows some improvement, but still kinda slow.

Over all I want to thank ATI for even taking a look into the minority of linux users. I know some companies don't even look in our direction.
 
i've been trying to get the fglrx driver working on my slackware 9.1 install with a radeon 9000. no such luck:( i can't just unrpm it because it fails dependencies on everything (including bash/sh) so i rpm2targz'd it and tar zxf'd it. then i ran the config a few times... before i figured out i needed to change the device in the XF86Config to 3:0:0, instead of the 3:0:1 that the config was setting. so i get into X11 (4.3.0, and i got the right driver off of ati's site) and run glxgears. 100-125 fps, whereas before i installed the driver i got 350-ish. (not that good, i know) so i check fglrxinfo. its using Mesa still. start paging through the X11 log file - find that it can't load the module because it isn't built. i haven't been able to get it to build right with 2.4.0 kernel or with 2.6.6 kernel (of course, the 2.6.6 kernel tends to hardlock on my machine for some reason) but it generally isn't being cool. i think i may have to wait for an automated installer for alternate operating systems (a tarball installer would rock, and would still work on redhat systems)

so i'd like a tarball with a ./configure & a ./install script. i'm sure many others here would as well. (and people elsewhere)

any suggestions for installing the current driver would be appreciated as well. (3.9.0 version i think - i downloaded it today)

thanks.

edit: just looked at it again and got it working. thanks devourment. i think i left out some of the 'build' steps and the modprobe init. honestly, that is way too much work. i much prefer the windows 'click to install, hey you're done' installer. but where's the fun in that?
 
here is exactly what i did for slack 10, and what i used to do for slack 9.1

1) download souce from ati.com
2) rpm2tgz fglrx-3.9.0.rpm (or whatever it is called)
3) su and enter password
4) installpkg fglrx-3.9.0.tgz (or whatever)
5) cd /lib/modules/fglrx/build_mod/
6) sh build_mod.sh (i believe or build_modules or something similar)
7) cd ..
8) sh make.sh
9) add fglrx to your /erc/rc.d/rc.modules
10) exit X, and modprobe fglrx and run fglrxconfig

This is how I have done it for a long time in slackware now... only in slackware 10 i needed a patch for 2.6.7 kernel

You should not have any problems with slack 9.1 using this method... if you get a build error it is probably because you are not using x 4.1-4.3 (x4.4 isn't supported yet)... i would just upgrade to x.org. OH yes almost forgot, make sure that in your kernel moduled unloading and forced unloading are compiled in, and make sure that you do not compile in DRI, even as a module. I believe that is all.
 
thanks for the fix but umm... this thread is for questions to the ati team.

and furthermore, they should be making their drivers so you dont have to go thru all that =p
 
I did post some questions above, and what i posted wasn't really a "fix", it is how you install the drivers on slackware. This is because ATI like to distrubute there drivers in RPM format, which i can somewhat understand because of the proprietary content they hold. It would be nice if ATI would release a tar.gz so us non rpm users could install them without having to do 10 steps. (even if it did not release the source, and was still mainly binary)

One other suggestion/request I have is: why ATI drivers XFREE86 dependent anyway. Everytime a new version of X comes out (or future x.org releases) you have to wait a while to get new drivers. Notice how nvidia (not to make comparisons) drivers are not X dependent, and they do not have to release 3 or 4 copies of the same driver for x4.1,x4.2,x4.3, etc... (they also have a tar.gz for us slackers)

Again thank you for your time ATI and Kyle.
 
devourment77 said:
I did post some questions above, and what i posted wasn't really a "fix", it is how you install the drivers on slackware. This is because ATI like to distrubute there drivers in RPM format, which i can somewhat understand because of the proprietary content they hold. It would be nice if ATI would release a tar.gz so us non rpm users could install them without having to do 10 steps. (even if it did not release the source, and was still mainly binary)

One other suggestion/request I have is: why ATI drivers XFREE86 dependent anyway. Everytime a new version of X comes out (or future x.org releases) you have to wait a while to get new drivers. Notice how nvidia (not to make comparisons) drivers are not X dependent, and they do not have to release 3 or 4 copies of the same driver for x4.1,x4.2,x4.3, etc... (they also have a tar.gz for us slackers)

Again thank you for your time ATI and Kyle.
Click to expand...
Actually, nvidia uses a modified Loki installer (now mantained by icculus.org) which compiles the needed hooks at install.
 
I am getting my new computer at the end of Summer, and by September I will decide what video card to get. I am leaning towards Nvidia not only for the cheap price in the 6800, but the talk of how ATI does not have the same ammount of quality on their drivers, with performance and only allowing RH to be installed on, which wouldnt be so bad if I wasnt heart-struck on getting Gentoo.

As for having to manually install them, I don't remember ever doing an install in RH for me without the manual way. Probably because every time I tried an RPM, it gave me issues and I got the tarball

Short Point: Make drivers work for every platform, to make it less of a hassle
 
whats the status on these questions? did they get submitted?

also mods, can you clean this thread up a lil bit so its easier for kyle to sift thru for questions to submit to ati?
 
I pulled what I thought were ones that should be answered and will be sending them to ATI.
 
emailthatguy said:
thanks for the fix but umm... this thread is for questions to the ati team.

and furthermore, they should be making their drivers so you dont have to go thru all that =p
Click to expand...

I don't mean this as an insult, or a "flame" or whatever you call it.

This is not a 'fix.' If you use Slack, this is the process to install the drivers. This thread called on Kyle's support, AND the support of linux users in the forum. The post made by devourment77 showcases the reason why the open source community is so great. I do agree that ATI should, however, help us out with drivers more, but you also have to consider some details of linux desktops...

1. Not every linux system uses the same kernel. (there are large differences in agpgart compatibility between the 2.4.x and 2.6.x kernels.)
2. Not every linux system uses the same distribution. There are small differences that prevents them for making a universal installer very easily. (This is what I'm guessing, if I'm wrong, please let me know.)

Again, no offense, just saying what I think.
 
I am leaning towards Nvidia not only for the cheap price in the 6800, but the talk of how ATI does not have the same ammount of quality on their drivers, with performance and only allowing RH to be installed on, which wouldnt be so bad if I wasnt heart-struck on getting Gentoo.
Click to expand...
Using gentoo is probably the easiest ati driver install of any linux distro IMO. All you do is this one command "emerge ati-drivers" then something like "opengl-update-ati", then the drivers are installed and working. Just those two commands gets it up, so if you are going to use gentoo, getting ati to work is easier than getting it to work on redhat.
 
devourment77 said:
Using gentoo is probably the easiest ati driver install of any linux distro IMO. All you do is this one command "emerge ati-drivers" then something like "opengl-update-ati", then the drivers are installed and working. Just those two commands gets it up, so if you are going to use gentoo, getting ati to work is easier than getting it to work on redhat.
Click to expand...
Yes, that will get the drivers installed, but working is another story altogether. I know I fought between internal agpgart and external agpgart for a long time before I finally found a combination of stuff that worked. Right now mine is working(as much as I can get working, that is), so I don't mess with it.
 
TOOL1075 said:
I don't mean this as an insult, or a "flame" or whatever you call it.

This is not a 'fix.' If you use Slack, this is the process to install the drivers. This thread called on Kyle's support, AND the support of linux users in the forum. T
Click to expand...

yes it did, but in reference to something very specific when szero started this thread

SZERO said:
This is why I'm calling on you. I want to gather enough support from ATI + Linux users here and when the post generates enough support, I would love it if Kyle would be awesome enough to contact ATI representing [H]ardOCP
Click to expand...

THIS THREAD IS SO IMPORTANT RIGHT NOW AND GIVING THE PEOPLE AT ATI TOO MUCH TO SIFT THRU IS NOT A GOOD THING. THOSE GUYS ARE INFAMOUS FOR SKIPPING OVER LONG THREADS.

if you wanna help someone in the community GREAT. thats what makes the linux community great. but THIS thread needs to stay focused. i.e., ONLY for submitting questions to ATI. please, there are like 50 other threads on this forum specifically for helping people get ati drivers installed in different distros. please help people in those.
 
ATI GET YOUR ASS IN GEAR AND WRITE PROPER LINUX DRIVERS.

I have posted A THOUSAND TIMES that we need better ATI drivers, but they don't listen. They insist on distributing their drivers as RH RPM's even when us folks run DEBIAN, SLACKWARE, or even GENTOO, which DONT WORK WITH RPMS.

I am very dissapointed with ATI. I would much rather buy an ATI card that takes up one slot in my box, and is much more elegant, requiring only a 350W P.S. MAX, but I keep buying nvidia cards... put that in your pipe and smoke it ATI.

Sorry to say - I think we can all agree that while the 6800 surely is a nice card, a single slot solution like the X800T PE that doesn't require such bad-ass cooling is a much more elegant solution.

ATI - if you write better Linux drivers, you would've had my $500 - twice.

We need to have equivalency between the Win32 and Linux drivers. We also need AMD64-safe drivers!

If you don't have the resources to write your own win-performance equivalent AMD64 drivers, then allow someone to sign an NDA, and they can write the drivers!
 
I'm probably a niche, but one that nVidia has actually catered to:

Will there ever be FreeBSD drivers? Of the same quality as, and updated as often as the linux ones?

If not, my next card will be a nVidia one.
It's not the quality of the drivers that bothers me. It's the nonexistance.
 
Looks like a new version of the ati drivers is out(as of a few days ago). I haven't installed it yet but from the release notes it doesn't look like there is anything too spectacular about the release.

here
 
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.
 
Thetargos has replied here. cool :p

unfortunately tho man, i think we got blown off at this thread too. kyle tried here and i really appreaciate that. but i really do believe at this point that ati doesnt care......

i think the ONLY thing that would get ati off of their butts about this might be the following....... this is something we absolutely would need kyle for and if he and brent are willing could be just the thing that could push ati into doing something about this in a timely manner.... (please give me feedback on this idea btw guys)

when you benchmark new cards against each other INCLUDE LINUX BENCHMARKS!!!!!!!

everyone knows that ati's performance against nvidia performance in linux on comparable cards is a joke at best. 9800xt's getting destroyed by nvidia cards that cost hundreds less in ut2k4, any game in winex. i would REALLY like to see those comparisons added to current benchmark methodology. then what were complaining about here would finally have a big spotlight shined on it. websites and forums all over the net would start buzzing over nvidia's total and overall performance across more than one platform.

i believe something like this idea could REALLY help
 
I pm'd Kyle and something is in the works. He didn't give me a time frame or anything. In other words, he hasn't forgot about us.
 
If something actually comes out of this I'd be extatic :D

(Until I remember I have to install some linux distro beside my dear FreeBSD to use it. Then I'll only be happy.)
 
Well, I did not expect to have replies here already :)

Anyway, about the current driver, once I spoke with Matthew Tippet (you know, the guy who actually makes these drivers), and based on those e-mails, I could almost assure the code up on which the current drivers are based is at least 4 months old. I'm not saying ATi is not working on the matter, heck I'd like to think they are re-working entirely the driver to make it better, but I also think that the code they have right now is being optimized some more, so I'd expect still some releases based on this code base before they move to something like version 4 of the driver. I have no proof whatsoever of what I'm saying here, so please do not take my word for granted, Terry and Matthew are in a much better position to answer that. I'd really like to believe ATi indeed cares.

And your idea, emailthatguy of having sites so respected when it comes to reviews as this one here, also testing and adding some preassure will benefit us all. With full in-depth reviews of the drivers (even if a head to head comparison against nVidia HW isn't possible, taking into account varous factors*), will at least inform better to potential future Linux users of the situation in regards to ATi hardware in Linux. I wouldn't mean such reviews as a BASH against ATi, nothing far from the intention, but as a means to really show that support (and interest) for Linux, and especially ATi hardware under Linux is a REALITY, not just rough numbers in a statistic, which leave out so many users who dualboot and the like.

Thanks.

*Although in terms of hardware head to head comparisons would be a logical step to take, to even show how immature the ATi drivers are, I wouldn't do that just yet. I'd better do comparisons agains previous releases to see if anything got broken, got fixed, and so on, and when we finally see performance similar to that of Windows, then do a head to head comparison, other wise, what you'll be testing are DRIVERS not the HARDWARE per se. (yeah, I know this whole thing is because of the drivers...)

Gian Paolo Mureddu
AKA Thetargos.
 
Thetargos,

I couldn't have said it any better and i thank you for writing the details here. And of course thanks to FragMaster for helping us with this.

And, yes more Linux BETA testers would be better and benefit both parties.
 
Actually last night I was thinking of a "protocol" to test ATi HW and drivers in Linux, and make the inevitable comparisons in just one step:
  1. Have two identical machines set up to dual boot Linux and Windows, and set them up the best possible way. For peformance sake, I'd recommend a Gentoo installation (though it may take a while :) ). In one machine install a GeForce card <insert choice here> and in the other a Radeon <insert choice here>.
  2. Do a standard Windows bechmark usin the various syntetic tests available. Although not a latest generation test, for the OpenGL part, it could be used the VulpinGL test or from a more professinal point of view Viewperf tests. It could also make sense to use some of the hottest games as tests too. Doom3 (when it finally comes out for Linux) and UT2004 could make excellent tests too.
  3. Compare with each card how does the DirectX Vs OpenGL tests do, and then run the tests in Linux.
  4. Compare first the OpenGL results in Linux of the two videocards and then contrast them with their Windows counterparts.

Many of us, already know that virtually any nVidia card will do exactly the same (if not a little better) in Linux as in Windows. However, from the few tests I coud run cross platform in my rig, at the time (drivers 3.2.5/3.2.8), Linux performance was a little bit above 50% of that in Windows with my setup.
 
Longtime [H] er longtime fan. Firstime post.

A note to Terry: I think part of the problem stems from the fact that you have Matthew Tippet developing the drivers in a Cygwin envrionment and not natively in Linux. Also, please stop using GCC to compile the code, don't be afraid to try other _faster_ compilers ESPECIALLY when you are working on proprietary stuff!!

Please heed the clarion call to move away from rpm. MOST Linux distro's use the same unix standard filesystem structure, ie /lib/modules.

DO NOT listen to the people suggesting that you support XFree 4.4.0. The XFree project is dead and will soon not be used. Instead prepare for the OpenGL based cairo Glitz support soon to be built into the x.org foundation that will allow OpenGL based compositing. I find that when I try to use a fullscreen session of Looking Glass it hard locks my system due to the fglrx module being killed off.

PLEASE PLEASE get us some OpenGL 1.2+ compliant drivers. I know of a very large competitor of yours that offers FULL OpenGL 1.5 compliance in their drivers whilst ATI is struggling to meet 1.0.

WE WANT VBO SUPPORT. Vertex Buffer Objects are used quite often in Ut2k+, Doom3, Savage, Ballistics, and RtCW (yes I know, Quake3, but they added those for a performance boost on drivers that support it). You support VBO's in your Windows OGL driver, and your windows OGL driver has some pretty damned impressive OGL compliance. However the Linux driver currently does not pass 1.0 specifications.

Performance PERFORMANCE PERFORMANCE. Start from the bottom, think "What compiler will we use for this? What libraries do we want to compile against? If we use a non gcc compiler, how do we write the kernel module so that it can interface with a proprietary binary but still load into a kernel image compiled off of gcc? How can we open that up so that people between different versions of gcc compile their libraries against ours? What timetable do we want to achieve OGLSL support in?" Your performance problems stem from the fact you are using a nearly unstable GCC compiler in an antiquated Cygwin environment under windows. Develop *like it's for a Unix system*.

That is my request for what I would like to see in the drivers.

[edit]
Mark Rein said this "Since we ask Linux users to provide servers, giving them a client was just the right thing to do, even if it doesn't make us any money whatsoever".

I realize ATI doesn't commit nor ask much of the Linux community, however nVidia does, and for them it's paying off in the form of professional workstation users.
 
OldSkool:

While I agree with much of your post, I cannot agree with you in one simple aspect: The kernel module. The problem could be much simpler to solve if the hardware abstraction is better. That way they can virutally make OpenSource the DRM module (and still distribute it by source, letting the host's GCC compile it and load it into the kernel ;)), preserving in the driver the much appreciated PR secrets. I also concur with you about the development platform. If you build having as your target Linux, wouldn't it make sense to have a machine with Linux to develop the driver? I personally have nothng against Cygwin or anything, but still I think working with the real thing would be better (and far easier to debuf IMO).

I cannot agree more with you in regards of Xorg support and the upcoming of Cairo addptance. The need to raise overall OpenGL perfromance is undeniable, and as you clearly point out, it also is FULL compliance with OpenGL 1.2+ (1.4+ preferrably). Just out of curiosity, does anyone have a list of supported OpenGL extensions in Windows, so we can copare that to Linux?

A tip, if I run from VT1 (changing to run-level 3) Looking Glass I will not have a system lock up ;) (and you hve to be root for the time being, as instructed by Sun).
 
I do run lg3d-session as root btw.

I look at my syslog and it's always related to the fglrx module.

As for the rest of your statement, thanks man, it is gratifying to know I'm not the only one :D
 
oldsk00l said:
I do run lg3d-session as root btw.

I look at my syslog and it's always related to the fglrx module.
Click to expand...
I had a couple of those, but it went away if i disabled FB console in my kernel (so yes, I had to reboot to use LG)
oldsk00l said:
As for the rest of your statement, thanks man, it is gratifying to know I'm not the only one :D
Click to expand...
I'm sure that many others think like you do, some folks and I at Rage3D have discussed about the lack of full support for OpenGL features. One thing is not being compatible with bizzare or other proprieatry extensions (like the NV ones), and another totally different is to lack support for standard ARB ones, this IMO is almost unforgivable. I know they are making their best, and being Linux not high in ATi's priorities just adds to the frustration many of us users have experienced for the last couple of years. That's why I said some posts above, if sites like this release objective reviews about Linux performance as they do with Windows (not at the same level, of course), then ATi on linux will begin to have more promotion (for good or for worse) and THAT's the incentive ATi needs IMO, the more exposure the ATi+Linux thing gets, the better, so they will raise Linux priority in their schedule.

Also a comment that missed my previous post: One of the benefits I see on having a NATIVE Linux platform would be to actually develop AMD64 drivers MUCH EASIER AND FASTER than what they can achieve in a cygwin environment... I think that as critical as performance and OpenGL improvements in the drivers are, that same deggree of cricial is also 64-bit computing, because in the term of 1.5-2 years from now, 32-bit platfroms will start to be things of the past, like old 8086 16-bit processors, and lets face it, ATi is lacking in this department a great deal. nVidia has an advantage on this of almost two years now (compared to the 1 year advantage they have over the overall Linux adoption).
 
You hit the nail right on the head with a sledgehammer. I couldn't agree more, in fact.

A note to Kyle and crew, you'd be surprised at the number of people interested in some professional application of mainstream graphics cards. Also, Thetargos has a very valid point, in some cases the nVidia driver on a 2.6 kernel actually does outperform the windows counterpart of a game. You'd also have a good time picking apart the behavior of the games (eg multitasking under Linux vs Windows).
 
Terry, can you tell us if ATI considers making drivers for FreeBSD?

I remember Alex Stohr posting on R3D forums that it would take about 2 weeks for a competent programmer with FreeBSD kernel knowledge to port the Linux driver...

Thanks!
 
I'd figure I'd jump on the bandwagon here and ask about FreeBSD drivers.

Are they in the works? near future?

Support for X.org? I think this is a must. FreeBSD and many distro's are converting over to X.org from Xfree86.

The only reason I ask is that my FreeBSD box has an outdated graphics card (Geforce2 GTS) and want to upgrade it.
 
considering this thread was posted over a month ago i think its pretty safe to assume this whole deal of ati getting in touch w/ us is over. if it was gonna happen it simply would have by now. lets not forget even ati's biggest fan-boy site rage3d.com couldnt even get their driver team to answer submitted questions.

edit: the fact that i had to hyphenate that word to keep it from getting filtered is the dumbest thing ive seen to date on an [H] site......
 
Thetargos said:
[*]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.
Click to expand...
I have seen them, and still see them with the current drivers if I boost resolution over 800X600. At 800X600 everything is fine. Also, IQ suffers at distance. I'll post a link to pics later showing the difference between linux and windows. I'm running a fairly popular distro, Mandrake 10, kernel 2.6.3-7. Installation was pretty easy though, unlike previous versions. I too am looking for an Nvidia card. Look at my sig. ;)
 
Wow, this last page of replies is excellent. Very informative. I hope Terry knows to look back here. Thanks Thertagos (sp?..not scrolling down)
 
Status
Not open for further replies.
Back
Top