Hi there,

I got a problem with sampling a texture in shaders with filter set to linear.

I have a texture which was rendered by previous passes and it contains data I needed in next pass. The texture format is A8R8G8B8 and it's in Default pool.

To sample this texture to get the data in shader, I created a sampler with MipFilter, MagFilter and MinFilter all set to Linear since I need some "smooth" fill effects. It works pretty well in one of my machine with GeForce 8600 video card, however when I run the same program in a machine with GeForce 6200 card, the result is really bad. The texture looks not smooth.

I was wondering if the linear filter doesn't work because of the device capability, so I changed the filter to Point and the result is discrete and worse than linear. So it looks linear interpolation did work, however I can't find a clue about why it looks different with different cards.

Anyone has any ideas on this kind of problems? If this is a device capability issue, can anyone point to me what kind of capabilities can affect the linear interpolation result?

Thanks!

Any GPU should be able to filter A8R8G8B8.  The problem might be that you have MipFilter set to linear....your render target won't have mip-maps unless you tell it to generate them.  Try setting MipFilter to NONE, and see if that changes anything.

Also you may want to try running your code with the reference rasterizer.  If this is a driver-related issue, the REF device will tell you which driver is behaving correctly.

Sometimes there is a control panel applet that let's the user choose device settings that override those of the application.  Did you check to see that texture filtering is set to application preference in the driver control panel for the problematic display?  Otherwise, as MJP says it should be filtering this no problem.

MJP:

Any GPU should be able to filter A8R8G8B8.  The problem might be that you have MipFilter set to linear....your render target won't have mip-maps unless you tell it to generate them.  Try setting MipFilter to NONE, and see if that changes anything.

Also you may want to try running your code with the reference rasterizer.  If this is a driver-related issue, the REF device will tell you which driver is behaving correctly.

Thanks for the reply. :)

Set MipFilter to NONE doesn't help. Actually I don't want any mip-maps generated for this texture. The strange thing is, linear filtering works well on other textures. Only difference is that the problematic texture was act as render target and it's in Default pool.

 

legalize:

Sometimes there is a control panel applet that let's the user choose device settings that override those of the application.  Did you check to see that texture filtering is set to application preference in the driver control panel for the problematic display?  Otherwise, as MJP says it should be filtering this no problem.

Yes the texture filtering in driver control panel has been set to application preference. I tried to override it to use maximum Quality and it doesn't help. As I said, for other textures in my application the filtering works well.

Anyway, thanks for the suggestions.

OK, let's step back a bit then and ask some basic questions:

• Debug runtime selected?
• All HRESULTs checked for success?
• No weird messages in the debug output?
• Are you trying to use the same texture as a source and as a destination? (You mentioned this was a render target texture.)

 

• Debug runtime selected?

           Yes. 

• All HRESULTs checked for success?

           Yes.

• No weird messages in the debug output?

           Didn't see any weired messages.

• Are you trying to use the same texture as a source and as a destination? (You mentioned this was a render target texture.)

          Yes. The texture was used as render target and then as a parameter in another draw loop.

RickyMaxc:

Are you trying to use the same texture as a source and as a destination? (You mentioned this was a render target texture.)

          Yes. The texture was used as render target and then as a parameter in another draw loop.

I'm surprised you didn't get whining from the debug runtime about this; you can't simultaneously use the same texture as a render target and as a texture on primitives being rendered into that same render target.  You have to render to a separate render target and then use it as a texture next time you draw.

legalize:

RickyMaxc:

Are you trying to use the same texture as a source and as a destination? (You mentioned this was a render target texture.)

          Yes. The texture was used as render target and then as a parameter in another draw loop.

I'm surprised you didn't get whining from the debug runtime about this; you can't simultaneously use the same texture as a render target and as a texture on primitives being rendered into that same render target.  You have to render to a separate render target and then use it as a texture next time you draw.

Hmm, sorry for the misunderstanding here.

Of course we can't use the same texture as render target and a parameter. In my application, the render target was set to other surface in next draw loop. As I said, all the things work well on one of my machines but break on another. I'm thinking this may be related some device caps, however I don't have a clue about what capabilities can lead to this issue.

It sounds like we haven't gotten down to the root cause of the problem yet.  I'd do "divide and conquer" and try to write the simplest program that can reproduce the differing behavior on the two graphics cards.  For instance, see if you can use the NVidia effects browser to see if you can quickly come up with an effect/technique the reproduces the problem.  Then take away as much as possible from the state you're setting to find the minimal amount needed to reproduce the problem.