Using EGL_IMAGE_BRCM_MULTIMEDIA_U/V textures crashes Pi

[usedbytes]

Using the EGL_IMAGE_BRCM_MULTIMEDIA_Y image works fine, but using the U or V locks up the camera/application.

This can be easily reproduced with:

raspistill -t 10000 -g -gs yuv

Specifically, creating the EGLImageKHR works, but calling glEGLImageTargetTexture2DOES(GL_EXTERNAL_OES, {uimg/vimg}) seems to cause the lock up when rendering. Even if the U/V texture(s) are never bound/made active or used in the shader, it still crashes.

[usedbytes]

Anyone interested in this? I know v4l2 is "the future", but as-of-yet I don't think it has the same fast-path that we can get with MMAL.

[6by9]

It's not V4L2 that is really seen as the future but the DRM/KMS drivers.
Part of the problem is the lack of people with in depth knowledge of how the GL rendering is running the fast path. Tracing through it is not going to be a trivial task, although having just run it with the debugger it has immediately triggered an assert that can easily be fixed. Whether that will help the overall situation is a totally different question.

[usedbytes]

OK thanks. Given that raspistill includes this feature as one of the GL scene test cases, I think it was probably working at some point in the past (though I don't have a data point to prove it) - so I was hoping it was a fairly simple regression somewhere.

Anything I can do to assist debug?

[6by9]

You're in luck - fixing the trivial assert (it didn't know how to compute the pitch of the U8 and V8 images) means that it runs and gives 4 quadrants to the preview (Y, U, YUV, and V respectively). I'm assuming that is what it is meant to do. It was fortuitous that it was such a simple thing to reproduce.

I'll put the firmware patch into the system, and it should be in the next rpi-update release (and eventually the apt-get releases).

[usedbytes]

Great news! That sounds like what I expected to see.
Thanks very much. So I should watch here for a fix https://github.com/Hexxeh/rpi-firmware ?

[6by9]

Yes, watch https://github.com/Hexxeh/rpi-firmware.
I've tagged my commit with a reference to this issue, so assuming that is retained then it should all get linked together.

[6by9]

Release done, so sudo rpi-update should get you the fix as it stands (normal warnings to backup data first before using rpi-update).
Please test and close if you're happy.

If you get other weird behaviour then a simple test case makes it significantly more likely to get investigated :-)

[usedbytes]

Working for me now, thanks very much for fixing this!