<div dir="ltr">On 7 January 2013 14:21, Chris Forbes <span dir="ltr"><<a href="mailto:chrisf@ijw.co.nz" target="_blank">chrisf@ijw.co.nz</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
This test actually gets *simpler*, generalized to arbitrary sample<br>
counts. I'll cook something up tonight.<br></blockquote><div><br></div><div>Ok, cool.  While you're looking into that, there are several other ways I think this test needs to be generalized:<br><br></div><div>- We need to test a pixel other than just (32, 32), so that if a bug causes the x and y coordinates to be interpreted incorrectly, we'll catch it.<br>
</div><div>- We need to test texelFetch of multisampled 2D array textures.<br></div><div>- We need to test texelFetch of integer and unsigned integer textures.<br><br></div><div>Rather than writing a new test to do all this, you might want to consider adding multisampled texture capability to the existing file tests/texturing/shaders/texelFetch.c, which is very thorough.  I think the only major difficulty in adapting that test would be to deal with the fact that multisampled textures can't be uploaded using glTexImage2D(), so when testing multisampled textures, you'd need to replace the call to generate_texture() with code that renders to the texture using a shader.<br>
</div></div></div></div>