GTX 1070 full-screen crash: Error creating framebuffer: FramebufferIncompleteAttachment

[lanroth]

When switching to full screen mode MHH crashes with the error Error creating framebuffer: FramebufferIncompleteAttachment.

Here's a debug log: mhh.log

Note the error doesn't appear in the log but it is written to the console.

Windows 10, GTX 1070

It works perfectly apart from this problem. It also works perfectly on several other PCs.

Thanks for your brilliant project. I've got it setup and running on 4 other PCs with large screens all being driven by SnapCast and Mopidy and it looks awesome.

[MV10]

Glad you're enjoying it. I'm curious how you found it.

I suspect the GTX 1070 doesn't support the pixel format used by the program, but I'll do some digging later this week.

I'll also look into the logging, it may be crashing out before the log file is updated (the threading in this thing is tricky).

[lanroth]

I found it while Googling around for Windows music visualisations which lead me to this post on Reddit. I'm hosting a party in a couple of weeks and wanted to setup a funky music room. Monkey Hi Hat seems perfect for my requirements :-)

Thanks for taking a look at this for me. For the record, it works full screen on the following hardware:

• GTX 4070
• Ryzen 3200G with Vega 8 built in GPU (some visualizations don't seem to work properly but most do)
• an ancient GTX 670
• Dell laptop with a GeForce 830M

[MV10]

I figured it was probably Reddit. I didn't have many good ideas about how to get people's attention to the project. To my surprise, a lot of Reddit subs deleted any mention of it, even when I replied to threads where people were asking for recommendations about programs like this. Which is typical of Reddit... anyway, glad it's getting used. In my house if we aren't watching a movie, it's pretty likely MHH is running instead.

The Ryzen issues don't surprise me, AMD drivers definitely have more problems than NVIDIA. I even mention it here in the wiki. If you have a list of those giving you trouble, I'd be interested in seeing that, too.

As for your 1070 issue, all I can say right now is that it isn't a problem with the pixel format, as I guessed earlier. I checked the specs and RGBA32F is a requirement for OpenGL 4.6. It'll be hard to guess what could be wrong without one to test with, but I'll certainly leave this open.

If the console shows a line before the error such as XXXX creating N resource groups for XXX, can you post a screenshot of the console output? This is an unrecoverable unmanaged resource allocation error so the "safest" thing to do is immediately end, which means any buffered log output never gets written to the file. In my next release I'll try forcing a log-flush before exit and maybe we'll get more details. Just before the framebuffer error is shown, the caller will have logged the resource group info I mentioned.

Notes for myself:
Console error: GLResourceManager.ValidateFramebuffer
Invoked by: GLResourceManager.CreateResourceGroups

[MV10]

By the way, since you have a lot of different hardware and you're planning to run this for a party (and nobody likes crashes or bugs!), I'll point out the --test commands, you can pretty quickly cycle through all the viz and FX files to make sure they work right.

mhh --test viz [file] will load and stay on one specific visualizer, and the +/- keys will cycle through the FX effects overlaid on that viz. You can see all the visualizer .conf filenames here (or in your local C:\ProgramData\mhh-content directory).

mhh --test fx [file] will load and stay on one specific effect, and the +/- keys will cycle through the visualizers with that FX applied. You can see all the FX .conf filenames here (or locally).

As the "test" switch name implies, I use this to test newly-written shaders with all the other content, but it'll work just as well for you to preview 100% of the content on your various machines.

[lanroth]

Thanks for getting back to me. I just checked and there is no more information in the console window:

.
.
.
[15:24:05 VRB] Program stage "idle.vert / passthrough.frag SetTexture": No uniform named "eyecandyShadertoy"; ignoring request.
[15:24:05 VRB] Program stage "idle.vert / passthrough.frag SetTexture": No uniform named "eyecandy4Channel"; ignoring request.
[15:24:05 VRB] Program stage "idle.vert / passthrough.frag SetTexture": No uniform named "eyecandyVolume"; ignoring request.
[15:24:05 VRB] Program stage "idle.vert / passthrough.frag SetUniform": No uniform named "randomseed"; ignoring request.
[15:24:05 VRB] Program stage "idle.vert / passthrough.frag SetUniform": No uniform named "randomnumber"; ignoring request.
[15:24:05 VRB] Program stage "idle.vert / passthrough.frag SetUniform": No uniform named "date"; ignoring request.
[15:24:05 VRB] Program stage "idle.vert / passthrough.frag SetUniform": No uniform named "clocktime"; ignoring request.
[15:24:05 VRB] Program stage "idle.vert / passthrough.frag SetUniform": No uniform named "frame"; ignoring request.
[15:24:05 VRB] Program stage "idle.vert / passthrough.frag SetUniform": No uniform named "randomrun"; ignoring request.
Error creating framebuffer: FramebufferIncompleteAttachment

C:\Program Files\mhh>

The Ryzen issues don't surprise me, AMD drivers definitely have more problems than NVIDIA... If you have a list of those giving you trouble, I'd be interested in seeing that, too.

I have decided not to use the Ryzen for the party but when I get time over Christmas I'll work out which ones are giving issues.

As to why more people don't know about this project - I don't know. It's pretty easy to get started with and you've provided lots of excellent documentation. It's a mystery to me!

Thanks for your help.

[MV10]

@lanroth if you're still out there, I'd be interested in seeing if the new error reporting / logging code in v4.3.1 sheds any light on your GTX 1070 issue. I spent a couple of days overhauling error handling and added a few additional bits of log output with your issue in mind.

Ideally set LogLevel=Trace in the config file (temporarily -- this will probably create a huge log file) then run your test and see if we get better error data in the log file. After that change it back to the default Warning log level to keep file size manageable.

[MV10]

In the version I will be releasing shortly (4.5.0) there is even more logging improvement. After an upgrade or fresh install, you will have the LogLevel setting mentioned above, but also LogCategories= MHH, Eyecandy.OpenGL. For troubleshooting, remove the OpenGL part so that we'll get all logging from the Eyecandy library. Once you've uploaded that log output, you can restore them to LogLevel=Warning and LogCategories= MHH, Eyecandy.OpenGL.

[lanroth]

Brilliant. Sorry for not getting round to grabbing some better logs. I will, I've just been very busy and the PC with the 1070 isn't currently wired in. Cheers.