ATI Catalyst drivers, pbuffer support bug?

OpenGL OpenGL: Advanced Coding
1

I have been experiencing problems in my app when running on a RADEON 7000,Windows XP, CATALYST 3.0. If the pbuffer to which I render does not have a width divisible by 64, I get a very strange shearing type effect.

I then tried NVIDIAS simple_pbuffer.cpp example, and it worked fine, with its default pbuffer width of 256, when I changed this to 266 for example, the same shearing effect appeared.

I do not have this problem on NVIDIA cards.

I have tested this on several other ATI cards with similar disapointing results.

Anyone else out there care to try this simple test, and tell me why ATI and NVIDIA have such dramatically different results ?

And yes I know that CAT 3.1 were just released.

2

I noticed that too. Doesn’t happen when I use a floating point pixel format though…

3

Yeah, It happens for me too, I tried it on the CATALYST 3.1 drivers released yesterday.

Can anyone from ATI explain why such basic functionality is so buggy. I know it may not be part of some game, but there are more uses for your hardware than just games I would hope.

Although judgeing by the driver release notes, game certainly figure prominently.

ATI !!! anybody out there ?

[This message has been edited by heath (edited 02-11-2003).]

4

Originally posted by Ribeye:
[b]…does not have a width divisible by 64, I get a very strange shearing type effect.

…with its default pbuffer width of 256, when I changed this to 266 for example, the same shearing effect appeared.
[/b]

What about 128 or 512? Or 32, or 16? Do they all work? (ie. Base 2)

Are you taking the image from the pbuffer and feeding it into a texture? If so what function call are you using?

5

No, They don’t all work. On a mobility Radeon, with the newest IBM driver it appeared to be a multiple of 128.

I cannot emphasize enough however that the problem is not just constrained to my initial description, there are also other random artifacts that occur, too numerous to mention.

What I suggest is (If you have a Radeon) download and build the NVIDIA simple_pbuffer test from the NVSDK. make the appropriate modification, and you’ll see it for yourself.

Surely all of you Radeon guys, ATI employees included, can reconstruct this simple experiment, and explain why something so simple is not supported on Radeon Cards.

Come on ATI prove me wrong. put the CATALYST crew on it !

6

I just ran a test using a 999x999 pbuffer on 9700/Cat3.1/Win2000 using my own pbuffer implementation and everything worked as expected.

I modified the simple_pbuffer app and did get some strange results. It might be related to ReadPixels or DrawPixels ( I never use these ).

[This message has been edited by PH (edited 02-11-2003).]

7

Thanks for trying it. Intersting effect don’t you think. Hopefully someone from ATI can explain this.

In my app I use texture_rectangle to move the pbuffer contents to a texture and get the exact same behaviour as simple_pbuffer. And I get this behaviour on 7000(cat 3.0 and 3.1), 7200 and 7500 mobility chips with lastest IBM drivers.

8

Just send a sample + explanation to devrel@ati.com

9

I have not seen a general pbuffer issue like this. I do know we fixed a readpixels issue with pbuffers, a while ago. If that is the issue, then it should be fixed in the next release. As mentioned by Hummus, mail devrel@ati.com with the issue.

-Evan

10

I sent the report a week ago to the CATALYST crew. I told them to try the simple_pbuffer test from NVIDIA.

I also think ATI should seriously consider beafing up their develper relations website, Its not a patch on NVIDIAS. There should at least be examples which exercise almost every single opengl function/extension that they support. They could probable cover the entire API in 20-30 sample programs.