14:42 <sarbes> Hi there. I have a question about MSAA.

14:42 <sarbes> I'm tinkering with MSAA in Kodi. It sort of works, but I'm getting pretty low frame rates. About half of what it would be with MSAA disabled. But I can't quite figure out what I'm doing wrong.

14:43 <sarbes> In my first attempt, I've just set the amount of samples when creating the EGL surface. This works on my desktop with GL and GLES, and on my Odroid C2. But on the latter, the framerate tanks. I suspect that the samples take a trip through main memory.

14:49 <sarbes> For my current attempt, I'm trying EXT_multisampled_render_to_texture. Here I create a FBO and render to it. On my desktop, I'm resolving this buffer via glBlitFramebuffer(), which is not available on GLES 2.0.

14:50 <sarbes> And from here, I'm unsure how to proceed. Could you give me some pointers?

14:54 <sarbes> Or is the performance loss to be expected? ARM brags about the "almost zero" cost of MSAA 4x, so I'm a bit skeptical about that.

16:43 <anarsoul> sarbes: it's zero when resolve is done in tile buffer, i.e. without full writeout

16:50 <anarsoul> sarbes: I think you need to draw a textured quad on gles 2.0

18:03 <sarbes> I'm not sure I can follow. I want the resolve to be happening in the tile buffer. Is there fixed function hardware for it?

18:04 <anarsoul> sarbes: use EXT_multisampled_render_to_texture then draw a textured quad

18:33 <sarbes> I'm sorry, but I don't see how I could be possibly be faster than the driver.

18:33 <sarbes> Quoting from the spec of FramebufferTexture2DMultisampleEXT():

18:34 <sarbes> "While the implicit multisample buffer is attached, color sample values are automatically resolved to a single color in the texture level each time a pixel is updated. This has the effect of making the antialiasing appear to be automatic at the application level."

18:34 <sarbes> That's almost what I want. Except for the default framebuffer, not FBOs.

18:39 <sarbes> According to ARM docs, MSAA for the default framebuffer is enabled via EGL config: https://developer.arm.com/documentation/ka005285/1-0/?lang=en. This is working with Lima, except it is too slow to be usable.

19:43 <anarsoul> sarbes: IIRC ARM driver is not compliant with the spec. Anyway, lima as a gallium driver does exactly what mesa asks for, this behavior is default for all the mesa drivers

19:44 <anarsoul> technically it's possible to do in-place resolve for default fb, but it's not implemented in mesa

19:44 <anarsoul> feel free to file an issue at https://gitlab.freedesktop.org/mesa/mesa/-/issues

19:45 <anarsoul> (however keep in mind that it won't be a lima change, it will be a behavior change for all the mesa drivers)

20:41 <sarbes> That's too bad. Unfortunately, this makes it unsuitable for my purpose.

20:42 <sarbes> Thanks for your time.

21:06 <anarsoul> sarbes: please file an issue at https://gitlab.freedesktop.org/mesa/mesa/-/issues

21:38 <sarbes> Will do. Is there something you would like me to put in the issue?

21:39 <sarbes> I recon this issue is applicable to all tiling GPUs?

22:06 <anarsoul> sarbes: to all the GPUs that support EXT_multisampled_render_to_texture

22:06 <anarsoul> I think what you want is in-place resolve for default fb in GLES2

22:07 <anarsoul> it's out of spec for desktop GL though

23:45 <sarbes> Roger.

23:45 <sarbes> Bye