[Linux w Intel GPU][cube] Most of the graphics missing

Colombo · Post by **Colombo** » Sun Jun 22, 2014 6:38 pm

dmesg | grep drm

drm

lspci

I can't test 10.0 but 9.8 now do the same. Must have been some silent update:( Ill try restart computer, it was sleeping a bit... But all the hope is lost now.

edit: restart did not help:(

Colombo · Post by **Colombo** » Tue Jun 24, 2014 2:55 pm

MF- · Post by **MF-** » Thu Jun 26, 2014 7:53 pm

So.. 0.10.1 works for you again, while the previous versions don't ??

Colombo · Post by **Colombo** » Thu Jun 26, 2014 10:40 pm

MF- wrote:So.. 0.10.1 works for you again, while the previous versions don't ??

Uh? No, 10.1 doesn't work, as well as 9.8. It worked before some silent update from ubuntu.

It is actually funny. I had to ditch Europa Universalis 4 because given 12.04 lack of intel support for IntelHD for such old kernel, terrain didn't rendered at all. But with 14.04, I can play EU4 without problem (only that it runs quite slow, but that may be solely due to poor PC).

But due to that, I can't run factorio after a while (did not happened immediately after 14.04 upgrade).

MF- · Post by **MF-** » Fri Jun 27, 2014 6:05 am

So.. .how is it "sortof solved", then?

Well.. ubuntu is keeping updated packages separately from "base install" versions,
so it's theoretically possible to figure out which package is responsible for your issues.
It could be the kernel driver, X11 driver, or some fancy-effects ubuntu app hogging VRAM (or anything else)

If you were really dedicated into locating the package responsible for the issues, you could downgrade back to 14.04 as released,
check that factorio works, selectively upgrade packages until the factorio breaks again.
Note that ubuntu is probably configured to install security updates (== any updated package that is marked as "carrying a security fix")
Some of the "base" versions thus may contain widely-known critical bugs.

PS: How often do you reboot? Could it be possible that you didn't reboot after the upgrade for a longer period of time?

Colombo · Post by **Colombo** » Fri Jun 27, 2014 6:33 am

MF- wrote:So.. .how is it "sortof solved", then?

Well.. ubuntu is keeping updated packages separately from "base install" versions,
so it's theoretically possible to figure out which package is responsible for your issues.
It could be the kernel driver, X11 driver, or some fancy-effects ubuntu app hogging VRAM (or anything else)

If you were really dedicated into locating the package responsible for the issues, you could downgrade back to 14.04 as released,
check that factorio works, selectively upgrade packages until the factorio breaks again.
Note that ubuntu is probably configured to install security updates (== any updated package that is marked as "carrying a security fix")
Some of the "base" versions thus may contain widely-known critical bugs.

PS: How often do you reboot? Could it be possible that you didn't reboot after the upgrade for a longer period of time?

It is not error of factorio update.

Blackence · Post by **Blackence** » Fri Jun 27, 2014 11:41 am

I actually fired up factorio on my Intel Box (very cheap Zotac product). It has an Ivy Bridge CPU and "Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09)" (integrated GPU). I'm not using Ubuntu on that box, it's Arch Linux, so latest stable mesa/kernel.

Factorio works, but is very slow (probably expected, according to timing stats a lot of time is spent "Flipping" though?). It also crashes(?not sure?) or gets OOM-killed (definitely) in the "load game" screen frequently. This box has 1,8GB of usable RAM and no swap, I guess there's only a few hundred MB free for factorio (it had jenkins and unity and probably firefox active at that time). Graphics were 100% correct AFAICT, and they even were high-res as opposed to my readeon desktop in 0.10.1. Another hint that integrated-with-CPU "Intel Core" graphics work better than old "Intel GMA" on-mainboard chips?

To debug this issue, maybe someone affected by this could use apitrace to trace what's going on. apitrace is in the ubuntu repos (seems a little outdated maybe, but works for me). "apitrace trace ./factorio" should start the game, then just load a game / start a new game to demonstrate the issue and exit the game. This will create a few hundred MB trace file. Be careful when distributing it, as it contains factorio textures, so strictly speaking you aren't allowed to distribute it. Maybe factorio devs allow this for debugging if we ask, just like Valve allows Phoronix to use traces for benchmarking. (As an example, I just extracted the atlas texture into a 43MB PNG file from my trace that seems to contain all of the factorio sprites in 16384*2472.) We can then use qapitrace to look at the trace and inspect each frame. It seems like it even allows to look at textures etc. I've never used it before, but looks like a nice tool (the GUI is a little strange). If you can get it to work, "VOGL" by valve might be worth a try, too.

Edit: Or maybe this is not such a good idea. apitrace probably just traces all of the commands sent to the GPU through OpenGL, and those are probably always the same, no matter what GPU/driver you use. So if the driver or your GPU corrupts some textures or fails to render them, we won't see it in the trace I guess. It might still be interesting to see if the same trace replays correctly on radeon, but shows missing graphics when replaying it on intel hardware. If so, submitting the trace to intel mesa developers could help them finding a fix.

MF- · Post by **MF-** » Fri Jun 27, 2014 4:29 pm

I thought VOGL is a specialized tool limited to the commands valve games are using.

Allright.. 11MB "wasted" on apitrace.
What exactly is in it's output, anyway? Just GL logs for the app?

MF- · Post by **MF-** » Sat Jun 28, 2014 6:05 am

Wait...
I thought ALL factorio textures are loaded during startup..
So.. won't the trace contain all textures and be giant?

MF- · Post by **MF-** » Sat Jun 28, 2014 8:36 am

I grabbed whatever I had lying on a shelf.
It was Factorio 0.8.8. x64

apitrace trace error output

qapitrace's "replay" feature replays exactly what I have seen.
No idea whether those are captured frames rendered by my card or those frames genuinely re-rendered again.

Errors subwindow after replay

the trace file is around 200M

EDIT: Final

Blackence · Post by **Blackence** » Sat Jun 28, 2014 11:41 am

As far as I can tell, the apitrace replay is not simply a captured video. It's really re-rendered from the trace file, as it contains all the textures/vertex data etc. and api calls that were used while capturing the trace.

The 11MB file is probably useless. I got a small trace when factorio crashed very early on in the loading process (due to the radeon bug). Just loading the main menu and quitting the game results in a very big trace file, more than 100MB even in low-res mode (as it contains all the textures in low-res).

That 200MB file sounds much better. When you replay the trace, do you see corrupted graphics? I'd like to replay the same trace on my radeon card to see if it works for me, but you'll probably need to ask someone from the factorio team for permission to share that file with me (and if it turns out to work for me, share it on the mesa bug tracker so Intel devs can hopefully take a look at it, or privately with an Intel dev at least).

Edit: Looking at my trace file, I notice there are loads of "glEnable(GL_BLEND); glBlendFuncSeparate(…); glBlendEquationSeparate(…);" each frame. I'm an OpenGL noob, but this seems like a ~once-per-frame setup thing? Is there any reason to do thousands of iterations? Or maybe it's just a glitch with apitrace? Anyway, it probably doesn't hurt performance too much because it's just a setup thing and no actual heavy processing takes place when doing this? Just makes the trace file hard to read.

MF- · Post by **MF-** » Sat Jun 28, 2014 7:47 pm

Yes, replay displays the same (=corrupt) as the game did (otherwise I wouldn't ask

)
Do you think that the trace SHOULD run on a better gpu? No intel-specific quirks by the library?

I also noticed that it seems that menu frames are repainted even when nothing changed.
Not important as-of-alpha IMO.

Colombo · Post by **Colombo** » Sun Jun 29, 2014 9:16 am

If I can somehow help (such as tracing it myself and send those files to you so you could compare), just ask.

Have you tried comparing this trace to normal trace?

Blackence · Post by **Blackence** » Sun Jun 29, 2014 11:05 am

MF- wrote:Do you think that the trace SHOULD run on a better gpu? No intel-specific quirks by the library?

I'm not sure I completely understand the way apitrace works, but currently I think: Yes, the trace should render correctly on a GPU for which the driver is "factorio compatible". Maybe you have access to both, a radeon/nvidia/modern intel *and* a broken Intel setup? If so, can you try replaying the intel trace on the compatible GPU? If it renders correctly, I think this is a valid candidate for the mesa bug tracker. It could still be a bug (incorrect OpenGL usage) in factorio/allegro library that has consequences on older Intel GPUs only, but since it works on most drivers and GPUs, hopefully the Intel developers can take a look at it.

Maybe I'm wrong and the trace is not "driver-agnostic" because it contains some parts that are generated by the driver itself, so the trace renders incorrectly on and hardware. In that case, maybe comparing traces from a good and bad driver (using the same savegame and same settings) can tell us where the problem is?

Colombo · Post by **Colombo** » Fri Jul 04, 2014 9:36 am

Post by **cube** » Sat Jul 12, 2014 9:44 am

I just found a computer on which I can replicate this! Moving to bug reports.

Post by **cube** » Sat Jul 12, 2014 10:12 am

... and we have a work around: In 0.10.3 there is a new config option max-texture-size in the [graphics] section of config.ini.
Setting it to 4096 helped in my case

Colombo · Post by **Colombo** » Sat Jul 12, 2014 2:36 pm

Great, it works!

Post by **slpwnd** » Mon Jul 14, 2014 1:13 pm

Awesome, one of the longest living issues finally getting some solution

MF- · Post by **MF-** » Sat Aug 02, 2014 8:42 am

AWESOME.
So the texture-size-override did the trick.

It also seems, that it indeed was possible to autodetect the corruption?

kovarex wrote:Hello,
Factorio 0.10.4 experimental bugfix release has just been released.

Bugfixes:

Added checks for validity of allocated bitmaps to work around a bug on some intel graphics cards on linux (https://forums.factorio.com/forum/vie ... f=7&t=1991)

I am surprised it's not mentioned here, though.
I guess noone report that it works because everyone affected is busy playing factorio now?

Sadly, I cannot check right now
+ I am really worried whether I'll like what's now called "factorio"

Did you figure out exactly which system library function returns the incorrect texture size?
Running unmodified older factorio version might be as simple as injecting a LD_PRELOAD, overriding that function.
(It might be easier on me to catch up slowly instead jumping straight from 0.7 to 0.10)

Factorio Forums

[Linux w Intel GPU][cube] Most of the graphics missing

Re: [Linux w Intel GPU] Most of the graphics missing

Re: [Linux w Intel GPU] Most of the graphics missing

Re: [Linux w Intel GPU] Most of the graphics missing

Re: [Linux w Intel GPU] Most of the graphics missing

Re: [Linux w Intel GPU] Most of the graphics missing

Re: [Linux w Intel GPU] Most of the graphics missing

Re: [Linux w Intel GPU] Most of the graphics missing

Re: [Linux w Intel GPU] Most of the graphics missing

Re: [Linux w Intel GPU] Most of the graphics missing

Re: [Linux w Intel GPU] Most of the graphics missing

Re: [Linux w Intel GPU] Most of the graphics missing

Re: [Linux w Intel GPU] Most of the graphics missing

Re: [Linux w Intel GPU] Most of the graphics missing

Re: [Linux w Intel GPU] Most of the graphics missing

Re: [Linux w Intel GPU] Most of the graphics missing

Re: [Linux w Intel GPU] Most of the graphics missing

Re: [Linux w Intel GPU] Most of the graphics missing

Re: [Linux w Intel GPU][cube] Most of the graphics missing

Re: [Linux w Intel GPU][cube] Most of the graphics missing

Re: [Linux w Intel GPU][cube] Most of the graphics missing