14:42sarbes: Hi there. I have a question about MSAA.
14:42sarbes: 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:43sarbes: 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:49sarbes: 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:50sarbes: And from here, I'm unsure how to proceed. Could you give me some pointers?
14:54sarbes: 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:43anarsoul: sarbes: it's zero when resolve is done in tile buffer, i.e. without full writeout
16:50anarsoul: sarbes: I think you need to draw a textured quad on gles 2.0
18:03sarbes: 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:04anarsoul: sarbes: use EXT_multisampled_render_to_texture then draw a textured quad
18:33sarbes: I'm sorry, but I don't see how I could be possibly be faster than the driver.
18:33sarbes: Quoting from the spec of FramebufferTexture2DMultisampleEXT():
18:34sarbes: "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:34sarbes: That's almost what I want. Except for the default framebuffer, not FBOs.
18:39sarbes: 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:43anarsoul: 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:44anarsoul: technically it's possible to do in-place resolve for default fb, but it's not implemented in mesa
19:44anarsoul: feel free to file an issue at https://gitlab.freedesktop.org/mesa/mesa/-/issues
19:45anarsoul: (however keep in mind that it won't be a lima change, it will be a behavior change for all the mesa drivers)
20:41sarbes: That's too bad. Unfortunately, this makes it unsuitable for my purpose.
20:42sarbes: Thanks for your time.
21:06anarsoul: sarbes: please file an issue at https://gitlab.freedesktop.org/mesa/mesa/-/issues
21:38sarbes: Will do. Is there something you would like me to put in the issue?
21:39sarbes: I recon this issue is applicable to all tiling GPUs?
22:06anarsoul: sarbes: to all the GPUs that support EXT_multisampled_render_to_texture
22:06anarsoul: I think what you want is in-place resolve for default fb in GLES2
22:07anarsoul: it's out of spec for desktop GL though
23:45sarbes: Roger.
23:45sarbes: Bye