How do I query the maximum allowable texture size?

1
I'm programming an experiment where we're using images that are much larger than the screen. The subject can click on a scaled-down overview map to zoom in on various parts of the image.

The problem is that the images are also too large to make textures on some computers. I'm using an Intel Core i7 iMac with 512MB of VRAM. When I try to turn the image (8466 x 3855 pixels) into a texture, I get the following error message:

PTB-ERROR: Texture creation failed or malfunctioned for a texture of requested size w x h = 3948 x 8480 texels
PTB-ERROR: and at least 4 bytes VRAM memory consumption per texel.
PTB-ERROR: Your image or texture exceeds the maximum width and/or height of 8192 texels supported by your graphics hardware.
PTB-ERROR: You'll have to either reduce the size of your images below that limit, or upgrade your hardware.

The machines we plan on using for testing have even less VRAM.

My solution is just to break up the image into tiles. But I would like some way of querying, within the program, what the maximum texture size would be (e.g., 8192 in this case) so I know when to engage in a tiling strategy, and when I can just pull out part of the array into a single texture.

I'm assuming there's some OpenGL command that will do this (I use glGetIntegerv for querying the maximum point size for DrawDots, for example), but I can't figure it out from the online OpenGL reference.

thanks
Todd
2
Thanks Mario, that's very helpful!

I will certainly upload a demo if I can solve this problem.

thanks
Todd


--- In psychtoolbox@yahoogroups.com, "Mario" <mario.kleiner@...> wrote:
>
>
>
> --- In psychtoolbox@yahoogroups.com, "todd_horowitz" <toddh@> wrote:
> >
> > I'm programming an experiment where we're using images that are much larger than the screen. The subject can click on a scaled-down overview map to zoom in on various parts of the image.
> >
> > The problem is that the images are also too large to make textures on some computers. I'm using an Intel Core i7 iMac with 512MB of VRAM. When I try to turn the image (8466 x 3855 pixels) into a texture, I get the following error message:
> >
> > PTB-ERROR: Texture creation failed or malfunctioned for a texture of requested size w x h = 3948 x 8480 texels
> > PTB-ERROR: and at least 4 bytes VRAM memory consumption per texel.
> > PTB-ERROR: Your image or texture exceeds the maximum width and/or height of 8192 texels supported by your graphics hardware.
> > PTB-ERROR: You'll have to either reduce the size of your images below that limit, or upgrade your hardware.
> >
> > The machines we plan on using for testing have even less VRAM.
> >
> > My solution is just to break up the image into tiles. But I would like some way of querying, within the program, what the maximum texture size would be (e.g., 8192 in this case) so I know when to engage in a tiling strategy, and when I can just pull out part of the array into a single texture.
> >
>
> Yes, tiling is the way to solve this.
>
> > I'm assuming there's some OpenGL command that will do this (I use glGetIntegerv for querying the maximum point size for DrawDots, for example), but I can't figure it out from the online OpenGL reference.
> >
>
> A call to InitializeMatlabOpenGL([],[],1); enables OpenGL support for pure 2D drawing -- Not needed if you used InitializeMatlabOpenGL already beforehand in your script somewhere, e.g., because you use 3D graphics or PsychImaging() which implies that.
>
> Then once the onscreen window is open:
> maxsize = glGetIntegerv(GL.MAX_RECTANGLE_TEXTURE_SIZE_EXT);
>
> However, this is a theoretical limit, the maximum the hardware+driver+os can support if there is a sufficient amount of free VRAM + system RAM. Some typical limits of common cards - not always guaranteed.
>
> OpenGL4/Direct3D-11: 16384 on high-end cards.
> OpenGL3/Direct3D-10: 8192
> OpenGL2/Direct3D-9: Typically between 2048 and 4096.
> Prehistoric hardware: <= 1024
>
> In practice, textures of your type will use width * height * 4 Bytes of memory and you can run into trouble for a total size smaller than the VRAM installed, e.g., already for maybe half its size or just a quarter its size. Your example would consumer 128 MB VRAM and possibly additionally 128 MB of Matlab's address space or at least of system RAM. If you use multiple textures/offscreen windows/GUI windows in parallel to ptb, the VRAM of the graphics card can get fragmented, similar to what sometimes happens to Matlab's memory, so big textures would not fit into VRAM even if they are smaller than VRAM - they don't fit in one piece. Because the (V)RAM consumption is not taken into account by the query, the only way to reliably know if a texture fits is to try to create it and see if it succeeds or fails.
>
> So be rather conservative and err on the side of using tiling and using small tiles, probably not more than 4k x 4k pixels in size on your machine which would theoretically allow for 8x x 8k, maybe even smaller tiles. Small tiles allow the gfx-driver to shuffle around fragmented memory limitations more reliably and be generally more clever in its allocation strategies.
>
> The other thing with your zoom-in idea: If you want to zoom into a small subregion (or [srcrect]) of your large texture, then the standard bilinear texture filtering may not be good enough quality-wise. You can solve that with trilinear texture filtering. This means specifying the optional 'filterMode' flag in Screen('DrawTexture') == 3. It also means you need to create a so called mip-map texture, something not built into Screen('MakeTexture'). See lines 90-137 of ShepardZoomDemo.m for a way to do this with power-of-two sized textures.
>
> In trilinear mode, the system builds a resolution pyramid (a "mipmap texture") of your original image - the image downfiltered/downscaled to different sizes. Then during drawing it selects the proper level of detail from the pyramid for a given "zoom" or even interpolates linearly between different resolution levels of the pyramid, not only between texels within a level of the pyramid.
>
> If you manage this, i think some nice demo on how to do this tiling/zooming would be a useful addition to our set of demos.
>
> thanks,
> -mario
>