View Full Version : ATI shader bug + rant on ATI dev support
10-03-2005, 03:54 AM
I don't like to complain but this is getting very frustrating.
I've discovered a bug on my ATI X850 XT on all Catalyst versions higher than 5.4 (excluded).
It seems to corrupt some registers while doing arithmetic operations done in an ARB_fragment_program shader.
Basically, i have two registers, R1 and R2. When i output them to the screen separately, both at correct. However, as soon as i do an operation between them, like an ADD or a MAD, the result is corrupted: random blocks of pixels appear, which are flickering.
It does not happen on Catalyst 5.4 or less, or on NVidia cards.
Here are two images:
http://www.fl-tw.com/opengl/ati_correct.jpg (correct version)
http://www.fl-tw.com/opengl/ati_bug.jpg (buggued version)
You can download the binary here:
So, why am i frustrated ? Well, for two reasons:
1. Since it was working before Catalyst 5.4, the logic conclusion is that ATI introduced a bug in their recent drivers. I tested them all until 5.9 and all of them suffer from the problem.
2. I emailed their developper support immediately after i discovered the bug, and have been completely ignored. And i am a registered ATI developer.
I just do not understand. I've been working in cooperation with ATI to solve some bugs many times in the past, and i always found them to be responsive and helpful. But since approximately one year, i found that their behavior changed. I already tried to submit a bug report before and was already ignored, although it was a minor one, so it didn't bother me too much at that time.
But here this is not the case. The bug demonstrated here is in a major area of my code and i cannot release my program without it.
If somebody has an idea or can have a look at the problem (Humus maybe?), i'd be very thankful.
Sorry for the rant.
10-04-2005, 12:34 AM
This may be completely wrong, but have you tried multiplying by 2.001 instead of 2 in the preceeding MAD operations? (I see in your shader you do a lot of MAD h.xyz, h, 2.0, -1.0;)
This could relate to the issue I had previously:
Where the optimizer was doing weird things when it saw it could optimize a MAD x, 2, -1;
10-04-2005, 05:35 AM
He doesn't use those temps so you can uncomment them.
I tried to move instructions around, move immediate values to PARAM, tried clamping, tried simply adding h and n1.
It's a stubborn problem.
Instead of using RECT, change to 2D for tex0.
Ysaneya, have you tried doing a GLSL version?
10-05-2005, 04:24 PM
You can't sample RECT textures in GLSL with ATI. And from the impression I was given by their developer relations, you likely never will. Kinda stupid if you ask me, considering they already support EXT_texture_rectangle. They just need the GLSL support to make it ARB_texture_rectangle.
10-05-2005, 08:19 PM
I'll take a look at this problem tomorrow.
10-06-2005, 01:08 PM
I'm using renderable floating point textures at some point, some a RECT target is needed.
I haven't tried a GLSL version.
Humus: thanks - please let me know if you find something.
10-06-2005, 01:38 PM
I've tracked down what change to the driver caused this bug and it appears to be related to the texture cache. Ironically, that change was a fix to an old bug I reported myself some time ago. My bug had the exact same problem, but that happened in GLSL.
Btw, are you by any chance using floating point textures?
10-06-2005, 02:17 PM
As i said in my last post, yes :)
I'm glad you found it. That was fast. Will you be able to fix it ? I guess that you don't want your old GLSL bug to reappear..
10-06-2005, 05:41 PM
Originally posted by fenris:
You can't sample RECT textures in GLSL with ATI. And from the impression I was given by their developer relations, you likely never will. Kinda stupid if you ask me, considering they already support EXT_texture_rectangle. They just need the GLSL support to make it ARB_texture_rectangle.I know you can't sample RECT, but it shouldn't be hard to use a 2D texture instead.
This is suppose to be a cache related problem? Very weird.
10-06-2005, 08:24 PM
Originally posted by Ysaneya:
As i said in my last post, yes :) Doh! How could I miss that? :)
Well, then the situation is exactly the same as mine, except I had the problem for GLSL.
Originally posted by Ysaneya:
I'm glad you found it. That was fast. Will you be able to fix it ? I guess that you don't want your old GLSL bug to reappear..I personally won't be able to fix it as I'm not a driver guy if that's what you meant. But I'll submit a bug report on it for the driver team to take a look at.
10-07-2005, 01:14 AM
Thanks. Could you please kindly ask them not to break something else ? :p
10-07-2005, 11:09 AM
Btw, I checked my old bug report and noted that I had a workaround that worked for me then. Simply unbinding the shader and binding it again between each pass made it work. You may want to try that and see if it helps.
10-07-2005, 01:54 PM
Originally posted by V-man:
I know you can't sample RECT, but it shouldn't be hard to use a 2D texture instead.I know it isn't hard. And I do use 2D textures on ATI parts when I need non-power-of-two dimensions. It becomes a pain because I have to write 2 of everything that uses NPOT textures due to the NV3x not supporting NPOT in hardware. I have to use RECTs. I'd much rather just use RECTs for everything. It's mostly just a gripe on my part, but I still don't see the point in ATI not supporting it.
P.S. Sorry for the thread intrusion!
Originally posted by Humus:
Btw, I checked my old bug report and noted that I had a workaround that worked for me then. Simply unbinding the shader and binding it again between each pass made it work. You may want to try that and see if it helps.i know ati get a hard time here in these forums so to even the balance a bit nvidia suffer from a similar bug. i have to rebind a shader beforehand or else rendering errors occur
glGetIntegerv( GL_CURRENT_PROGRAM, &active_programID )
glUseProgram( active_programID );
though i admit nvidia do look after developers better
10-11-2005, 12:51 AM
I have to use RECTs. I'd much rather just use RECTs for everything.I'd much rather just use 2D for everything :D
10-11-2005, 12:27 PM
I'd much rather just use 2D for everything :D [/QB]Oh, don't get me wrong. I would too. But for now, NV3x is still significant. RECTs work just fine for what I need NPOT textures for at this time. It would just be convienient and nice if I could use them across the board.
10-15-2005, 08:12 AM
I know. But I don't see why the driver can't provide partial NPOT support that's emulated using the rectangle target. As long as I adhere to the limitations of RECT textures it should be fine.
ATI boards don't fully support NPOT either, but it works in hardware as long as you don't use certain things (mipmapping, ...).
What I really wanted to say with my previous post is:
Why does everyone complain to ATI about the lack of ARB_texture_rectangle, but noone to nVidia about the lack of partial NPOT on GFFX?
10-17-2005, 12:22 PM
Originally posted by Overmind:
Why does everyone complain to ATI about the lack of ARB_texture_rectangle, but noone to nVidia about the lack of partial NPOT on GFFX?Because unlike the NV3x, which cannot do NPOT in hardware at all, ATI can accelerate RECTs. They already do. Just no GLSL support :( It just seems like it shouldn't be a problem for them to add the rest of the support for a feature their hardware can handle just fine.
10-17-2005, 10:08 PM
ATI supporting RECTs is about the same as Nvidia support TEXTURE_2D. It's the same limitations, just that nVidia needs to scale up the texture coordinates by [w, h], whereas ATI need to scale down texture coordinates by [1/w, 1/h] for RECTs.
10-17-2005, 10:46 PM
Right. But I can also sample 2D NPOT or RECTs in GLSL with an nvidia card. That's what I mean. I'd like to be able to sample RECTs on ATI cards in GLSL as well. ATI already allows me to sample RECTs in ARB_fragment_program, why not GLSL? I know you've explained this to me before Humus, but I just can't let it go :D
Powered by vBulletin® Version 4.2.2 Copyright © 2013 vBulletin Solutions, Inc. All rights reserved.