Roger, thanks very much for pointing out this issue.
The test is definitely buggy. The tests which check that an
INVALID_OPERATION error is generated are passing by luck. They are
supposed to pass because of argument validation, but instead they're
passing because no texture is bound, which also generates an
INVALID_OPERATION error. The tests aren't supposed to verify the
behavior if two errors might be generated, only one. This is an
embarrassingly longstanding bug.
I've just merged a pull request which fixes this in the top-of-tree
. Can you confirm that this test works on your implementation now? If
so, we can merge this fix back to the earlier conformance suites.
Note that the exception-throwing tests should probably be working on
all implementations. The type conversions are conceptually supposed to
be done during the call, before the implementation of texImage2D or
texSubImage2D is reached. In fact, some of those tests should probably
be run both with a texture bound and without.
On Fri, Feb 6, 2015 at 12:52 PM, Roger Fong <email@example.com> wrote:
> Hello again folks,
> I have a question about TexSubImage2D and more specifically about the
> implications of this test:
> For starters, there is a setup() function in this test, but stepping into
> the code, it never ever gets called.
> This seems like a problem, as the test still seems to expect that
> texSubImage2D calls should fail, not because there is no bound texture to
> write over, but because of invalid data issues.
> Does this imply that texSubImage2D should fail due to invalid data types
> even before checking for whether or not a texture is actually bound? Or is
> the test just faulty?