I know there are some subtle differences between GL_EXT_framebuffer_object and GL_ARB_framebuffer_object but I expected apitrace to handle them both well.

Yes, please provide the trace and I'll try to look into it.

I know there are some subtle differences between GL_EXT_framebuffer_object and GL_ARB_framebuffer_object but I expected apitrace to handle them both well.

Yes, please provide the trace and I'll try to look into it.

Here's the trace. https://drive.google.com/file/d/1fI1354x17F-Sys_laRGd0TZuUdP0LX1A/view?usp=share_link

FBO state dumps seems to be working fine for me.

There's a single FBO, with a single depth stencil attachment, used for shadow maps. The first draw call that draws into it is no 214963, and when I dump the state at draw call 214963 it shows the depth stenctil:

Do you see differently?

This was with NVIDIA Linux GL driver. It's not impossible things vary with different GL drivers, as apitrace will take different code paths for drivers which don't support GL 3.0 not GL_ARB_framebuffer_object. But from what I can tell you're using a modern Mesa driver which supports both, so I don't see how possibly this could go wrong.

FBO state dumps seems to be working fine for me.

There's a single FBO, with a single depth stencil attachment, used for shadow maps. The first draw call that draws into it is no 214963, and when I dump the state at draw call 214963 it shows the depth stenctil:

Do you see differently?

This was with NVIDIA Linux GL driver. It's not impossible things vary with different GL drivers, as apitrace will take different code paths for drivers which don't support GL 3.0 not GL_ARB_framebuffer_object. But from what I can tell you're using a modern Mesa driver which supports both, so I don't see how possibly this could go wrong.

I'm indeed using a modern Mesa driver (mesa-git on amdgpu) so it could be a RadeonSI bug I suppose. I'll test apitrace elsewhere and see if it fails there too. I have a Linux laptop with Intel Graphics I can test on.