[Piglit] [PATCH] max-texture-size: test non-proxy targets with max size from proxy test

[Kenneth Graunke]

On 02/11/2014 07:59 AM, Brian Paul wrote:
> On 02/10/2014 07:49 PM, Ian Romanick wrote:
>> On 02/07/2014 03:34 PM, Brian Paul wrote:
>>> Save the max texture size found with the proxy targets.  Then use
>>> that max size when we test the regular/non-proxy targets with
>>> glTexImage and glTexSubImage().
>>>
>>> The whole point of proxy textures is to be able to probe the maximum
>>> texture size.  So let's use that size when we try the real textures.
>>> That's what an application would typically do.

Right now, the proxy cases are split out as separate subtests...but they
don't really test much...just that you don't get a GL error.  I suppose
they could also check that the value obtained via proxy textures is <=
the advertised maximum.  Not sure how valuable that would be.

But maybe we should drop the "test" aspect of the proxy texture code and
just use it as a mechanism to figure out what size to try in the "real"
tests...

>>> As it was, most of the GL_TEXTURE_3D tests were returning 'skip'
>>> results because we couldn't allocate a 2048^3 or 1024^3 texture.
>>> Now we should get pass/fail/crash when we try creating an N^3
>>> texture when OpenGL told us that N should work.
>>
>> Which hardware, if any, have you tried this on?  Any closed source
>> drivers?
> 
> Yes, NVIDIA's driver.  The test behaves the same way before and after
> this change.  NVIDIA's proxy texture tests always pass for the max
> advertised texture size.  Ex: it happily says a 2048^3 x RGBA32F 3D
> texture is doable.  But then our call to calloc() fails the test just
> reports 'skip'.

I'm not clear whether we actually want to calloc data to pass to
TexImage.  It seems like passing NULL ought to be sufficient, since the
driver should still allocate storage for it (so it could be populated
via rendering)...but maybe that could be deferred.

It seems like calloc'ing a huge amount of data just increases the
likelihood of GL_OUT_OF_MEMORY errors....

> But I've also found that this test (NVIDIA) is sensitive to whatever
> else might be running.  In my first run I also had several VMs running
> on my system (using a fair amount of RAM and VRAM) and max-texture-size
> hung my system when it was testing a 16384 RGBA32F cube map.
> 
> I'm curious what AMD's driver does.
> 
> -Brian

Whatever you want to do here is probably fine.  I was mostly working on
it because I needed to raise our driver's limit to make an application
work, and discovered there was no way I could pass the piglit test as
written...even though there wasn't a bug in my driver.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/piglit/attachments/20140216/3ea0e371/attachment.pgp>