ATI Linux Drivers

Hi,

I’ve just seen that ATI has released their new Linux drivers 2.4.3. Would it be possible to get a list of supported extension for the differents ATI cards with this new driver [Read: if you have an ATI card and you’re running Linux, please install the new driver, run glxinfo, and put the output here, thank you ].

Best regards,

Niels

Would, but the driver fails to install properly (I’ve already sent some feedback to the Linux Feedback on their site) so I’m still stuck using the old driver for my 8500LE (but I’ve only had a few minutes to play with it, so I will be messing around with it more this evening)

Dan

Hi Dan,

Originally posted by Dan82181:
… I’ve already sent some feedback to the Linux Feedback on their site…

Could you post a link to the Linux Feedback…

– Niels

Here ya go
http://apps.ati.com/linuxDfeedback/

Dan

The driver is supposed to support 2 series of cards…

the 8500/FGL8700/FGL8800/FGL E1
and 9700/9700PRO/FGL Z1/FGL X1

For the 8500, glxinfo reports to me the following

display: :0.0 screen:0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.2
server glx extensions:
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context
client glx vendor string: SGI
client glx version string: 1.2
client glx extensions:
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context,
GLX_ATI_pixel_format_float
GLX extensions:
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context
OpenGL vendor string: ATI Technologies Inc.
OpenGL renderer string: Radeon 8500 DDR Pentium III (SSE)
OpenGL version string: 1.3.3477 (X4.2.0-2.4.3)
OpenGL extensions:
GL_ARB_multitexture, GL_EXT_texture_env_add, GL_EXT_compiled_vertex_array,
GL_S3_s3tc, GL_ARB_point_parameters, GL_ARB_texture_border_clamp,
GL_ARB_texture_compression, GL_ARB_texture_cube_map,
GL_ARB_texture_env_add, GL_ARB_texture_env_combine,
GL_ARB_texture_env_crossbar, GL_ARB_texture_env_dot3,
GL_ARB_texture_mirrored_repeat, GL_ARB_transpose_matrix,
GL_ARB_vertex_blend, GL_ARB_vertex_program, GL_ARB_window_pos,
GL_ATI_element_array, GL_ATI_envmap_bumpmap, GL_ATI_fragment_shader,
GL_ATI_map_object_buffer, GL_ATI_texture_env_combine3,
GL_ATI_texture_mirror_once, GL_ATI_vertex_array_object,
GL_ATI_vertex_attrib_array_object, GL_ATI_vertex_streams,
GL_ATIX_texture_env_combine3, GL_ATIX_texture_env_route,
GL_ATIX_vertex_shader_output_point_size, GL_EXT_abgr, GL_EXT_bgra,
GL_EXT_blend_color, GL_EXT_blend_func_separate, GL_EXT_blend_minmax,
GL_EXT_blend_subtract, GL_EXT_clip_volume_hint,
GL_EXT_draw_range_elements, GL_EXT_fog_coord, GL_EXT_multi_draw_arrays,
GL_EXT_packed_pixels, GL_EXT_point_parameters, GL_EXT_rescale_normal,
GL_EXT_polygon_offset, GL_EXT_secondary_color,
GL_EXT_separate_specular_color, GL_EXT_stencil_wrap,
GL_EXT_texgen_reflection, GL_EXT_texture3D,
GL_EXT_texture_compression_s3tc, GL_EXT_texture_cube_map,
GL_EXT_texture_edge_clamp, GL_EXT_texture_env_combine,
GL_EXT_texture_env_dot3, GL_EXT_texture_filter_anisotropic,
GL_EXT_texture_lod_bias, GL_EXT_texture_object, GL_EXT_texture_rectangle,
GL_EXT_vertex_array, GL_EXT_vertex_shader, GL_HP_occlusion_test,
GL_NV_texgen_reflection, GL_NV_blend_square, GL_NV_occlusion_query,
GL_SGI_texture_edge_clamp, GL_SGIS_texture_border_clamp,
GL_SGIS_texture_lod, GL_SGIS_generate_mipmap, GL_SGIS_multitexture,
GL_SUN_multi_draw_arrays
glu version: 1.3
glu extensions:
GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess

visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav
id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat

0x25 24 tc 0 24 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow
0x26 24 tc 0 24 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow
0x27 24 tc 0 24 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow
0x28 24 tc 0 24 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow
0x29 24 tc 0 24 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None
0x2a 24 tc 0 24 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None
0x2b 24 tc 0 24 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None
0x2c 24 tc 0 24 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None
0x2d 24 dc 0 24 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow
0x2e 24 dc 0 24 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow
0x2f 24 dc 0 24 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow
0x30 24 dc 0 24 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow
0x31 24 dc 0 24 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None
0x32 24 dc 0 24 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None
0x33 24 dc 0 24 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None
0x34 24 dc 0 24 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None

Enjoy!!!

Dan

Sweet, ARB_vertex_program!! Still waiting for nVidia to implement that in their Linux drivers.

One of the reasons I haven’t bought an ATI is because of Linux drivers. Now all I need are some benchmarks.

Originally posted by PK:
[b]Sweet, ARB_vertex_program!! Still waiting for nVidia to implement that in their Linux drivers.

One of the reasons I haven’t bought an ATI is because of Linux drivers. Now all I need are some benchmarks.[/b]

Tell me how to benchmark RTCW v1.4 and I’ll post some numbers (I’ve never done a benchmark with a game before, sorry, I just play’em )

I have installed the new drivers and I must say, they are the best to date, as I should expect. I have a Radeon 8500. I primarily run a GeForce4 4600 on my devel machine. I’ve also come across an alpha version of the drivers (nVIDIA) versioned 40.71 (shush ). Being ‘alpha’ drivers, I must say they are about as rock solid as any other release, with a few minor quirks (so minor I won’t even mention them, as they are not officialy released). They support a full OpenGL 1.4. Awesome. But I was horribly disappointed that the latest ATI drivers only supported a few 1.4 extensions (no ARB_depth_texture and ARB_shadow support. tisk tisk…). glxinfo claimed they supported ARB_vertex_program, but my current projected deemed otherwise. The drivers would bomb out when loading a perfectly error-free vertex program and cause my app to seg-fault (a program that the ‘alpha’ nVIDIA drivers I mentioned earlier would load and run just fine). Not only that, but all of my apps that used the ATI_vertex_array_object extension would die misserably. This isn’t the first time this has happened either. All of their Linux drivers to date have given me problems with that particular extension. I do not blame ATI however, nor do I blame the drivers. I run a system with a VIA chipset (KT266a) with an AMD Athlon 1.4GHz (not an XP chip). I have frequently heard of people running into problems on very similar setups. These ATI drivers performed exceptionally well with my Linux games (q3a, RtCW, etc…), but not with anything that used either the ATI specific extensions (VAO, ATI_fragment_shader, etc…) or any of the OpenGL 1.4 extensions the drivers did support (ARB_fragment_program mainly). I can say this though. ATI is headed on the right track, and if what they have done now continues, then all Linux nuts like myself should be grateful. You will have the same freedom of choice in a graphics accelerator as the Windows kids have as far as available driver support. But alas, I must say, anyone serious about 3D graphics on a Linux platform today (be it for programming or gaming), I’d stick with nVIDIA. But keep your eyes on ATI. They are certainly going places (and not a moment too soon either!).

Originally posted by Dan82181:
Tell me how to benchmark RTCW v1.4 and I’ll post some numbers (I’ve never done a benchmark with a game before, sorry, I just play’em )

I don’t remember which command shows the FPS and I have some crappy RAM in machine which is causing a bunch of instability so…
Hit the tilda key (~) to bring up the console. Then type /cmdlist to get (surprise!!) the command list.

You can also try Specviewperf http://www.spec.org/gpc/downloadindex.html

Warning!! It’s about an 300MB download.

There’s also xbench. Not sure how good it is. http://www.ibiblio.org/pub/X11/contrib/utilities/

[This message has been edited by PK (edited 11-22-2002).]

Dan wrote:
> so I’m still stuck using the old driver
> for my 8500LE

You refer to the DRI driver, right?

> For the 8500, glxinfo reports to me the
> following [snip]

This is after you got the new ATI (non-DRI) driver installed, correct?

PK,
I know how to use the console, I frequently use it for modifying some cvars while in the middle of a game instead of having to always use the menu. I remember something called timedemos or something like that that are always used for benchmarking games, but I’ve never done it before, and I’m not sure if the base install of RTCW comes with some or not. So if you know how I can use the timedemo stuff, just email it to me and I’ll post my results for everyone. 300MB download… I’ve got DSL, so I’m not worried, but I’ll give it a shot. Might I suggest some Crucial memory?!

jmg,
I was using the previous drivers off ATI’s site (v1.4.3) The new ones, when installing, wouldn’t find a matching binary for my system. I’ve got a Redhat 7.2 distro that I use as a shell to get me up and running, but I’ve since changed just about everything since installation (Kernel 2.4.19, GCC 2.95.3, XF86 4.2.0, …, …, …) The drivers, however, have a little bit of them that are somewhat architecture/kernel dependant that can be compiled to build a module for your system. However, durring the building of the module, I was getting several errors, in particular related to the macro __KE_ERROR(“some string here”,…), whenever there were no optional variables place in the …, it kept complaining. I’ve fixed the code and I have the new driver working now (v2.4.3), and my output from the glxinfo is of the new driver (look at the GL_VERSION string)

fenris,
I’m still looking into a few problems I’ve been having myself related to VAO, but also w/ ARB_texture_compression. The driver exports the ARB_texture_compression string, yet any call to glXGetProcAddressARB(“func_here”) for any of the ARB_texture_compression functions return NULL. I do get all of my VAO functions, I can generate a VAO object name/number, but the moment I attempt to load any data into my buffer causes an immediate sigfault. I haven’t tried ARB_vertex_program yet, I’m still transplanting a lot of windoze code to oonics, and right now I’m concentrating on my ATI_fragment_shader stuff, but when I eventually get to the EXT_vertex_shader stuff, I will be redoing that stuff for ARB_vertex_program.

Dan

Multimonitor support in this new driver is sweet too, almost forgot to mention

Now if we could get some TV output, we’d be set

Dan

Quick update for Fenris…

I’ve checked out my VAO code and it appears to have been a problem with my code. Seems to have not been a problem under W2k, but causes a SIGSEGV as soon as I would try to put data into my buffer. But I have no problems whatsoever with VAO now (so far atleast.) Wierd…

Dan

Just want to know why they dont make drivers for Radeon 7500. I bought a 7500 ayear ago just cause I tought it would get linux drivers earlier…and they skiped it… ggrrrrrr… I got furious with that. Now I have a Useless card and no money to buy another.

Originally posted by Dan82181:
[b]The driver is supposed to support 2 series of cards…

the 8500/FGL8700/FGL8800/FGL E1
and 9700/9700PRO/FGL Z1/FGL X1

For the 8500, glxinfo reports to me the following
[b]

The 9700 supports additional extensions:

GL_ARB_depth_texture GL_ARB_fragment_program
GL_ARB_multisample
GL_ARB_shadow
GL_ARB_shadow_ambient
GL_ATI_draw_buffers
GL_ATI_separate_stencil
GL_ATI_texture_float

It seems to support the same visuals, though.

Originally posted by Dan82181:
[b]Quick update for Fenris…

I’ve checked out my VAO code and it appears to have been a problem with my code. Seems to have not been a problem under W2k, but causes a SIGSEGV as soon as I would try to put data into my buffer. But I have no problems whatsoever with VAO now (so far atleast.) Wierd…

Dan[/b]

Does that mean you can use VAO but not put data in the buffer? Seems to defeat the purpose a bit…

Or does it just work? How fast is it, then?

For us the drivers seem to be quite good, given that they’re the first try for the Radeon 9700 (they’re based on the FireGL drivers, which have been around a while).

We only had a problem with glPolygonMode in some old code, which resulted in spurious lines going all over the place, which we couldn’t reproduce in the current code. And there was a crash in a multi-threaded application that didn’t shut down correctly, but I can accept that.

I’m more interested in other people’s experience with the card and the drivers, feature-, stability- as well as performance-wise. We just tried some informal tests running some of our apps, and it seemed to be quite stable and somewhat faster than the GF4. Didn’t seriously test it, though.

As I have to decide on what card to use for our upcoming graphics cluster very soon I’m very interested in other people’s experiences.

Do all the nice extensions work, especially the GL_ARB_*_program stuff? What is the performance you get? What’s the best way to get the best performance? How does it compare to the Windows drivers and/or to other cards? You know, all the interesting stuff…

Are the current ATI driver a completely separated stuff from DRI ones? Did ATI anounced any plan of integrarting them at Xfree distributions?

Also I would like to know about quality of these drivers operations. I would be really mad if I buy a r9700 and discover its drivers produces lots of artifacts like the 7500 does.

If anyone has a 9700 runnign on linux… some screenshots would be nice.

[This message has been edited by OldMan (edited 11-24-2002).]

Thanks for glxinfo for R200/R300…

This driver have some R100 relative code(and I have this card) , but it dosn’t work…