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!