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

[Kenneth Graunke]

On 02/18/2014 03:46 PM, Ian Romanick wrote:
> On 02/16/2014 03:31 PM, Kenneth Graunke wrote:
>> 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.
> 
> That's a really good suggestion.  Doing a glTexImage2D with NULL
> pixels followed by a glTexSubImage2D of a single pixel in the middle
> of the texture should do the trick.

Ah, the subsequent TexSubImage2D trick is pretty clever.  That way the
driver will actually create the storage...

--Ken

-------------- 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/20140218/3f12e919/attachment-0001.pgp>