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

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)

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!

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.

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

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 ?

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.

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

Quote:

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:

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.