Bug in Catalyst 4.6

I just wanted to ask, if anyone of you experienced strange behaviour in the OpenGL driver of the latest Catalyst version.
I experienced two completely broken backend paths in my engine.
One is using ATI_fragment_shader+ ARB_vertex_program, the other is using GLSL. No application crashes happen, no GL errors are created, the resulting output is just plain wrong (false colors, some textures seem missing an so on). A third backend, using ARB_fragment_program+ARB_vertex_program is working flawless just as usual.
All backends have worked for several driver versions now and got first broken with the pre 4.6 beta version.
I mailed ATI devrel on this, but got no answer (my description was rather fuzzy). I´m hoping to get some backup from fellow sufferers, since I have no clue what part of the driver broke.
Unfortunately all those ATI_fs and GLSL demos you can download at ATI still work :frowning:

thank you in advance

PS: I´m using a R9800non-pro

ATI_fragment_shader+ ARB_vertex_program
I don’t like that combination at all. Is there even a document that explains how these two interact with oneanother?

Consider using EXT_vertex_shader (or the text version if you prefer).

I mailed ATI devrel on this, but got no answer (my description was rather fuzzy).
Consider sending a short sample application that displays the problem. That tends to work better than just saying that using two extensions together doesn’t work.

Originally posted by Korval:
[quote]ATI_fragment_shader+ ARB_vertex_program
I don’t like that combination at all. Is there even a document that explains how these two interact with oneanother?
[/QUOTE]What’s wrong with that combination? You can’t access the fog coord in the fragment stage, true, but ATI_fragment_shader doesn’t rule out fixed function fog, so …

Otherwise it’s fully functional.

skynet,
I have an ARB_vp+ATI_fs combination going, too. I’m not yet on Catalyst 4.6, but I’ll keep my eyes open.

Switched to Catalyst 4.6 half an hour ago, and howdathunkit, I’m having some issues, too.

My R200 path (which uses ATI_fragment_shader) has definitely worked fine before, I’ve actually checked the file date, and it has last been modified in April. Now I’m having some mild discoloration stuff.

With ARB_fragment_program, everything’s good.

My gut feeling tells me two things:
1)It’s something about constants … constants not ending up in the right places, or not getting updated at all under some special circumstances.
2)It won’t show up on actual R200 class hardware. I’ll check that later, I still have one on the shelf.

Btw, did anyone notice that (OpenGL) application controlled anisotropic filtering is broken since Cat 4.5?
It’s shimmering a lot, looks like a negative lod bias. That doesn’t happen if you force it in the control panel. Strange stuff …

Have you tried adjusting other panel settings like quality to see if it obeys application settings? In my panel high quality tends to override app preference settings. There is also the filtering method in this panel which may have some bearing on the aliasing you are seeing. It is possible that the defaults have changed between drivers.

Originally posted by dorbie:
Have you tried adjusting other panel settings like quality to see if it obeys application settings? In my panel high quality tends to override app preference settings. There is also the filtering method in this panel which may have some bearing on the aliasing you are seeing. It is possible that the defaults have changed between drivers.
I double and triple checked control panel settings. In fact it was the control panel overrides that made me so certain that it must be real.

Forcing aniso via the CP does not produce more than the usual, tiny amount of shimmering, even under extreme cases. App controlled aniso OTOH is just extreme. I’ve written a little kinda worst case testing app (slowly moving black/white checkerboard) just to make sure, with base filter, aniso and lod bias controls. I’ve only looked into “16x” aniso.

I’ve used that to compare CP aniso to app controlled ansio and concluded that I need a lod bias of +1.5 to get the same quality as with CP forced aniso. I’m not kidding you.

PS: I may release that thing. Does “Moiré monster” sound like a good name? :cool:

It’s true. It looks almost like GL_NEAREST for min filter, but not exactly the same.

I can only see it in the far distance, maybe something to do with certain mipmaps beeing accessed.

Thanks, V-man.
You’ll see it better if you use relatively small textures. My test app uses a 64x64 texture. I can clearly see it in a 640x480 viewport and in semi-fullscreen (maximized window on a 1280x960 desktop).
Aniso (if it works correctly, and if the rendered surface warrants anisotropic filtering) stays on the base level “longer”, and pushes mipmap transitions farther away. That’s why large textures diminish the effect. If only the base level is magnified (in a place where it should rightfully be magnified) there can’t be any shimmering.

I should add that this is R300 class hardware (9500Pro), not the new X800 series.

I’m starting to feel sorry for hijacking skynet’s thread :frowning:

Mipmaping algorithm is not based on texture dimension, only mipmap dimensions.
Go ahead and use 1024 x 1024 textures.

Aniso (if it works correctly, and if the rendered surface warrants anisotropic filtering) stays on the base level “longer”, and pushes mipmap transitions farther away. That’s why large textures diminish the effect.
I experimented a bit and it is more complex than that.

The behavior you describe is visible if you watch a polygon at sharp angles, but when you watch the polygon “head on” (poly is facing you), then the mipmap selection ends up beeing the same for aniso and non-aniso.

I think it has to do with how high the derivatives are across the poly.

I’m using 4.5 R9700.
I have no idea why the control panel fixes this, but ati did not document this on their 4.6 page I think.

Is it fixed in 4.6?

No, Catalyst 4.6 doesn’t fix it.
And sorry about my previous post. That must have been the worst nonsense I’ve ever written about texture filtering. It’s exactly the other way round …

However, it’s clear as mud to me. I (most of the time) understand quite well how and where anisotropic works. Of course nothing will happen with a “flat on” texture, that’s expected and perfectly fine.

I may upload the test case later, if I manage to get this object recycler thingy finished before falling asleep.

edit:
Ahem. Here .

That must have been the worst nonsense I’ve ever written about texture filtering
yes, yes it was :slight_smile:

I haven’t tested on 4.6, only 4.5, but if you are sure, email them devrel@ati.com

I forgot to mention I also tested with a combination of various min and max filtering and fiddled with with the aniso factor and the problem was always there unless aniso was really low.
At <2.0, it becomes hard to see if aniso is on.

skynet,

Originally posted by zeckensack:
My gut feeling tells me two things:
<…>
2)It won’t show up on actual R200 class hardware. I’ll check that later, I still have one on the shelf.

Right on. I’m now on a Radeon 9200, Catalyst 4.6 of course, and the issues just aren’t there.

Hello, I’m a developer of the OpenGL Shader Designer and I haven’t an ATI card, but some Shader Designer users had noticed that after install Catalyst 4.6, when they try to load any shader, the application locks up the computer, with black screens, desktop resolution changes, and at the end, reboot. I emailed to ATI guys but it’s impossible that I can make an example application to send to them.
Before install 4.6, the SD worked fine on their machines.

I can confirm that my R200 backend still works on R200 class hardware. It seems, the R300 emulation of ATI_fragment_shader is buggy in 4.6.

:frowning:

This is getting silly. The Radeon 9200 w Cat 4.6 seems to ignore any and all LOD bias application control. Can be proven using the same test .

Edit: I take that back. The code is wrong, not the driver.
Lod bias should not be set with TexParameter, but with TexEnv and GL_TEXTURE_FILTER_CONTROL target. So that’s okay.

I just find it mildly strange that R300/Cat4.6 accepts this as if it was correct code, and RV280/Cat4.6 does not :confused:
Btw, FW61.12 accepts the wrong code, too (FX5700).

Edit2: d’oh. Core functionality!=EXT_texture_lod_bias functionality …

Upgraded to 4.6 a few days ago. I was shocked by the strange performance boost in my project: in the GUI screen FPS tremendously incresed from 150 upto 300. (the scene consists of several dozens triangles rendered via OpenGL immediate mode, GLSL is used). What can it be ?

Wanna try Catalyst 4.7 beta?

http://www.station-drivers.com/page/atidriv.htm

only for Win2k/XP (third column)

PS: 4.6 has the same bug

//Edit// Woops, I meant to say 4.7, not 3.7

Btw, did anyone notice that (OpenGL) application controlled anisotropic filtering is broken since Cat 4.5?
It’s shimmering a lot, looks like a negative lod bias. That doesn’t happen if you force it in the control panel. Strange stuff …
The official 4.7 still seems to have this problem it seems.

Originally posted by V-man:
The official 4.7 still seems to have this problem it seems.
Agreed. I’ve sent a report and test case on Saturday. R300 is affected, RV280 is fine.
FWIW, I found a workaround for current drivers:

if (do_workaround)
{
	glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MIN_FILTER,a_different_min_filter);
}

glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MAX_ANISOTROPY_EXT,desired_aniso_degree);

glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MIN_FILTER,desired_min_filter);

You get the idea :slight_smile:

Yet another reason to leave client side state checking to the application.