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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Piglit mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/piglit
