Hi, I believe ATI Radeon 4800s drivers have problems with sampler objects.
For example if you have a texture bound to unit 2, and also a sampler object bound to unit 2, its states will not be used for the texture. Also if at the same time you have a sampler object bound to unit 0, it will use their states instead.
I’ve attached the source code to a test I made, it requires the glew library, I used the latest version 1.5.7. Also it’s setup to run in windows only. The program doesn’t require any resources (e.g. texture is generated using a framebuffer object, and shaders are stored in strings).
You can see that the sampler states are not being used if the wrap_s and wrap_t aren’t using the clamp_to_edge (aka a single image at the bottom left) and instead are using the default repeat (aka the image tiled across the screen).
I’ve tested the program with a ATI Radeon 4850 (using latest drivers) and 4890, which both failed the test, also I had someone else try with a nVidia 8600 M, which passed the test.
I wasn’t sure where to post this problem, but this seemed like the best place.
Here’s another link to the source code, I can’t seem to be able to access the attachment.
I think it’s a misunderstanding. Pierre is our fellow and he will assign the bug to others. But it doesn’t mean all developers know there exists such a bug. For the person who manages the bug data base, he knows the two bugs are actually the same.
I will ask for the status of the issue after the holiday.
Frank, I am sorry but I agree with Chris on the regard that it seems something is wrong at AMD with the bug report management. I report bugs on sampler object and uniform buffer months ago (3 / 6 months) and I am bit surprised to receive now a mail to confirm a bug that I already confirm remain.
I am happy with AMD concerns for making more stable drivers but I guess something could be better regarding the bug reports management.
I tested this with someone’s quick test. At first I also got black screen, but the texture had only 1st mipmap, and the sampler parameters for texture filtering wasn’t never set. I can confirm it now reads the sampler parameters from the correct texture unit -checked with few simple demos.
ARB_debug_output supports which works fine, apparently exactly the way is works on nVidia which means under debug context only and without asynchronous support but the specification doesn’t really state about when the messages are retrieved (as far as I know) so that’s fine.