[0.9.8][cube] LINUX Problem with Factorio crashing!

[Blackence]

I've set some debug environment variables and now I get some additional log info:

Code: Select all

radeon: Failed to allocate a buffer:
radeon:    size      : 402653184 bytes
radeon:    alignment : 65536 bytes
radeon:    domains   : 4
radeon: Failed to allocate a buffer:
radeon:    size      : 402653184 bytes
radeon:    alignment : 65536 bytes
radeon:    domains   : 4
-> Mesa: User error: GL_OUT_OF_MEMORY in glTexImage <-
-> Mesa: User error: GL_OUT_OF_MEMORY in glTexImage2D <-
Couldn't create atlas bitmap (size 16384X6028).
Probably not enough video memory.
Turning low graphics options on, please restart the game.

This apparently confirms the "probably not enough video memory" message.
So maybe my GPU supports 16k * 16k technically, however there's not enough VRAM left to store the texture?

[cube]

Yes, it could also be caused by VRAM fragmentation ... who knows how exactly the allocator works.

[Algram]

I can't really tell if this is a driver bug, but i now for a fact, that OpenGL does the right thing here.
You can not ask how much VideoMem there is, because OpenGl doesnt know that.

I'm assuming it is a bug in Mesa, Steam has the same issue for example if you try to go into "Big Picture Mode", because it thinsk you dont have enough Memory (;

[sergei_chizhov]

Cool Game, but i have same problem
---
libpng warning: iCCP: known incorrect sRGB profile
radeon: Failed to allocate a buffer:
radeon: size : 402653184 bytes
radeon: alignment : 65536 bytes
radeon: domains : 4
radeon: Failed to allocate a buffer:
radeon: size : 402653184 bytes
radeon: alignment : 65536 bytes
radeon: domains : 4
Couldn't create atlas bitmap (size 16384X6031).
Probably not enough video memory.
----
i7-2600 / 24GB RAM
radeon hd6970 (2GB VRAM) open driver
Linux home1 3.11.10-11-desktop #1 SMP PREEMPT Mon May 12 13:37:06 UTC 2014 (3d22b5f) x86_64 x86_64 x86_64 GNU/Linux
OpenSuse 13.1 x86_64, latest updates

[Blackence]

I noticed dmesg clearly states the reason for this failure in my case:

Code: Select all

[  552.003518] radeon_gem_object_create:62 alloc size 384Mb bigger than 256Mb limit

I don't know why that 256Mb limit is there. Using the error message I found a mesa bug report about this. Someone suggested to lower the max. texture size to 8k*8k because with a 16k*16k texture, radeon fails to allocate a buffer that is large enough to store the texture.

However, that suggestion was rejected because some texture formats are small enough to fit into 256Mb even with a size of 16k*16k. Instead, applications should use Texture Proxies (see 21.130) to check if their texture format/size combo is supported.

Is the correct place to add this in allegro or factorio (or both)? (Also, according to the OpenGL FAQ, it's a driver bug AFAICT because it should fall back to software rendering instead of returning GL_OUT_OF_MEMORY?)

[cube]

I noticed dmesg clearly states the reason for this failure in my case:

Code: Select all

[  552.003518] radeon_gem_object_create:62 alloc size 384Mb bigger than 256Mb limit

I don't know why that 256Mb limit is there. Using the error message I found a mesa bug report about this. Someone suggested to lower the max. texture size to 8k*8k because with a 16k*16k texture, radeon fails to allocate a buffer that is large enough to store the texture.

However, that suggestion was rejected because some texture formats are small enough to fit into 256Mb even with a size of 16k*16k. Instead, applications should use Texture Proxies (see 21.130) to check if their texture format/size combo is supported.

Is the correct place to add this in allegro or factorio (or both)? (Also, according to the OpenGL FAQ, it's a driver bug AFAICT because it should fall back to software rendering instead of returning GL_OUT_OF_MEMORY?)

Thanks for the info. In fact I had an idea to progressively try allocate smaler and smaller texture sizes, so in this case we would succeed at second step with 8k by 8k. This would slow down startup of Factorio a little, but IMO not significantly.
This could fix the problem relatively simply and maybe also some other issues on mac.

What I'm afraid of now is that one day they will fix this bug and we will be getting large textures without hw acceleration.

[Blackence]

What I'm afraid of now is that one day they will fix this bug and we will be getting large textures without hw acceleration.

Even if the bug gets fixed, you should still be able to query for hardware acceleration support using texture proxies (the FAQ is titled "What's the maximum size texture map my device will render hardware accelerated?" after all ). It's probably faster than trying to buffer the texture data and checking for GL_OUT_OF_MEMORY, too (not sure about that).

[Blackence]

Bad news, the texture proxy stuff does not seem to solve this issue.

I hacked together a simple tool today that queries GL_MAX_TEXTURE_SIZE and then does the proxy texture check to see if the size works. If it doesn't work, it cuts one of the two dimensions in half (alternating between width and height) and tries again.

Using the radeon driver…

Texture size probably used by factorio: 16384. Trying to allocate a texture of that size…
radeon: Failed to allocate a buffer:
radeon: size : 1431656448 bytes
radeon: alignment : 65536 bytes
radeon: domains : 4
radeon: Failed to allocate a buffer:
radeon: size : 1431656448 bytes
radeon: alignment : 65536 bytes
radeon: domains : 4
Error while trying to buffer texture data: out of memory

Now using GL_PROXY_TEXTURE_2D to find a working texture size…
Testing 16384 * 16384… Queried width of texture proxy: 16384
Found working texture size: 16384 * 16384. Trying to allocate a texture of that size…
radeon: Failed to allocate a buffer:
radeon: size : 1431656448 bytes
radeon: alignment : 65536 bytes
radeon: domains : 4
radeon: Failed to allocate a buffer:
radeon: size : 1431656448 bytes
radeon: alignment : 65536 bytes
radeon: domains : 4
Unexpected error while trying to buffer texture data: out of memory

So the texture proxy check actually claims that 16384*16384 is okay, even though that fails when trying to really allocate the texture.

So in order to fix this, cube's solution with checking for GL_OUT_OF_MEMORY is probably required. Or maybe this is a mesa bug and proxy textures should check with the allocator to see if it's possible to allocate the chunk of memory required for the texture.

Edit: After talking to someone who knows more about the radeon driver than anyone in this thread (I guess!), it seems like the correct solution is to check for GL_OUT_OF_MEMORY. The texture proxy feature is not meant to check for out of memory conditions and Mesa can't do the check easily because the 256MB limit is only known to the kernel. (Maybe you still want to do the check though, it could prevent software rendering fallbacks?)

[cube]

Good news! In 0.10.2 we will have the adaptive atlas allocation thingie. This means that we start with the texture size reported by allegro (= opengl / directx) and if this fails, we repeatedly try 4 times smaller texture, until it succeeds or we get under 1024x1024. Time spent on this is not noticible even when starting at very large textures

Moving this topic to resolved for next release.

[Colombo]

Could this solve intelHD problems as well?

[cube]

Unlikely. The only place this will help is when factorio reports not enough vram.

[Blackence]

Cool, thanks for the quick fix!

[Algram]

If this works I'll be so happy!!!
Thanks for working on this bug guys! You are awesome!

[MF-]

Unlikely. The only place this will help is when factorio reports not enough vram.

:sad_face:
I guess it would be too complex to hack in really-supported size detection by reading the corners of the texture back?
EDIT: Or an override for those texture dimensions available in the config file?

I'm glad that at least both radeon and nvidia owners can play of course!

[Blackence]

A config override might be a nice way to test if smaller textures solve the intel issues (and similar issues on other platforms?). For the average joe, a better solution is required I guess…

Have you tested if reading the corners of textures back correctly identifies texture issues using a simple test program? (It seems like a very dirty hack, the driver should report issues instead of ignoring them. If reading back really finds discrepancies, it should be reported to the mesa bug tracker.) If so, the chances of this workaround being added to factorio are probably better. I'll post to the Intel thread about some new debug ideas.

[MF-]

A config override might be a nice way to test if smaller textures solve the intel issues (and similar issues on other platforms?). For the average joe, a better solution is required I guess…

Have you tested if reading the corners of textures back correctly identifies texture issues using a simple test program? (It seems like a very dirty hack, the driver should report issues instead of ignoring them. If reading back really finds discrepancies, it should be reported to the mesa bug tracker.) If so, the chances of this workaround being added to factorio are probably better. I'll post to the Intel thread about some new debug ideas.

Sure, if such override proves to be helpful, a better solution might be considered.

Sorry, I have no GL experience, don't know how to do that.

Hunting down bugs instead of masking them is OFC better.

[Algram]

With the 10.2 build, I cant even start Factorio, it just completely freezes my PC

[cube]

Config setting: good idea, I'll add it for 0.10.3

@Algram: I started a new bug reports thread here: https://forums.factorio.com/forum/vie ... f=7&t=4730
Please post there the content of ~/.factorio/factorio-current.log , what distribution you are using and what video card you have.
Also useful might be a result of

Code: Select all

strace ./factorio 2> ~/factorio-strace.txt