The Official ATI Linux Issues Thread

[spyke]

4K stacks does work with ATI drivers, its just nVidia's that puke with it, I've always used 4k stacks..

[Mythos]

Originally posted by spyke
4K stacks does work with ATI drivers, its just nVidia's that puke with it, I've always used 4k stacks..

Yep, it works here as well!

[loyal_lin]

so i suppose what i reported is a problem....grrr
(mythos : ti leei ola kala?)

[WhO_KnOwS]

Sorry for the long abscence (HD went fubar).
I'll check the 4k stacks myself, then act acordingly.

@Inexplicable:
Unfortunately I cannot test this, as my LCD wont allow resolutions as high as that. But I'll try to test it elsewhere. Anyone else is free to try

[Thetargos]

I have kernels using both the 8K and the 4K stacks, both work pretty good with the latest ATi driver... I haven't noticed any performance gaine or impact, but then again I haven't tested them too thoroughly

[loyal_lin]

guys thanks for yous attention....
i think that the problem has to do with the SMP

[dberger]

Reporting an issue which I submitted via the driver feedback form moments ago.

While trying to run Wine (or WineX) on my 2x1Ghz PIII with a 9600XT, I get a reproducable kernel oops in the ATI driver - results in the system locking hard. Only occurs running an SMP kernel. Running Fedora Core 2 tried both the latest fedora update kernel and a stock 2.6.6. (BTW: the latest update kernel requires some fixes to the source portions of the driver - references to the count field of a page need to become _count)

Here's the oops:

Jun 23 22:18:13 rage kernel: Unable to handle kernel paging request at virtual address 0001ba52
Jun 23 22:18:13 rage kernel: printing eip:
Jun 23 22:18:13 rage kernel: 229c5798
Jun 23 22:18:13 rage kernel: *pde = 00000000
Jun 23 22:18:13 rage kernel: Oops: 0000 [#1]
Jun 23 22:18:13 rage kernel: Modules linked in: udf floppy snd_intel8x0 snd_mpu401_uart snd_mixer_oss snd_cs46xx snd_rawmidi snd_seq_device snd_ac97_codec snd_pcm snd_timer snd snd_page_alloc gameport soundcore fglrx binfmt_misc ipv6 parport_pc lp parport autofs4 sunrpc 3c59x ipt_REJECT ipt_state ip_conntrack iptable_filter ip_tables microcode nls_utf8 nls_cp437 vfat fat dm_mod sd_mod usb_storage scsi_mod uhci_hcd ohci_hcd ehci_hcd button battery asus_acpi ac ext3 jbd raid1
Jun 23 22:18:13 rage kernel: CPU: 0
Jun 23 22:18:13 rage kernel: EIP: 0060:[<229c5798>] Tainted: P
Jun 23 22:18:13 rage kernel: EFLAGS: 00010096 (2.6.6-1.435)
Jun 23 22:18:13 rage kernel: EIP is at sig_notifier+0x8/0x50 [fglrx]
Jun 23 22:18:13 rage kernel: eax: 229e9728 ebx: 229c5790 ecx: 02349920 edx: 0001ba52
Jun 23 22:18:13 rage kernel: esi: 08b24000 edi: 048e6b50 ebp: 08b24f28 esp: 08b24ed4
Jun 23 22:18:13 rage kernel: ds: 007b es: 007b ss: 0068
Jun 23 22:18:13 rage kernel: Process wine (pid: 3562, threadinfo=08b24000 task=048e6b50)
Jun 23 22:18:13 rage kernel: Stack: 229c5790 0211e672 02349920 00000013 048e7074 08b24000 08b24f28 048e6b50
Jun 23 22:18:13 rage kernel: 048e7064 0211e790 08b24000 08b24000 08b24f28 08b24fc4 0211f7df 048e7064
Jun 23 22:18:13 rage kernel: 08b24fc4 08b24000 048e7064 08b24000 02105f69 00000001 40da6415 1c1bd664
Jun 23 22:18:13 rage kernel: Call Trace:
Jun 23 22:18:13 rage kernel: [<229c5790>] sig_notifier+0x0/0x50 [fglrx]
Jun 23 22:18:13 rage kernel: [<0211e672>] __dequeue_signal+0x49/0x152
Jun 23 22:18:13 rage kernel: [<0211e790>] dequeue_signal+0x15/0x54
Jun 23 22:18:13 rage kernel: [<0211f7df>] get_signal_to_deliver+0x7a/0x2a5
Jun 23 22:18:13 rage kernel: [<02105f69>] do_signal+0x4e/0xbb
Jun 23 22:18:13 rage kernel: [<0214af47>] pipe_writev+0x2ba/0x2c6
Jun 23 22:18:13 rage kernel: [<021156ed>] recalc_task_prio+0x128/0x133
Jun 23 22:18:13 rage kernel: [<02281afc>] schedule+0x34c/0x369
Jun 23 22:18:13 rage kernel: [<02105ffd>] do_notify_resume+0x27/0x36
Jun 23 22:18:13 rage kernel:
Jun 23 22:18:13 rage kernel: Code: 8b 1a 85 db 78 07 b8 01 00 00 00 5b c3 8b 1a 81 e3 ff ff ff

[hydroxyhydride]

Dual Display Problems:
--2D perfomance gets even worse and becomes craptacular when running "DUAL HEAD" mode (2 drivers mode) . What do I mean? I mean that Totem movie player is choppy--especially when in full screen mode. Also, terminal window updates seem choppy too. System feels slow. glxgears does not seem to suffer any speed effects.
--Cannot play UT2k4 when in "Big Desktop" mode because it tries to center the game and the half on the secondary monitor isn't rendering (possibly because I set my resoluion to only be 1600x1200 which makes the secondary screen gray).

Other Issues:
--UT2k4 performance "sucks" in comparison to windows and I'm still working on eliminating segfault crashes.
--Cannot switch to another console and then back to X--X doesn't come back!

System Configuration:
Motherboard: Asus K8V Deluxe
OS: stock Slackware 10. (2.4.26 Kernel with Xorg)
Drivers: 3.9.0 for XFree86 4.3.0

[Thetargos]

Only thing I can tell you about UT2K4 is to install the latest drivers, that surely eliminates most of the issues I had with the game.

[riprjak]

1 general question, when will the build target for the binary driver be updated a little from i386?? I am certain the driver would benefit from having athlonXP, Pentium 3, Pentium 4, Pentium M specfic -march builds; hell, even updating to i586 march would be a start??

3 issues, my desktop, my notebook and my partners notebook
I have a fairly basic desktop system for an engineering professional., but its not x86.

Athlon64 3200+
MSI k8tneo FSIR2
1 GB 400MHz DDR
(scrapped) Firegl (SCRAPPED) nvidia Geforce 5950XL 256MB
assorted EIDE and FUW SCSI drives

When will ati support x86_64?? (using the -m64 cflag should be all that is required), not that it matters since I scrapped the ATI card 6 months afo as I could not afford to wait any longer for hardware accelerated openGL support... (x86_64 architecture has now been available for over 2 years and stable production distributions for 6+ months; ati themselves *promised* x86_64 support in April LAST YEAR)

Notebook :

Acer Aspire 2012 WLCi with Mobility 9700 64MB

When will the ati-drivers (fglrx) work for the mobility cards without locking the system... hell, at least compile the binary only crap they release with frame pointers so I have a shot at debugging the problem?? (with the x86_64 above, I see a pattern of ati ignoring non-x86-desktop environments).

Notebook2 :

iBook 12" with mobility 9200

when will ATi release fglrx binaries that support ALL platforms they make graphics cards for??

Considering the rude, confrontational and technically inept responses Ive had from ATi when investigating such issues over the past year; I doubt I will see any meaningful responses to my questions - but I live in hope.

err!
jak

EDIT : Oh! yeah; Distro is universally Gentoo. the notebook started at 2004.0, the ibook at 2004.1 and the desktop and 1.4; but all are emerge sync'd and update as of this morning

[sthein]

You should be able to use the OpenSource radeon-driver on the iBook.

[riprjak]

Originally Posted by sthein

You should be able to use the OpenSource radeon-driver on the iBook.

That is a good point... assuming that the opensource driver provides DRI and hardware openGL for the 9200... thx

[Thetargos]

Originally Posted by riprjak

That is a good point... assuming that the opensource driver provides DRI and hardware openGL for the 9200... thx

Well for that particular model you may need to use the latest branch, but yes, they do (they only lack some of the extensions and the use of S3TC).

[vanbirk]

- problem: reading back depthbuffer with glReadPixels() doesn't work

If have the following issue that explains some of the "I shoot at something but don't hit it" problems.
After drawing my scene and trying to read back a clicked location from the
depth buffer via glReadPixels() and GL_DEPTH_COMPONENT, the call returns a single value:
0.00390625
I can read back the whole buffer and everything is stuffed with this value, but reading back
something like the framebuffer works. I have tested this problem under windows and there it
works as expected, returning the correct values.
I think this issue is serious because picking and other stuff relies heavily on this.
Btw. when will be the next driver released ?

-motherboard: ASUS A7N8X nforce2
-gfx card: Radeon 9600 XT
-kernel version: 2.6.5-7.95-default
-driver version: 3.9.0 from SuSe ftp
-distro: SuSe 9.1

[sthein]

Originally Posted by vanbirk

Btw. when will be the next driver released ?

It depends...
If they keep their "one driver every two months"-promise (counting from 29.12.2003 when 3.7.0 was released) then tomorrow... but tomorrow two months ago.

Actually they never did that. Counting two months from the last driver it will be released two days ago.

Initially it was said that they would release one with every second catalyst (that would be around ~10.08.04). AFAIK there was never a driver released parallel with any catalyst...

However, I would prefer that they take the time they need to build a *stable* driver instead of pushing out frequent but broken releases...

I still don't know what this "one every (other) month" policy is about. I'm a coder myself and a piece of software is ready when it is ready and not when the monthly deadline hits you...

[Inexplicable]

Originally Posted by sthein

I still don't know what this "one every (other) month" policy is about. I'm a coder myself and a piece of software is ready when it is ready and not when the monthly deadline hits you...

It can be done but there's a price. It means you maintain a stable branch and have multiple development branches on the side for new features. You make releases from the stable branch and merge new features in when they are ready. That's how "big software" gets made. Only problem is, you need ten times as many people to get anything done.

[vanbirk]

Originally Posted by sthein

I'm a coder myself ...

Excellent , so could you pleeeeeeze try this code snippet ?
I've never had the chance to ask someone, but it would be interesting
if it depends on my HW setup.

 
// Copy and paste to myfile.cpp and compile with: 
// g++ myfile.cpp -lGL -lGLU -lglut -o depthtest
#include <iostream>
using namespace std;
#include <GL/gl.h>
#include <GL/glu.h>
#include <GL/glut.h>
 
int main( int argc, char **argv )
{
glutInit( &argc, argv );
glutInitWindowSize( 128, 128 );
glutInitDisplayMode( GLUT_DOUBLE | GLUT_RGBA | GLUT_DEPTH );
glutCreateWindow( "depth test" );
float val;
glClear( GL_DEPTH_BUFFER_BIT );
glReadPixels( 0, 0, 1, 1, GL_DEPTH_COMPONENT, GL_FLOAT, &val );
cout << "[Depthtest] Read value: " << val << " and it should be 1." << endl;
return 0;
}

Thanx a lot in advance !

[Inexplicable]

Originally Posted by vanbirk

Excellent , so could you pleeeeeeze try this code snippet ?

Yeah, looks like a bug. It works ok with Mesa but not with firegl. Mine's a 9700pro.

[Thetargos]

Originally Posted by Inexplicable

Yeah, looks like a bug. It works ok with Mesa but not with firegl. Mine's a 9700pro.

I tried that too and works OK in MESA (as you already pointed out) but not with fglrx 3.9.0, Radeon 9500). Maybe this is the same problem with the game Cube?

[vanbirk]

Originally Posted by Thetargos

I tried that too and works OK in MESA (as you already pointed out) but not with fglrx 3.9.0, Radeon 9500). Maybe this is the same problem with the game Cube?

This is exactly what I meant.
Every program that relies on depth buffer reads should not work as expected.

[sthein]

Doesn't work here either (with current DRI drivers, NOT fglrx).
But I think that the problem here isn't the drivers:

The display state of a window is initially for the window to be shown. But the window's display state is not actually acted upon until glutMainLoop is entered. This means until glutMainLoop is called, rendering to a created window is ineffective because the window can not yet be displayed.

Since I haven't ever used glut before, I quickly rewrote the test-prog with SDL:

// Copy and paste to myfile.c and compile with:
// gcc myfile.c -lGL -lGLU -lSDL -o depthtestsdl
#include <stdio.h>
#include "SDL/SDL.h"
#include <GL/gl.h>
#include <GL/glu.h>

int main( int argc, char **argv )
{
        float val, clearval;
        SDL_Surface *screen;

        if(SDL_Init(SDL_INIT_VIDEO)) { printf("SDL error\n"); return 1; }
        screen = SDL_SetVideoMode(128, 128, 32, SDL_OPENGL | SDL_HWSURFACE | SDL_HWPALETTE);

        glGetFloatv( GL_DEPTH_CLEAR_VALUE, &clearval );
        glClear( GL_DEPTH_BUFFER_BIT );
        glReadPixels( 0, 0, 1, 1, GL_DEPTH_COMPONENT, GL_FLOAT, &val );

        printf("[Depthtest] Read value: %f and it should be %f.\n", val, clearval);

        return 0;
}

This returns 0.1 on my Radeon with DRI drivers. Better than 0 but still not what we want ;-) Will talk to the dri guys about that...

I tested this on one of my nVidia-based systems and the glut-based prog doesn't work there either (returns 0 as well) but the SDL one works (returns 1.0 as expected).

Originally Posted by Inexplicable

It can be done but there's a price. It means you maintain a stable branch and have multiple development branches on the side for new features.

Using multiple branches is the common way but it doesn't solve all the problems, especially when doing big structural changes to a project.

[vanbirk]

You're right, but this has been a strongly stripped down version of the full testing program.
I just didn't want to leave the necessary functions in the prog for the sake of length of the post.
Strange, but the stripped one returns the values as expected under windows ( I've tried
changing the cleardepth value and it always returned the correct one )
If anyone wants the glut-based full-one please post.

[sthein]

What does the SDL prog return on your system?

For the glut-prog: Windows and X might handle those initialized-but-not-yet-displayed windows quite differently. Check for GL-Errors...

[vanbirk]

Returns the same value (0.003906).
Even under the new 3.11.1 drivers ...

[Inexplicable]

Originally Posted by sthein

Using multiple branches is the common way but it doesn't solve all the problems, especially when doing big structural changes to a project.

Version management is always a pain in the butt.

[WhO_KnOwS]

Could you guys go through the issues your reported and check if they are still there (would do it myelf, but am quite busy these days). Thanks for any feedback.

[sthein]

- mobility Radeon bug still existant
- UT2004 menu bugs are gone but the game itself now turns into garbage instantly.

[ewschone]

The new drivers compile ok against my 2.6.7 vanilla kernel, but modprobe gives me this:

FATAL: Error inserting fglrx (/lib/modules/2.6.7/kernel/drivers/char/drm/fglrx.ko): Unknown symbol in module, or unknown parameter (see dmesg)

/var/log/messages:
Aug 8 20:02:04 suseAthlonXP kernel: fglrx: Unknown symbol __might_sleep

Maybe I didnt compile something into the kernel that the new drivers expect !

[Thetargos]

Originally Posted by ewschone

The new drivers compile ok against my 2.6.7 vanilla kernel, but modprobe gives me this:

FATAL: Error inserting fglrx (/lib/modules/2.6.7/kernel/drivers/char/drm/fglrx.ko): Unknown symbol in module, or unknown parameter (see dmesg)

/var/log/messages:
Aug 8 20:02:04 suseAthlonXP kernel: fglrx: Unknown symbol __might_sleep

Maybe I didnt compile something into the kernel that the new drivers expect !

Do you have ACPI and/or APM compiled in your kenrel.?

[ewschone]

Do you have ACPI and/or APM compiled in your kenrel.?

I think I have .

<6>ACPI: Subsystem revision 20040326
<6>ACPI: Interpreter enabled
<6>ACPI: Using IOAPIC for interrupt routing

Can't find anything on APM though.