Frag Shader NPOT Texture2D Sampling Corruption / Bug on Nvidia GPUs Only

I have a shader asset that uses texture bombing techniques in order to render tile maps on a single quad, and it works as expected on my work computer's GPU which happens to be the RX 590. I have also tested this same shader with success on other AMD GPUs, including a R9 390 and a very old Radeon HD5850. Below is the expected result of this shader, a correctly rendered isometric tile map :

​

​

Note that even though it looks isometric, what you are seeing are actually rectangular sprites added on two interlaced "grids" in the fragment shader. The sprites are being sampled from a Texture Array using the 32 bit pixel color value of the tile map data containing texture and turns it into a 32 bit unsigned integer value, which is the index of a particular tile type's sprite in the texture array.

As you can see in the video not only can the data be correctly rendered, the function Graphics.CopyTexture is also used in order to quickly edit parts of the Texture containing the tile map by pasting a small edit buffer texture over the full tile map texture. This also works as expected on my own GPU.

Now, here is the resulting behavior on a few Nvidia GPUs ( so far I know the GTX 980M and 970M have this bug ). Basically, the tile map has visible data corruption / sample errors. This screenshot is from a WebGL build ( which you can test here ).

​

It appears to bug too on a standalone Windows 64 build. ( Download Link Here for those who want to test ). In the below image I'm trying to edit the map and only some tiles, those that are not bugged, can be edited. It appears as if some pixels of the tile map cannot be correctly sampled.

​

Here I'm trying to draw tiles / pixels in a transparent part of the map / texture and you can clearly see how some tiles simply refuse to either be edited or, as I'm assuming is the issue, sampled.

​

If this was not weird enough already, I also noticed that most of the texture simply cannot be edited at all even on portions that appear to render the correct data. In fact, only 3 columns of increasing size can be edited on the texture using Graphics.CopyTexture.

​

I have a RenderDoc capture that contains a disassembly of the shader and all the information someone who knows what they are looking at should need to tell me exactly what is going on, but I'm going to wait to see if a graphics wizard that has the skill and will to help me out responds to this thread before I post it.

After looking for a while, I believe the main culprit for this weirdness is the fact that the tile map texture is a NON POWER OF TWO sized texture of 4100 x 8192. If I turn down the width of the tile map texture to the nearest power of two, being 4096, both the rendering and edit copy is working exactly as expected. Note that the created texture has point filtering and clamp warp mode so it seems unrelated to any texture setting other than the size. Also worth noting is the fact that RenderDoc shows the texture resource as correctly sized and filled with the expected data so there doesn't appear to be any GPU sided resizing or compression happening.

Given how basically every single piece of documentation I have read on the subject says that NPOT textures are capable of being handled by the GPUs in question I'm extremely confused as to why this is happening. I'm guessing there is a difference in NPOT texture handling which causes the Nvidia GPUs to have problems with it comes to sampling those textures. While I'm most likely going to fix this by adding a sort of compatibility mode that forces power of two map sizes for users who have problematic devices, I would love to know why this is happening and how I can make sure that NPOT textures are correctly sampled on these devices, if that's possible.

So if anyone has any idea why this is going on, I'd love to hear it and thanks in advance to anyone willing to help me out!

 

You should probably filed a bug

 

Yeah that's a good idea and probably what I'm going to end up doing as soon as I'm sure this isn't a case of me doing something wrong. I'm pretty sure this is out of my control and down to the way shaders are being compiled but my knowledge of this topic is quite limited so I can't be certain.

 

I've filed a bug report a few days ago using this minimal problem reproduction project. I've removed pretty much all of my asset code and got it down to the core isometric grid rendering. When working properly the project should render an isometric checker pattern like this :

​

Below is the bugged result on Nvidia hardware :

​

And finally here is the result using my workaround for Nvidia, using power of two value for texture size :

​

If anyone wants to try it out for themselves and see if the issue occurs on their hardware, here are the steps to reproduce the buggy behavior :

1: Extract file ReproProject.zip and open project in Editor using Nvidia or AMD GPU
2: Open included scene file
3: Make sure "Reproscript" component value "Width" on object "Quad" is set to 65 (Or any NPOT value)
4: Hit play to see result (should work on AMD but not Nvidia) then exit play mode
5: Set "Reproscript" component value "Width" on object "Quad" to 64 (Or any power of two value)
6: Hit play to see result (should work on both AMD and Nvidia)
7: Repeat 1 to 6 for different hardware to compare results

 

How long is the delay before you get a reply on a bug report? I have sent this report on the 12th of February and so far have not received anything in response, not even an acknowledgement or demand for more information. Is this normal or did something happen to my bug report?

 

I have just received a response on my bug report: apparently this is caused by NVidia drivers and not related to anything Unity is doing. Not much else anyone can do beside asking around on NVidia forums, which I'll be doing and reporting back with any extra information or hopefully even a permanent fix or workaround allowing NPOT textures.