GameMaker What determines max texture page size on a system?

[galewolf]

Whenever the topic of texture page sizes comes up, there's a vague "if you use bigger texture page sizes, it might not be supported" answer given out.
Even the manual says this: "Note that the maximum size of a texture page will depend on the chosen export platform, as some targets will not permit pages larger than 2048x2048px, and even then, the maximum available size may not be optimal for all the devices that use the target platform OS."

But no one actually says what component of the system determines the max size of the image it supports. Is it the GPU? Where can I find out the size that a GPU supports?

Having a vague answer to this question isn't really good enough, because if someone has an incompatible system, they just won't be able to play the game at all. So finding out the answer to this question is important.

 

[Cameron]

Memory/Ram. 2048 is typically like android/mobile devices (In terms of size limitations).
If you are releasing for PC then you can go twice or even four times that if you want to.
The reason it seems vague is because it's case dependent. A lot depends on the target system and even the game type of what is the optimal decision.
For example, if the game is low-res pixel art then you really have no reason to go with bigger texture pages.
Main reason for going with larger texture pages is high-resolution games and/or games with very large images.

 

[O.Stogden]

Some devices will outright refuse to work with some larger texture pages as well.

Older Android devices from 2013-2015 or so generally won't output texture pages that are 4096x4096 or above. You'll just get a garbled mess. That is potentially due to not being able to fit the entire page in the RAM though.

Windows devices will generally handle anything, even ones with integrated graphics, I couldn't comment on other platforms.

 

[galewolf]

Thanks for replies, but I seem to have not communicated accurately.
I am aware that some devices will outright refuse to work with larger texture pages, that's why I'm asking the question:

What, on the device, determines the maximum size of texture page? Is it the CPU, or is it the GPU? Or something else? What do I need to google to find this out for a specific component, like Intel HD Graphics 4000 or a GTX 1080 for example. I can find out the VRAM it supports easily. I do not see anything about a max texture page size.

Cameron said it's the RAM, but I don't think that's likely? If the texture page is 2048x2048 RGBA and has 4 bytes for each pixel, that's like 16.7 megabytes for one texture page. So having 2048MB of RAM doesn't seem like a limit there. Besides, I would think you can open a 4096x4096 image on any smartphone in a web browser. I've certainly never had an issue doing that.

 

[O.Stogden]

That depends entirely on how many texture pages you have I think...

A discrete card will probably run any texture page size, as they don't sell them with less than 4GB nowadays, and most games require at least 2GB, which should hold anything.

An integrated card varies wildly, as they usually have 0MB of memory themselves, they use whatever RAM people put in their laptops/desktops for the CPU, and share that. So there is no fixed amount of memory for an Intel/AMD integrated GPU.

I don't think it's strictly RAM, I think the age has something to do with it, but I'm not sure what exactly determines whether it can or not, likely internally there's a maximum size the GPU can handle per texture, or something like that.

Usually I'd just stick with 2048x2048 on Android and 4096x4096 on Windows, they're pretty safe sizes, and there shouldn't be much of a need to go beyond those sizes.

EDIT: Looking at sites such as Stackoverflow regarding 3D textures and what size GPU's can support, they basically that it's a "test and see" thing, and you can't truly predict what GPU will support what texture size, it's dependant on other variables such as what else the PC is doing at the time, and how the GPU is handling memory allocation etc. I'm not sure you'll get a definitive answer to this, as it appears there isn't one.

All I know is that 4096x4096 texture pages won't work on a couple of old Android devices I have from 2014 and 2015, however it does work on my 2018 Android phone. So you could use 4096x4096 for Android and get away with it these days.

Hardware answers are difficult, as there's literally hundreds of configurations, it would be difficult to say specifically that "this config will work on this texture page", because if they change one thing, it might not anymore.

 

[galewolf]

Thanks. Yeah I know the limit is theoretical, because you'll be using other applications which use VRAM at the time, but to pick an option I still need a rough idea of what it will do.

From what others have posted, my guess is it seems like the limit is integrated graphics/mobile devices, since they don't have dedicated VRAM they use RAM as VRAM. But like you said, there might be some kind of limit on how much they use.

But I don't know and I'd like a firm answer as to how the limit is determined. I know there'll be hundreds of configurations, and I'll test my game on as many machines as I can, but I still need have some idea of how the limit is determined so I can pick a sensible default.

 

[Murzy]

Based on our experiences, if you don't run into performance issues with 2048x2048, then stick with it.

On platforms where there is a lot of fragmentation in hardware (basically anything else than iOS and consoles) you'll always have the odd user that is running your game on a 10-year-old potato, and files a bug report for the game not running

Like said above, the main problem is that the bigger texture pages take a lot of video memory, as the texture page is stored in uncompressed format in the GPU VRAM. Older hardware can have very limited amounts of this (think 256MB or 512MB), so where a couple of 2048x2048 => 16MB texture pages can fit alongside other things that are consuming it already, and the game runs normally – it is a totally different story when the texture pages are bigger, for example 4096x4096, i.e. 64MB a piece.

If the texture pages cannot be loaded, so the game will just crash, so it is better to be safe than sorry and just use the smaller texture pages. Although, if you are running into performance issues with the amount of texture swaps with smaller pages, then this becomes a question if you want to even support the older devices at all...

 

[Cameron]

The main reason to use larger texture pages is if images are larger than your current texture pages and they are being downscaled affecting image quality. Like if you have texture pages at 2048x2048 and an image larger than that, then the compiler will downscale the image to fit it on the texture page and that will lower the quality/resolution of the image.
So you have to ask yourself what your largest image is going to be and use a texture page that will fit it. If that's too big for a target device then you have to either have minimum required specs or be willing to lower the quality of the image.

CPU doesn't have anything to do with the texture pages, that's all gpu and vram limitations.
Again, what's your target platform? Is it PC? If so then you really don't have to worry about it. What's the resolution/size of your images? Are they small or reasonable? You really don't have to worry about it. If they are massive and you targeting mobile devices then you will have to accept the fact that the resolution will be lowered.

 

[gnysek]

2048x2048 => 16MB (...) 4096x4096, i.e. 64MB

That's interesting, cause theoretically, if you have 32 2048x2048 textures, which are taking 512 MB, same game should fit on 8 4096x4096 textures, which also takes 512MB. Bigger textures sounds like they would require less texture swaps, so they will be faster.
So, except of lack of support for 4K texture pages on some device, I see no issues with using them until you fill whole 8 pages. Not fitting on them might mean that game also won't fit on 2K textures to not exceed 512 MB. Generally, game can have even more texture pages if it's not using them all at once on each game level (if your game have different worlds for example, put each world on different texture page - common sprites can be put either on separate page, or duplicated on few pages).
The only issue I see here is when you need to draw 10 sprites from 10 different 4K textures, while not passing 512 MB of VRAM - in that case 2K textures would be safer.

Remember, that while GMS is packing textures to PNG files, GPU is unpacking them and uses them like uncompressed BMP (or just RGBA) file - that's why 2K texture uses 16 MB, while PNG files can be 1-2MB.

 

[Cameron]

That's interesting, cause theoretically, if you have 32 2048x2048 textures, which are taking 512 MB, same game should fit on 8 4096x4096 textures, which also takes 512MB. Bigger textures sounds like they would require less texture swaps, so they will be faster.
So, except of lack of support for 4K texture pages on some device, I see no issues with using them until you fill whole 8 pages. Not fitting on them might mean that game also won't fit on 2K textures to not exceed 512 MB. Generally, game can have even more texture pages if it's not using them all at once on each game level (if your game have different worlds for example, put each world on different texture page - common sprites can be put either on separate page, or duplicated on few pages).
The only issue I see here is when you need to draw 10 sprites from 10 different 4K textures, while not passing 512 MB of VRAM - in that case 2K textures would be safer.

Remember, that while GMS is packing textures to PNG files, GPU is unpacking them and uses them like uncompressed BMP (or just RGBA) file - that's why 2K texture uses 16 MB, while PNG files can be 1-2MB.

Have you ever tested optimizing texture swaps? In my experience it's a micro-optimization at best and if your game is hypothetically chugging there are way better places of optimization, such as draw code or expensive logic. This could be system and/or game context specific but the work I've done in optimization the texture swaps made little difference even when doing many texture swaps. For me the bottle neck have always been too many draw functions, too much/many expensive shader/effect use, lots of heavy game logic such as large expensive loops, etc., I mean, if someone is worried about texture swaps then by all means use larger texture pages but I've not been convinced that it's a good argument/case to make for using larger texture pages. I maintain that larger images is the only reason you would want or need to use larger texture pages.

Edit: I should make clear that I do think it's wise to assign texture groups so you don't have to load images/texture pages into memory that you don't need.

 

[Murzy]

That's interesting, cause theoretically, if you have 32 2048x2048 textures, which are taking 512 MB, same game should fit on 8 4096x4096 textures, which also takes 512MB. Bigger textures sounds like they would require less texture swaps, so they will be faster.

Yes, theoretically. But I think with graphics cards with lower amounts of memory, we also can run into issues where it is harder to allocate the bigger memory pages in practice. We need to remember that the game is not running in isolation, so there will other things consuming the memory as well. So say, with a 512MB memory, we might run into issues where it is hard to allocate more than just a handful of 64MB continuous chunks of the VRAM, whereas the smaller pieces would fit without problems.

Also, with larger texture pages like these, it's more likely that you run into situations where the game NEEDS to display data from, say, 3 out of the 4 texture pages that the game has. If these won't fit onto the memory, the game will crash – whereas with the smaller pages we could've just swapped the texture pages around so that we can continue running the game.

 

[Ricardo]

Based on my experience, using bigger texture pages to achieve less texture swaps not necessarily translates into better performance (specially on old systems). It's quite the opposite. For some reason old GPUs seem happy to swap between a bunch of small textures, but really struggle when handling big ones. I remember reading that this has something to do with memory bandwidth and cache sizes, but I'm not 100% certain (it was a while ago, I hope I'm not confusing it with other thing).
Anyways, optimizing the GPU batches is by far one of the techniques that has brought me better results so far - and to do it properly the texture pages need to be well organized of course, so keeping texture swaps as low as possible is certainly a good thing.

 

[gnysek]

It might be that if more pixels from 0,0 is, then more it takes to read them because of some operations (like time to read coordinates of sprites in array of sprites).