-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. > 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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iEYEARECAAYFAlMD8OkACgkQX1gOwKyEAw8ydACdHNTvvoXIOopWkrkd0qGZIqqs YCUAnjZ9Qs4T5c3CRZTJ+P2DCxY0jIyy =rRSY -----END PGP SIGNATURE----- _______________________________________________ Piglit mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/piglit
