Crash with SDL2's Metal renderer.

[tiessa]

Sometimes I receive the error:

-[MTLRenderPipelineDescriptorInternal validateWithDevice:]:2400: failed assertion `No valid pixelFormats set.'

And python crashes completely. How would you advise me helping to isolate the error?

[HexDecimal]

What is your OS? I assume it's some version of MacOS based on the error.

You can use python -m trace --trace my_script.py to get the last Python line before the crash.

Try setting the environment variable SDL_RENDER_DRIVER=software before starting the script. This will avoid using Metal for graphics rendering and should at least give you a different error.

[tiessa]

Mac OS 10.13.4

I'll add those when I run my program and when it dies again (if it does), I'll update this thread.

[tiessa]

SDL_RENDER_DRIVER=software

Seems to have solved it - instead of crashing every 5 times I ran it, it hasn't crashed in days.

Thank you!

[HexDecimal]

I don't think I'll be able to reproduce this since it might only be a problem with SDL2 and Metal. This could be from SDL2's Metal support being fairly new, but I don't know much about it.

I'd be nice if you checked other SDL2 programs to see if the same issue happens. Python-tcod is currently on SDL2.0.10. Metal support was added in SDL2.0.8.

[tiessa]

I don't think you will able to reproduce it either. I tried any number of things to narrow it down, but couldn't figure out the trigger. I wish I could have and made your life easier.

I'm mainly thinking it might be something to put in the docs as a faq, "if you're having crashing problems on the mac, try..."

I don't know of any other SDL programs that I use, I'm sorry otherwise I would.

One way or the other, thank you for picking up the support for tcod and improving it! Your work is appreciated.

[tiessa]

One more thing, before using the SDL software renderer, it would take a second sometimes to update a screen of about 80x40 characters and otherwise run at about 17 ms for an update of a smaller part of it. Now, it doesn't have the big pause and consistently hits <4 ms for an update.

I think SDL support for metal has a long way to go before its a useable alternative.

[HexDecimal]

Don't worry about it if you can't pinpoint what the cause is.

I think MacOS still supports OpenGL, so SDL_RENDER_DRIVER=opengl should give better performance (assuming tcod's renderer is set to tcod.RENDERER_SDL2.) There's also tcod.RENDERER_OPENGL2, but that's slightly less cross-platform.

[tiessa]

I played with the various renderers with the sample program - one of the OpenGL ones just outright crashed every time. I think it was OpenGL2 even, which seemed strange to me, going with the theory that everything new is better :D

I didn't realize I could specify the SDL renderer separate from the tcod one. I went and set SDL_RENDER_DRIVER=opengl right now and it went back to the 17ms and crashed.

[HexDecimal]

Closing this as the issues are more with SDL and MacOS hardware than with Python-tcod, and the workarounds are known.

Python-tcod keeps up with the latest version of SDL, so it's possible this was fixed by one of the newer versions. Anyone still having this issue can try the SDL_RENDER_DRIVER=software hint as a last resort workaround. This hint can be set from Python with os.environ["SDL_RENDER_DRIVER"] = "software" before initializing the libtcod context or touching SDL initialization.

Other options for SDL_RENDER_DRIVER are documented here.